From 33a35848c727f088922a7d6fd7400c7db0c20814 Mon Sep 17 00:00:00 2001 From: l4check Date: Sun, 18 Aug 2013 14:45:55 +0000 Subject: [PATCH] update: sync git-svn-id: http://svn.tudos.org/repos/oc/tudos/trunk@57 d050ee49-bd90-4346-b210-929a50b99cfc --- kernel/fiasco/src/kern/mp_lock.cpp | 182 - kernel/fiasco/src/kern/obj_ref_ptr.cpp | 44 - kernel/fiasco/src/kern/ref_ptr.cpp | 70 - l4/pkg/libsdl/contrib/Borland.zip | Bin 157899 -> 0 bytes l4/pkg/libsdl/contrib/README.CVS | 4 - l4/pkg/libsdl/contrib/README.SVN | 23 - l4/pkg/libsdl/contrib/VisualC.zip | Bin 43373 -> 0 bytes l4/pkg/libsdl/contrib/VisualCE.zip | Bin 56390 -> 0 bytes l4/pkg/libsdl/contrib/Watcom-OS2.zip | Bin 63088 -> 0 bytes l4/pkg/libsdl/contrib/Watcom-Win32.zip | Bin 3709 -> 0 bytes .../src/joystick/darwin/10.3.9-FIX/IOHIDLib.h | 874 - .../src/joystick/os2/SDL_sysjoystick.c | 668 - .../libsdl/contrib/src/joystick/os2/joyos2.h | 177 - l4/pkg/libsdl/contrib/symbian.zip | Bin 378899 -> 0 bytes .../include/bits/gthr-posix.h | 897 - .../include/bits/gthr-single.h | 294 - l4/pkg/libstdc++-headers/include/bits/gthr.h | 176 - .../contrib/libstdc++-v3-4.4/doc/Makefile.am | 235 - .../contrib/libstdc++-v3-4.4/doc/Makefile.in | 661 - .../libstdc++-v3-4.4/doc/doxygen/Intro.3 | 132 - .../contrib/libstdc++-v3-4.4/doc/doxygen/TODO | 70 - .../doc/doxygen/doxygroups.cc | 158 - .../doc/doxygen/mainpage.html | 108 - .../libstdc++-v3-4.4/doc/doxygen/stdheader.cc | 171 - .../libstdc++-v3-4.4/doc/doxygen/tables.html | 644 - .../libstdc++-v3-4.4/doc/doxygen/user.cfg.in | 1711 - .../contrib/libstdc++-v3-4.4/doc/html/README | 3 - .../libstdc++-v3-4.4/doc/html/api.html | 54 - .../libstdc++-v3-4.4/doc/html/bk02.html | 3 - .../libstdc++-v3-4.4/doc/html/bk03.html | 3 - .../doc/html/ext/lwg-active.html | 19718 ---- .../doc/html/ext/lwg-closed.html | 14016 --- .../doc/html/ext/lwg-defects.html | 29778 ------ .../doc/html/ext/pb_ds/PythonPoweredSmall.gif | Bin 361 -> 0 bytes .../doc/html/ext/pb_ds/acks.html | 65 - .../html/ext/pb_ds/assoc_container_tag_cd.png | Bin 21668 -> 0 bytes .../html/ext/pb_ds/assoc_container_tag_cd.svg | 491 - .../ext/pb_ds/assoc_container_traits.html | 170 - .../doc/html/ext/pb_ds/assoc_design.html | 46 - .../doc/html/ext/pb_ds/assoc_examples.html | 151 - .../ext/pb_ds/assoc_performance_tests.html | 345 - .../ext/pb_ds/assoc_regression_tests.html | 93 - .../doc/html/ext/pb_ds/assoc_tests.html | 24 - .../ext/pb_ds/associative_container_tag.html | 47 - .../doc/html/ext/pb_ds/balls_and_bins.png | Bin 10139 -> 0 bytes .../doc/html/ext/pb_ds/basic_hash_table.html | 436 - .../doc/html/ext/pb_ds/basic_hash_tag.html | 47 - .../pb_ds/basic_invalidation_guarantee.html | 26 - .../doc/html/ext/pb_ds/basic_tree.html | 660 - ...e_assoc_container_const_node_iterator.html | 383 - .../doc/html/ext/pb_ds/basic_tree_tag.html | 47 - .../doc/html/ext/pb_ds/binary_heap_tag.html | 47 - ..._queue_random_int_push_timing_test_gcc.png | Bin 5357 -> 0 bytes ...ueue_random_int_push_timing_test_local.png | Bin 6710 -> 0 bytes ...queue_random_int_push_timing_test_msvc.png | Bin 5373 -> 0 bytes .../doc/html/ext/pb_ds/binomial_heap_tag.html | 47 - ...sh_max_collision_check_resize_trigger.html | 532 - ...c_hash_random_int_find_timing_test_gcc.png | Bin 7074 -> 0 bytes ...hash_random_int_find_timing_test_local.png | Bin 8534 -> 0 bytes ..._hash_random_int_find_timing_test_msvc.png | Bin 7235 -> 0 bytes ...dom_int_subscript_timing_test_find_gcc.png | Bin 6811 -> 0 bytes ...m_int_subscript_timing_test_find_local.png | Bin 8445 -> 0 bytes ...om_int_subscript_timing_test_find_msvc.png | Bin 7230 -> 0 bytes ...m_int_subscript_timing_test_insert_gcc.png | Bin 7636 -> 0 bytes ...int_subscript_timing_test_insert_local.png | Bin 9396 -> 0 bytes ..._int_subscript_timing_test_insert_msvc.png | Bin 6840 -> 0 bytes .../doc/html/ext/pb_ds/cc_hash_table.html | 724 - .../doc/html/ext/pb_ds/cc_hash_tag.html | 47 - ...m_int_subscript_timing_test_insert_gcc.png | Bin 7355 -> 0 bytes ...int_subscript_timing_test_insert_local.png | Bin 9557 -> 0 bytes ..._int_subscript_timing_test_insert_msvc.png | Bin 7572 -> 0 bytes .../doc/html/ext/pb_ds/checked_by_tidy.gif | Bin 1367 -> 0 bytes .../doc/html/ext/pb_ds/concepts.html | 118 - .../doc/html/ext/pb_ds/contact.html | 22 - .../doc/html/ext/pb_ds/container_base.html | 1063 - .../doc/html/ext/pb_ds/container_cd.png | Bin 11884 -> 0 bytes .../doc/html/ext/pb_ds/container_cd.svg | 418 - .../doc/html/ext/pb_ds/container_tag.html | 24 - .../doc/html/ext/pb_ds/counter_lu_policy.html | 259 - .../doc/html/ext/pb_ds/design.html | 96 - .../ext/pb_ds/different_underlying_dss.png | Bin 31858 -> 0 bytes .../ext/pb_ds/direct_mask_range_hashing.html | 167 - .../ext/pb_ds/direct_mod_range_hashing.html | 144 - .../doc/html/ext/pb_ds/disclaimer.html | 34 - .../doc/html/ext/pb_ds/ds_gen.html | 344 - .../doc/html/ext/pb_ds/embedded_lists_1.png | Bin 16350 -> 0 bytes .../doc/html/ext/pb_ds/embedded_lists_2.png | Bin 18206 -> 0 bytes .../doc/html/ext/pb_ds/embedded_lists_3.png | Bin 5612 -> 0 bytes .../doc/html/ext/pb_ds/examples.html | 24 - .../doc/html/ext/pb_ds/exceptions.html | 46 - ...p_hash_random_int_find_timing_test_gcc.png | Bin 6194 -> 0 bytes ...hash_random_int_find_timing_test_local.png | Bin 7916 -> 0 bytes ..._hash_random_int_find_timing_test_msvc.png | Bin 6140 -> 0 bytes ...dom_int_subscript_timing_test_find_gcc.png | Bin 6110 -> 0 bytes ...m_int_subscript_timing_test_find_local.png | Bin 7570 -> 0 bytes ...om_int_subscript_timing_test_find_msvc.png | Bin 6314 -> 0 bytes ...m_int_subscript_timing_test_insert_gcc.png | Bin 6763 -> 0 bytes ...int_subscript_timing_test_insert_local.png | Bin 8499 -> 0 bytes ..._int_subscript_timing_test_insert_msvc.png | Bin 6721 -> 0 bytes .../doc/html/ext/pb_ds/gp_hash_table.html | 891 - .../doc/html/ext/pb_ds/gp_hash_tag.html | 47 - .../html/ext/pb_ds/hash_based_containers.html | 835 - .../pb_ds/hash_exponential_size_policy.html | 183 - .../pb_ds/hash_load_check_resize_trigger.html | 583 - .../doc/html/ext/pb_ds/hash_policy_cd.png | Bin 25302 -> 0 bytes .../ext/pb_ds/hash_prime_size_policy.html | 149 - .../hash_random_int_erase_mem_usage_test.html | 173 - ...sh_random_int_erase_mem_usage_test_gcc.png | Bin 6356 -> 0 bytes ..._random_int_erase_mem_usage_test_local.png | Bin 7405 -> 0 bytes ...h_random_int_erase_mem_usage_test_msvc.png | Bin 6401 -> 0 bytes ...hash_random_int_find_find_timing_test.html | 247 - ...random_int_subscript_find_timing_test.html | 220 - ...ndom_int_subscript_insert_timing_test.html | 365 - .../pb_ds/hash_range_hashing_seq_diagram.png | Bin 12962 -> 0 bytes .../pb_ds/hash_range_hashing_seq_diagram2.png | Bin 8918 -> 0 bytes .../hash_ranged_hash_range_hashing_fns.png | Bin 19773 -> 0 bytes .../pb_ds/hash_standard_resize_policy.html | 795 - .../hash_text_find_find_timing_test.html | 164 - ...zlob_random_int_find_find_timing_test.html | 163 - ...h_zlob_random_int_find_timing_test_gcc.png | Bin 6910 -> 0 bytes ...zlob_random_int_find_timing_test_local.png | Bin 8436 -> 0 bytes ..._zlob_random_int_find_timing_test_msvc.png | Bin 7204 -> 0 bytes .../doc/html/ext/pb_ds/index.html | 146 - .../doc/html/ext/pb_ds/insert_error.html | 53 - .../pb_ds/insert_resize_sequence_diagram1.png | Bin 25834 -> 0 bytes .../pb_ds/insert_resize_sequence_diagram2.png | Bin 25522 -> 0 bytes .../pb_ds/insert_resize_sequence_diagram3.png | Bin 24542 -> 0 bytes .../doc/html/ext/pb_ds/interface.html | 446 - .../doc/html/ext/pb_ds/introduction.html | 120 - .../ext/pb_ds/invalidation_guarantee_cd.png | Bin 8331 -> 0 bytes .../pb_ds/invalidation_guarantee_erase.png | Bin 25884 -> 0 bytes .../doc/html/ext/pb_ds/join_error.html | 48 - .../doc/html/ext/pb_ds/linear_probe_fn.html | 140 - .../doc/html/ext/pb_ds/list_update.html | 316 - .../doc/html/ext/pb_ds/list_update_tag.html | 47 - .../doc/html/ext/pb_ds/lu.png | Bin 20987 -> 0 bytes .../html/ext/pb_ds/lu_based_containers.html | 229 - .../doc/html/ext/pb_ds/misc.html | 26 - .../doc/html/ext/pb_ds/motivation.html | 993 - .../ext/pb_ds/move_to_front_lu_policy.html | 194 - .../multimap_text_find_timing_test_large.html | 215 - ...xt_find_timing_test_large_s2p_hash_gcc.png | Bin 6323 -> 0 bytes ..._find_timing_test_large_s2p_hash_local.png | Bin 7299 -> 0 bytes ...t_find_timing_test_large_s2p_hash_msvc.png | Bin 6490 -> 0 bytes ...xt_find_timing_test_large_s2p_tree_gcc.png | Bin 6284 -> 0 bytes ..._find_timing_test_large_s2p_tree_local.png | Bin 6706 -> 0 bytes ...t_find_timing_test_large_s2p_tree_msvc.png | Bin 6204 -> 0 bytes .../multimap_text_find_timing_test_small.html | 215 - ...xt_find_timing_test_small_s2p_hash_gcc.png | Bin 6237 -> 0 bytes ..._find_timing_test_small_s2p_hash_local.png | Bin 6732 -> 0 bytes ...t_find_timing_test_small_s2p_hash_msvc.png | Bin 6268 -> 0 bytes ...xt_find_timing_test_small_s2p_tree_gcc.png | Bin 6064 -> 0 bytes ..._find_timing_test_small_s2p_tree_local.png | Bin 6396 -> 0 bytes ...t_find_timing_test_small_s2p_tree_msvc.png | Bin 6012 -> 0 bytes ...imap_text_insert_mem_usage_test_large.html | 210 - ...sert_mem_usage_test_large_s2p_hash_gcc.png | Bin 6835 -> 0 bytes ...rt_mem_usage_test_large_s2p_hash_local.png | Bin 7275 -> 0 bytes ...ert_mem_usage_test_large_s2p_hash_msvc.png | Bin 6588 -> 0 bytes ...sert_mem_usage_test_large_s2p_tree_gcc.png | Bin 6778 -> 0 bytes ...rt_mem_usage_test_large_s2p_tree_local.png | Bin 7191 -> 0 bytes ...ert_mem_usage_test_large_s2p_tree_msvc.png | Bin 6535 -> 0 bytes ...imap_text_insert_mem_usage_test_small.html | 212 - ...sert_mem_usage_test_small_s2p_hash_gcc.png | Bin 6449 -> 0 bytes ...rt_mem_usage_test_small_s2p_hash_local.png | Bin 6845 -> 0 bytes ...ert_mem_usage_test_small_s2p_hash_msvc.png | Bin 6570 -> 0 bytes ...sert_mem_usage_test_small_s2p_tree_gcc.png | Bin 6419 -> 0 bytes ...rt_mem_usage_test_small_s2p_tree_local.png | Bin 6925 -> 0 bytes ...ert_mem_usage_test_small_s2p_tree_msvc.png | Bin 6569 -> 0 bytes ...ultimap_text_insert_timing_test_large.html | 212 - ..._insert_timing_test_large_s2p_hash_gcc.png | Bin 6380 -> 0 bytes ...nsert_timing_test_large_s2p_hash_local.png | Bin 7000 -> 0 bytes ...insert_timing_test_large_s2p_hash_msvc.png | Bin 6460 -> 0 bytes ..._insert_timing_test_large_s2p_tree_gcc.png | Bin 6204 -> 0 bytes ...nsert_timing_test_large_s2p_tree_local.png | Bin 6764 -> 0 bytes ...insert_timing_test_large_s2p_tree_msvc.png | Bin 6357 -> 0 bytes ...ultimap_text_insert_timing_test_small.html | 217 - ..._insert_timing_test_small_s2p_hash_gcc.png | Bin 6456 -> 0 bytes ...nsert_timing_test_small_s2p_hash_local.png | Bin 7035 -> 0 bytes ...insert_timing_test_small_s2p_hash_msvc.png | Bin 6547 -> 0 bytes ..._insert_timing_test_small_s2p_tree_gcc.png | Bin 6111 -> 0 bytes ...nsert_timing_test_small_s2p_tree_local.png | Bin 6853 -> 0 bytes ...insert_timing_test_small_s2p_tree_msvc.png | Bin 6430 -> 0 bytes .../pb_ds/node_invariant_invalidations.png | Bin 32276 -> 0 bytes .../doc/html/ext/pb_ds/node_invariants.png | Bin 16553 -> 0 bytes .../doc/html/ext/pb_ds/null_hash_fn.html | 32 - .../doc/html/ext/pb_ds/null_lu_metadata.html | 25 - .../doc/html/ext/pb_ds/null_mapped_type.html | 25 - .../doc/html/ext/pb_ds/null_probe_fn.html | 29 - .../html/ext/pb_ds/null_tree_node_update.html | 101 - .../html/ext/pb_ds/null_trie_node_update.html | 102 - .../doc/html/ext/pb_ds/ov_tree_tag.html | 47 - .../doc/html/ext/pb_ds/pairing_heap_tag.html | 47 - ...ty_queue_text_push_pop_timing_test_gcc.png | Bin 5395 -> 0 bytes ..._queue_text_push_pop_timing_test_local.png | Bin 6892 -> 0 bytes ...y_queue_text_push_pop_timing_test_msvc.png | Bin 5514 -> 0 bytes ...iority_queue_text_push_timing_test_gcc.png | Bin 5678 -> 0 bytes ...rity_queue_text_push_timing_test_local.png | Bin 6760 -> 0 bytes ...ority_queue_text_push_timing_test_msvc.png | Bin 5878 -> 0 bytes .../doc/html/ext/pb_ds/pat_trie.png | Bin 26182 -> 0 bytes .../doc/html/ext/pb_ds/pat_trie_tag.html | 47 - .../pb_ds/point_invalidation_guarantee.html | 51 - .../doc/html/ext/pb_ds/point_iterators_cd.png | Bin 20307 -> 0 bytes .../ext/pb_ds/point_iterators_range_ops_1.png | Bin 14206 -> 0 bytes .../ext/pb_ds/point_iterators_range_ops_2.png | Bin 12876 -> 0 bytes .../html/ext/pb_ds/pq_container_traits.html | 132 - .../doc/html/ext/pb_ds/pq_design.html | 381 - .../ext/pb_ds/pq_different_underlying_dss.png | Bin 15660 -> 0 bytes .../doc/html/ext/pb_ds/pq_examples.html | 54 - .../html/ext/pb_ds/pq_performance_tests.html | 332 - .../html/ext/pb_ds/pq_regression_tests.html | 52 - .../doc/html/ext/pb_ds/pq_tests.html | 24 - .../doc/html/ext/pb_ds/prerequisites.html | 46 - .../doc/html/ext/pb_ds/priority_queue.html | 995 - ...queue_random_int_push_pop_timing_test.html | 161 - ...ue_random_int_push_pop_timing_test_gcc.png | Bin 7350 -> 0 bytes ..._random_int_push_pop_timing_test_local.png | Bin 9275 -> 0 bytes ...e_random_int_push_pop_timing_test_msvc.png | Bin 7065 -> 0 bytes ...ity_queue_random_int_push_timing_test.html | 200 - ..._queue_random_int_push_timing_test_gcc.png | Bin 7021 -> 0 bytes ...ueue_random_int_push_timing_test_local.png | Bin 8986 -> 0 bytes ...queue_random_int_push_timing_test_msvc.png | Bin 7100 -> 0 bytes .../html/ext/pb_ds/priority_queue_tag.html | 47 - .../html/ext/pb_ds/priority_queue_tag_cd.png | Bin 10845 -> 0 bytes .../html/ext/pb_ds/priority_queue_tag_cd.svg | 368 - .../priority_queue_text_join_timing_test.html | 141 - ...iority_queue_text_join_timing_test_gcc.png | Bin 6458 -> 0 bytes ...rity_queue_text_join_timing_test_local.png | Bin 7989 -> 0 bytes ...ority_queue_text_join_timing_test_msvc.png | Bin 6461 -> 0 bytes ...ty_queue_text_modify_down_timing_test.html | 204 - ...queue_text_modify_down_timing_test_gcc.png | Bin 6788 -> 0 bytes ...eue_text_modify_down_timing_test_local.png | Bin 7633 -> 0 bytes ...ueue_text_modify_down_timing_test_msvc.png | Bin 6956 -> 0 bytes ...dify_down_timing_test_pairing_thin_gcc.png | Bin 5007 -> 0 bytes ...fy_down_timing_test_pairing_thin_local.png | Bin 5878 -> 0 bytes ...ify_down_timing_test_pairing_thin_msvc.png | Bin 4996 -> 0 bytes ...rity_queue_text_modify_up_timing_test.html | 222 - ...y_queue_text_modify_up_timing_test_gcc.png | Bin 6950 -> 0 bytes ...queue_text_modify_up_timing_test_local.png | Bin 7748 -> 0 bytes ..._queue_text_modify_up_timing_test_msvc.png | Bin 6983 -> 0 bytes ...modify_up_timing_test_pairing_thin_gcc.png | Bin 4867 -> 0 bytes ...dify_up_timing_test_pairing_thin_local.png | Bin 6105 -> 0 bytes ...odify_up_timing_test_pairing_thin_msvc.png | Bin 5216 -> 0 bytes ...riority_queue_text_pop_mem_usage_test.html | 143 - ...rity_queue_text_pop_mem_usage_test_gcc.png | Bin 6582 -> 0 bytes ...ty_queue_text_pop_mem_usage_test_local.png | Bin 7424 -> 0 bytes ...ity_queue_text_pop_mem_usage_test_msvc.png | Bin 6849 -> 0 bytes ...ority_queue_text_push_pop_timing_test.html | 209 - ...ty_queue_text_push_pop_timing_test_gcc.png | Bin 7072 -> 0 bytes ..._queue_text_push_pop_timing_test_local.png | Bin 9006 -> 0 bytes ...y_queue_text_push_pop_timing_test_msvc.png | Bin 7289 -> 0 bytes .../priority_queue_text_push_timing_test.html | 219 - ...iority_queue_text_push_timing_test_gcc.png | Bin 6832 -> 0 bytes ...rity_queue_text_push_timing_test_local.png | Bin 8477 -> 0 bytes ...ority_queue_text_push_timing_test_msvc.png | Bin 7266 -> 0 bytes .../html/ext/pb_ds/quadratic_probe_fn.html | 141 - ...dom_int_find_find_timing_test_tree_gcc.png | Bin 5960 -> 0 bytes ...m_int_find_find_timing_test_tree_local.png | Bin 7377 -> 0 bytes ...om_int_find_find_timing_test_tree_msvc.png | Bin 5636 -> 0 bytes .../pb_ds/range_invalidation_guarantee.html | 52 - .../ext/pb_ds/rationale_null_node_updator.png | Bin 25097 -> 0 bytes .../doc/html/ext/pb_ds/rb_tree_tag.html | 47 - .../html/ext/pb_ds/rc_binomial_heap_tag.html | 47 - .../doc/html/ext/pb_ds/references.html | 258 - .../doc/html/ext/pb_ds/resize_error.html | 50 - .../doc/html/ext/pb_ds/resize_policy_cd.png | Bin 20806 -> 0 bytes .../ext/pb_ds/restoring_node_invariants.png | Bin 14432 -> 0 bytes .../doc/html/ext/pb_ds/sample_probe_fn.html | 152 - .../html/ext/pb_ds/sample_range_hashing.html | 172 - .../html/ext/pb_ds/sample_ranged_hash_fn.html | 171 - .../ext/pb_ds/sample_ranged_probe_fn.html | 178 - .../html/ext/pb_ds/sample_resize_policy.html | 413 - .../html/ext/pb_ds/sample_resize_trigger.html | 462 - .../html/ext/pb_ds/sample_size_policy.html | 163 - .../ext/pb_ds/sample_tree_node_update.html | 193 - .../pb_ds/sample_trie_e_access_traits.html | 231 - .../ext/pb_ds/sample_trie_node_update.html | 194 - .../html/ext/pb_ds/sample_update_policy.html | 178 - .../doc/html/ext/pb_ds/simple_list.png | Bin 4299 -> 0 bytes .../doc/html/ext/pb_ds/splay_tree_tag.html | 47 - .../pb_ds/string_trie_e_access_traits.html | 400 - .../doc/html/ext/pb_ds/tests.html | 24 - .../pb_ds/text_find_timing_test_hash_gcc.png | Bin 7013 -> 0 bytes .../text_find_timing_test_hash_local.png | Bin 9361 -> 0 bytes .../pb_ds/text_find_timing_test_hash_msvc.png | Bin 6932 -> 0 bytes .../text_find_timing_test_tree_like_gcc.png | Bin 6207 -> 0 bytes .../text_find_timing_test_tree_like_local.png | Bin 7650 -> 0 bytes .../text_find_timing_test_tree_like_msvc.png | Bin 6059 -> 0 bytes .../doc/html/ext/pb_ds/thin_heap_tag.html | 47 - .../doc/html/ext/pb_ds/tree.html | 516 - .../html/ext/pb_ds/tree_based_containers.html | 358 - .../html/ext/pb_ds/tree_node_iterator.html | 143 - .../ext/pb_ds/tree_node_updator_policy_cd.png | Bin 9236 -> 0 bytes .../tree_order_statistics_node_update.html | 678 - .../tree_order_statistics_timing_test.html | 118 - .../tree_order_statistics_timing_test_gcc.png | Bin 5698 -> 0 bytes ...ree_order_statistics_timing_test_local.png | Bin 6739 -> 0 bytes ...tree_order_statistics_timing_test_msvc.png | Bin 5684 -> 0 bytes ...tree_random_int_find_find_timing_test.html | 160 - .../pb_ds/tree_split_join_timing_test.html | 143 - .../pb_ds/tree_split_join_timing_test_gcc.png | Bin 5649 -> 0 bytes .../tree_split_join_timing_test_local.png | Bin 6734 -> 0 bytes .../tree_split_join_timing_test_msvc.png | Bin 5675 -> 0 bytes .../doc/html/ext/pb_ds/tree_tag.html | 47 - .../tree_text_find_find_timing_test.html | 162 - .../pb_ds/tree_text_insert_timing_test.html | 226 - ..._text_insert_timing_test_node_tree_gcc.png | Bin 5373 -> 0 bytes ...ext_insert_timing_test_node_tree_local.png | Bin 6690 -> 0 bytes ...text_insert_timing_test_node_tree_msvc.png | Bin 5212 -> 0 bytes ...e_text_insert_timing_test_pat_trie_gcc.png | Bin 4895 -> 0 bytes ...text_insert_timing_test_pat_trie_local.png | Bin 6011 -> 0 bytes ..._text_insert_timing_test_pat_trie_msvc.png | Bin 4881 -> 0 bytes ...ext_insert_timing_test_vector_tree_gcc.png | Bin 5140 -> 0 bytes ...t_insert_timing_test_vector_tree_local.png | Bin 6270 -> 0 bytes ...xt_insert_timing_test_vector_tree_msvc.png | Bin 5131 -> 0 bytes .../tree_text_lor_find_find_timing_test.html | 126 - .../tree_text_lor_find_timing_test_gcc.png | Bin 6162 -> 0 bytes .../tree_text_lor_find_timing_test_local.png | Bin 7796 -> 0 bytes .../tree_text_lor_find_timing_test_msvc.png | Bin 5831 -> 0 bytes .../doc/html/ext/pb_ds/trie.html | 489 - .../html/ext/pb_ds/trie_based_containers.html | 241 - .../ext/pb_ds/trie_const_node_iterator.html | 478 - .../html/ext/pb_ds/trie_node_iterator.html | 235 - .../ext/pb_ds/trie_node_updator_policy_cd.png | Bin 12126 -> 0 bytes .../trie_order_statistics_node_update.html | 770 - .../pb_ds/trie_prefix_search_node_update.html | 628 - .../doc/html/ext/pb_ds/trie_tag.html | 47 - .../html/ext/pb_ds/trivial_iterator_tag.html | 25 - .../doc/html/ext/pb_ds/tutorial.html | 670 - .../doc/html/ext/pb_ds/update_policy_cd.png | Bin 8570 -> 0 bytes .../doc/html/ext/pb_ds/update_seq_diagram.png | Bin 10789 -> 0 bytes .../libstdc++-v3-4.4/doc/html/faq.html | 874 - .../libstdc++-v3-4.4/doc/html/index.html | 43 - .../libstdc++-v3-4.4/doc/html/manual/abi.html | 521 - .../doc/html/manual/algorithms.html | 9 - .../libstdc++-v3-4.4/doc/html/manual/api.html | 154 - .../html/manual/appendix_contributing.html | 113 - .../doc/html/manual/appendix_free.html | 124 - .../doc/html/manual/appendix_gfdl.html | 395 - .../doc/html/manual/appendix_gpl.html | 681 - .../doc/html/manual/appendix_porting.html | 230 - .../doc/html/manual/associative.html | 87 - .../doc/html/manual/auto_ptr.html | 90 - .../doc/html/manual/backwards.html | 932 - .../doc/html/manual/bitmap_allocator.html | 340 - .../doc/html/manual/bitset.html | 105 - .../doc/html/manual/bk01ix01.html | 48 - .../doc/html/manual/bk01pt02ch04s02.html | 49 - .../doc/html/manual/bk01pt02ch04s03.html | 29 - .../doc/html/manual/bk01pt02pr01.html | 17 - .../doc/html/manual/bk01pt03ch07s02.html | 20 - .../doc/html/manual/bk01pt03ch07s03.html | 4 - .../doc/html/manual/bk01pt03ch08.html | 45 - .../doc/html/manual/bk01pt05ch13.html | 95 - .../doc/html/manual/bk01pt05ch13s02.html | 40 - .../doc/html/manual/bk01pt05ch13s03.html | 57 - .../doc/html/manual/bk01pt05ch13s04.html | 85 - .../doc/html/manual/bk01pt05ch13s05.html | 15 - .../doc/html/manual/bk01pt05ch13s06.html | 94 - .../doc/html/manual/bk01pt08ch19.html | 36 - .../doc/html/manual/bk01pt08ch19s02.html | 86 - .../doc/html/manual/bk01pt09ch20.html | 19 - .../doc/html/manual/bk01pt09pr02.html | 41 - .../doc/html/manual/bk01pt10ch23s02.html | 19 - .../doc/html/manual/bk01pt11ch25s02.html | 77 - .../doc/html/manual/bk01pt11ch27s02.html | 95 - .../doc/html/manual/bk01pt11ch27s03.html | 22 - .../doc/html/manual/bk01pt11ch28s02.html | 49 - .../doc/html/manual/bk01pt12ch30s02.html | 55 - .../doc/html/manual/bk01pt12ch30s03.html | 24 - .../doc/html/manual/bk01pt12ch30s04.html | 409 - .../doc/html/manual/bk01pt12ch31s02.html | 11 - .../doc/html/manual/bk01pt12ch31s03.html | 66 - .../doc/html/manual/bk01pt12ch31s04.html | 213 - .../doc/html/manual/bk01pt12ch31s05.html | 26 - .../doc/html/manual/bk01pt12ch33s02.html | 43 - .../doc/html/manual/bk01pt12ch33s03.html | 50 - .../doc/html/manual/bk01pt12ch40s02.html | 41 - .../doc/html/manual/bk01pt12ch40s03.html | 37 - .../doc/html/manual/bk01pt12pr03.html | 27 - .../doc/html/manual/bugs.html | 330 - .../doc/html/manual/codecvt.html | 379 - .../doc/html/manual/complex.html | 25 - .../doc/html/manual/configure.html | 201 - .../doc/html/manual/containers.html | 9 - .../doc/html/manual/containers_and_c.html | 66 - .../doc/html/manual/debug.html | 152 - .../doc/html/manual/debug_mode.html | 37 - .../doc/html/manual/diagnostics.html | 9 - .../doc/html/manual/documentation_style.html | 230 - .../doc/html/manual/dynamic_memory.html | 69 - .../doc/html/manual/exceptions.html | 22 - .../doc/html/manual/ext_algorithms.html | 23 - .../doc/html/manual/ext_allocators.html | 397 - .../doc/html/manual/ext_compile_checks.html | 40 - .../doc/html/manual/ext_concurrency.html | 91 - .../doc/html/manual/ext_containers.html | 9 - .../doc/html/manual/ext_demangling.html | 74 - .../doc/html/manual/ext_io.html | 51 - .../doc/html/manual/ext_iterators.html | 14 - .../doc/html/manual/ext_numerics.html | 20 - .../doc/html/manual/ext_utilities.html | 41 - .../doc/html/manual/extensions.html | 9 - .../doc/html/manual/facets.html | 77 - .../doc/html/manual/fstreams.html | 52 - .../doc/html/manual/functors.html | 15 - .../doc/html/manual/fundamental_types.html | 43 - .../generalized_numeric_operations.html | 29 - .../doc/html/manual/internals.html | 374 - .../doc/html/manual/intro.html | 9 - .../libstdc++-v3-4.4/doc/html/manual/io.html | 9 - .../doc/html/manual/io_and_c.html | 11 - .../doc/html/manual/iostream_objects.html | 119 - .../doc/html/manual/iterators.html | 9 - .../doc/html/manual/license.html | 105 - .../doc/html/manual/locales.html | 428 - .../doc/html/manual/localization.html | 9 - .../doc/html/manual/make.html | 9 - .../doc/html/manual/memory.html | 349 - .../doc/html/manual/messages.html | 284 - .../doc/html/manual/numerics.html | 9 - .../doc/html/manual/numerics_and_c.html | 21 - .../doc/html/manual/pairs.html | 42 - .../doc/html/manual/parallel_mode.html | 24 - .../doc/html/manual/sequences.html | 43 - .../doc/html/manual/setup.html | 101 - .../doc/html/manual/shared_ptr.html | 304 - .../doc/html/manual/source_code_style.html | 588 - .../doc/html/manual/source_design_notes.html | 863 - .../doc/html/manual/source_organization.html | 97 - .../doc/html/manual/spine.html | 57 - .../doc/html/manual/status.html | 237 - .../doc/html/manual/streambufs.html | 60 - .../doc/html/manual/strings.html | 9 - .../doc/html/manual/stringstreams.html | 37 - .../doc/html/manual/support.html | 9 - .../doc/html/manual/termination.html | 48 - .../doc/html/manual/test.html | 489 - .../doc/html/manual/traits.html | 10 - .../doc/html/manual/using.html | 44 - .../doc/html/manual/using_concurrency.html | 219 - .../doc/html/manual/using_exceptions.html | 6 - .../doc/html/manual/using_headers.html | 101 - .../doc/html/manual/using_macros.html | 70 - .../doc/html/manual/using_namespaces.html | 61 - .../doc/html/manual/utilities.html | 9 - .../doc/html/manual/vector.html | 16 - .../doc/html/manual/verbose_termination.html | 79 - .../libstdc++-v3-4.4/doc/html/spine.html | 52 - .../contrib/libstdc++-v3-4.4/doc/xml/api.xml | 106 - .../libstdc++-v3-4.4/doc/xml/authors.xml | 184 - .../libstdc++-v3-4.4/doc/xml/book.txml | 33 - .../libstdc++-v3-4.4/doc/xml/chapter.txml | 54 - .../libstdc++-v3-4.4/doc/xml/class.txml | 154 - .../contrib/libstdc++-v3-4.4/doc/xml/faq.xml | 1255 - .../libstdc++-v3-4.4/doc/xml/gnu/fdl-1.2.xml | 503 - .../libstdc++-v3-4.4/doc/xml/gnu/gpl-2.0.xml | 366 - .../libstdc++-v3-4.4/doc/xml/gnu/gpl-3.0.xml | 837 - .../doc/xml/images/confdeps.dot | 14 - .../doc/xml/images/confdeps.png | Bin 3486 -> 0 bytes .../libstdc++-v3-4.4/doc/xml/manual/abi.xml | 1189 - .../doc/xml/manual/algorithms.xml | 107 - .../doc/xml/manual/allocator.xml | 659 - .../doc/xml/manual/appendix_contributing.xml | 2250 - .../doc/xml/manual/appendix_free.xml | 182 - .../doc/xml/manual/appendix_porting.xml | 53 - .../doc/xml/manual/auto_ptr.xml | 133 - .../xml/manual/backwards_compatibility.xml | 1315 - .../doc/xml/manual/bitmap_allocator.xml | 559 - .../doc/xml/manual/build_hacking.xml | 354 - .../doc/xml/manual/codecvt.xml | 730 - .../doc/xml/manual/concurrency.xml | 337 - .../doc/xml/manual/configure.xml | 348 - .../doc/xml/manual/containers.xml | 450 - .../libstdc++-v3-4.4/doc/xml/manual/ctype.xml | 259 - .../libstdc++-v3-4.4/doc/xml/manual/debug.xml | 246 - .../doc/xml/manual/debug_mode.xml | 888 - .../doc/xml/manual/diagnostics.xml | 130 - .../doc/xml/manual/evolution.xml | 452 - .../doc/xml/manual/extensions.xml | 589 - .../doc/xml/manual/internals.xml | 548 - .../libstdc++-v3-4.4/doc/xml/manual/intro.xml | 854 - .../libstdc++-v3-4.4/doc/xml/manual/io.xml | 673 - .../doc/xml/manual/iterators.xml | 180 - .../doc/xml/manual/locale.xml | 652 - .../doc/xml/manual/localization.xml | 59 - .../doc/xml/manual/messages.xml | 604 - .../doc/xml/manual/mt_allocator.xml | 554 - .../doc/xml/manual/numerics.xml | 149 - .../doc/xml/manual/parallel_mode.xml | 896 - .../doc/xml/manual/prerequisites.xml | 158 - .../doc/xml/manual/shared_ptr.xml | 580 - .../libstdc++-v3-4.4/doc/xml/manual/spine.xml | 114 - .../doc/xml/manual/status_cxx1998.xml | 1162 - .../doc/xml/manual/status_cxx200x.xml | 2572 - .../doc/xml/manual/status_cxxtr1.xml | 1782 - .../doc/xml/manual/strings.xml | 498 - .../doc/xml/manual/support.xml | 455 - .../libstdc++-v3-4.4/doc/xml/manual/test.xml | 804 - .../libstdc++-v3-4.4/doc/xml/manual/using.xml | 1297 - .../doc/xml/manual/utilities.xml | 131 - .../libstdc++-v3-4.4/doc/xml/spine.xml | 47 - .../contrib/libstdc++-v3-4.7/doc/Makefile.am | 633 - .../contrib/libstdc++-v3-4.7/doc/Makefile.in | 995 - .../libstdc++-v3-4.7/doc/doxygen/Intro.3 | 132 - .../doc/doxygen/doxygroups.cc | 158 - .../doc/doxygen/mainpage.html | 108 - .../libstdc++-v3-4.7/doc/doxygen/stdheader.cc | 171 - .../libstdc++-v3-4.7/doc/doxygen/tables.html | 644 - .../libstdc++-v3-4.7/doc/doxygen/user.cfg.in | 1990 - .../contrib/libstdc++-v3-4.7/doc/html/README | 3 - .../libstdc++-v3-4.7/doc/html/api.html | 59 - .../libstdc++-v3-4.7/doc/html/bk02.html | 3 - .../libstdc++-v3-4.7/doc/html/bk03.html | 3 - .../doc/html/ext/lwg-active.html | 8074 -- .../doc/html/ext/lwg-closed.html | 51135 ---------- .../doc/html/ext/lwg-defects.html | 83797 ---------------- .../libstdc++-v3-4.7/doc/html/faq.html | 872 - .../doc/html/images/confdeps.png | Bin 20653 -> 0 bytes .../doc/html/images/pbds_balls_and_bins.png | Bin 10139 -> 0 bytes .../pbds_binary_priority_queue_int_push.png | Bin 32915 -> 0 bytes ...bds_binary_priority_queue_int_push_pop.png | Bin 33264 -> 0 bytes .../doc/html/images/pbds_cc_hash_int_find.png | Bin 66803 -> 0 bytes .../pbds_cc_hash_int_subscript_find.png | Bin 67129 -> 0 bytes .../pbds_cc_hash_int_subscript_insert.png | Bin 67625 -> 0 bytes .../pbds_ccgp_hash_int_subscript_insert.png | Bin 64083 -> 0 bytes .../images/pbds_container_tag_hierarchy.png | Bin 85192 -> 0 bytes .../pbds_different_underlying_dss_1.png | Bin 31858 -> 0 bytes .../pbds_different_underlying_dss_2.png | Bin 15660 -> 0 bytes .../doc/html/images/pbds_embedded_lists_1.png | Bin 16350 -> 0 bytes .../doc/html/images/pbds_embedded_lists_2.png | Bin 18206 -> 0 bytes .../doc/html/images/pbds_embedded_lists_3.png | Bin 5612 -> 0 bytes .../html/images/pbds_exception_hierarchy.png | Bin 18245 -> 0 bytes .../doc/html/images/pbds_gp_hash_int_find.png | Bin 46447 -> 0 bytes .../pbds_gp_hash_int_subscript_find.png | Bin 47232 -> 0 bytes .../pbds_gp_hash_int_subscript_insert.png | Bin 49697 -> 0 bytes .../html/images/pbds_hash_int_erase_mem.png | Bin 48012 -> 0 bytes .../doc/html/images/pbds_hash_policy_cd.png | Bin 25302 -> 0 bytes .../pbds_hash_range_hashing_seq_diagram.png | Bin 12962 -> 0 bytes .../pbds_hash_range_hashing_seq_diagram2.png | Bin 8918 -> 0 bytes ...bds_hash_ranged_hash_range_hashing_fns.png | Bin 19773 -> 0 bytes .../doc/html/images/pbds_hash_text_find.png | Bin 57070 -> 0 bytes .../html/images/pbds_hash_zlob_int_find.png | Bin 53858 -> 0 bytes .../pbds_insert_resize_sequence_diagram1.png | Bin 25834 -> 0 bytes .../pbds_insert_resize_sequence_diagram2.png | Bin 25522 -> 0 bytes .../pbds_insert_resize_sequence_diagram3.png | Bin 24542 -> 0 bytes .../pbds_invalidation_guarantee_erase.png | Bin 25884 -> 0 bytes .../pbds_invalidation_tag_hierarchy.png | Bin 14178 -> 0 bytes .../doc/html/images/pbds_list_update.png | Bin 20987 -> 0 bytes ...pbds_multimap_text_find_large_s2p_hash.png | Bin 45704 -> 0 bytes ...pbds_multimap_text_find_large_s2p_tree.png | Bin 37835 -> 0 bytes ...pbds_multimap_text_find_small_s2p_hash.png | Bin 44996 -> 0 bytes ...pbds_multimap_text_find_small_s2p_tree.png | Bin 37341 -> 0 bytes ...ds_multimap_text_insert_large_s2p_hash.png | Bin 46498 -> 0 bytes ...ds_multimap_text_insert_large_s2p_tree.png | Bin 37488 -> 0 bytes ...ultimap_text_insert_mem_large_s2p_hash.png | Bin 49055 -> 0 bytes ...ultimap_text_insert_mem_large_s2p_tree.png | Bin 41256 -> 0 bytes ...ultimap_text_insert_mem_small_s2p_hash.png | Bin 48026 -> 0 bytes ...ultimap_text_insert_mem_small_s2p_tree.png | Bin 40541 -> 0 bytes ...ds_multimap_text_insert_small_s2p_hash.png | Bin 47330 -> 0 bytes ...ds_multimap_text_insert_small_s2p_tree.png | Bin 38337 -> 0 bytes .../doc/html/images/pbds_node_invariants.png | Bin 16553 -> 0 bytes ...g_priority_queue_text_modify_down_thin.png | Bin 25795 -> 0 bytes ...ing_priority_queue_text_modify_up_thin.png | Bin 26470 -> 0 bytes .../pbds_pairing_priority_queue_text_push.png | Bin 35873 -> 0 bytes ...s_pairing_priority_queue_text_push_pop.png | Bin 34785 -> 0 bytes .../doc/html/images/pbds_pat_trie.png | Bin 26182 -> 0 bytes .../images/pbds_point_iterator_hierarchy.png | Bin 20307 -> 0 bytes .../pbds_point_iterators_range_ops_1.png | Bin 14206 -> 0 bytes .../pbds_point_iterators_range_ops_2.png | Bin 12876 -> 0 bytes ...riority_queue_different_underlying_dss.png | Bin 15660 -> 0 bytes .../images/pbds_priority_queue_int_push.png | Bin 44300 -> 0 bytes .../pbds_priority_queue_int_push_pop.png | Bin 47243 -> 0 bytes .../pbds_priority_queue_tag_hierarchy.png | Bin 29346 -> 0 bytes .../images/pbds_priority_queue_text_join.png | Bin 49521 -> 0 bytes .../pbds_priority_queue_text_modify_down.png | Bin 45433 -> 0 bytes .../pbds_priority_queue_text_modify_up.png | Bin 44676 -> 0 bytes .../pbds_priority_queue_text_pop_mem.png | Bin 44599 -> 0 bytes .../images/pbds_priority_queue_text_push.png | Bin 43555 -> 0 bytes .../pbds_priority_queue_text_push_pop.png | Bin 44314 -> 0 bytes .../pbds_rationale_null_node_updator.png | Bin 25097 -> 0 bytes .../doc/html/images/pbds_resize_policy_cd.png | Bin 20806 -> 0 bytes .../images/pbds_restoring_node_invariants.png | Bin 14432 -> 0 bytes .../doc/html/images/pbds_simple_list.png | Bin 4299 -> 0 bytes .../doc/html/images/pbds_tree_int_find.png | Bin 37647 -> 0 bytes .../images/pbds_tree_node_invalidations.png | Bin 32276 -> 0 bytes .../html/images/pbds_tree_node_invariants.png | Bin 16553 -> 0 bytes .../pbds_tree_node_updator_policy_cd.png | Bin 9236 -> 0 bytes .../images/pbds_tree_order_statistics.png | Bin 36565 -> 0 bytes .../doc/html/images/pbds_tree_split_join.png | Bin 38092 -> 0 bytes .../doc/html/images/pbds_tree_text_find.png | Bin 43323 -> 0 bytes .../images/pbds_tree_text_insert_node.png | Bin 35682 -> 0 bytes .../images/pbds_tree_text_insert_trie.png | Bin 28044 -> 0 bytes .../images/pbds_tree_text_insert_vector.png | Bin 28291 -> 0 bytes .../html/images/pbds_tree_text_lor_find.png | Bin 43242 -> 0 bytes .../pbds_trie_node_updator_policy_cd.png | Bin 12126 -> 0 bytes .../html/images/pbds_update_seq_diagram.png | Bin 10789 -> 0 bytes .../libstdc++-v3-4.7/doc/html/index.html | 168 - .../libstdc++-v3-4.7/doc/html/manual/abi.html | 536 - .../doc/html/manual/algorithms.html | 61 - .../libstdc++-v3-4.7/doc/html/manual/api.html | 240 - .../html/manual/appendix_contributing.html | 116 - .../doc/html/manual/appendix_free.html | 126 - .../doc/html/manual/appendix_gfdl.html | 449 - .../doc/html/manual/appendix_gpl.html | 683 - .../doc/html/manual/appendix_porting.html | 252 - .../doc/html/manual/associative.html | 192 - .../doc/html/manual/atomics.html | 31 - .../doc/html/manual/backwards.html | 959 - .../doc/html/manual/bitmap_allocator.html | 33 - .../doc/html/manual/bk01pt02.html | 46 - .../doc/html/manual/bk01pt02ch05s02.html | 50 - .../doc/html/manual/bk01pt03ch17s02.html | 55 - .../doc/html/manual/bk01pt03ch17s03.html | 24 - .../doc/html/manual/bk01pt03ch17s04.html | 412 - .../doc/html/manual/bk01pt03ch18s02.html | 11 - .../doc/html/manual/bk01pt03ch18s03.html | 66 - .../doc/html/manual/bk01pt03ch18s04.html | 213 - .../doc/html/manual/bk01pt03ch18s05.html | 26 - .../doc/html/manual/bk01pt03ch19s02.html | 122 - .../doc/html/manual/bk01pt03ch19s03.html | 10 - .../doc/html/manual/bk01pt03ch19s04.html | 18 - .../doc/html/manual/bk01pt03ch19s05.html | 51 - .../doc/html/manual/bk01pt03ch19s06.html | 68 - .../doc/html/manual/bk01pt03ch19s07.html | 558 - .../doc/html/manual/bk01pt03ch20s02.html | 39 - .../doc/html/manual/bk01pt03ch20s03.html | 161 - .../doc/html/manual/bk01pt03ch20s04.html | 79 - .../doc/html/manual/bk01pt03ch20s05.html | 107 - .../doc/html/manual/bk01pt03ch21s02.html | 313 - .../doc/html/manual/bk01pt03ch23s02.html | 59 - .../doc/html/manual/bk01pt03ch30s02.html | 45 - .../doc/html/manual/bk01pt03ch30s03.html | 36 - .../doc/html/manual/bk01pt03pr01.html | 27 - .../doc/html/manual/bk01pt04.html | 43 - .../doc/html/manual/bugs.html | 352 - .../doc/html/manual/concurrency.html | 42 - .../doc/html/manual/configure.html | 214 - .../doc/html/manual/containers.html | 55 - .../doc/html/manual/containers_and_c.html | 90 - .../doc/html/manual/debug.html | 241 - .../doc/html/manual/debug_mode.html | 38 - .../doc/html/manual/diagnostics.html | 43 - .../html/manual/documentation_hacking.html | 444 - .../doc/html/manual/dynamic_memory.html | 72 - .../doc/html/manual/ext_algorithms.html | 23 - .../doc/html/manual/ext_compile_checks.html | 40 - .../doc/html/manual/ext_concurrency.html | 94 - .../doc/html/manual/ext_containers.html | 42 - .../doc/html/manual/ext_demangling.html | 74 - .../doc/html/manual/ext_io.html | 45 - .../doc/html/manual/ext_iterators.html | 14 - .../doc/html/manual/ext_numerics.html | 24 - .../doc/html/manual/ext_utilities.html | 42 - .../doc/html/manual/extensions.html | 74 - .../doc/html/manual/facets.html | 737 - .../doc/html/manual/fstreams.html | 150 - .../generalized_numeric_operations.html | 32 - .../doc/html/manual/index.html | 166 - .../doc/html/manual/internals.html | 368 - .../doc/html/manual/intro.html | 9 - .../libstdc++-v3-4.7/doc/html/manual/io.html | 121 - .../doc/html/manual/io_and_c.html | 57 - .../doc/html/manual/iterators.html | 130 - .../doc/html/manual/license.html | 105 - .../doc/html/manual/localization.html | 437 - .../doc/html/manual/make.html | 9 - .../doc/html/manual/memory.html | 684 - .../doc/html/manual/mt_allocator.html | 23 - .../doc/html/manual/numerics.html | 30 - .../doc/html/manual/numerics_and_c.html | 37 - .../doc/html/manual/pairs.html | 44 - .../doc/html/manual/parallel_mode.html | 24 - .../policy_based_data_structures_test.html | 3813 - .../html/manual/policy_data_structures.html | 1312 - .../manual/policy_data_structures_biblio.html | 29 - .../manual/policy_data_structures_design.html | 1430 - .../manual/policy_data_structures_using.html | 483 - .../doc/html/manual/profile_mode.html | 146 - .../doc/html/manual/setup.html | 93 - .../doc/html/manual/source_code_style.html | 620 - .../doc/html/manual/source_design_notes.html | 863 - .../doc/html/manual/source_organization.html | 97 - .../doc/html/manual/status.html | 337 - .../doc/html/manual/streambufs.html | 137 - .../doc/html/manual/strings.html | 366 - .../doc/html/manual/stringstreams.html | 37 - .../doc/html/manual/support.html | 130 - .../doc/html/manual/termination.html | 124 - .../doc/html/manual/test.html | 639 - .../doc/html/manual/traits.html | 10 - .../doc/html/manual/using.html | 15 - .../doc/html/manual/using_concurrency.html | 272 - .../html/manual/using_dynamic_or_shared.html | 109 - .../doc/html/manual/using_exceptions.html | 314 - .../doc/html/manual/using_headers.html | 103 - .../doc/html/manual/using_macros.html | 77 - .../doc/html/manual/using_namespaces.html | 61 - .../doc/html/manual/utilities.html | 17 - .../contrib/libstdc++-v3-4.7/doc/xml/api.xml | 112 - .../libstdc++-v3-4.7/doc/xml/authors.xml | 120 - .../libstdc++-v3-4.7/doc/xml/book.txml | 30 - .../libstdc++-v3-4.7/doc/xml/chapter.txml | 51 - .../libstdc++-v3-4.7/doc/xml/class.txml | 165 - .../contrib/libstdc++-v3-4.7/doc/xml/faq.xml | 1247 - .../libstdc++-v3-4.7/doc/xml/gnu/fdl-1.3.xml | 562 - .../libstdc++-v3-4.7/doc/xml/gnu/gpl-3.0.xml | 834 - .../doc/xml/images/confdeps.dot | 16 - .../doc/xml/images/confdeps.pdf | Bin 50629 -> 0 bytes .../doc/xml/images/confdeps.png | Bin 20653 -> 0 bytes .../doc/xml/images/pbds_balls_and_bins.png | Bin 10139 -> 0 bytes .../pbds_binary_priority_queue_int_push.pdf | Bin 81428 -> 0 bytes .../pbds_binary_priority_queue_int_push.png | Bin 32915 -> 0 bytes .../pbds_binary_priority_queue_int_push.svg | 442 - ...bds_binary_priority_queue_int_push_pop.pdf | Bin 81328 -> 0 bytes ...bds_binary_priority_queue_int_push_pop.png | Bin 33264 -> 0 bytes ...bds_binary_priority_queue_int_push_pop.svg | 442 - .../doc/xml/images/pbds_cc_hash_int_find.pdf | Bin 90172 -> 0 bytes .../doc/xml/images/pbds_cc_hash_int_find.png | Bin 66803 -> 0 bytes .../doc/xml/images/pbds_cc_hash_int_find.svg | 593 - .../pbds_cc_hash_int_subscript_find.pdf | Bin 90040 -> 0 bytes .../pbds_cc_hash_int_subscript_find.png | Bin 67129 -> 0 bytes .../pbds_cc_hash_int_subscript_find.svg | 593 - .../pbds_cc_hash_int_subscript_insert.pdf | Bin 90196 -> 0 bytes .../pbds_cc_hash_int_subscript_insert.png | Bin 67625 -> 0 bytes .../pbds_cc_hash_int_subscript_insert.svg | 594 - .../pbds_ccgp_hash_int_subscript_insert.pdf | Bin 77608 -> 0 bytes .../pbds_ccgp_hash_int_subscript_insert.png | Bin 64083 -> 0 bytes .../pbds_ccgp_hash_int_subscript_insert.svg | 402 - .../images/pbds_container_tag_hierarchy.pdf | Bin 9605 -> 0 bytes .../images/pbds_container_tag_hierarchy.png | Bin 85192 -> 0 bytes .../images/pbds_container_tag_hierarchy.svg | 256 - .../pbds_different_underlying_dss_1.png | Bin 31858 -> 0 bytes .../pbds_different_underlying_dss_2.png | Bin 15660 -> 0 bytes .../doc/xml/images/pbds_embedded_lists_1.png | Bin 16350 -> 0 bytes .../doc/xml/images/pbds_embedded_lists_2.png | Bin 18206 -> 0 bytes .../doc/xml/images/pbds_embedded_lists_3.png | Bin 5612 -> 0 bytes .../xml/images/pbds_exception_hierarchy.pdf | Bin 7520 -> 0 bytes .../xml/images/pbds_exception_hierarchy.png | Bin 18245 -> 0 bytes .../xml/images/pbds_exception_hierarchy.svg | 76 - .../doc/xml/images/pbds_gp_hash_int_find.pdf | Bin 76134 -> 0 bytes .../doc/xml/images/pbds_gp_hash_int_find.png | Bin 46447 -> 0 bytes .../doc/xml/images/pbds_gp_hash_int_find.svg | 365 - .../pbds_gp_hash_int_subscript_find.pdf | Bin 76225 -> 0 bytes .../pbds_gp_hash_int_subscript_find.png | Bin 47232 -> 0 bytes .../pbds_gp_hash_int_subscript_find.svg | 365 - .../pbds_gp_hash_int_subscript_insert.pdf | Bin 76238 -> 0 bytes .../pbds_gp_hash_int_subscript_insert.png | Bin 49697 -> 0 bytes .../pbds_gp_hash_int_subscript_insert.svg | 365 - .../xml/images/pbds_hash_int_erase_mem.pdf | Bin 77175 -> 0 bytes .../xml/images/pbds_hash_int_erase_mem.png | Bin 48012 -> 0 bytes .../xml/images/pbds_hash_int_erase_mem.svg | 412 - .../doc/xml/images/pbds_hash_policy_cd.png | Bin 25302 -> 0 bytes .../pbds_hash_range_hashing_seq_diagram.png | Bin 12962 -> 0 bytes .../pbds_hash_range_hashing_seq_diagram2.png | Bin 8918 -> 0 bytes ...bds_hash_ranged_hash_range_hashing_fns.png | Bin 19773 -> 0 bytes .../doc/xml/images/pbds_hash_text_find.pdf | Bin 83353 -> 0 bytes .../doc/xml/images/pbds_hash_text_find.png | Bin 57070 -> 0 bytes .../doc/xml/images/pbds_hash_text_find.svg | 479 - .../xml/images/pbds_hash_zlob_int_find.pdf | Bin 89031 -> 0 bytes .../xml/images/pbds_hash_zlob_int_find.png | Bin 53858 -> 0 bytes .../xml/images/pbds_hash_zlob_int_find.svg | 552 - .../pbds_insert_resize_sequence_diagram1.png | Bin 25834 -> 0 bytes .../pbds_insert_resize_sequence_diagram2.png | Bin 25522 -> 0 bytes .../pbds_insert_resize_sequence_diagram3.png | Bin 24542 -> 0 bytes .../pbds_invalidation_guarantee_erase.png | Bin 25884 -> 0 bytes .../pbds_invalidation_tag_hierarchy.pdf | Bin 6903 -> 0 bytes .../pbds_invalidation_tag_hierarchy.png | Bin 14178 -> 0 bytes .../pbds_invalidation_tag_hierarchy.svg | 40 - .../doc/xml/images/pbds_list_update.png | Bin 20987 -> 0 bytes ...pbds_multimap_text_find_large_s2p_hash.pdf | Bin 67642 -> 0 bytes ...pbds_multimap_text_find_large_s2p_hash.png | Bin 45704 -> 0 bytes ...pbds_multimap_text_find_large_s2p_hash.svg | 235 - ...pbds_multimap_text_find_large_s2p_tree.pdf | Bin 70583 -> 0 bytes ...pbds_multimap_text_find_large_s2p_tree.png | Bin 37835 -> 0 bytes ...pbds_multimap_text_find_large_s2p_tree.svg | 277 - ...pbds_multimap_text_find_small_s2p_hash.pdf | Bin 67623 -> 0 bytes ...pbds_multimap_text_find_small_s2p_hash.png | Bin 44996 -> 0 bytes ...pbds_multimap_text_find_small_s2p_hash.svg | 235 - ...pbds_multimap_text_find_small_s2p_tree.pdf | Bin 70942 -> 0 bytes ...pbds_multimap_text_find_small_s2p_tree.png | Bin 37341 -> 0 bytes ...pbds_multimap_text_find_small_s2p_tree.svg | 277 - ...ds_multimap_text_insert_large_s2p_hash.pdf | Bin 67457 -> 0 bytes ...ds_multimap_text_insert_large_s2p_hash.png | Bin 46498 -> 0 bytes ...ds_multimap_text_insert_large_s2p_hash.svg | 235 - ...ds_multimap_text_insert_large_s2p_tree.pdf | Bin 70759 -> 0 bytes ...ds_multimap_text_insert_large_s2p_tree.png | Bin 37488 -> 0 bytes ...ds_multimap_text_insert_large_s2p_tree.svg | 277 - ...ultimap_text_insert_mem_large_s2p_hash.pdf | Bin 67786 -> 0 bytes ...ultimap_text_insert_mem_large_s2p_hash.png | Bin 49055 -> 0 bytes ...ultimap_text_insert_mem_large_s2p_hash.svg | 240 - ...ultimap_text_insert_mem_large_s2p_tree.pdf | Bin 70776 -> 0 bytes ...ultimap_text_insert_mem_large_s2p_tree.png | Bin 41256 -> 0 bytes ...ultimap_text_insert_mem_large_s2p_tree.svg | 282 - ...ultimap_text_insert_mem_small_s2p_hash.pdf | Bin 67808 -> 0 bytes ...ultimap_text_insert_mem_small_s2p_hash.png | Bin 48026 -> 0 bytes ...ultimap_text_insert_mem_small_s2p_hash.svg | 249 - ...ultimap_text_insert_mem_small_s2p_tree.pdf | Bin 70972 -> 0 bytes ...ultimap_text_insert_mem_small_s2p_tree.png | Bin 40541 -> 0 bytes ...ultimap_text_insert_mem_small_s2p_tree.svg | 291 - ...ds_multimap_text_insert_small_s2p_hash.pdf | Bin 67656 -> 0 bytes ...ds_multimap_text_insert_small_s2p_hash.png | Bin 47330 -> 0 bytes ...ds_multimap_text_insert_small_s2p_hash.svg | 235 - ...ds_multimap_text_insert_small_s2p_tree.pdf | Bin 70738 -> 0 bytes ...ds_multimap_text_insert_small_s2p_tree.png | Bin 38337 -> 0 bytes ...ds_multimap_text_insert_small_s2p_tree.svg | 277 - .../doc/xml/images/pbds_node_invariants.png | Bin 16553 -> 0 bytes ...g_priority_queue_text_modify_down_thin.pdf | Bin 68294 -> 0 bytes ...g_priority_queue_text_modify_down_thin.png | Bin 25795 -> 0 bytes ...g_priority_queue_text_modify_down_thin.svg | 251 - ...ing_priority_queue_text_modify_up_thin.pdf | Bin 68500 -> 0 bytes ...ing_priority_queue_text_modify_up_thin.png | Bin 26470 -> 0 bytes ...ing_priority_queue_text_modify_up_thin.svg | 252 - .../pbds_pairing_priority_queue_text_push.pdf | Bin 82821 -> 0 bytes .../pbds_pairing_priority_queue_text_push.png | Bin 35873 -> 0 bytes .../pbds_pairing_priority_queue_text_push.svg | 475 - ...s_pairing_priority_queue_text_push_pop.pdf | Bin 75989 -> 0 bytes ...s_pairing_priority_queue_text_push_pop.png | Bin 34785 -> 0 bytes ...s_pairing_priority_queue_text_push_pop.svg | 365 - .../doc/xml/images/pbds_pat_trie.png | Bin 26182 -> 0 bytes .../images/pbds_point_iterator_hierarchy.png | Bin 20307 -> 0 bytes .../pbds_point_iterators_range_ops_1.png | Bin 14206 -> 0 bytes .../pbds_point_iterators_range_ops_2.png | Bin 12876 -> 0 bytes ...riority_queue_different_underlying_dss.png | Bin 15660 -> 0 bytes .../images/pbds_priority_queue_int_push.pdf | Bin 103791 -> 0 bytes .../images/pbds_priority_queue_int_push.png | Bin 44300 -> 0 bytes .../images/pbds_priority_queue_int_push.svg | 821 - .../pbds_priority_queue_int_push_pop.pdf | Bin 103910 -> 0 bytes .../pbds_priority_queue_int_push_pop.png | Bin 47243 -> 0 bytes .../pbds_priority_queue_int_push_pop.svg | 821 - .../pbds_priority_queue_tag_hierarchy.pdf | Bin 7842 -> 0 bytes .../pbds_priority_queue_tag_hierarchy.png | Bin 29346 -> 0 bytes .../pbds_priority_queue_tag_hierarchy.svg | 88 - .../images/pbds_priority_queue_text_join.pdf | Bin 103511 -> 0 bytes .../images/pbds_priority_queue_text_join.png | Bin 49521 -> 0 bytes .../images/pbds_priority_queue_text_join.svg | 817 - .../pbds_priority_queue_text_modify_down.pdf | Bin 103701 -> 0 bytes .../pbds_priority_queue_text_modify_down.png | Bin 45433 -> 0 bytes .../pbds_priority_queue_text_modify_down.svg | 821 - .../pbds_priority_queue_text_modify_up.pdf | Bin 103554 -> 0 bytes .../pbds_priority_queue_text_modify_up.png | Bin 44676 -> 0 bytes .../pbds_priority_queue_text_modify_up.svg | 821 - .../pbds_priority_queue_text_pop_mem.pdf | Bin 102962 -> 0 bytes .../pbds_priority_queue_text_pop_mem.png | Bin 44599 -> 0 bytes .../pbds_priority_queue_text_pop_mem.svg | 831 - .../images/pbds_priority_queue_text_push.pdf | Bin 103249 -> 0 bytes .../images/pbds_priority_queue_text_push.png | Bin 43555 -> 0 bytes .../images/pbds_priority_queue_text_push.svg | 821 - .../pbds_priority_queue_text_push_pop.pdf | Bin 103894 -> 0 bytes .../pbds_priority_queue_text_push_pop.png | Bin 44314 -> 0 bytes .../pbds_priority_queue_text_push_pop.svg | 821 - .../pbds_rationale_null_node_updator.png | Bin 25097 -> 0 bytes .../doc/xml/images/pbds_resize_policy_cd.png | Bin 20806 -> 0 bytes .../images/pbds_restoring_node_invariants.png | Bin 14432 -> 0 bytes .../doc/xml/images/pbds_simple_list.png | Bin 4299 -> 0 bytes .../doc/xml/images/pbds_tree_int_find.pdf | Bin 82717 -> 0 bytes .../doc/xml/images/pbds_tree_int_find.png | Bin 37647 -> 0 bytes .../doc/xml/images/pbds_tree_int_find.svg | 501 - .../images/pbds_tree_node_invalidations.png | Bin 32276 -> 0 bytes .../xml/images/pbds_tree_node_invariants.png | Bin 16553 -> 0 bytes .../pbds_tree_node_updator_policy_cd.png | Bin 9236 -> 0 bytes .../xml/images/pbds_tree_order_statistics.pdf | Bin 81007 -> 0 bytes .../xml/images/pbds_tree_order_statistics.png | Bin 36565 -> 0 bytes .../xml/images/pbds_tree_order_statistics.svg | 442 - .../doc/xml/images/pbds_tree_split_join.pdf | Bin 82727 -> 0 bytes .../doc/xml/images/pbds_tree_split_join.png | Bin 38092 -> 0 bytes .../doc/xml/images/pbds_tree_split_join.svg | 501 - .../doc/xml/images/pbds_tree_text_find.pdf | Bin 84206 -> 0 bytes .../doc/xml/images/pbds_tree_text_find.png | Bin 43323 -> 0 bytes .../doc/xml/images/pbds_tree_text_find.svg | 538 - .../xml/images/pbds_tree_text_insert_node.pdf | Bin 80772 -> 0 bytes .../xml/images/pbds_tree_text_insert_node.png | Bin 35682 -> 0 bytes .../xml/images/pbds_tree_text_insert_node.svg | 442 - .../xml/images/pbds_tree_text_insert_trie.pdf | Bin 68209 -> 0 bytes .../xml/images/pbds_tree_text_insert_trie.png | Bin 28044 -> 0 bytes .../xml/images/pbds_tree_text_insert_trie.svg | 251 - .../images/pbds_tree_text_insert_vector.pdf | Bin 68484 -> 0 bytes .../images/pbds_tree_text_insert_vector.png | Bin 28291 -> 0 bytes .../images/pbds_tree_text_insert_vector.svg | 273 - .../xml/images/pbds_tree_text_lor_find.pdf | Bin 82720 -> 0 bytes .../xml/images/pbds_tree_text_lor_find.png | Bin 43242 -> 0 bytes .../xml/images/pbds_tree_text_lor_find.svg | 501 - .../pbds_trie_node_updator_policy_cd.png | Bin 12126 -> 0 bytes .../xml/images/pbds_update_seq_diagram.png | Bin 10789 -> 0 bytes .../libstdc++-v3-4.7/doc/xml/manual/abi.xml | 1193 - .../doc/xml/manual/algorithms.xml | 101 - .../doc/xml/manual/allocator.xml | 590 - .../doc/xml/manual/appendix_contributing.xml | 1804 - .../doc/xml/manual/appendix_free.xml | 178 - .../doc/xml/manual/appendix_porting.xml | 50 - .../doc/xml/manual/atomics.xml | 57 - .../doc/xml/manual/auto_ptr.xml | 134 - .../xml/manual/backwards_compatibility.xml | 1323 - .../doc/xml/manual/bitmap_allocator.xml | 561 - .../doc/xml/manual/build_hacking.xml | 355 - .../doc/xml/manual/codecvt.xml | 680 - .../doc/xml/manual/concurrency.xml | 81 - .../doc/xml/manual/concurrency_extensions.xml | 342 - .../doc/xml/manual/configure.xml | 375 - .../doc/xml/manual/containers.xml | 462 - .../libstdc++-v3-4.7/doc/xml/manual/ctype.xml | 222 - .../libstdc++-v3-4.7/doc/xml/manual/debug.xml | 365 - .../doc/xml/manual/debug_mode.xml | 889 - .../doc/xml/manual/diagnostics.xml | 129 - .../doc/xml/manual/documentation_hacking.xml | 1010 - .../doc/xml/manual/evolution.xml | 631 - .../doc/xml/manual/extensions.xml | 584 - .../doc/xml/manual/internals.xml | 546 - .../libstdc++-v3-4.7/doc/xml/manual/intro.xml | 878 - .../libstdc++-v3-4.7/doc/xml/manual/io.xml | 649 - .../doc/xml/manual/iterators.xml | 185 - .../doc/xml/manual/locale.xml | 619 - .../doc/xml/manual/localization.xml | 51 - .../doc/xml/manual/messages.xml | 572 - .../doc/xml/manual/mt_allocator.xml | 555 - .../doc/xml/manual/numerics.xml | 145 - .../doc/xml/manual/parallel_mode.xml | 878 - .../doc/xml/manual/policy_data_structures.xml | 6583 -- .../doc/xml/manual/prerequisites.xml | 140 - .../doc/xml/manual/profile_mode.xml | 1718 - .../doc/xml/manual/shared_ptr.xml | 488 - .../libstdc++-v3-4.7/doc/xml/manual/spine.xml | 247 - .../doc/xml/manual/status_cxx1998.xml | 1164 - .../doc/xml/manual/status_cxx2011.xml | 2674 - .../doc/xml/manual/status_cxxtr1.xml | 1798 - .../doc/xml/manual/status_cxxtr24733.xml | 299 - .../doc/xml/manual/strings.xml | 486 - .../doc/xml/manual/support.xml | 443 - .../libstdc++-v3-4.7/doc/xml/manual/test.xml | 1035 - .../manual/test_policy_data_structures.xml | 9774 -- .../libstdc++-v3-4.7/doc/xml/manual/using.xml | 1616 - .../doc/xml/manual/using_exceptions.xml | 557 - .../doc/xml/manual/utilities.xml | 123 - .../libstdc++-v3-4.7/doc/xml/spine.xml | 81 - l4/pkg/linux-26-headers/include/Kbuild | 10 - .../linux-26-headers/include/acpi/acconfig.h | 217 - .../linux-26-headers/include/acpi/acdebug.h | 223 - .../linux-26-headers/include/acpi/acdisasm.h | 441 - .../linux-26-headers/include/acpi/acdispat.h | 345 - .../linux-26-headers/include/acpi/acevents.h | 216 - .../linux-26-headers/include/acpi/acexcep.h | 309 - .../linux-26-headers/include/acpi/acglobal.h | 387 - .../linux-26-headers/include/acpi/achware.h | 131 - .../linux-26-headers/include/acpi/acinterp.h | 529 - .../linux-26-headers/include/acpi/aclocal.h | 967 - .../linux-26-headers/include/acpi/acmacros.h | 706 - .../linux-26-headers/include/acpi/acnames.h | 83 - .../linux-26-headers/include/acpi/acnamesp.h | 305 - .../linux-26-headers/include/acpi/acobject.h | 423 - .../linux-26-headers/include/acpi/acopcode.h | 323 - .../linux-26-headers/include/acpi/acoutput.h | 185 - .../linux-26-headers/include/acpi/acparser.h | 234 - l4/pkg/linux-26-headers/include/acpi/acpi.h | 69 - .../linux-26-headers/include/acpi/acpi_bus.h | 399 - .../include/acpi/acpi_drivers.h | 154 - .../linux-26-headers/include/acpi/acpi_numa.h | 20 - .../linux-26-headers/include/acpi/acpiosxf.h | 283 - l4/pkg/linux-26-headers/include/acpi/acpixf.h | 343 - .../linux-26-headers/include/acpi/acresrc.h | 336 - .../linux-26-headers/include/acpi/acstruct.h | 228 - .../linux-26-headers/include/acpi/actables.h | 115 - l4/pkg/linux-26-headers/include/acpi/actbl.h | 297 - l4/pkg/linux-26-headers/include/acpi/actbl1.h | 1303 - .../linux-26-headers/include/acpi/actypes.h | 1242 - .../linux-26-headers/include/acpi/acutils.h | 583 - .../linux-26-headers/include/acpi/amlcode.h | 494 - .../linux-26-headers/include/acpi/amlresrc.h | 311 - .../linux-26-headers/include/acpi/container.h | 12 - .../linux-26-headers/include/acpi/pdc_intel.h | 33 - .../include/acpi/platform/acenv.h | 363 - .../include/acpi/platform/acgcc.h | 65 - .../include/acpi/platform/aclinux.h | 140 - .../linux-26-headers/include/acpi/processor.h | 355 - l4/pkg/linux-26-headers/include/acpi/reboot.h | 11 - .../include/asm-arm/.gitignore | 2 - .../include/asm-arm/plat-s3c/debug-macro.S | 75 - .../include/asm-arm/plat-s3c/iic.h | 33 - .../include/asm-arm/plat-s3c/map.h | 40 - .../include/asm-arm/plat-s3c/nand.h | 50 - .../include/asm-arm/plat-s3c/regs-ac97.h | 67 - .../include/asm-arm/plat-s3c/regs-adc.h | 60 - .../include/asm-arm/plat-s3c/regs-iic.h | 56 - .../include/asm-arm/plat-s3c/regs-nand.h | 123 - .../include/asm-arm/plat-s3c/regs-rtc.h | 61 - .../include/asm-arm/plat-s3c/regs-serial.h | 232 - .../include/asm-arm/plat-s3c/regs-timer.h | 115 - .../include/asm-arm/plat-s3c/regs-watchdog.h | 41 - .../include/asm-arm/plat-s3c/uncompress.h | 155 - .../include/asm-arm/plat-s3c24xx/clock.h | 64 - .../asm-arm/plat-s3c24xx/common-smdk.h | 15 - .../include/asm-arm/plat-s3c24xx/cpu.h | 54 - .../include/asm-arm/plat-s3c24xx/devs.h | 49 - .../include/asm-arm/plat-s3c24xx/dma.h | 82 - .../include/asm-arm/plat-s3c24xx/irq.h | 109 - .../include/asm-arm/plat-s3c24xx/mci.h | 15 - .../include/asm-arm/plat-s3c24xx/pm.h | 73 - .../include/asm-arm/plat-s3c24xx/regs-iis.h | 77 - .../asm-arm/plat-s3c24xx/regs-s3c2412-iis.h | 72 - .../include/asm-arm/plat-s3c24xx/regs-spi.h | 82 - .../include/asm-arm/plat-s3c24xx/regs-udc.h | 153 - .../include/asm-arm/plat-s3c24xx/s3c2400.h | 31 - .../include/asm-arm/plat-s3c24xx/s3c2410.h | 31 - .../include/asm-arm/plat-s3c24xx/s3c2412.h | 29 - .../include/asm-arm/plat-s3c24xx/s3c2440.h | 17 - .../include/asm-arm/plat-s3c24xx/s3c2442.h | 17 - .../include/asm-arm/plat-s3c24xx/s3c2443.h | 32 - .../include/asm-arm/plat-s3c24xx/udc.h | 36 - .../linux-26-headers/include/asm-cris/Kbuild | 11 - .../linux-26-headers/include/asm-cris/a.out.h | 26 - .../include/asm-cris/arch-v10/Kbuild | 4 - .../include/asm-cris/arch-v10/atomic.h | 7 - .../include/asm-cris/arch-v10/bitops.h | 73 - .../include/asm-cris/arch-v10/bug.h | 66 - .../include/asm-cris/arch-v10/byteorder.h | 26 - .../include/asm-cris/arch-v10/cache.h | 8 - .../include/asm-cris/arch-v10/checksum.h | 29 - .../include/asm-cris/arch-v10/delay.h | 20 - .../include/asm-cris/arch-v10/dma.h | 74 - .../include/asm-cris/arch-v10/elf.h | 81 - .../include/asm-cris/arch-v10/io.h | 199 - .../asm-cris/arch-v10/io_interface_mux.h | 75 - .../include/asm-cris/arch-v10/irq.h | 160 - .../include/asm-cris/arch-v10/memmap.h | 22 - .../include/asm-cris/arch-v10/mmu.h | 109 - .../include/asm-cris/arch-v10/offset.h | 33 - .../include/asm-cris/arch-v10/page.h | 30 - .../include/asm-cris/arch-v10/pgtable.h | 17 - .../include/asm-cris/arch-v10/processor.h | 70 - .../include/asm-cris/arch-v10/ptrace.h | 119 - .../include/asm-cris/arch-v10/sv_addr.agh | 7306 -- .../include/asm-cris/arch-v10/sv_addr_ag.h | 139 - .../include/asm-cris/arch-v10/svinto.h | 64 - .../include/asm-cris/arch-v10/system.h | 63 - .../include/asm-cris/arch-v10/thread_info.h | 12 - .../include/asm-cris/arch-v10/timex.h | 30 - .../include/asm-cris/arch-v10/tlb.h | 13 - .../include/asm-cris/arch-v10/uaccess.h | 660 - .../include/asm-cris/arch-v10/unistd.h | 148 - .../include/asm-cris/arch-v10/user.h | 46 - .../include/asm-cris/arch-v32/Kbuild | 2 - .../include/asm-cris/arch-v32/arbiter.h | 30 - .../include/asm-cris/arch-v32/atomic.h | 36 - .../include/asm-cris/arch-v32/bitops.h | 64 - .../include/asm-cris/arch-v32/bug.h | 33 - .../include/asm-cris/arch-v32/byteorder.h | 20 - .../include/asm-cris/arch-v32/cache.h | 19 - .../include/asm-cris/arch-v32/checksum.h | 29 - .../include/asm-cris/arch-v32/cryptocop.h | 272 - .../include/asm-cris/arch-v32/delay.h | 28 - .../include/asm-cris/arch-v32/dma.h | 79 - .../include/asm-cris/arch-v32/elf.h | 73 - .../include/asm-cris/arch-v32/hwregs/Makefile | 186 - .../arch-v32/hwregs/asm/ata_defs_asm.h | 222 - .../arch-v32/hwregs/asm/bif_core_defs_asm.h | 319 - .../arch-v32/hwregs/asm/bif_dma_defs_asm.h | 495 - .../arch-v32/hwregs/asm/bif_slave_defs_asm.h | 249 - .../arch-v32/hwregs/asm/config_defs_asm.h | 131 - .../asm-cris/arch-v32/hwregs/asm/cpu_vect.h | 41 - .../arch-v32/hwregs/asm/cris_defs_asm.h | 114 - .../arch-v32/hwregs/asm/cris_supp_reg.h | 10 - .../arch-v32/hwregs/asm/dma_defs_asm.h | 368 - .../arch-v32/hwregs/asm/eth_defs_asm.h | 498 - .../arch-v32/hwregs/asm/gio_defs_asm.h | 276 - .../asm-cris/arch-v32/hwregs/asm/intr_vect.h | 38 - .../arch-v32/hwregs/asm/intr_vect_defs_asm.h | 355 - .../arch-v32/hwregs/asm/irq_nmi_defs_asm.h | 69 - .../arch-v32/hwregs/asm/marb_defs_asm.h | 579 - .../arch-v32/hwregs/asm/mmu_defs_asm.h | 212 - .../arch-v32/hwregs/asm/mmu_supp_reg.h | 7 - .../arch-v32/hwregs/asm/pinmux_defs_asm.h | 632 - .../arch-v32/hwregs/asm/reg_map_asm.h | 96 - .../arch-v32/hwregs/asm/rt_trace_defs_asm.h | 142 - .../arch-v32/hwregs/asm/ser_defs_asm.h | 359 - .../arch-v32/hwregs/asm/sser_defs_asm.h | 462 - .../arch-v32/hwregs/asm/strcop_defs_asm.h | 84 - .../arch-v32/hwregs/asm/strmux_defs_asm.h | 100 - .../arch-v32/hwregs/asm/timer_defs_asm.h | 229 - .../asm-cris/arch-v32/hwregs/ata_defs.h | 222 - .../asm-cris/arch-v32/hwregs/bif_core_defs.h | 284 - .../asm-cris/arch-v32/hwregs/bif_dma_defs.h | 473 - .../asm-cris/arch-v32/hwregs/bif_slave_defs.h | 249 - .../asm-cris/arch-v32/hwregs/config_defs.h | 142 - .../asm-cris/arch-v32/hwregs/cpu_vect.h | 41 - .../include/asm-cris/arch-v32/hwregs/dma.h | 127 - .../asm-cris/arch-v32/hwregs/dma_defs.h | 436 - .../asm-cris/arch-v32/hwregs/eth_defs.h | 378 - .../asm-cris/arch-v32/hwregs/extmem_defs.h | 369 - .../asm-cris/arch-v32/hwregs/gio_defs.h | 295 - .../asm-cris/arch-v32/hwregs/intr_vect.h | 39 - .../asm-cris/arch-v32/hwregs/iop/Makefile | 146 - .../hwregs/iop/asm/iop_crc_par_defs_asm.h | 171 - .../hwregs/iop/asm/iop_dmc_in_defs_asm.h | 321 - .../hwregs/iop/asm/iop_dmc_out_defs_asm.h | 349 - .../hwregs/iop/asm/iop_fifo_in_defs_asm.h | 234 - .../iop/asm/iop_fifo_in_extra_defs_asm.h | 155 - .../hwregs/iop/asm/iop_fifo_out_defs_asm.h | 254 - .../iop/asm/iop_fifo_out_extra_defs_asm.h | 158 - .../hwregs/iop/asm/iop_mpu_defs_asm.h | 177 - .../hwregs/iop/asm/iop_reg_space_asm.h | 44 - .../hwregs/iop/asm/iop_sap_in_defs_asm.h | 182 - .../hwregs/iop/asm/iop_sap_out_defs_asm.h | 346 - .../hwregs/iop/asm/iop_scrc_in_defs_asm.h | 111 - .../hwregs/iop/asm/iop_scrc_out_defs_asm.h | 105 - .../hwregs/iop/asm/iop_spu_defs_asm.h | 573 - .../hwregs/iop/asm/iop_sw_cfg_defs_asm.h | 1052 - .../hwregs/iop/asm/iop_sw_cpu_defs_asm.h | 1758 - .../hwregs/iop/asm/iop_sw_mpu_defs_asm.h | 1776 - .../hwregs/iop/asm/iop_sw_spu_defs_asm.h | 691 - .../hwregs/iop/asm/iop_timer_grp_defs_asm.h | 237 - .../hwregs/iop/asm/iop_trigger_grp_defs_asm.h | 157 - .../hwregs/iop/asm/iop_version_defs_asm.h | 64 - .../arch-v32/hwregs/iop/iop_crc_par_defs.h | 232 - .../arch-v32/hwregs/iop/iop_dmc_in_defs.h | 325 - .../arch-v32/hwregs/iop/iop_dmc_out_defs.h | 326 - .../arch-v32/hwregs/iop/iop_fifo_in_defs.h | 255 - .../hwregs/iop/iop_fifo_in_extra_defs.h | 164 - .../arch-v32/hwregs/iop/iop_fifo_out_defs.h | 278 - .../hwregs/iop/iop_fifo_out_extra_defs.h | 164 - .../arch-v32/hwregs/iop/iop_mpu_defs.h | 190 - .../arch-v32/hwregs/iop/iop_mpu_macros.h | 764 - .../arch-v32/hwregs/iop/iop_reg_space.h | 44 - .../arch-v32/hwregs/iop/iop_sap_in_defs.h | 179 - .../arch-v32/hwregs/iop/iop_sap_out_defs.h | 306 - .../arch-v32/hwregs/iop/iop_scrc_in_defs.h | 160 - .../arch-v32/hwregs/iop/iop_scrc_out_defs.h | 146 - .../arch-v32/hwregs/iop/iop_spu_defs.h | 453 - .../arch-v32/hwregs/iop/iop_sw_cfg_defs.h | 1042 - .../arch-v32/hwregs/iop/iop_sw_cpu_defs.h | 853 - .../arch-v32/hwregs/iop/iop_sw_mpu_defs.h | 893 - .../arch-v32/hwregs/iop/iop_sw_spu_defs.h | 552 - .../arch-v32/hwregs/iop/iop_timer_grp_defs.h | 249 - .../hwregs/iop/iop_trigger_grp_defs.h | 170 - .../arch-v32/hwregs/iop/iop_version_defs.h | 99 - .../asm-cris/arch-v32/hwregs/irq_nmi_defs.h | 104 - .../asm-cris/arch-v32/hwregs/marb_bp_defs.h | 205 - .../asm-cris/arch-v32/hwregs/marb_defs.h | 475 - .../asm-cris/arch-v32/hwregs/pinmux_defs.h | 357 - .../asm-cris/arch-v32/hwregs/reg_rdwr.h | 17 - .../asm-cris/arch-v32/hwregs/rt_trace_defs.h | 173 - .../asm-cris/arch-v32/hwregs/ser_defs.h | 308 - .../asm-cris/arch-v32/hwregs/sser_defs.h | 331 - .../include/asm-cris/arch-v32/hwregs/strcop.h | 57 - .../asm-cris/arch-v32/hwregs/strcop_defs.h | 109 - .../asm-cris/arch-v32/hwregs/strmux_defs.h | 127 - .../asm-cris/arch-v32/hwregs/supp_reg.h | 78 - .../include/asm-cris/arch-v32/intmem.h | 9 - .../include/asm-cris/arch-v32/io.h | 136 - .../include/asm-cris/arch-v32/irq.h | 124 - .../asm-cris/arch-v32/mach-a3/arbiter.h | 34 - .../include/asm-cris/arch-v32/mach-a3/dma.h | 31 - .../mach-a3/hwregs/asm/clkgen_defs_asm.h | 164 - .../mach-a3/hwregs/asm/ddr2_defs_asm.h | 266 - .../mach-a3/hwregs/asm/gio_defs_asm.h | 849 - .../mach-a3/hwregs/asm/pinmux_defs_asm.h | 572 - .../mach-a3/hwregs/asm/pio_defs_asm.h | 337 - .../arch-v32/mach-a3/hwregs/asm/reg_map_asm.h | 99 - .../mach-a3/hwregs/asm/timer_defs_asm.h | 228 - .../arch-v32/mach-a3/hwregs/clkgen_defs.h | 159 - .../arch-v32/mach-a3/hwregs/ddr2_defs.h | 281 - .../arch-v32/mach-a3/hwregs/gio_defs.h | 837 - .../arch-v32/mach-a3/hwregs/intr_vect.h | 46 - .../arch-v32/mach-a3/hwregs/intr_vect_defs.h | 341 - .../hwregs/iop/asm/iop_reg_space_asm.h | 31 - .../hwregs/iop/asm/iop_sap_in_defs_asm.h | 109 - .../hwregs/iop/asm/iop_sap_out_defs_asm.h | 276 - .../hwregs/iop/asm/iop_sw_cfg_defs_asm.h | 739 - .../hwregs/iop/asm/iop_sw_cpu_defs_asm.h | 950 - .../hwregs/iop/asm/iop_sw_mpu_defs_asm.h | 1086 - .../hwregs/iop/asm/iop_sw_spu_defs_asm.h | 523 - .../hwregs/iop/asm/iop_version_defs_asm.h | 61 - .../mach-a3/hwregs/iop/iop_reg_space.h | 31 - .../mach-a3/hwregs/iop/iop_sap_in_defs.h | 141 - .../mach-a3/hwregs/iop/iop_sap_out_defs.h | 231 - .../mach-a3/hwregs/iop/iop_sw_cfg_defs.h | 725 - .../mach-a3/hwregs/iop/iop_sw_cpu_defs.h | 522 - .../mach-a3/hwregs/iop/iop_sw_mpu_defs.h | 648 - .../mach-a3/hwregs/iop/iop_sw_spu_defs.h | 441 - .../mach-a3/hwregs/iop/iop_version_defs.h | 96 - .../arch-v32/mach-a3/hwregs/l2cache_defs.h | 142 - .../arch-v32/mach-a3/hwregs/marb_bar_defs.h | 482 - .../arch-v32/mach-a3/hwregs/marb_foo_defs.h | 626 - .../arch-v32/mach-a3/hwregs/pinmux_defs.h | 312 - .../arch-v32/mach-a3/hwregs/pio_defs.h | 371 - .../arch-v32/mach-a3/hwregs/reg_map.h | 103 - .../arch-v32/mach-a3/hwregs/strmux_defs.h | 120 - .../arch-v32/mach-a3/hwregs/timer_defs.h | 265 - .../asm-cris/arch-v32/mach-a3/memmap.h | 10 - .../asm-cris/arch-v32/mach-a3/pinmux.h | 45 - .../asm-cris/arch-v32/mach-a3/startup.inc | 60 - .../asm-cris/arch-v32/mach-fs/arbiter.h | 28 - .../mach-fs/hwregs/asm/bif_core_defs_asm.h | 319 - .../mach-fs/hwregs/asm/config_defs_asm.h | 131 - .../mach-fs/hwregs/asm/gio_defs_asm.h | 276 - .../mach-fs/hwregs/asm/pinmux_defs_asm.h | 632 - .../arch-v32/mach-fs/hwregs/asm/reg_map_asm.h | 96 - .../mach-fs/hwregs/asm/timer_defs_asm.h | 229 - .../arch-v32/mach-fs/hwregs/bif_core_defs.h | 284 - .../arch-v32/mach-fs/hwregs/bif_dma_defs.h | 473 - .../arch-v32/mach-fs/hwregs/bif_slave_defs.h | 249 - .../arch-v32/mach-fs/hwregs/config_defs.h | 142 - .../arch-v32/mach-fs/hwregs/gio_defs.h | 295 - .../arch-v32/mach-fs/hwregs/intr_vect.h | 41 - .../arch-v32/mach-fs/hwregs/intr_vect_defs.h | 228 - .../arch-v32/mach-fs/hwregs/marb_bp_defs.h | 205 - .../arch-v32/mach-fs/hwregs/marb_defs.h | 475 - .../arch-v32/mach-fs/hwregs/pinmux_defs.h | 357 - .../arch-v32/mach-fs/hwregs/reg_map.h | 104 - .../arch-v32/mach-fs/hwregs/strmux_defs.h | 127 - .../arch-v32/mach-fs/hwregs/timer_defs.h | 266 - .../asm-cris/arch-v32/mach-fs/pinmux.h | 38 - .../asm-cris/arch-v32/mach-fs/startup.inc | 77 - .../include/asm-cris/arch-v32/memmap.h | 24 - .../include/asm-cris/arch-v32/mmu.h | 111 - .../include/asm-cris/arch-v32/offset.h | 35 - .../include/asm-cris/arch-v32/page.h | 27 - .../include/asm-cris/arch-v32/pgtable.h | 9 - .../include/asm-cris/arch-v32/pinmux.h | 40 - .../include/asm-cris/arch-v32/processor.h | 59 - .../include/asm-cris/arch-v32/ptrace.h | 118 - .../include/asm-cris/arch-v32/spinlock.h | 129 - .../include/asm-cris/arch-v32/system.h | 69 - .../include/asm-cris/arch-v32/thread_info.h | 13 - .../include/asm-cris/arch-v32/timex.h | 31 - .../include/asm-cris/arch-v32/tlb.h | 14 - .../include/asm-cris/arch-v32/uaccess.h | 748 - .../include/asm-cris/arch-v32/unistd.h | 155 - .../include/asm-cris/arch-v32/user.h | 41 - .../include/asm-cris/atomic.h | 164 - .../include/asm-cris/auxvec.h | 4 - .../include/asm-cris/axisflashmap.h | 61 - .../include/asm-cris/bitops.h | 166 - .../linux-26-headers/include/asm-cris/bug.h | 4 - .../linux-26-headers/include/asm-cris/bugs.h | 21 - .../include/asm-cris/byteorder.h | 27 - .../linux-26-headers/include/asm-cris/cache.h | 6 - .../include/asm-cris/cacheflush.h | 31 - .../include/asm-cris/checksum.h | 83 - .../include/asm-cris/cputime.h | 6 - .../include/asm-cris/current.h | 15 - .../linux-26-headers/include/asm-cris/delay.h | 27 - .../include/asm-cris/device.h | 7 - .../linux-26-headers/include/asm-cris/div64.h | 1 - .../include/asm-cris/dma-mapping.h | 170 - .../linux-26-headers/include/asm-cris/dma.h | 21 - .../linux-26-headers/include/asm-cris/elf.h | 93 - .../include/asm-cris/emergency-restart.h | 6 - .../linux-26-headers/include/asm-cris/errno.h | 6 - .../include/asm-cris/eshlibld.h | 113 - .../include/asm-cris/ethernet.h | 21 - .../include/asm-cris/etraxgpio.h | 179 - .../include/asm-cris/etraxi2c.h | 36 - .../include/asm-cris/fasttimer.h | 47 - l4/pkg/linux-26-headers/include/asm-cris/fb.h | 12 - .../linux-26-headers/include/asm-cris/fcntl.h | 1 - .../linux-26-headers/include/asm-cris/futex.h | 6 - .../include/asm-cris/hardirq.h | 27 - .../include/asm-cris/hw_irq.h | 5 - l4/pkg/linux-26-headers/include/asm-cris/io.h | 154 - .../linux-26-headers/include/asm-cris/ioctl.h | 1 - .../include/asm-cris/ioctls.h | 91 - .../include/asm-cris/ipcbuf.h | 29 - .../linux-26-headers/include/asm-cris/irq.h | 13 - .../include/asm-cris/irq_regs.h | 1 - .../include/asm-cris/kdebug.h | 1 - .../include/asm-cris/kmap_types.h | 25 - .../include/asm-cris/linkage.h | 6 - .../linux-26-headers/include/asm-cris/local.h | 1 - .../linux-26-headers/include/asm-cris/mman.h | 19 - .../linux-26-headers/include/asm-cris/mmu.h | 10 - .../include/asm-cris/mmu_context.h | 26 - .../include/asm-cris/module.h | 9 - .../include/asm-cris/msgbuf.h | 33 - .../linux-26-headers/include/asm-cris/mutex.h | 9 - .../linux-26-headers/include/asm-cris/page.h | 74 - .../linux-26-headers/include/asm-cris/param.h | 23 - .../linux-26-headers/include/asm-cris/pci.h | 68 - .../include/asm-cris/percpu.h | 6 - .../include/asm-cris/pgalloc.h | 58 - .../include/asm-cris/pgtable.h | 299 - .../linux-26-headers/include/asm-cris/poll.h | 1 - .../include/asm-cris/posix_types.h | 66 - .../include/asm-cris/processor.h | 75 - .../include/asm-cris/ptrace.h | 16 - .../include/asm-cris/resource.h | 6 - .../linux-26-headers/include/asm-cris/rs485.h | 20 - .../linux-26-headers/include/asm-cris/rtc.h | 107 - .../include/asm-cris/scatterlist.h | 23 - .../include/asm-cris/sections.h | 7 - .../include/asm-cris/segment.h | 8 - .../include/asm-cris/sembuf.h | 25 - .../linux-26-headers/include/asm-cris/setup.h | 6 - .../include/asm-cris/shmbuf.h | 42 - .../include/asm-cris/shmparam.h | 8 - .../include/asm-cris/sigcontext.h | 24 - .../include/asm-cris/siginfo.h | 6 - .../include/asm-cris/signal.h | 163 - .../linux-26-headers/include/asm-cris/smp.h | 11 - .../include/asm-cris/socket.h | 61 - .../include/asm-cris/sockios.h | 13 - .../include/asm-cris/spinlock.h | 1 - .../linux-26-headers/include/asm-cris/stat.h | 81 - .../include/asm-cris/statfs.h | 6 - .../include/asm-cris/string.h | 14 - .../include/asm-cris/sync_serial.h | 107 - .../include/asm-cris/system.h | 88 - .../include/asm-cris/termbits.h | 234 - .../include/asm-cris/termios.h | 91 - .../include/asm-cris/thread_info.h | 104 - .../linux-26-headers/include/asm-cris/timex.h | 24 - .../linux-26-headers/include/asm-cris/tlb.h | 19 - .../include/asm-cris/tlbflush.h | 48 - .../include/asm-cris/topology.h | 6 - .../linux-26-headers/include/asm-cris/types.h | 30 - .../include/asm-cris/uaccess.h | 404 - .../include/asm-cris/ucontext.h | 12 - .../include/asm-cris/unaligned.h | 13 - .../include/asm-cris/unistd.h | 374 - .../linux-26-headers/include/asm-cris/user.h | 52 - .../linux-26-headers/include/asm-frv/Kbuild | 5 - .../linux-26-headers/include/asm-frv/atomic.h | 202 - .../linux-26-headers/include/asm-frv/auxvec.h | 4 - .../include/asm-frv/ax88796.h | 22 - .../linux-26-headers/include/asm-frv/bitops.h | 399 - l4/pkg/linux-26-headers/include/asm-frv/bug.h | 53 - .../linux-26-headers/include/asm-frv/bugs.h | 14 - .../include/asm-frv/busctl-regs.h | 41 - .../include/asm-frv/byteorder.h | 13 - .../linux-26-headers/include/asm-frv/cache.h | 23 - .../include/asm-frv/cacheflush.h | 104 - .../include/asm-frv/checksum.h | 180 - .../include/asm-frv/cpu-irqs.h | 81 - .../include/asm-frv/cpumask.h | 6 - .../include/asm-frv/cputime.h | 6 - .../include/asm-frv/current.h | 30 - .../linux-26-headers/include/asm-frv/delay.h | 50 - .../linux-26-headers/include/asm-frv/device.h | 7 - .../linux-26-headers/include/asm-frv/div64.h | 1 - .../linux-26-headers/include/asm-frv/dm9000.h | 37 - .../include/asm-frv/dma-mapping.h | 174 - l4/pkg/linux-26-headers/include/asm-frv/dma.h | 125 - l4/pkg/linux-26-headers/include/asm-frv/elf.h | 142 - .../include/asm-frv/emergency-restart.h | 6 - .../linux-26-headers/include/asm-frv/errno.h | 7 - l4/pkg/linux-26-headers/include/asm-frv/fb.h | 12 - .../linux-26-headers/include/asm-frv/fcntl.h | 1 - l4/pkg/linux-26-headers/include/asm-frv/fpu.h | 11 - .../linux-26-headers/include/asm-frv/futex.h | 19 - .../include/asm-frv/gdb-stub.h | 140 - .../include/asm-frv/gpio-regs.h | 116 - .../include/asm-frv/hardirq.h | 35 - .../include/asm-frv/highmem.h | 180 - .../linux-26-headers/include/asm-frv/hw_irq.h | 16 - l4/pkg/linux-26-headers/include/asm-frv/ide.h | 32 - .../linux-26-headers/include/asm-frv/init.h | 12 - l4/pkg/linux-26-headers/include/asm-frv/io.h | 392 - .../linux-26-headers/include/asm-frv/ioctl.h | 1 - .../linux-26-headers/include/asm-frv/ioctls.h | 86 - .../linux-26-headers/include/asm-frv/ipcbuf.h | 30 - .../include/asm-frv/irc-regs.h | 53 - l4/pkg/linux-26-headers/include/asm-frv/irq.h | 30 - .../include/asm-frv/irq_regs.h | 27 - .../linux-26-headers/include/asm-frv/kdebug.h | 1 - .../include/asm-frv/kmap_types.h | 29 - .../include/asm-frv/linkage.h | 7 - .../linux-26-headers/include/asm-frv/local.h | 6 - .../include/asm-frv/math-emu.h | 301 - .../include/asm-frv/mb-regs.h | 200 - .../include/asm-frv/mb86943a.h | 42 - .../include/asm-frv/mb93091-fpga-irqs.h | 42 - .../include/asm-frv/mb93093-fpga-irqs.h | 29 - .../include/asm-frv/mb93493-irqs.h | 50 - .../include/asm-frv/mb93493-regs.h | 281 - .../include/asm-frv/mc146818rtc.h | 16 - .../include/asm-frv/mem-layout.h | 86 - .../linux-26-headers/include/asm-frv/mman.h | 18 - l4/pkg/linux-26-headers/include/asm-frv/mmu.h | 42 - .../include/asm-frv/mmu_context.h | 50 - .../linux-26-headers/include/asm-frv/module.h | 28 - .../linux-26-headers/include/asm-frv/msgbuf.h | 32 - .../linux-26-headers/include/asm-frv/mutex.h | 9 - .../linux-26-headers/include/asm-frv/page.h | 78 - .../linux-26-headers/include/asm-frv/param.h | 22 - l4/pkg/linux-26-headers/include/asm-frv/pci.h | 118 - .../linux-26-headers/include/asm-frv/percpu.h | 6 - .../include/asm-frv/pgalloc.h | 69 - .../include/asm-frv/pgtable.h | 551 - .../linux-26-headers/include/asm-frv/poll.h | 12 - .../include/asm-frv/posix_types.h | 62 - .../include/asm-frv/processor.h | 153 - .../linux-26-headers/include/asm-frv/ptrace.h | 83 - .../include/asm-frv/registers.h | 232 - .../include/asm-frv/resource.h | 7 - .../include/asm-frv/scatterlist.h | 46 - .../include/asm-frv/sections.h | 46 - .../include/asm-frv/segment.h | 45 - .../linux-26-headers/include/asm-frv/sembuf.h | 26 - .../include/asm-frv/serial-regs.h | 44 - .../linux-26-headers/include/asm-frv/serial.h | 18 - .../linux-26-headers/include/asm-frv/setup.h | 31 - .../linux-26-headers/include/asm-frv/shmbuf.h | 43 - .../include/asm-frv/shmparam.h | 7 - .../include/asm-frv/sigcontext.h | 26 - .../include/asm-frv/siginfo.h | 12 - .../linux-26-headers/include/asm-frv/signal.h | 161 - l4/pkg/linux-26-headers/include/asm-frv/smp.h | 9 - .../linux-26-headers/include/asm-frv/socket.h | 58 - .../include/asm-frv/sockios.h | 14 - .../include/asm-frv/spinlock.h | 17 - .../include/asm-frv/spr-regs.h | 416 - .../linux-26-headers/include/asm-frv/stat.h | 100 - .../linux-26-headers/include/asm-frv/statfs.h | 7 - .../linux-26-headers/include/asm-frv/string.h | 51 - .../include/asm-frv/suspend.h | 20 - .../linux-26-headers/include/asm-frv/system.h | 301 - .../include/asm-frv/termbits.h | 202 - .../include/asm-frv/termios.h | 58 - .../include/asm-frv/thread_info.h | 144 - .../include/asm-frv/timer-regs.h | 106 - .../linux-26-headers/include/asm-frv/timex.h | 20 - l4/pkg/linux-26-headers/include/asm-frv/tlb.h | 27 - .../include/asm-frv/tlbflush.h | 73 - .../include/asm-frv/topology.h | 12 - .../linux-26-headers/include/asm-frv/types.h | 40 - .../include/asm-frv/uaccess.h | 321 - .../include/asm-frv/ucontext.h | 12 - .../include/asm-frv/unaligned.h | 22 - .../linux-26-headers/include/asm-frv/unistd.h | 382 - .../linux-26-headers/include/asm-frv/user.h | 80 - l4/pkg/linux-26-headers/include/asm-frv/vga.h | 17 - .../include/asm-frv/virtconvert.h | 41 - l4/pkg/linux-26-headers/include/asm-frv/xor.h | 1 - .../include/asm-generic/4level-fixup.h | 37 - .../include/asm-generic/Kbuild | 13 - .../include/asm-generic/Kbuild.asm | 37 - .../include/asm-generic/atomic.h | 258 - .../include/asm-generic/audit_change_attr.h | 22 - .../include/asm-generic/audit_dir_write.h | 18 - .../include/asm-generic/audit_read.h | 8 - .../include/asm-generic/audit_signal.h | 3 - .../include/asm-generic/audit_write.h | 11 - .../include/asm-generic/bitops.h | 33 - .../include/asm-generic/bitops/__ffs.h | 43 - .../include/asm-generic/bitops/__fls.h | 43 - .../include/asm-generic/bitops/atomic.h | 188 - .../include/asm-generic/bitops/ext2-atomic.h | 22 - .../asm-generic/bitops/ext2-non-atomic.h | 20 - .../include/asm-generic/bitops/ffs.h | 41 - .../include/asm-generic/bitops/ffz.h | 12 - .../include/asm-generic/bitops/find.h | 15 - .../include/asm-generic/bitops/fls.h | 41 - .../include/asm-generic/bitops/fls64.h | 36 - .../include/asm-generic/bitops/hweight.h | 11 - .../include/asm-generic/bitops/le.h | 57 - .../include/asm-generic/bitops/lock.h | 45 - .../include/asm-generic/bitops/minix-le.h | 17 - .../include/asm-generic/bitops/minix.h | 15 - .../include/asm-generic/bitops/non-atomic.h | 108 - .../include/asm-generic/bitops/sched.h | 31 - .../include/asm-generic/bug.h | 119 - .../include/asm-generic/cmpxchg-local.h | 65 - .../include/asm-generic/cmpxchg.h | 22 - .../include/asm-generic/cputime.h | 69 - .../include/asm-generic/device.h | 12 - .../include/asm-generic/div64.h | 58 - .../include/asm-generic/dma-coherent.h | 32 - .../include/asm-generic/dma-mapping-broken.h | 82 - .../include/asm-generic/dma-mapping.h | 308 - .../include/asm-generic/emergency-restart.h | 9 - .../include/asm-generic/futex.h | 56 - .../include/asm-generic/gpio.h | 172 - .../include/asm-generic/ide_iops.h | 38 - .../include/asm-generic/iomap.h | 72 - .../include/asm-generic/irq_regs.h | 37 - .../include/asm-generic/kdebug.h | 8 - .../include/asm-generic/libata-portmap.h | 7 - .../include/asm-generic/local.h | 75 - .../include/asm-generic/memory_model.h | 84 - .../include/asm-generic/mm_hooks.h | 18 - .../include/asm-generic/mutex-dec.h | 112 - .../include/asm-generic/mutex-null.h | 19 - .../include/asm-generic/mutex-xchg.h | 118 - .../include/asm-generic/page.h | 24 - .../include/asm-generic/pci-dma-compat.h | 107 - .../include/asm-generic/pci.h | 55 - .../include/asm-generic/percpu.h | 83 - .../include/asm-generic/pgtable-nopmd.h | 69 - .../include/asm-generic/pgtable-nopud.h | 61 - .../include/asm-generic/pgtable.h | 294 - .../include/asm-generic/rtc.h | 210 - .../include/asm-generic/sections.h | 23 - .../include/asm-generic/syscall.h | 141 - .../include/asm-generic/tlb.h | 148 - .../include/asm-generic/topology.h | 70 - .../include/asm-generic/uaccess.h | 26 - .../include/asm-generic/vmlinux.lds.h | 391 - .../include/asm-generic/xor.h | 718 - .../linux-26-headers/include/asm-m32r/Kbuild | 1 - .../linux-26-headers/include/asm-m32r/a.out.h | 20 - .../include/asm-m32r/addrspace.h | 57 - .../include/asm-m32r/assembler.h | 229 - .../include/asm-m32r/atomic.h | 324 - .../include/asm-m32r/auxvec.h | 4 - .../include/asm-m32r/bitops.h | 274 - .../linux-26-headers/include/asm-m32r/bug.h | 4 - .../linux-26-headers/include/asm-m32r/bugs.h | 19 - .../include/asm-m32r/byteorder.h | 17 - .../linux-26-headers/include/asm-m32r/cache.h | 8 - .../include/asm-m32r/cachectl.h | 26 - .../include/asm-m32r/cacheflush.h | 69 - .../include/asm-m32r/checksum.h | 204 - .../include/asm-m32r/cputime.h | 6 - .../include/asm-m32r/current.h | 15 - .../linux-26-headers/include/asm-m32r/delay.h | 26 - .../include/asm-m32r/device.h | 7 - .../linux-26-headers/include/asm-m32r/div64.h | 1 - .../linux-26-headers/include/asm-m32r/dma.h | 12 - .../linux-26-headers/include/asm-m32r/elf.h | 134 - .../include/asm-m32r/emergency-restart.h | 6 - .../linux-26-headers/include/asm-m32r/errno.h | 6 - l4/pkg/linux-26-headers/include/asm-m32r/fb.h | 19 - .../linux-26-headers/include/asm-m32r/fcntl.h | 1 - .../linux-26-headers/include/asm-m32r/flat.h | 146 - .../linux-26-headers/include/asm-m32r/futex.h | 6 - .../include/asm-m32r/hardirq.h | 36 - .../include/asm-m32r/hw_irq.h | 4 - l4/pkg/linux-26-headers/include/asm-m32r/io.h | 200 - .../linux-26-headers/include/asm-m32r/ioctl.h | 1 - .../include/asm-m32r/ioctls.h | 87 - .../include/asm-m32r/ipcbuf.h | 29 - .../linux-26-headers/include/asm-m32r/irq.h | 90 - .../include/asm-m32r/irq_regs.h | 1 - .../include/asm-m32r/kdebug.h | 1 - .../include/asm-m32r/kmap_types.h | 29 - .../include/asm-m32r/linkage.h | 7 - .../linux-26-headers/include/asm-m32r/local.h | 366 - .../include/asm-m32r/m32102.h | 314 - .../include/asm-m32r/m32104ut/m32104ut_pld.h | 161 - .../include/asm-m32r/m32700ut/m32700ut_lan.h | 103 - .../include/asm-m32r/m32700ut/m32700ut_lcd.h | 55 - .../include/asm-m32r/m32700ut/m32700ut_pld.h | 259 - .../linux-26-headers/include/asm-m32r/m32r.h | 160 - .../include/asm-m32r/m32r_mp_fpga.h | 313 - .../include/asm-m32r/mappi2/mappi2_pld.h | 150 - .../include/asm-m32r/mappi3/mappi3_pld.h | 142 - .../include/asm-m32r/mc146818rtc.h | 29 - .../linux-26-headers/include/asm-m32r/mman.h | 17 - .../linux-26-headers/include/asm-m32r/mmu.h | 22 - .../include/asm-m32r/mmu_context.h | 164 - .../include/asm-m32r/mmzone.h | 59 - .../include/asm-m32r/module.h | 10 - .../include/asm-m32r/msgbuf.h | 31 - .../linux-26-headers/include/asm-m32r/mutex.h | 9 - .../include/asm-m32r/opsput/opsput_lan.h | 52 - .../include/asm-m32r/opsput/opsput_lcd.h | 55 - .../include/asm-m32r/opsput/opsput_pld.h | 255 - .../linux-26-headers/include/asm-m32r/page.h | 87 - .../linux-26-headers/include/asm-m32r/param.h | 23 - .../linux-26-headers/include/asm-m32r/pci.h | 8 - .../include/asm-m32r/percpu.h | 6 - .../include/asm-m32r/pgalloc.h | 76 - .../include/asm-m32r/pgtable-2level.h | 78 - .../include/asm-m32r/pgtable.h | 363 - .../linux-26-headers/include/asm-m32r/poll.h | 1 - .../include/asm-m32r/posix_types.h | 118 - .../include/asm-m32r/processor.h | 147 - .../include/asm-m32r/ptrace.h | 148 - .../include/asm-m32r/resource.h | 6 - .../linux-26-headers/include/asm-m32r/rtc.h | 65 - .../include/asm-m32r/s1d13806.h | 199 - .../include/asm-m32r/scatterlist.h | 21 - .../include/asm-m32r/sections.h | 7 - .../include/asm-m32r/segment.h | 10 - .../include/asm-m32r/sembuf.h | 25 - .../include/asm-m32r/serial.h | 9 - .../linux-26-headers/include/asm-m32r/setup.h | 38 - .../include/asm-m32r/shmbuf.h | 42 - .../include/asm-m32r/shmparam.h | 6 - .../include/asm-m32r/sigcontext.h | 39 - .../include/asm-m32r/siginfo.h | 6 - .../include/asm-m32r/signal.h | 166 - .../linux-26-headers/include/asm-m32r/smp.h | 121 - .../include/asm-m32r/socket.h | 57 - .../include/asm-m32r/sockios.h | 13 - .../include/asm-m32r/spinlock.h | 323 - .../include/asm-m32r/spinlock_types.h | 23 - .../linux-26-headers/include/asm-m32r/stat.h | 87 - .../include/asm-m32r/statfs.h | 6 - .../include/asm-m32r/string.h | 13 - .../include/asm-m32r/syscall.h | 8 - .../include/asm-m32r/system.h | 431 - .../include/asm-m32r/termbits.h | 199 - .../include/asm-m32r/termios.h | 91 - .../include/asm-m32r/thread_info.h | 184 - .../linux-26-headers/include/asm-m32r/timex.h | 27 - .../linux-26-headers/include/asm-m32r/tlb.h | 20 - .../include/asm-m32r/tlbflush.h | 97 - .../include/asm-m32r/topology.h | 6 - .../linux-26-headers/include/asm-m32r/types.h | 30 - .../include/asm-m32r/uaccess.h | 693 - .../include/asm-m32r/ucontext.h | 12 - .../include/asm-m32r/unaligned.h | 18 - .../include/asm-m32r/unistd.h | 389 - .../linux-26-headers/include/asm-m32r/user.h | 52 - .../linux-26-headers/include/asm-m32r/vga.h | 20 - .../linux-26-headers/include/asm-m32r/xor.h | 6 - .../linux-26-headers/include/asm-m68k/Kbuild | 2 - .../include/asm-m68k/a.out-core.h | 67 - .../linux-26-headers/include/asm-m68k/a.out.h | 20 - .../include/asm-m68k/adb_iop.h | 44 - .../include/asm-m68k/amigahw.h | 350 - .../include/asm-m68k/amigaints.h | 113 - .../include/asm-m68k/amigayle.h | 107 - .../include/asm-m68k/amipcmcia.h | 110 - .../include/asm-m68k/apollodma.h | 248 - .../include/asm-m68k/apollohw.h | 108 - .../linux-26-headers/include/asm-m68k/atafd.h | 12 - .../include/asm-m68k/atafdreg.h | 79 - .../include/asm-m68k/atari_joystick.h | 22 - .../include/asm-m68k/atari_stdma.h | 22 - .../include/asm-m68k/atari_stram.h | 17 - .../include/asm-m68k/atarihw.h | 808 - .../include/asm-m68k/atariints.h | 204 - .../include/asm-m68k/atarikb.h | 46 - .../include/asm-m68k/atomic.h | 197 - .../include/asm-m68k/auxvec.h | 4 - .../include/asm-m68k/bitops.h | 459 - .../include/asm-m68k/blinken.h | 32 - .../include/asm-m68k/bootinfo.h | 378 - .../linux-26-headers/include/asm-m68k/bug.h | 29 - .../linux-26-headers/include/asm-m68k/bugs.h | 14 - .../include/asm-m68k/bvme6000hw.h | 150 - .../include/asm-m68k/byteorder.h | 25 - .../linux-26-headers/include/asm-m68k/cache.h | 11 - .../include/asm-m68k/cachectl.h | 14 - .../include/asm-m68k/cacheflush.h | 156 - .../include/asm-m68k/checksum.h | 148 - .../include/asm-m68k/contregs.h | 53 - .../include/asm-m68k/cputime.h | 6 - .../include/asm-m68k/current.h | 6 - .../linux-26-headers/include/asm-m68k/delay.h | 57 - .../include/asm-m68k/device.h | 7 - .../linux-26-headers/include/asm-m68k/div64.h | 28 - .../include/asm-m68k/dma-mapping.h | 96 - .../linux-26-headers/include/asm-m68k/dma.h | 20 - .../include/asm-m68k/dsp56k.h | 35 - .../linux-26-headers/include/asm-m68k/dvma.h | 240 - .../linux-26-headers/include/asm-m68k/elf.h | 119 - .../include/asm-m68k/emergency-restart.h | 6 - .../linux-26-headers/include/asm-m68k/entry.h | 137 - .../linux-26-headers/include/asm-m68k/errno.h | 6 - l4/pkg/linux-26-headers/include/asm-m68k/fb.h | 34 - .../linux-26-headers/include/asm-m68k/fbio.h | 330 - .../linux-26-headers/include/asm-m68k/fcntl.h | 11 - .../include/asm-m68k/floppy.h | 254 - .../linux-26-headers/include/asm-m68k/fpu.h | 21 - .../linux-26-headers/include/asm-m68k/futex.h | 6 - .../include/asm-m68k/hardirq.h | 16 - .../include/asm-m68k/hp300hw.h | 25 - .../include/asm-m68k/hw_irq.h | 6 - .../include/asm-m68k/hwtest.h | 15 - .../linux-26-headers/include/asm-m68k/ide.h | 139 - .../include/asm-m68k/idprom.h | 27 - .../include/asm-m68k/intersil.h | 48 - l4/pkg/linux-26-headers/include/asm-m68k/io.h | 421 - .../linux-26-headers/include/asm-m68k/ioctl.h | 1 - .../include/asm-m68k/ioctls.h | 84 - .../include/asm-m68k/ipcbuf.h | 29 - .../linux-26-headers/include/asm-m68k/irq.h | 125 - .../include/asm-m68k/irq_regs.h | 1 - .../include/asm-m68k/kdebug.h | 1 - .../include/asm-m68k/kmap_types.h | 21 - .../include/asm-m68k/linkage.h | 7 - .../linux-26-headers/include/asm-m68k/local.h | 6 - .../include/asm-m68k/mac_asc.h | 27 - .../include/asm-m68k/mac_baboon.h | 32 - .../include/asm-m68k/mac_iop.h | 162 - .../include/asm-m68k/mac_mouse.h | 23 - .../include/asm-m68k/mac_oss.h | 94 - .../include/asm-m68k/mac_psc.h | 248 - .../include/asm-m68k/mac_via.h | 267 - .../include/asm-m68k/machdep.h | 35 - .../include/asm-m68k/machines.h | 85 - .../linux-26-headers/include/asm-m68k/machw.h | 71 - .../include/asm-m68k/macintosh.h | 135 - .../include/asm-m68k/macints.h | 155 - .../include/asm-m68k/math-emu.h | 315 - .../include/asm-m68k/mc146818rtc.h | 26 - l4/pkg/linux-26-headers/include/asm-m68k/md.h | 13 - .../linux-26-headers/include/asm-m68k/mman.h | 17 - .../linux-26-headers/include/asm-m68k/mmu.h | 7 - .../include/asm-m68k/mmu_context.h | 154 - .../include/asm-m68k/mmzone.h | 9 - .../include/asm-m68k/module.h | 39 - .../include/asm-m68k/motorola_pgalloc.h | 109 - .../include/asm-m68k/motorola_pgtable.h | 291 - .../linux-26-headers/include/asm-m68k/movs.h | 55 - .../include/asm-m68k/msgbuf.h | 31 - .../linux-26-headers/include/asm-m68k/mutex.h | 9 - .../include/asm-m68k/mvme147hw.h | 113 - .../include/asm-m68k/mvme16xhw.h | 111 - .../linux-26-headers/include/asm-m68k/nubus.h | 46 - .../include/asm-m68k/openprom.h | 312 - .../linux-26-headers/include/asm-m68k/oplib.h | 291 - .../linux-26-headers/include/asm-m68k/page.h | 228 - .../include/asm-m68k/page_offset.h | 8 - .../linux-26-headers/include/asm-m68k/param.h | 22 - .../include/asm-m68k/parport.h | 26 - .../linux-26-headers/include/asm-m68k/pci.h | 57 - .../include/asm-m68k/percpu.h | 6 - .../include/asm-m68k/pgalloc.h | 19 - .../include/asm-m68k/pgtable.h | 166 - .../linux-26-headers/include/asm-m68k/poll.h | 9 - .../include/asm-m68k/posix_types.h | 61 - .../include/asm-m68k/processor.h | 130 - .../include/asm-m68k/ptrace.h | 80 - .../include/asm-m68k/q40_master.h | 69 - .../include/asm-m68k/q40ints.h | 29 - .../include/asm-m68k/raw_io.h | 347 - .../include/asm-m68k/resource.h | 6 - .../linux-26-headers/include/asm-m68k/rtc.h | 76 - .../linux-26-headers/include/asm-m68k/sbus.h | 45 - .../include/asm-m68k/scatterlist.h | 23 - .../include/asm-m68k/sections.h | 6 - .../include/asm-m68k/segment.h | 57 - .../include/asm-m68k/sembuf.h | 25 - .../include/asm-m68k/serial.h | 33 - .../linux-26-headers/include/asm-m68k/setup.h | 376 - .../linux-26-headers/include/asm-m68k/shm.h | 31 - .../include/asm-m68k/shmbuf.h | 42 - .../include/asm-m68k/shmparam.h | 6 - .../include/asm-m68k/sigcontext.h | 19 - .../include/asm-m68k/siginfo.h | 92 - .../include/asm-m68k/signal.h | 206 - .../include/asm-m68k/socket.h | 57 - .../include/asm-m68k/sockios.h | 13 - .../include/asm-m68k/spinlock.h | 6 - .../linux-26-headers/include/asm-m68k/stat.h | 77 - .../include/asm-m68k/statfs.h | 6 - .../include/asm-m68k/string.h | 131 - .../include/asm-m68k/sun3-head.h | 10 - .../include/asm-m68k/sun3_pgalloc.h | 102 - .../include/asm-m68k/sun3_pgtable.h | 234 - .../include/asm-m68k/sun3ints.h | 37 - .../include/asm-m68k/sun3mmu.h | 171 - .../linux-26-headers/include/asm-m68k/sun3x.h | 27 - .../include/asm-m68k/sun3xflop.h | 263 - .../include/asm-m68k/sun3xprom.h | 43 - .../include/asm-m68k/suspend.h | 6 - .../include/asm-m68k/system.h | 218 - .../include/asm-m68k/termbits.h | 200 - .../include/asm-m68k/termios.h | 92 - .../include/asm-m68k/thread_info.h | 56 - .../linux-26-headers/include/asm-m68k/timex.h | 18 - .../linux-26-headers/include/asm-m68k/tlb.h | 20 - .../include/asm-m68k/tlbflush.h | 219 - .../include/asm-m68k/topology.h | 6 - .../linux-26-headers/include/asm-m68k/traps.h | 272 - .../linux-26-headers/include/asm-m68k/types.h | 37 - .../include/asm-m68k/uaccess.h | 374 - .../include/asm-m68k/ucontext.h | 30 - .../include/asm-m68k/unaligned.h | 13 - .../include/asm-m68k/unistd.h | 374 - .../linux-26-headers/include/asm-m68k/user.h | 86 - .../include/asm-m68k/virtconvert.h | 54 - .../linux-26-headers/include/asm-m68k/xor.h | 1 - .../linux-26-headers/include/asm-m68k/zorro.h | 45 - .../linux-26-headers/include/asm-mips/Kbuild | 3 - .../linux-26-headers/include/asm-mips/a.out.h | 35 - .../linux-26-headers/include/asm-mips/abi.h | 25 - .../include/asm-mips/addrspace.h | 154 - .../linux-26-headers/include/asm-mips/asm.h | 409 - .../include/asm-mips/asmmacro-32.h | 158 - .../include/asm-mips/asmmacro-64.h | 139 - .../include/asm-mips/asmmacro.h | 82 - .../include/asm-mips/atomic.h | 801 - .../include/asm-mips/auxvec.h | 4 - .../include/asm-mips/barrier.h | 155 - .../include/asm-mips/bcache.h | 60 - .../include/asm-mips/bitops.h | 672 - .../include/asm-mips/bootinfo.h | 110 - .../include/asm-mips/branch.h | 38 - .../linux-26-headers/include/asm-mips/break.h | 34 - .../linux-26-headers/include/asm-mips/bug.h | 33 - .../linux-26-headers/include/asm-mips/bugs.h | 53 - .../include/asm-mips/byteorder.h | 76 - .../linux-26-headers/include/asm-mips/cache.h | 20 - .../include/asm-mips/cachectl.h | 26 - .../include/asm-mips/cacheflush.h | 116 - .../include/asm-mips/cacheops.h | 85 - .../include/asm-mips/cevt-r4k.h | 46 - .../include/asm-mips/checksum.h | 260 - .../linux-26-headers/include/asm-mips/cmp.h | 18 - .../include/asm-mips/cmpxchg.h | 124 - .../include/asm-mips/compat-signal.h | 119 - .../include/asm-mips/compat.h | 221 - .../include/asm-mips/compiler.h | 19 - .../include/asm-mips/cpu-features.h | 219 - .../include/asm-mips/cpu-info.h | 84 - .../linux-26-headers/include/asm-mips/cpu.h | 267 - .../include/asm-mips/cputime.h | 6 - .../include/asm-mips/current.h | 23 - .../linux-26-headers/include/asm-mips/debug.h | 48 - .../include/asm-mips/dec/ecc.h | 55 - .../include/asm-mips/dec/interrupts.h | 126 - .../include/asm-mips/dec/ioasic.h | 38 - .../include/asm-mips/dec/ioasic_addrs.h | 152 - .../include/asm-mips/dec/ioasic_ints.h | 74 - .../include/asm-mips/dec/kn01.h | 90 - .../include/asm-mips/dec/kn02.h | 91 - .../include/asm-mips/dec/kn02ba.h | 67 - .../include/asm-mips/dec/kn02ca.h | 79 - .../include/asm-mips/dec/kn02xa.h | 84 - .../include/asm-mips/dec/kn03.h | 74 - .../include/asm-mips/dec/kn05.h | 76 - .../include/asm-mips/dec/kn230.h | 26 - .../include/asm-mips/dec/machtype.h | 27 - .../include/asm-mips/dec/prom.h | 174 - .../include/asm-mips/dec/system.h | 19 - .../linux-26-headers/include/asm-mips/delay.h | 112 - .../include/asm-mips/device.h | 7 - .../linux-26-headers/include/asm-mips/div64.h | 110 - .../include/asm-mips/dma-mapping.h | 81 - .../linux-26-headers/include/asm-mips/dma.h | 315 - .../include/asm-mips/ds1286.h | 15 - .../include/asm-mips/ds1287.h | 27 - .../linux-26-headers/include/asm-mips/dsp.h | 85 - .../linux-26-headers/include/asm-mips/edac.h | 34 - .../linux-26-headers/include/asm-mips/elf.h | 371 - .../include/asm-mips/emergency-restart.h | 6 - .../include/asm-mips/emma2rh/emma2rh.h | 333 - .../include/asm-mips/emma2rh/markeins.h | 75 - .../linux-26-headers/include/asm-mips/errno.h | 131 - l4/pkg/linux-26-headers/include/asm-mips/fb.h | 19 - .../linux-26-headers/include/asm-mips/fcntl.h | 61 - .../include/asm-mips/fixmap.h | 118 - .../include/asm-mips/floppy.h | 56 - .../include/asm-mips/fpregdef.h | 99 - .../linux-26-headers/include/asm-mips/fpu.h | 153 - .../include/asm-mips/fpu_emulator.h | 37 - .../linux-26-headers/include/asm-mips/futex.h | 203 - .../include/asm-mips/fw/arc/hinv.h | 175 - .../include/asm-mips/fw/arc/types.h | 86 - .../include/asm-mips/fw/cfe/cfe_api.h | 122 - .../include/asm-mips/fw/cfe/cfe_error.h | 80 - .../include/asm-mips/gcmpregs.h | 117 - .../linux-26-headers/include/asm-mips/gic.h | 487 - .../linux-26-headers/include/asm-mips/gpio.h | 6 - .../include/asm-mips/gt64120.h | 580 - .../include/asm-mips/hardirq.h | 24 - .../include/asm-mips/hazards.h | 271 - .../include/asm-mips/highmem.h | 67 - .../include/asm-mips/hw_irq.h | 20 - .../linux-26-headers/include/asm-mips/i8253.h | 21 - .../linux-26-headers/include/asm-mips/i8259.h | 86 - .../linux-26-headers/include/asm-mips/ide.h | 13 - .../linux-26-headers/include/asm-mips/inst.h | 394 - l4/pkg/linux-26-headers/include/asm-mips/io.h | 589 - .../linux-26-headers/include/asm-mips/ioctl.h | 94 - .../include/asm-mips/ioctls.h | 109 - .../include/asm-mips/ip32/crime.h | 158 - .../include/asm-mips/ip32/ip32_ints.h | 114 - .../include/asm-mips/ip32/mace.h | 365 - .../include/asm-mips/ipcbuf.h | 28 - .../linux-26-headers/include/asm-mips/irq.h | 163 - .../include/asm-mips/irq_cpu.h | 20 - .../include/asm-mips/irq_gt641xx.h | 60 - .../include/asm-mips/irq_regs.h | 21 - .../include/asm-mips/irqflags.h | 283 - .../include/asm-mips/isadep.h | 34 - .../linux-26-headers/include/asm-mips/jazz.h | 310 - .../include/asm-mips/jazzdma.h | 95 - .../include/asm-mips/kdebug.h | 13 - .../linux-26-headers/include/asm-mips/kexec.h | 30 - .../linux-26-headers/include/asm-mips/kgdb.h | 44 - .../include/asm-mips/kmap_types.h | 30 - .../linux-26-headers/include/asm-mips/kspd.h | 36 - .../include/asm-mips/lasat/ds1603.h | 18 - .../include/asm-mips/lasat/eeprom.h | 17 - .../include/asm-mips/lasat/head.h | 22 - .../include/asm-mips/lasat/lasat.h | 258 - .../include/asm-mips/lasat/lasatint.h | 14 - .../include/asm-mips/lasat/picvue.h | 15 - .../include/asm-mips/lasat/serial.h | 13 - .../include/asm-mips/linkage.h | 10 - .../linux-26-headers/include/asm-mips/local.h | 221 - .../include/asm-mips/m48t35.h | 27 - .../include/asm-mips/m48t37.h | 35 - .../include/asm-mips/mach-au1x00/au1000.h | 1772 - .../include/asm-mips/mach-au1x00/au1000_dma.h | 458 - .../asm-mips/mach-au1x00/au1000_gpio.h | 56 - .../include/asm-mips/mach-au1x00/au1100_mmc.h | 208 - .../include/asm-mips/mach-au1x00/au1550_spi.h | 15 - .../include/asm-mips/mach-au1x00/au1xxx.h | 43 - .../asm-mips/mach-au1x00/au1xxx_dbdma.h | 386 - .../include/asm-mips/mach-au1x00/au1xxx_ide.h | 194 - .../include/asm-mips/mach-au1x00/au1xxx_psc.h | 505 - .../include/asm-mips/mach-au1x00/gpio.h | 69 - .../include/asm-mips/mach-au1x00/ioremap.h | 42 - .../include/asm-mips/mach-au1x00/prom.h | 13 - .../include/asm-mips/mach-au1x00/war.h | 25 - .../include/asm-mips/mach-bcm47xx/bcm47xx.h | 25 - .../include/asm-mips/mach-bcm47xx/gpio.h | 59 - .../include/asm-mips/mach-bcm47xx/war.h | 25 - .../include/asm-mips/mach-cobalt/cobalt.h | 22 - .../mach-cobalt/cpu-feature-overrides.h | 56 - .../include/asm-mips/mach-cobalt/irq.h | 57 - .../asm-mips/mach-cobalt/mach-gt64120.h | 27 - .../include/asm-mips/mach-cobalt/war.h | 25 - .../include/asm-mips/mach-db1x00/db1200.h | 230 - .../include/asm-mips/mach-db1x00/db1x00.h | 179 - .../include/asm-mips/mach-dec/mc146818rtc.h | 43 - .../include/asm-mips/mach-dec/war.h | 25 - .../include/asm-mips/mach-emma2rh/irq.h | 15 - .../include/asm-mips/mach-emma2rh/war.h | 25 - .../mach-excite/cpu-feature-overrides.h | 48 - .../include/asm-mips/mach-excite/excite.h | 154 - .../asm-mips/mach-excite/excite_fpga.h | 80 - .../asm-mips/mach-excite/excite_nandflash.h | 7 - .../include/asm-mips/mach-excite/rm9k_eth.h | 23 - .../include/asm-mips/mach-excite/rm9k_wdt.h | 12 - .../include/asm-mips/mach-excite/rm9k_xicap.h | 16 - .../include/asm-mips/mach-excite/war.h | 25 - .../mach-generic/cpu-feature-overrides.h | 13 - .../asm-mips/mach-generic/dma-coherence.h | 45 - .../include/asm-mips/mach-generic/floppy.h | 139 - .../include/asm-mips/mach-generic/gpio.h | 21 - .../include/asm-mips/mach-generic/ide.h | 167 - .../include/asm-mips/mach-generic/ioremap.h | 34 - .../include/asm-mips/mach-generic/irq.h | 45 - .../asm-mips/mach-generic/kernel-entry-init.h | 25 - .../include/asm-mips/mach-generic/kmalloc.h | 13 - .../asm-mips/mach-generic/mangle-port.h | 52 - .../asm-mips/mach-generic/mc146818rtc.h | 36 - .../include/asm-mips/mach-generic/spaces.h | 85 - .../include/asm-mips/mach-generic/topology.h | 1 - .../mach-ip22/cpu-feature-overrides.h | 44 - .../include/asm-mips/mach-ip22/ds1286.h | 18 - .../include/asm-mips/mach-ip22/spaces.h | 27 - .../include/asm-mips/mach-ip22/war.h | 29 - .../mach-ip27/cpu-feature-overrides.h | 54 - .../asm-mips/mach-ip27/dma-coherence.h | 50 - .../include/asm-mips/mach-ip27/irq.h | 22 - .../asm-mips/mach-ip27/kernel-entry-init.h | 59 - .../include/asm-mips/mach-ip27/kmalloc.h | 8 - .../include/asm-mips/mach-ip27/mangle-port.h | 25 - .../include/asm-mips/mach-ip27/mmzone.h | 36 - .../include/asm-mips/mach-ip27/spaces.h | 30 - .../include/asm-mips/mach-ip27/topology.h | 59 - .../include/asm-mips/mach-ip27/war.h | 25 - .../mach-ip28/cpu-feature-overrides.h | 50 - .../include/asm-mips/mach-ip28/ds1286.h | 4 - .../include/asm-mips/mach-ip28/spaces.h | 22 - .../include/asm-mips/mach-ip28/war.h | 25 - .../mach-ip32/cpu-feature-overrides.h | 50 - .../asm-mips/mach-ip32/dma-coherence.h | 72 - .../include/asm-mips/mach-ip32/kmalloc.h | 11 - .../include/asm-mips/mach-ip32/mangle-port.h | 26 - .../include/asm-mips/mach-ip32/mc146818rtc.h | 36 - .../include/asm-mips/mach-ip32/war.h | 25 - .../asm-mips/mach-jazz/dma-coherence.h | 40 - .../include/asm-mips/mach-jazz/floppy.h | 135 - .../include/asm-mips/mach-jazz/mc146818rtc.h | 38 - .../include/asm-mips/mach-jazz/war.h | 25 - .../include/asm-mips/mach-lasat/irq.h | 13 - .../asm-mips/mach-lasat/mach-gt64120.h | 27 - .../include/asm-mips/mach-lasat/war.h | 25 - .../asm-mips/mach-lemote/dma-coherence.h | 42 - .../asm-mips/mach-lemote/mc146818rtc.h | 36 - .../include/asm-mips/mach-lemote/war.h | 25 - .../mach-malta/cpu-feature-overrides.h | 72 - .../include/asm-mips/mach-malta/irq.h | 9 - .../asm-mips/mach-malta/kernel-entry-init.h | 52 - .../asm-mips/mach-malta/mach-gt64120.h | 19 - .../include/asm-mips/mach-malta/mc146818rtc.h | 48 - .../include/asm-mips/mach-malta/war.h | 25 - .../mach-mipssim/cpu-feature-overrides.h | 65 - .../include/asm-mips/mach-mipssim/war.h | 25 - .../asm-mips/mach-pb1x00/mc146818rtc.h | 34 - .../include/asm-mips/mach-pb1x00/pb1000.h | 87 - .../include/asm-mips/mach-pb1x00/pb1100.h | 85 - .../include/asm-mips/mach-pb1x00/pb1200.h | 259 - .../include/asm-mips/mach-pb1x00/pb1500.h | 49 - .../include/asm-mips/mach-pb1x00/pb1550.h | 177 - .../include/asm-mips/mach-pnx8550/cm.h | 43 - .../include/asm-mips/mach-pnx8550/glb.h | 86 - .../include/asm-mips/mach-pnx8550/int.h | 140 - .../asm-mips/mach-pnx8550/kernel-entry-init.h | 262 - .../include/asm-mips/mach-pnx8550/nand.h | 121 - .../include/asm-mips/mach-pnx8550/pci.h | 185 - .../include/asm-mips/mach-pnx8550/uart.h | 30 - .../include/asm-mips/mach-pnx8550/usb.h | 32 - .../include/asm-mips/mach-pnx8550/war.h | 25 - .../mach-rc32434/cpu-feature-overrides.h | 81 - .../include/asm-mips/mach-rc32434/ddr.h | 141 - .../include/asm-mips/mach-rc32434/dma.h | 103 - .../include/asm-mips/mach-rc32434/dma_v.h | 52 - .../include/asm-mips/mach-rc32434/eth.h | 220 - .../include/asm-mips/mach-rc32434/gpio.h | 126 - .../include/asm-mips/mach-rc32434/integ.h | 59 - .../include/asm-mips/mach-rc32434/irq.h | 8 - .../include/asm-mips/mach-rc32434/pci.h | 481 - .../include/asm-mips/mach-rc32434/prom.h | 44 - .../include/asm-mips/mach-rc32434/rb.h | 81 - .../include/asm-mips/mach-rc32434/rc32434.h | 61 - .../include/asm-mips/mach-rc32434/timer.h | 65 - .../include/asm-mips/mach-rc32434/war.h | 25 - .../asm-mips/mach-rm/cpu-feature-overrides.h | 43 - .../include/asm-mips/mach-rm/mc146818rtc.h | 21 - .../include/asm-mips/mach-rm/war.h | 29 - .../mach-sibyte/cpu-feature-overrides.h | 47 - .../include/asm-mips/mach-sibyte/war.h | 37 - .../include/asm-mips/mach-tx39xx/ioremap.h | 38 - .../asm-mips/mach-tx39xx/mangle-port.h | 23 - .../include/asm-mips/mach-tx39xx/war.h | 25 - .../mach-tx49xx/cpu-feature-overrides.h | 23 - .../include/asm-mips/mach-tx49xx/ioremap.h | 43 - .../include/asm-mips/mach-tx49xx/kmalloc.h | 8 - .../include/asm-mips/mach-tx49xx/war.h | 25 - .../include/asm-mips/mach-vr41xx/irq.h | 8 - .../include/asm-mips/mach-vr41xx/war.h | 25 - .../asm-mips/mach-wrppmc/mach-gt64120.h | 83 - .../include/asm-mips/mach-wrppmc/war.h | 25 - .../mach-yosemite/cpu-feature-overrides.h | 47 - .../include/asm-mips/mach-yosemite/war.h | 25 - .../include/asm-mips/mc146818-time.h | 119 - .../include/asm-mips/mc146818rtc.h | 16 - .../include/asm-mips/mips-boards/bonito64.h | 436 - .../include/asm-mips/mips-boards/generic.h | 104 - .../include/asm-mips/mips-boards/launch.h | 35 - .../include/asm-mips/mips-boards/malta.h | 102 - .../include/asm-mips/mips-boards/maltaint.h | 110 - .../include/asm-mips/mips-boards/msc01_pci.h | 258 - .../include/asm-mips/mips-boards/piix4.h | 80 - .../include/asm-mips/mips-boards/prom.h | 47 - .../include/asm-mips/mips-boards/sim.h | 40 - .../include/asm-mips/mips-boards/simint.h | 31 - .../include/asm-mips/mips_mt.h | 26 - .../include/asm-mips/mipsmtregs.h | 395 - .../include/asm-mips/mipsprom.h | 76 - .../include/asm-mips/mipsregs.h | 1526 - .../linux-26-headers/include/asm-mips/mman.h | 77 - .../linux-26-headers/include/asm-mips/mmu.h | 6 - .../include/asm-mips/mmu_context.h | 297 - .../include/asm-mips/mmzone.h | 17 - .../include/asm-mips/module.h | 136 - .../include/asm-mips/msc01_ic.h | 148 - .../include/asm-mips/msgbuf.h | 47 - .../linux-26-headers/include/asm-mips/mutex.h | 9 - .../linux-26-headers/include/asm-mips/nile4.h | 310 - .../include/asm-mips/paccess.h | 112 - .../linux-26-headers/include/asm-mips/page.h | 191 - .../linux-26-headers/include/asm-mips/param.h | 31 - .../include/asm-mips/parport.h | 15 - .../linux-26-headers/include/asm-mips/pci.h | 179 - .../include/asm-mips/pci/bridge.h | 854 - .../include/asm-mips/percpu.h | 6 - .../include/asm-mips/pgalloc.h | 143 - .../include/asm-mips/pgtable-32.h | 234 - .../include/asm-mips/pgtable-64.h | 253 - .../include/asm-mips/pgtable-bits.h | 137 - .../include/asm-mips/pgtable.h | 383 - .../asm-mips/pmc-sierra/msp71xx/msp_cic_int.h | 151 - .../asm-mips/pmc-sierra/msp71xx/msp_int.h | 43 - .../asm-mips/pmc-sierra/msp71xx/msp_pci.h | 205 - .../asm-mips/pmc-sierra/msp71xx/msp_prom.h | 176 - .../asm-mips/pmc-sierra/msp71xx/msp_regops.h | 236 - .../asm-mips/pmc-sierra/msp71xx/msp_regs.h | 663 - .../asm-mips/pmc-sierra/msp71xx/msp_slp_int.h | 141 - .../include/asm-mips/pmc-sierra/msp71xx/war.h | 28 - .../linux-26-headers/include/asm-mips/pmon.h | 46 - .../linux-26-headers/include/asm-mips/poll.h | 9 - .../include/asm-mips/posix_types.h | 144 - .../include/asm-mips/prefetch.h | 87 - .../include/asm-mips/processor.h | 263 - .../include/asm-mips/ptrace.h | 99 - .../include/asm-mips/r4k-timer.h | 30 - .../include/asm-mips/r4kcache.h | 443 - .../include/asm-mips/reboot.h | 15 - .../linux-26-headers/include/asm-mips/reg.h | 128 - .../include/asm-mips/regdef.h | 100 - .../include/asm-mips/resource.h | 35 - .../include/asm-mips/rm9k-ocd.h | 56 - .../linux-26-headers/include/asm-mips/rtlx.h | 65 - .../include/asm-mips/scatterlist.h | 28 - .../include/asm-mips/seccomp.h | 37 - .../include/asm-mips/sections.h | 6 - .../include/asm-mips/segment.h | 6 - .../include/asm-mips/sembuf.h | 22 - .../include/asm-mips/serial.h | 22 - .../linux-26-headers/include/asm-mips/setup.h | 10 - .../include/asm-mips/sgi/gio.h | 86 - .../include/asm-mips/sgi/hpc3.h | 317 - .../include/asm-mips/sgi/ioc.h | 200 - .../include/asm-mips/sgi/ip22.h | 78 - .../include/asm-mips/sgi/mc.h | 231 - .../include/asm-mips/sgi/pi1.h | 71 - .../include/asm-mips/sgi/seeq.h | 21 - .../include/asm-mips/sgi/sgi.h | 47 - .../include/asm-mips/sgi/wd.h | 20 - .../include/asm-mips/sgialib.h | 124 - .../include/asm-mips/sgiarcs.h | 548 - .../include/asm-mips/sgidefs.h | 44 - .../include/asm-mips/shmbuf.h | 38 - .../include/asm-mips/shmparam.h | 13 - .../include/asm-mips/sibyte/bcm1480_int.h | 312 - .../include/asm-mips/sibyte/bcm1480_l2c.h | 176 - .../include/asm-mips/sibyte/bcm1480_mc.h | 984 - .../include/asm-mips/sibyte/bcm1480_regs.h | 902 - .../include/asm-mips/sibyte/bcm1480_scd.h | 406 - .../include/asm-mips/sibyte/bigsur.h | 49 - .../include/asm-mips/sibyte/board.h | 68 - .../include/asm-mips/sibyte/carmel.h | 58 - .../include/asm-mips/sibyte/sb1250.h | 68 - .../include/asm-mips/sibyte/sb1250_defs.h | 259 - .../include/asm-mips/sibyte/sb1250_dma.h | 594 - .../include/asm-mips/sibyte/sb1250_genbus.h | 474 - .../include/asm-mips/sibyte/sb1250_int.h | 248 - .../include/asm-mips/sibyte/sb1250_l2c.h | 131 - .../include/asm-mips/sibyte/sb1250_ldt.h | 423 - .../include/asm-mips/sibyte/sb1250_mac.h | 656 - .../include/asm-mips/sibyte/sb1250_mc.h | 550 - .../include/asm-mips/sibyte/sb1250_regs.h | 893 - .../include/asm-mips/sibyte/sb1250_scd.h | 654 - .../include/asm-mips/sibyte/sb1250_smbus.h | 204 - .../include/asm-mips/sibyte/sb1250_syncser.h | 146 - .../include/asm-mips/sibyte/sb1250_uart.h | 362 - .../include/asm-mips/sibyte/sentosa.h | 40 - .../include/asm-mips/sibyte/swarm.h | 64 - .../include/asm-mips/sigcontext.h | 100 - .../include/asm-mips/siginfo.h | 130 - .../include/asm-mips/signal.h | 139 - .../linux-26-headers/include/asm-mips/sim.h | 82 - .../include/asm-mips/smp-ops.h | 57 - .../linux-26-headers/include/asm-mips/smp.h | 63 - .../linux-26-headers/include/asm-mips/smtc.h | 71 - .../include/asm-mips/smtc_ipi.h | 128 - .../include/asm-mips/smtc_proc.h | 23 - .../linux-26-headers/include/asm-mips/smvp.h | 19 - .../include/asm-mips/sn/addrs.h | 430 - .../include/asm-mips/sn/agent.h | 46 - .../include/asm-mips/sn/arch.h | 64 - .../include/asm-mips/sn/fru.h | 44 - .../include/asm-mips/sn/gda.h | 107 - .../include/asm-mips/sn/hub.h | 16 - .../include/asm-mips/sn/intr.h | 129 - .../linux-26-headers/include/asm-mips/sn/io.h | 59 - .../include/asm-mips/sn/ioc3.h | 663 - .../include/asm-mips/sn/klconfig.h | 898 - .../include/asm-mips/sn/kldir.h | 217 - .../include/asm-mips/sn/klkernvars.h | 29 - .../include/asm-mips/sn/launch.h | 106 - .../include/asm-mips/sn/mapped_kernel.h | 54 - .../include/asm-mips/sn/nmi.h | 125 - .../include/asm-mips/sn/sn0/addrs.h | 288 - .../include/asm-mips/sn/sn0/arch.h | 72 - .../include/asm-mips/sn/sn0/hub.h | 40 - .../include/asm-mips/sn/sn0/hubio.h | 972 - .../include/asm-mips/sn/sn0/hubmd.h | 789 - .../include/asm-mips/sn/sn0/hubni.h | 255 - .../include/asm-mips/sn/sn0/hubpi.h | 409 - .../include/asm-mips/sn/sn0/ip27.h | 85 - .../include/asm-mips/sn/sn_private.h | 19 - .../include/asm-mips/sn/types.h | 26 - .../linux-26-headers/include/asm-mips/sni.h | 244 - .../include/asm-mips/socket.h | 117 - .../include/asm-mips/sockios.h | 26 - .../include/asm-mips/sparsemem.h | 14 - .../include/asm-mips/spinlock.h | 376 - .../include/asm-mips/spinlock_types.h | 20 - .../include/asm-mips/stackframe.h | 574 - .../include/asm-mips/stacktrace.h | 48 - .../linux-26-headers/include/asm-mips/stat.h | 132 - .../include/asm-mips/statfs.h | 96 - .../include/asm-mips/string.h | 143 - .../include/asm-mips/suspend.h | 6 - .../include/asm-mips/sysmips.h | 25 - .../include/asm-mips/system.h | 220 - .../include/asm-mips/termbits.h | 226 - .../include/asm-mips/termios.h | 132 - .../include/asm-mips/thread_info.h | 151 - .../linux-26-headers/include/asm-mips/time.h | 79 - .../linux-26-headers/include/asm-mips/timex.h | 43 - .../include/asm-mips/titan_dep.h | 231 - .../linux-26-headers/include/asm-mips/tlb.h | 23 - .../include/asm-mips/tlbdebug.h | 16 - .../include/asm-mips/tlbflush.h | 47 - .../include/asm-mips/topology.h | 17 - .../linux-26-headers/include/asm-mips/traps.h | 28 - .../include/asm-mips/txx9/generic.h | 62 - .../include/asm-mips/txx9/jmr3927.h | 180 - .../include/asm-mips/txx9/pci.h | 39 - .../include/asm-mips/txx9/rbtx4927.h | 89 - .../include/asm-mips/txx9/rbtx4938.h | 145 - .../include/asm-mips/txx9/smsc_fdc37m81x.h | 67 - .../include/asm-mips/txx9/spi.h | 19 - .../include/asm-mips/txx9/tx3927.h | 339 - .../include/asm-mips/txx9/tx4927.h | 255 - .../include/asm-mips/txx9/tx4927pcic.h | 203 - .../include/asm-mips/txx9/tx4938.h | 293 - .../include/asm-mips/txx9irq.h | 34 - .../include/asm-mips/txx9pio.h | 29 - .../include/asm-mips/txx9tmr.h | 67 - .../linux-26-headers/include/asm-mips/types.h | 54 - .../include/asm-mips/uaccess.h | 852 - .../include/asm-mips/ucontext.h | 21 - .../include/asm-mips/unaligned.h | 28 - .../include/asm-mips/unistd.h | 1037 - .../linux-26-headers/include/asm-mips/user.h | 58 - .../linux-26-headers/include/asm-mips/vga.h | 47 - .../linux-26-headers/include/asm-mips/vpe.h | 37 - .../include/asm-mips/vr41xx/capcella.h | 43 - .../include/asm-mips/vr41xx/giu.h | 78 - .../include/asm-mips/vr41xx/irq.h | 101 - .../include/asm-mips/vr41xx/mpc30x.h | 37 - .../include/asm-mips/vr41xx/pci.h | 90 - .../include/asm-mips/vr41xx/siu.h | 58 - .../include/asm-mips/vr41xx/tb0219.h | 42 - .../include/asm-mips/vr41xx/tb0226.h | 43 - .../include/asm-mips/vr41xx/tb0287.h | 43 - .../include/asm-mips/vr41xx/vr41xx.h | 152 - .../linux-26-headers/include/asm-mips/war.h | 244 - .../include/asm-mips/wbflush.h | 34 - .../linux-26-headers/include/asm-mips/xor.h | 1 - .../include/asm-mips/xtalk/xtalk.h | 52 - .../include/asm-mips/xtalk/xwidget.h | 167 - .../include/asm-mn10300/.gitignore | 2 - .../include/asm-mn10300/Kbuild | 1 - .../include/asm-mn10300/atomic.h | 166 - .../include/asm-mn10300/auxvec.h | 4 - .../include/asm-mn10300/bitops.h | 229 - .../include/asm-mn10300/bug.h | 35 - .../include/asm-mn10300/bugs.h | 20 - .../include/asm-mn10300/busctl-regs.h | 151 - .../include/asm-mn10300/byteorder.h | 46 - .../include/asm-mn10300/cache.h | 54 - .../include/asm-mn10300/cacheflush.h | 116 - .../include/asm-mn10300/checksum.h | 86 - .../include/asm-mn10300/cpu-regs.h | 290 - .../include/asm-mn10300/cputime.h | 1 - .../include/asm-mn10300/current.h | 37 - .../include/asm-mn10300/delay.h | 19 - .../include/asm-mn10300/device.h | 1 - .../include/asm-mn10300/div64.h | 100 - .../include/asm-mn10300/dma-mapping.h | 234 - .../include/asm-mn10300/dma.h | 118 - .../include/asm-mn10300/dmactl-regs.h | 101 - .../include/asm-mn10300/elf.h | 147 - .../include/asm-mn10300/emergency-restart.h | 1 - .../include/asm-mn10300/errno.h | 1 - .../include/asm-mn10300/exceptions.h | 121 - .../linux-26-headers/include/asm-mn10300/fb.h | 23 - .../include/asm-mn10300/fcntl.h | 1 - .../include/asm-mn10300/fpu.h | 85 - .../include/asm-mn10300/frame.inc | 91 - .../include/asm-mn10300/futex.h | 1 - .../include/asm-mn10300/gdb-stub.h | 183 - .../include/asm-mn10300/hardirq.h | 48 - .../include/asm-mn10300/highmem.h | 114 - .../include/asm-mn10300/hw_irq.h | 14 - .../include/asm-mn10300/ide.h | 39 - .../include/asm-mn10300/intctl-regs.h | 73 - .../linux-26-headers/include/asm-mn10300/io.h | 301 - .../include/asm-mn10300/ioctl.h | 1 - .../include/asm-mn10300/ioctls.h | 88 - .../include/asm-mn10300/ipc.h | 1 - .../include/asm-mn10300/ipcbuf.h | 29 - .../include/asm-mn10300/irq.h | 32 - .../include/asm-mn10300/irq_regs.h | 24 - .../include/asm-mn10300/kdebug.h | 22 - .../include/asm-mn10300/kmap_types.h | 31 - .../include/asm-mn10300/kprobes.h | 50 - .../include/asm-mn10300/linkage.h | 20 - .../include/asm-mn10300/local.h | 1 - .../include/asm-mn10300/mc146818rtc.h | 1 - .../include/asm-mn10300/mman.h | 28 - .../include/asm-mn10300/mmu.h | 19 - .../include/asm-mn10300/mmu_context.h | 138 - .../include/asm-mn10300/module.h | 27 - .../include/asm-mn10300/msgbuf.h | 31 - .../include/asm-mn10300/mutex.h | 16 - .../include/asm-mn10300/nmi.h | 14 - .../include/asm-mn10300/page.h | 128 - .../include/asm-mn10300/page_offset.h | 11 - .../include/asm-mn10300/param.h | 34 - .../include/asm-mn10300/pci.h | 124 - .../include/asm-mn10300/percpu.h | 1 - .../include/asm-mn10300/pgalloc.h | 56 - .../include/asm-mn10300/pgtable.h | 492 - .../include/asm-mn10300/pio-regs.h | 233 - .../include/asm-mn10300/poll.h | 1 - .../include/asm-mn10300/posix_types.h | 132 - .../asm-mn10300/proc-mn103e010/cache.h | 33 - .../asm-mn10300/proc-mn103e010/clock.h | 18 - .../include/asm-mn10300/proc-mn103e010/irq.h | 34 - .../include/asm-mn10300/proc-mn103e010/proc.h | 18 - .../include/asm-mn10300/processor.h | 186 - .../include/asm-mn10300/ptrace.h | 103 - .../include/asm-mn10300/reset-regs.h | 64 - .../include/asm-mn10300/resource.h | 1 - .../include/asm-mn10300/rtc-regs.h | 86 - .../include/asm-mn10300/rtc.h | 41 - .../include/asm-mn10300/scatterlist.h | 55 - .../include/asm-mn10300/sections.h | 1 - .../include/asm-mn10300/sembuf.h | 25 - .../include/asm-mn10300/serial-regs.h | 160 - .../include/asm-mn10300/serial.h | 36 - .../include/asm-mn10300/setup.h | 17 - .../include/asm-mn10300/shmbuf.h | 42 - .../include/asm-mn10300/shmparam.h | 6 - .../include/asm-mn10300/sigcontext.h | 52 - .../include/asm-mn10300/siginfo.h | 1 - .../include/asm-mn10300/signal.h | 171 - .../include/asm-mn10300/smp.h | 18 - .../include/asm-mn10300/socket.h | 57 - .../include/asm-mn10300/sockios.h | 13 - .../include/asm-mn10300/spinlock.h | 16 - .../include/asm-mn10300/stat.h | 78 - .../include/asm-mn10300/statfs.h | 1 - .../include/asm-mn10300/string.h | 32 - .../include/asm-mn10300/system.h | 237 - .../include/asm-mn10300/termbits.h | 200 - .../include/asm-mn10300/termios.h | 92 - .../include/asm-mn10300/thread_info.h | 170 - .../include/asm-mn10300/timer-regs.h | 293 - .../include/asm-mn10300/timex.h | 33 - .../include/asm-mn10300/tlb.h | 34 - .../include/asm-mn10300/tlbflush.h | 80 - .../include/asm-mn10300/topology.h | 1 - .../include/asm-mn10300/types.h | 38 - .../include/asm-mn10300/uaccess.h | 490 - .../include/asm-mn10300/ucontext.h | 22 - .../include/asm-mn10300/unaligned.h | 20 - .../include/asm-mn10300/unistd.h | 390 - .../include/asm-mn10300/unit-asb2303/clock.h | 45 - .../include/asm-mn10300/unit-asb2303/leds.h | 43 - .../include/asm-mn10300/unit-asb2303/serial.h | 136 - .../asm-mn10300/unit-asb2303/smc91111.h | 50 - .../include/asm-mn10300/unit-asb2303/timex.h | 135 - .../include/asm-mn10300/unit-asb2305/clock.h | 45 - .../include/asm-mn10300/unit-asb2305/leds.h | 51 - .../include/asm-mn10300/unit-asb2305/serial.h | 120 - .../include/asm-mn10300/unit-asb2305/timex.h | 135 - .../include/asm-mn10300/user.h | 53 - .../include/asm-mn10300/vga.h | 17 - .../include/asm-mn10300/xor.h | 1 - .../include/asm-parisc/Kbuild | 3 - .../include/asm-parisc/a.out.h | 20 - .../linux-26-headers/include/asm-parisc/agp.h | 24 - .../include/asm-parisc/asmregs.h | 183 - .../include/asm-parisc/assembly.h | 519 - .../include/asm-parisc/atomic.h | 348 - .../include/asm-parisc/auxvec.h | 4 - .../include/asm-parisc/bitops.h | 239 - .../linux-26-headers/include/asm-parisc/bug.h | 92 - .../include/asm-parisc/bugs.h | 19 - .../include/asm-parisc/byteorder.h | 82 - .../include/asm-parisc/cache.h | 60 - .../include/asm-parisc/cacheflush.h | 121 - .../include/asm-parisc/checksum.h | 210 - .../include/asm-parisc/compat.h | 165 - .../include/asm-parisc/compat_rt_sigframe.h | 50 - .../include/asm-parisc/compat_signal.h | 2 - .../include/asm-parisc/compat_ucontext.h | 17 - .../include/asm-parisc/cputime.h | 6 - .../include/asm-parisc/current.h | 15 - .../include/asm-parisc/delay.h | 43 - .../include/asm-parisc/device.h | 7 - .../include/asm-parisc/div64.h | 1 - .../include/asm-parisc/dma-mapping.h | 253 - .../linux-26-headers/include/asm-parisc/dma.h | 186 - .../include/asm-parisc/eisa_bus.h | 23 - .../include/asm-parisc/eisa_eeprom.h | 153 - .../linux-26-headers/include/asm-parisc/elf.h | 342 - .../include/asm-parisc/emergency-restart.h | 6 - .../include/asm-parisc/errno.h | 124 - .../linux-26-headers/include/asm-parisc/fb.h | 19 - .../include/asm-parisc/fcntl.h | 39 - .../include/asm-parisc/fixmap.h | 30 - .../include/asm-parisc/floppy.h | 271 - .../include/asm-parisc/futex.h | 77 - .../include/asm-parisc/grfioctl.h | 113 - .../include/asm-parisc/hardirq.h | 29 - .../include/asm-parisc/hardware.h | 127 - .../include/asm-parisc/hw_irq.h | 8 - .../linux-26-headers/include/asm-parisc/ide.h | 61 - .../linux-26-headers/include/asm-parisc/io.h | 293 - .../include/asm-parisc/ioctl.h | 44 - .../include/asm-parisc/ioctls.h | 90 - .../include/asm-parisc/ipcbuf.h | 27 - .../linux-26-headers/include/asm-parisc/irq.h | 57 - .../include/asm-parisc/irq_regs.h | 1 - .../include/asm-parisc/kdebug.h | 1 - .../include/asm-parisc/kmap_types.h | 30 - .../linux-26-headers/include/asm-parisc/led.h | 42 - .../include/asm-parisc/linkage.h | 31 - .../include/asm-parisc/local.h | 1 - .../include/asm-parisc/machdep.h | 16 - .../include/asm-parisc/mc146818rtc.h | 9 - .../include/asm-parisc/mckinley.h | 9 - .../include/asm-parisc/mman.h | 61 - .../linux-26-headers/include/asm-parisc/mmu.h | 7 - .../include/asm-parisc/mmu_context.h | 75 - .../include/asm-parisc/mmzone.h | 73 - .../include/asm-parisc/module.h | 32 - .../include/asm-parisc/msgbuf.h | 37 - .../include/asm-parisc/mutex.h | 9 - .../include/asm-parisc/page.h | 173 - .../include/asm-parisc/param.h | 22 - .../include/asm-parisc/parisc-device.h | 64 - .../include/asm-parisc/parport.h | 18 - .../linux-26-headers/include/asm-parisc/pci.h | 294 - .../linux-26-headers/include/asm-parisc/pdc.h | 757 - .../include/asm-parisc/pdc_chassis.h | 381 - .../include/asm-parisc/pdcpat.h | 308 - .../include/asm-parisc/percpu.h | 7 - .../include/asm-parisc/perf.h | 74 - .../include/asm-parisc/pgalloc.h | 149 - .../include/asm-parisc/pgtable.h | 508 - .../include/asm-parisc/poll.h | 1 - .../include/asm-parisc/posix_types.h | 129 - .../include/asm-parisc/prefetch.h | 39 - .../include/asm-parisc/processor.h | 357 - .../linux-26-headers/include/asm-parisc/psw.h | 62 - .../include/asm-parisc/ptrace.h | 58 - .../include/asm-parisc/real.h | 5 - .../include/asm-parisc/resource.h | 7 - .../include/asm-parisc/ropes.h | 322 - .../include/asm-parisc/rt_sigframe.h | 23 - .../linux-26-headers/include/asm-parisc/rtc.h | 131 - .../include/asm-parisc/runway.h | 12 - .../include/asm-parisc/scatterlist.h | 27 - .../include/asm-parisc/sections.h | 12 - .../include/asm-parisc/segment.h | 6 - .../include/asm-parisc/sembuf.h | 29 - .../include/asm-parisc/serial.h | 10 - .../include/asm-parisc/setup.h | 6 - .../include/asm-parisc/shmbuf.h | 58 - .../include/asm-parisc/shmparam.h | 8 - .../include/asm-parisc/sigcontext.h | 20 - .../include/asm-parisc/siginfo.h | 14 - .../include/asm-parisc/signal.h | 153 - .../linux-26-headers/include/asm-parisc/smp.h | 68 - .../include/asm-parisc/socket.h | 62 - .../include/asm-parisc/sockios.h | 13 - .../include/asm-parisc/spinlock.h | 194 - .../include/asm-parisc/spinlock_types.h | 21 - .../include/asm-parisc/stat.h | 100 - .../include/asm-parisc/statfs.h | 58 - .../include/asm-parisc/string.h | 10 - .../include/asm-parisc/superio.h | 85 - .../include/asm-parisc/system.h | 182 - .../include/asm-parisc/termbits.h | 200 - .../include/asm-parisc/termios.h | 90 - .../include/asm-parisc/thread_info.h | 74 - .../include/asm-parisc/timex.h | 20 - .../linux-26-headers/include/asm-parisc/tlb.h | 27 - .../include/asm-parisc/tlbflush.h | 80 - .../include/asm-parisc/topology.h | 6 - .../include/asm-parisc/traps.h | 16 - .../include/asm-parisc/types.h | 36 - .../include/asm-parisc/uaccess.h | 244 - .../include/asm-parisc/ucontext.h | 12 - .../include/asm-parisc/unaligned.h | 16 - .../include/asm-parisc/unistd.h | 991 - .../include/asm-parisc/unwind.h | 77 - .../include/asm-parisc/user.h | 5 - .../linux-26-headers/include/asm-parisc/vga.h | 6 - .../linux-26-headers/include/asm-parisc/xor.h | 1 - .../include/asm-um/a.out-core.h | 27 - .../linux-26-headers/include/asm-um/a.out.h | 11 - .../include/asm-um/alternative-asm.h | 6 - .../include/asm-um/alternative.h | 6 - l4/pkg/linux-26-headers/include/asm-um/apic.h | 4 - .../include/asm-um/archparam-i386.h | 26 - .../include/asm-um/archparam-ppc.h | 8 - .../include/asm-um/archparam-x86_64.h | 26 - l4/pkg/linux-26-headers/include/asm-um/asm.h | 6 - .../linux-26-headers/include/asm-um/atomic.h | 11 - .../linux-26-headers/include/asm-um/auxvec.h | 4 - .../linux-26-headers/include/asm-um/bitops.h | 10 - l4/pkg/linux-26-headers/include/asm-um/boot.h | 6 - l4/pkg/linux-26-headers/include/asm-um/bug.h | 6 - l4/pkg/linux-26-headers/include/asm-um/bugs.h | 6 - .../include/asm-um/byteorder.h | 6 - .../linux-26-headers/include/asm-um/cache.h | 17 - .../include/asm-um/cacheflush.h | 6 - .../linux-26-headers/include/asm-um/calling.h | 9 - .../include/asm-um/checksum.h | 6 - .../linux-26-headers/include/asm-um/cmpxchg.h | 6 - .../linux-26-headers/include/asm-um/cobalt.h | 6 - .../include/asm-um/common.lds.S | 130 - .../include/asm-um/cpufeature.h | 6 - .../linux-26-headers/include/asm-um/cputime.h | 6 - .../linux-26-headers/include/asm-um/current.h | 13 - .../linux-26-headers/include/asm-um/delay.h | 20 - l4/pkg/linux-26-headers/include/asm-um/desc.h | 16 - .../linux-26-headers/include/asm-um/device.h | 7 - .../linux-26-headers/include/asm-um/div64.h | 6 - .../include/asm-um/dma-mapping.h | 121 - l4/pkg/linux-26-headers/include/asm-um/dma.h | 10 - .../linux-26-headers/include/asm-um/dwarf2.h | 11 - .../include/asm-um/elf-i386.h | 163 - .../linux-26-headers/include/asm-um/elf-ppc.h | 53 - .../include/asm-um/elf-x86_64.h | 119 - .../include/asm-um/emergency-restart.h | 6 - .../linux-26-headers/include/asm-um/errno.h | 6 - .../linux-26-headers/include/asm-um/fcntl.h | 6 - .../linux-26-headers/include/asm-um/fixmap.h | 98 - .../linux-26-headers/include/asm-um/floppy.h | 6 - .../linux-26-headers/include/asm-um/frame.h | 6 - .../linux-26-headers/include/asm-um/futex.h | 6 - .../linux-26-headers/include/asm-um/hardirq.h | 25 - .../linux-26-headers/include/asm-um/highmem.h | 12 - .../include/asm-um/host_ldt-i386.h | 34 - .../include/asm-um/host_ldt-x86_64.h | 38 - .../linux-26-headers/include/asm-um/hw_irq.h | 7 - l4/pkg/linux-26-headers/include/asm-um/ide.h | 6 - l4/pkg/linux-26-headers/include/asm-um/io.h | 57 - .../linux-26-headers/include/asm-um/ioctl.h | 6 - .../linux-26-headers/include/asm-um/ioctls.h | 6 - .../linux-26-headers/include/asm-um/ipcbuf.h | 6 - l4/pkg/linux-26-headers/include/asm-um/irq.h | 23 - .../include/asm-um/irq_regs.h | 1 - .../include/asm-um/irq_vectors.h | 20 - .../include/asm-um/irqflags.h | 6 - .../linux-26-headers/include/asm-um/kdebug.h | 1 - .../include/asm-um/kmap_types.h | 29 - l4/pkg/linux-26-headers/include/asm-um/ldt.h | 37 - .../linux-26-headers/include/asm-um/linkage.h | 6 - .../linux-26-headers/include/asm-um/local.h | 6 - .../linux-26-headers/include/asm-um/locks.h | 6 - .../linux-26-headers/include/asm-um/mca_dma.h | 6 - l4/pkg/linux-26-headers/include/asm-um/mman.h | 6 - l4/pkg/linux-26-headers/include/asm-um/mmu.h | 22 - .../include/asm-um/mmu_context.h | 54 - .../include/asm-um/module-generic.h | 6 - .../include/asm-um/module-i386.h | 13 - .../include/asm-um/module-x86_64.h | 30 - .../linux-26-headers/include/asm-um/msgbuf.h | 6 - l4/pkg/linux-26-headers/include/asm-um/mtrr.h | 6 - .../linux-26-headers/include/asm-um/mutex.h | 9 - l4/pkg/linux-26-headers/include/asm-um/nops.h | 6 - l4/pkg/linux-26-headers/include/asm-um/page.h | 122 - .../include/asm-um/page_offset.h | 1 - .../linux-26-headers/include/asm-um/param.h | 20 - .../include/asm-um/paravirt.h | 6 - l4/pkg/linux-26-headers/include/asm-um/pci.h | 7 - l4/pkg/linux-26-headers/include/asm-um/pda.h | 31 - .../linux-26-headers/include/asm-um/percpu.h | 6 - .../linux-26-headers/include/asm-um/pgalloc.h | 72 - .../include/asm-um/pgtable-2level.h | 53 - .../include/asm-um/pgtable-3level.h | 146 - .../linux-26-headers/include/asm-um/pgtable.h | 358 - l4/pkg/linux-26-headers/include/asm-um/poll.h | 6 - .../include/asm-um/posix_types.h | 6 - .../linux-26-headers/include/asm-um/prctl.h | 6 - .../include/asm-um/processor-generic.h | 136 - .../include/asm-um/processor-i386.h | 78 - .../include/asm-um/processor-ppc.h | 15 - .../include/asm-um/processor-x86_64.h | 56 - .../include/asm-um/ptrace-generic.h | 55 - .../include/asm-um/ptrace-i386.h | 60 - .../include/asm-um/ptrace-x86_64.h | 81 - .../include/asm-um/required-features.h | 9 - .../include/asm-um/resource.h | 6 - .../linux-26-headers/include/asm-um/rwlock.h | 6 - .../linux-26-headers/include/asm-um/rwsem.h | 6 - .../include/asm-um/scatterlist.h | 6 - .../include/asm-um/sections.h | 7 - .../linux-26-headers/include/asm-um/segment.h | 10 - .../linux-26-headers/include/asm-um/sembuf.h | 6 - .../linux-26-headers/include/asm-um/serial.h | 6 - .../linux-26-headers/include/asm-um/setup.h | 10 - .../linux-26-headers/include/asm-um/shmbuf.h | 6 - .../include/asm-um/shmparam.h | 6 - .../include/asm-um/sigcontext-generic.h | 6 - .../include/asm-um/sigcontext-i386.h | 6 - .../include/asm-um/sigcontext-ppc.h | 10 - .../include/asm-um/sigcontext-x86_64.h | 22 - .../linux-26-headers/include/asm-um/siginfo.h | 6 - .../linux-26-headers/include/asm-um/signal.h | 29 - l4/pkg/linux-26-headers/include/asm-um/smp.h | 33 - .../linux-26-headers/include/asm-um/socket.h | 6 - .../linux-26-headers/include/asm-um/sockios.h | 6 - .../include/asm-um/spinlock.h | 6 - .../include/asm-um/spinlock_types.h | 6 - l4/pkg/linux-26-headers/include/asm-um/stat.h | 6 - .../linux-26-headers/include/asm-um/statfs.h | 6 - .../linux-26-headers/include/asm-um/string.h | 7 - .../linux-26-headers/include/asm-um/suspend.h | 4 - .../include/asm-um/system-generic.h | 47 - .../include/asm-um/system-i386.h | 6 - .../include/asm-um/system-ppc.h | 12 - .../include/asm-um/system-x86_64.h | 23 - .../include/asm-um/termbits.h | 6 - .../linux-26-headers/include/asm-um/termios.h | 6 - .../include/asm-um/thread_info.h | 81 - .../linux-26-headers/include/asm-um/timex.h | 13 - l4/pkg/linux-26-headers/include/asm-um/tlb.h | 127 - .../include/asm-um/tlbflush.h | 31 - .../include/asm-um/topology.h | 6 - .../linux-26-headers/include/asm-um/types.h | 6 - .../linux-26-headers/include/asm-um/uaccess.h | 99 - .../include/asm-um/ucontext.h | 6 - .../include/asm-um/unaligned.h | 6 - .../linux-26-headers/include/asm-um/unistd.h | 41 - l4/pkg/linux-26-headers/include/asm-um/user.h | 6 - l4/pkg/linux-26-headers/include/asm-um/vga.h | 6 - .../include/asm-um/vm-flags-i386.h | 14 - .../include/asm-um/vm-flags-x86_64.h | 33 - l4/pkg/linux-26-headers/include/asm-um/vm86.h | 6 - l4/pkg/linux-26-headers/include/asm-um/xor.h | 6 - .../linux-26-headers/include/asm-x86/Kbuild | 24 - .../include/asm-x86/a.out-core.h | 73 - .../linux-26-headers/include/asm-x86/acpi.h | 178 - l4/pkg/linux-26-headers/include/asm-x86/agp.h | 35 - .../include/asm-x86/alternative-asm.h | 22 - .../include/asm-x86/alternative.h | 183 - .../include/asm-x86/amd_iommu.h | 32 - .../include/asm-x86/amd_iommu_types.h | 344 - .../linux-26-headers/include/asm-x86/apic.h | 131 - .../include/asm-x86/apicdef.h | 414 - .../include/asm-x86/arch_hooks.h | 28 - .../include/asm-x86/asm-offsets.h | 78 - l4/pkg/linux-26-headers/include/asm-x86/asm.h | 42 - .../linux-26-headers/include/asm-x86/atomic.h | 5 - .../include/asm-x86/atomic_32.h | 259 - .../include/asm-x86/atomic_64.h | 473 - .../include/asm-x86/bios_ebda.h | 19 - .../linux-26-headers/include/asm-x86/bitops.h | 461 - l4/pkg/linux-26-headers/include/asm-x86/bug.h | 39 - .../linux-26-headers/include/asm-x86/bugs.h | 7 - .../linux-26-headers/include/asm-x86/cache.h | 20 - .../include/asm-x86/cacheflush.h | 115 - .../include/asm-x86/calgary.h | 72 - .../include/asm-x86/calling.h | 170 - .../include/asm-x86/checksum.h | 5 - .../include/asm-x86/checksum_32.h | 189 - .../include/asm-x86/checksum_64.h | 191 - .../include/asm-x86/cmpxchg.h | 5 - .../include/asm-x86/cmpxchg_32.h | 344 - .../include/asm-x86/cmpxchg_64.h | 185 - .../linux-26-headers/include/asm-x86/compat.h | 218 - l4/pkg/linux-26-headers/include/asm-x86/cpu.h | 20 - .../include/asm-x86/cpufeature.h | 227 - .../include/asm-x86/cputime.h | 1 - .../include/asm-x86/current.h | 39 - .../linux-26-headers/include/asm-x86/delay.h | 31 - .../linux-26-headers/include/asm-x86/desc.h | 400 - .../include/asm-x86/desc_defs.h | 95 - .../linux-26-headers/include/asm-x86/device.h | 16 - .../linux-26-headers/include/asm-x86/div64.h | 60 - .../include/asm-x86/dma-mapping.h | 253 - l4/pkg/linux-26-headers/include/asm-x86/dma.h | 318 - l4/pkg/linux-26-headers/include/asm-x86/dmi.h | 26 - l4/pkg/linux-26-headers/include/asm-x86/ds.h | 72 - .../linux-26-headers/include/asm-x86/dwarf2.h | 61 - .../linux-26-headers/include/asm-x86/edac.h | 18 - l4/pkg/linux-26-headers/include/asm-x86/efi.h | 97 - l4/pkg/linux-26-headers/include/asm-x86/elf.h | 335 - .../include/asm-x86/emergency-restart.h | 18 - l4/pkg/linux-26-headers/include/asm-x86/fb.h | 21 - .../linux-26-headers/include/asm-x86/fixmap.h | 68 - .../include/asm-x86/fixmap_32.h | 123 - .../include/asm-x86/fixmap_64.h | 83 - .../linux-26-headers/include/asm-x86/floppy.h | 281 - .../linux-26-headers/include/asm-x86/frame.h | 27 - .../linux-26-headers/include/asm-x86/ftrace.h | 14 - .../linux-26-headers/include/asm-x86/futex.h | 140 - .../linux-26-headers/include/asm-x86/gart.h | 71 - .../include/asm-x86/genapic.h | 5 - .../include/asm-x86/genapic_32.h | 124 - .../include/asm-x86/genapic_64.h | 50 - .../linux-26-headers/include/asm-x86/geode.h | 253 - .../linux-26-headers/include/asm-x86/gpio.h | 56 - .../include/asm-x86/hardirq.h | 11 - .../include/asm-x86/hardirq_32.h | 28 - .../include/asm-x86/hardirq_64.h | 23 - .../include/asm-x86/highmem.h | 82 - .../linux-26-headers/include/asm-x86/hpet.h | 93 - .../include/asm-x86/hugetlb.h | 93 - .../linux-26-headers/include/asm-x86/hw_irq.h | 115 - .../include/asm-x86/hypertransport.h | 45 - .../linux-26-headers/include/asm-x86/i387.h | 339 - .../linux-26-headers/include/asm-x86/i8253.h | 18 - .../linux-26-headers/include/asm-x86/i8259.h | 60 - .../linux-26-headers/include/asm-x86/ia32.h | 170 - .../include/asm-x86/ia32_unistd.h | 18 - .../linux-26-headers/include/asm-x86/idle.h | 15 - .../include/asm-x86/intel_arch_perfmon.h | 31 - l4/pkg/linux-26-headers/include/asm-x86/io.h | 102 - .../linux-26-headers/include/asm-x86/io_32.h | 284 - .../linux-26-headers/include/asm-x86/io_64.h | 248 - .../include/asm-x86/io_apic.h | 192 - .../linux-26-headers/include/asm-x86/iommu.h | 45 - l4/pkg/linux-26-headers/include/asm-x86/ipi.h | 132 - l4/pkg/linux-26-headers/include/asm-x86/irq.h | 50 - .../include/asm-x86/irq_regs.h | 5 - .../include/asm-x86/irq_regs_32.h | 29 - .../include/asm-x86/irq_regs_64.h | 1 - .../include/asm-x86/irq_vectors.h | 182 - .../include/asm-x86/irqflags.h | 232 - l4/pkg/linux-26-headers/include/asm-x86/k8.h | 15 - .../linux-26-headers/include/asm-x86/kdebug.h | 38 - .../linux-26-headers/include/asm-x86/kexec.h | 175 - .../linux-26-headers/include/asm-x86/kgdb.h | 79 - .../include/asm-x86/kmap_types.h | 29 - .../include/asm-x86/kprobes.h | 97 - .../include/asm-x86/kvm_host.h | 738 - .../include/asm-x86/kvm_x86_emulate.h | 184 - .../linux-26-headers/include/asm-x86/lguest.h | 94 - .../include/asm-x86/lguest_hcall.h | 71 - .../include/asm-x86/linkage.h | 61 - .../linux-26-headers/include/asm-x86/local.h | 235 - .../include/asm-x86/mach-bigsmp/mach_apic.h | 144 - .../asm-x86/mach-bigsmp/mach_apicdef.h | 13 - .../include/asm-x86/mach-bigsmp/mach_ipi.h | 25 - .../include/asm-x86/mach-default/apm.h | 73 - .../include/asm-x86/mach-default/do_timer.h | 16 - .../include/asm-x86/mach-default/entry_arch.h | 35 - .../include/asm-x86/mach-default/mach_apic.h | 141 - .../asm-x86/mach-default/mach_apicdef.h | 24 - .../include/asm-x86/mach-default/mach_ipi.h | 64 - .../asm-x86/mach-default/mach_mpparse.h | 17 - .../asm-x86/mach-default/mach_mpspec.h | 12 - .../include/asm-x86/mach-default/mach_timer.h | 48 - .../include/asm-x86/mach-default/mach_traps.h | 39 - .../asm-x86/mach-default/mach_wakecpu.h | 42 - .../asm-x86/mach-default/pci-functions.h | 19 - .../include/asm-x86/mach-default/setup_arch.h | 3 - .../asm-x86/mach-default/smpboot_hooks.h | 59 - .../include/asm-x86/mach-es7000/mach_apic.h | 194 - .../asm-x86/mach-es7000/mach_apicdef.h | 13 - .../include/asm-x86/mach-es7000/mach_ipi.h | 24 - .../asm-x86/mach-es7000/mach_mpparse.h | 29 - .../asm-x86/mach-es7000/mach_wakecpu.h | 59 - .../include/asm-x86/mach-generic/gpio.h | 15 - .../asm-x86/mach-generic/irq_vectors_limits.h | 14 - .../include/asm-x86/mach-generic/mach_apic.h | 32 - .../asm-x86/mach-generic/mach_apicdef.h | 11 - .../include/asm-x86/mach-generic/mach_ipi.h | 10 - .../asm-x86/mach-generic/mach_mpparse.h | 10 - .../asm-x86/mach-generic/mach_mpspec.h | 12 - .../include/asm-x86/mach-numaq/mach_apic.h | 138 - .../include/asm-x86/mach-numaq/mach_apicdef.h | 14 - .../include/asm-x86/mach-numaq/mach_ipi.h | 25 - .../include/asm-x86/mach-numaq/mach_mpparse.h | 7 - .../include/asm-x86/mach-numaq/mach_wakecpu.h | 43 - .../include/asm-x86/mach-rdc321x/gpio.h | 57 - .../asm-x86/mach-rdc321x/rdc321x_defs.h | 12 - .../asm-x86/mach-summit/irq_vectors_limits.h | 14 - .../include/asm-x86/mach-summit/mach_apic.h | 185 - .../asm-x86/mach-summit/mach_apicdef.h | 13 - .../include/asm-x86/mach-summit/mach_ipi.h | 25 - .../asm-x86/mach-summit/mach_mpparse.h | 110 - .../include/asm-x86/mach-voyager/do_timer.h | 17 - .../include/asm-x86/mach-voyager/entry_arch.h | 26 - .../include/asm-x86/mach-voyager/setup_arch.h | 12 - .../include/asm-x86/math_emu.h | 31 - .../include/asm-x86/mc146818rtc.h | 104 - l4/pkg/linux-26-headers/include/asm-x86/mca.h | 43 - .../include/asm-x86/mca_dma.h | 201 - .../include/asm-x86/mmconfig.h | 12 - l4/pkg/linux-26-headers/include/asm-x86/mmu.h | 31 - .../include/asm-x86/mmu_context.h | 37 - .../include/asm-x86/mmu_context_32.h | 56 - .../include/asm-x86/mmu_context_64.h | 54 - l4/pkg/linux-26-headers/include/asm-x86/mmx.h | 14 - .../linux-26-headers/include/asm-x86/mmzone.h | 5 - .../include/asm-x86/mmzone_32.h | 134 - .../include/asm-x86/mmzone_64.h | 52 - .../linux-26-headers/include/asm-x86/module.h | 82 - .../linux-26-headers/include/asm-x86/mpspec.h | 144 - .../include/asm-x86/mpspec_def.h | 180 - .../linux-26-headers/include/asm-x86/msidef.h | 51 - .../linux-26-headers/include/asm-x86/mutex.h | 5 - .../include/asm-x86/mutex_32.h | 125 - .../include/asm-x86/mutex_64.h | 100 - l4/pkg/linux-26-headers/include/asm-x86/nmi.h | 84 - .../linux-26-headers/include/asm-x86/nops.h | 118 - .../linux-26-headers/include/asm-x86/numa.h | 5 - .../include/asm-x86/numa_32.h | 11 - .../include/asm-x86/numa_64.h | 43 - .../linux-26-headers/include/asm-x86/numaq.h | 169 - .../linux-26-headers/include/asm-x86/olpc.h | 132 - .../linux-26-headers/include/asm-x86/page.h | 202 - .../include/asm-x86/page_32.h | 129 - .../include/asm-x86/page_64.h | 105 - .../include/asm-x86/paravirt.h | 1637 - .../include/asm-x86/parport.h | 10 - l4/pkg/linux-26-headers/include/asm-x86/pat.h | 22 - .../include/asm-x86/pci-direct.h | 21 - l4/pkg/linux-26-headers/include/asm-x86/pci.h | 114 - .../linux-26-headers/include/asm-x86/pci_32.h | 34 - .../linux-26-headers/include/asm-x86/pci_64.h | 66 - l4/pkg/linux-26-headers/include/asm-x86/pda.h | 137 - .../linux-26-headers/include/asm-x86/percpu.h | 218 - .../include/asm-x86/pgalloc.h | 114 - .../include/asm-x86/pgtable-2level-defs.h | 20 - .../include/asm-x86/pgtable-2level.h | 81 - .../include/asm-x86/pgtable-3level-defs.h | 28 - .../include/asm-x86/pgtable-3level.h | 182 - .../include/asm-x86/pgtable.h | 524 - .../include/asm-x86/pgtable_32.h | 189 - .../include/asm-x86/pgtable_64.h | 287 - .../include/asm-x86/processor-cyrix.h | 30 - .../include/asm-x86/processor.h | 946 - .../linux-26-headers/include/asm-x86/proto.h | 32 - .../include/asm-x86/pvclock-abi.h | 42 - .../include/asm-x86/pvclock.h | 13 - .../linux-26-headers/include/asm-x86/reboot.h | 21 - .../include/asm-x86/reboot_fixups.h | 6 - .../include/asm-x86/required-features.h | 82 - .../include/asm-x86/resume-trace.h | 21 - l4/pkg/linux-26-headers/include/asm-x86/rio.h | 63 - l4/pkg/linux-26-headers/include/asm-x86/rtc.h | 1 - .../linux-26-headers/include/asm-x86/rwlock.h | 8 - .../linux-26-headers/include/asm-x86/rwsem.h | 265 - .../include/asm-x86/scatterlist.h | 33 - .../include/asm-x86/seccomp.h | 5 - .../include/asm-x86/seccomp_32.h | 17 - .../include/asm-x86/seccomp_64.h | 25 - .../include/asm-x86/sections.h | 1 - .../include/asm-x86/segment.h | 215 - .../linux-26-headers/include/asm-x86/serial.h | 29 - .../include/asm-x86/shmparam.h | 6 - l4/pkg/linux-26-headers/include/asm-x86/smp.h | 208 - .../include/asm-x86/sparsemem.h | 34 - .../include/asm-x86/spinlock.h | 369 - .../include/asm-x86/spinlock_types.h | 20 - .../linux-26-headers/include/asm-x86/srat.h | 39 - .../include/asm-x86/stacktrace.h | 21 - .../linux-26-headers/include/asm-x86/string.h | 5 - .../include/asm-x86/string_32.h | 326 - .../include/asm-x86/string_64.h | 60 - .../include/asm-x86/suspend.h | 5 - .../include/asm-x86/suspend_32.h | 51 - .../include/asm-x86/suspend_64.h | 52 - .../include/asm-x86/swiotlb.h | 58 - .../include/asm-x86/sync_bitops.h | 130 - .../linux-26-headers/include/asm-x86/system.h | 422 - .../include/asm-x86/system_64.h | 22 - l4/pkg/linux-26-headers/include/asm-x86/tce.h | 48 - .../include/asm-x86/therm_throt.h | 9 - .../include/asm-x86/thread_info.h | 261 - .../linux-26-headers/include/asm-x86/time.h | 61 - .../linux-26-headers/include/asm-x86/timer.h | 63 - .../linux-26-headers/include/asm-x86/timex.h | 19 - l4/pkg/linux-26-headers/include/asm-x86/tlb.h | 11 - .../include/asm-x86/tlbflush.h | 168 - .../include/asm-x86/topology.h | 258 - .../include/asm-x86/trampoline.h | 21 - .../linux-26-headers/include/asm-x86/traps.h | 66 - l4/pkg/linux-26-headers/include/asm-x86/tsc.h | 62 - .../include/asm-x86/uaccess.h | 454 - .../include/asm-x86/uaccess_32.h | 218 - .../include/asm-x86/uaccess_64.h | 202 - .../include/asm-x86/unaligned.h | 14 - .../linux-26-headers/include/asm-x86/unwind.h | 13 - .../linux-26-headers/include/asm-x86/user.h | 5 - .../linux-26-headers/include/asm-x86/user32.h | 70 - .../include/asm-x86/user_32.h | 131 - .../include/asm-x86/user_64.h | 137 - .../include/asm-x86/uv/bios.h | 68 - .../include/asm-x86/uv/uv_bau.h | 332 - .../include/asm-x86/uv/uv_hub.h | 354 - .../include/asm-x86/uv/uv_mmrs.h | 1295 - .../linux-26-headers/include/asm-x86/vdso.h | 47 - l4/pkg/linux-26-headers/include/asm-x86/vga.h | 20 - .../linux-26-headers/include/asm-x86/vgtod.h | 29 - l4/pkg/linux-26-headers/include/asm-x86/vic.h | 61 - .../include/asm-x86/visws/cobalt.h | 125 - .../include/asm-x86/visws/lithium.h | 53 - .../include/asm-x86/visws/piix4.h | 107 - .../include/asm-x86/visws/sgivw.h | 5 - l4/pkg/linux-26-headers/include/asm-x86/vmi.h | 263 - .../include/asm-x86/vmi_time.h | 98 - .../include/asm-x86/voyager.h | 528 - .../include/asm-x86/xen/events.h | 24 - .../include/asm-x86/xen/grant_table.h | 7 - .../include/asm-x86/xen/hypercall.h | 527 - .../include/asm-x86/xen/hypervisor.h | 72 - .../include/asm-x86/xen/interface.h | 175 - .../include/asm-x86/xen/interface_32.h | 97 - .../include/asm-x86/xen/interface_64.h | 159 - .../include/asm-x86/xen/page.h | 165 - l4/pkg/linux-26-headers/include/asm-x86/xor.h | 5 - .../linux-26-headers/include/asm-x86/xor_32.h | 888 - .../linux-26-headers/include/asm-x86/xor_64.h | 361 - .../include/asm-xtensa/Kbuild | 1 - .../include/asm-xtensa/a.out.h | 29 - .../include/asm-xtensa/asmmacro.h | 153 - .../include/asm-xtensa/atomic.h | 300 - .../include/asm-xtensa/auxvec.h | 4 - .../include/asm-xtensa/bitops.h | 121 - .../include/asm-xtensa/bootparam.h | 61 - .../linux-26-headers/include/asm-xtensa/bug.h | 18 - .../include/asm-xtensa/bugs.h | 18 - .../include/asm-xtensa/byteorder.h | 82 - .../include/asm-xtensa/cache.h | 33 - .../include/asm-xtensa/cacheasm.h | 177 - .../include/asm-xtensa/cacheflush.h | 155 - .../include/asm-xtensa/checksum.h | 250 - .../include/asm-xtensa/coprocessor.h | 177 - .../include/asm-xtensa/cpumask.h | 16 - .../include/asm-xtensa/cputime.h | 6 - .../include/asm-xtensa/current.h | 38 - .../include/asm-xtensa/delay.h | 49 - .../include/asm-xtensa/device.h | 7 - .../include/asm-xtensa/div64.h | 16 - .../include/asm-xtensa/dma-mapping.h | 179 - .../linux-26-headers/include/asm-xtensa/dma.h | 61 - .../linux-26-headers/include/asm-xtensa/elf.h | 205 - .../include/asm-xtensa/emergency-restart.h | 6 - .../include/asm-xtensa/errno.h | 16 - .../linux-26-headers/include/asm-xtensa/fb.h | 12 - .../include/asm-xtensa/fcntl.h | 1 - .../include/asm-xtensa/futex.h | 1 - .../include/asm-xtensa/hardirq.h | 28 - .../include/asm-xtensa/highmem.h | 17 - .../include/asm-xtensa/hw_irq.h | 14 - .../linux-26-headers/include/asm-xtensa/io.h | 198 - .../include/asm-xtensa/ioctl.h | 1 - .../include/asm-xtensa/ioctls.h | 116 - .../include/asm-xtensa/ipcbuf.h | 37 - .../linux-26-headers/include/asm-xtensa/irq.h | 30 - .../include/asm-xtensa/irq_regs.h | 1 - .../include/asm-xtensa/kdebug.h | 1 - .../include/asm-xtensa/kmap_types.h | 31 - .../include/asm-xtensa/linkage.h | 16 - .../include/asm-xtensa/local.h | 16 - .../include/asm-xtensa/mman.h | 84 - .../linux-26-headers/include/asm-xtensa/mmu.h | 17 - .../include/asm-xtensa/mmu_context.h | 136 - .../include/asm-xtensa/module.h | 27 - .../include/asm-xtensa/msgbuf.h | 48 - .../include/asm-xtensa/mutex.h | 9 - .../include/asm-xtensa/page.h | 174 - .../include/asm-xtensa/param.h | 34 - .../include/asm-xtensa/pci-bridge.h | 88 - .../linux-26-headers/include/asm-xtensa/pci.h | 82 - .../include/asm-xtensa/percpu.h | 16 - .../include/asm-xtensa/pgalloc.h | 73 - .../include/asm-xtensa/pgtable.h | 416 - .../asm-xtensa/platform-iss/hardware.h | 29 - .../include/asm-xtensa/platform-iss/simcall.h | 62 - .../include/asm-xtensa/platform.h | 91 - .../include/asm-xtensa/poll.h | 20 - .../include/asm-xtensa/posix_types.h | 122 - .../include/asm-xtensa/processor.h | 193 - .../include/asm-xtensa/ptrace.h | 135 - .../include/asm-xtensa/regs.h | 145 - .../include/asm-xtensa/resource.h | 16 - .../include/asm-xtensa/rmap.h | 16 - .../include/asm-xtensa/rwsem.h | 164 - .../include/asm-xtensa/scatterlist.h | 39 - .../include/asm-xtensa/sections.h | 16 - .../include/asm-xtensa/segment.h | 16 - .../include/asm-xtensa/sembuf.h | 44 - .../include/asm-xtensa/serial.h | 18 - .../include/asm-xtensa/setup.h | 16 - .../include/asm-xtensa/shmbuf.h | 71 - .../include/asm-xtensa/shmparam.h | 21 - .../include/asm-xtensa/sigcontext.h | 28 - .../include/asm-xtensa/siginfo.h | 16 - .../include/asm-xtensa/signal.h | 172 - .../linux-26-headers/include/asm-xtensa/smp.h | 27 - .../include/asm-xtensa/socket.h | 68 - .../include/asm-xtensa/sockios.h | 31 - .../include/asm-xtensa/spinlock.h | 16 - .../include/asm-xtensa/stat.h | 59 - .../include/asm-xtensa/statfs.h | 17 - .../include/asm-xtensa/string.h | 124 - .../include/asm-xtensa/syscall.h | 42 - .../include/asm-xtensa/system.h | 215 - .../include/asm-xtensa/termbits.h | 219 - .../include/asm-xtensa/termios.h | 105 - .../include/asm-xtensa/thread_info.h | 162 - .../include/asm-xtensa/timex.h | 96 - .../linux-26-headers/include/asm-xtensa/tlb.h | 47 - .../include/asm-xtensa/tlbflush.h | 191 - .../include/asm-xtensa/topology.h | 16 - .../include/asm-xtensa/types.h | 42 - .../include/asm-xtensa/uaccess.h | 500 - .../include/asm-xtensa/ucontext.h | 22 - .../include/asm-xtensa/unaligned.h | 29 - .../include/asm-xtensa/unistd.h | 735 - .../include/asm-xtensa/user.h | 20 - .../include/asm-xtensa/variant-fsf/core.h | 359 - .../include/asm-xtensa/variant-fsf/tie-asm.h | 70 - .../include/asm-xtensa/variant-fsf/tie.h | 77 - .../linux-26-headers/include/asm-xtensa/vga.h | 19 - .../linux-26-headers/include/asm-xtensa/xor.h | 16 - .../linux-26-headers/include/config/8139cp.h | 0 .../linux-26-headers/include/config/8139too.h | 0 l4/pkg/linux-26-headers/include/config/acpi.h | 0 .../linux-26-headers/include/config/acpi/ac.h | 0 .../include/config/acpi/battery.h | 0 .../include/config/acpi/blacklist/year.h | 0 .../include/config/acpi/button.h | 0 .../include/config/acpi/container.h | 0 .../include/config/acpi/debug.h | 0 .../include/config/acpi/dock.h | 0 .../linux-26-headers/include/config/acpi/ec.h | 0 .../include/config/acpi/fan.h | 0 .../include/config/acpi/hotplug/cpu.h | 0 .../include/config/acpi/power.h | 0 .../include/config/acpi/proc/event.h | 0 .../include/config/acpi/processor.h | 0 .../include/config/acpi/procfs.h | 0 .../include/config/acpi/procfs/power.h | 0 .../include/config/acpi/sleep.h | 0 .../include/config/acpi/sysfs/power.h | 0 .../include/config/acpi/system.h | 0 .../include/config/acpi/thermal.h | 0 l4/pkg/linux-26-headers/include/config/agp.h | 0 .../include/config/agp/amd64.h | 0 .../include/config/agp/intel.h | 0 .../include/config/aic79xx/cmds/per/device.h | 0 .../include/config/aic79xx/debug/mask.h | 0 .../include/config/aic79xx/reset/delay/ms.h | 0 .../include/config/aic7xxx/cmds/per/device.h | 0 .../include/config/aic7xxx/debug/enable.h | 0 .../include/config/aic7xxx/debug/mask.h | 0 .../include/config/aic7xxx/reg/pretty/print.h | 0 .../include/config/aic7xxx/reset/delay/ms.h | 0 .../include/config/anon/inodes.h | 0 .../include/config/arch/defconfig.h | 0 .../config/arch/enable/memory/hotplug.h | 0 .../include/config/arch/has/cache/line/size.h | 0 .../include/config/arch/has/cpu/idle/wait.h | 0 .../include/config/arch/has/cpu/relax.h | 0 .../config/arch/hibernation/possible.h | 0 .../include/config/arch/may/have/pc/fdc.h | 0 .../include/config/arch/populates/node/map.h | 0 .../include/config/arch/supports/aout.h | 0 .../include/config/arch/supports/msi.h | 0 .../config/arch/supports/optimized/inlining.h | 0 .../include/config/arch/suspend/possible.h | 0 .../config/arch/want/optional/gpiolib.h | 0 l4/pkg/linux-26-headers/include/config/ata.h | 0 .../include/config/ata/acpi.h | 0 .../include/config/ata/piix.h | 0 .../linux-26-headers/include/config/ata/sff.h | 0 .../linux-26-headers/include/config/auto.conf | 515 - .../include/config/auto.conf.cmd | 346 - .../include/config/autofs4/fs.h | 0 l4/pkg/linux-26-headers/include/config/b44.h | 0 .../linux-26-headers/include/config/b44/pci.h | 0 .../include/config/b44/pci/autoselect.h | 0 .../include/config/b44/pcicore/autoselect.h | 0 .../include/config/base/full.h | 0 .../include/config/base/small.h | 0 .../include/config/binfmt/elf.h | 0 .../include/config/bitreverse.h | 0 .../linux-26-headers/include/config/blk/dev.h | 0 .../include/config/blk/dev/3w/xxxx/raid.h | 0 .../include/config/blk/dev/amd74xx.h | 0 .../include/config/blk/dev/dm.h | 0 .../include/config/blk/dev/fd.h | 0 .../include/config/blk/dev/ide.h | 0 .../include/config/blk/dev/ideacpi.h | 0 .../include/config/blk/dev/idecd.h | 0 .../config/blk/dev/idecd/verbose/errors.h | 0 .../include/config/blk/dev/idedisk.h | 0 .../include/config/blk/dev/idedma.h | 0 .../include/config/blk/dev/idedma/pci.h | 0 .../include/config/blk/dev/idedma/sff.h | 0 .../include/config/blk/dev/idepci.h | 0 .../include/config/blk/dev/initrd.h | 0 .../include/config/blk/dev/loop.h | 0 .../include/config/blk/dev/piix.h | 0 .../include/config/blk/dev/ram.h | 0 .../include/config/blk/dev/ram/count.h | 0 .../include/config/blk/dev/ram/size.h | 0 .../include/config/blk/dev/sd.h | 0 .../include/config/blk/dev/sr.h | 0 .../linux-26-headers/include/config/block.h | 0 l4/pkg/linux-26-headers/include/config/bnx2.h | 0 .../config/bootparam/softlockup/panic/value.h | 0 .../linux-26-headers/include/config/bounce.h | 0 l4/pkg/linux-26-headers/include/config/bug.h | 0 .../include/config/cc/optimize/for/size.h | 0 .../include/config/chr/dev/sg.h | 0 .../include/config/classic/rcu.h | 0 .../include/config/clocksource/watchdog.h | 0 .../include/config/compat/brk.h | 0 .../include/config/compat/vdso.h | 0 .../include/config/console/translations.h | 0 .../include/config/cpu/freq.h | 0 .../include/config/cpu/freq/debug.h | 0 .../config/cpu/freq/default/gov/performance.h | 0 .../config/cpu/freq/gov/conservative.h | 0 .../include/config/cpu/freq/gov/ondemand.h | 0 .../include/config/cpu/freq/gov/performance.h | 0 .../include/config/cpu/freq/gov/userspace.h | 0 .../include/config/cpu/freq/stat.h | 0 .../include/config/cpu/freq/table.h | 0 .../include/config/cpu/idle.h | 0 .../include/config/cpu/idle/gov/ladder.h | 0 .../include/config/cpu/idle/gov/menu.h | 0 .../linux-26-headers/include/config/crc32.h | 0 .../linux-26-headers/include/config/crypto.h | 0 .../include/config/crypto/hw.h | 0 l4/pkg/linux-26-headers/include/config/dab.h | 0 .../include/config/debug/bugverbose.h | 0 .../include/config/debug/kernel.h | 0 .../include/config/debug/memory/init.h | 0 .../include/config/debug/stackoverflow.h | 0 .../include/config/default/cfq.h | 0 .../include/config/default/io/delay/type.h | 0 .../include/config/default/iosched.h | 0 .../include/config/default/tcp/cong.h | 0 .../include/config/defconfig/list.h | 0 .../include/config/detect/softlockup.h | 0 .../linux-26-headers/include/config/devkmem.h | 0 .../linux-26-headers/include/config/devport.h | 0 l4/pkg/linux-26-headers/include/config/dmi.h | 0 .../linux-26-headers/include/config/dmiid.h | 0 .../linux-26-headers/include/config/dnotify.h | 0 .../include/config/doublefault.h | 0 .../include/config/dummy/console.h | 0 l4/pkg/linux-26-headers/include/config/e100.h | 0 .../linux-26-headers/include/config/e1000.h | 0 .../linux-26-headers/include/config/e1000e.h | 0 .../include/config/early/printk.h | 0 .../include/config/elf/core.h | 0 .../include/config/enable/warn/deprecated.h | 0 .../linux-26-headers/include/config/epoll.h | 0 .../linux-26-headers/include/config/eventfd.h | 0 .../include/config/experimental.h | 0 .../include/config/exportfs.h | 0 .../linux-26-headers/include/config/ext2/fs.h | 0 .../include/config/ext2/fs/posix/acl.h | 0 .../include/config/ext2/fs/xattr.h | 0 .../linux-26-headers/include/config/ext3/fs.h | 0 .../include/config/ext3/fs/posix/acl.h | 0 .../include/config/ext3/fs/xattr.h | 0 .../include/config/extra/firmware.h | 0 .../include/config/fast/cmpxchg/local.h | 0 .../include/config/fat/default/codepage.h | 0 .../include/config/fat/default/iocharset.h | 0 .../linux-26-headers/include/config/fat/fs.h | 0 .../include/config/firmware/in/kernel.h | 0 .../include/config/firmware/memmap.h | 0 .../include/config/fix/earlycon/mem.h | 0 .../include/config/flat/node/mem/map.h | 0 .../linux-26-headers/include/config/flatmem.h | 0 .../include/config/flatmem/manual.h | 0 .../include/config/forcedeth.h | 0 .../include/config/frame/warn.h | 0 .../include/config/fs/mbcache.h | 0 .../include/config/fs/posix/acl.h | 0 .../linux-26-headers/include/config/fusion.h | 0 .../include/config/fusion/max/sge.h | 0 .../include/config/fusion/spi.h | 0 .../linux-26-headers/include/config/futex.h | 0 .../include/config/fw/loader.h | 0 .../include/config/generic/acl.h | 0 .../include/config/generic/bug.h | 0 .../include/config/generic/calibrate/delay.h | 0 .../include/config/generic/clockevents.h | 0 .../config/generic/clockevents/broadcast.h | 0 .../config/generic/clockevents/build.h | 0 .../include/config/generic/cmos/update.h | 0 .../include/config/generic/find/first/bit.h | 0 .../include/config/generic/find/next/bit.h | 0 .../include/config/generic/hardirqs.h | 0 .../include/config/generic/hweight.h | 0 .../include/config/generic/iomap.h | 0 .../include/config/generic/irq/probe.h | 0 .../include/config/generic/isa/dma.h | 0 .../include/config/generic/pending/irq.h | 0 .../include/config/generic/time.h | 0 .../linux-26-headers/include/config/has/dma.h | 0 .../include/config/has/iomem.h | 0 .../include/config/has/ioport.h | 0 .../include/config/have/arch/kgdb.h | 0 .../include/config/have/dynamic/ftrace.h | 0 .../config/have/efficient/unaligned/access.h | 0 .../include/config/have/ftrace.h | 0 .../config/have/generic/dma/coherent.h | 0 .../include/config/have/ide.h | 0 .../include/config/have/ioremap/prot.h | 0 .../include/config/have/kprobes.h | 0 .../include/config/have/kretprobes.h | 0 .../include/config/have/kvm.h | 0 .../include/config/have/latencytop/support.h | 0 .../include/config/have/oprofile.h | 0 .../include/config/have/setup/per/cpu/area.h | 0 .../config/have/unstable/sched/clock.h | 0 l4/pkg/linux-26-headers/include/config/hid.h | 0 .../include/config/hid/support.h | 0 .../include/config/high/res/timers.h | 0 .../linux-26-headers/include/config/highmem.h | 0 .../include/config/highmem4g.h | 0 .../linux-26-headers/include/config/hotplug.h | 0 .../include/config/hotplug/cpu.h | 0 l4/pkg/linux-26-headers/include/config/hpet.h | 0 .../include/config/hpet/emulate/rtc.h | 0 .../include/config/hpet/mmap.h | 0 .../include/config/hpet/rtc/irq.h | 0 .../include/config/hpet/timer.h | 0 .../include/config/hugetlb/page.h | 0 .../include/config/hugetlbfs.h | 0 .../include/config/hw/console.h | 0 .../include/config/hw/random.h | 0 .../include/config/hw/random/amd.h | 0 .../include/config/hw/random/geode.h | 0 .../include/config/hw/random/intel.h | 0 .../include/config/hw/random/via.h | 0 l4/pkg/linux-26-headers/include/config/hz.h | 0 .../linux-26-headers/include/config/hz/250.h | 0 l4/pkg/linux-26-headers/include/config/ide.h | 0 .../include/config/ide/generic.h | 0 .../include/config/ide/proc/fs.h | 0 .../include/config/ide/timings.h | 0 .../include/config/idedisk/multi/mode.h | 0 .../include/config/idepci/pcibus/order.h | 0 .../include/config/ieee1394.h | 0 .../include/config/ieee1394/ohci1394.h | 0 .../include/config/ieee1394/rawio.h | 0 .../include/config/ikconfig.h | 0 .../include/config/ikconfig/proc.h | 0 l4/pkg/linux-26-headers/include/config/inet.h | 0 .../include/config/inet/diag.h | 0 .../include/config/inet/tcp/diag.h | 0 .../include/config/inet/tunnel.h | 0 .../include/config/inet/xfrm/mode/transport.h | 0 .../include/config/inet/xfrm/mode/tunnel.h | 0 .../config/inet6/xfrm/mode/transport.h | 0 .../include/config/inet6/xfrm/mode/tunnel.h | 0 .../include/config/init/env/arg/limit.h | 0 .../include/config/initramfs/source.h | 0 .../linux-26-headers/include/config/inotify.h | 0 .../include/config/inotify/user.h | 0 .../linux-26-headers/include/config/input.h | 0 .../include/config/input/evdev.h | 0 .../include/config/input/keyboard.h | 0 .../include/config/input/mouse.h | 0 .../include/config/input/mousedev.h | 0 .../include/config/input/mousedev/psaux.h | 0 .../include/config/input/mousedev/screen/x.h | 0 .../include/config/input/mousedev/screen/y.h | 0 .../include/config/io/delay/0x80.h | 0 .../include/config/io/delay/type/0x80.h | 0 .../include/config/io/delay/type/0xed.h | 0 .../include/config/io/delay/type/none.h | 0 .../include/config/io/delay/type/udelay.h | 0 .../include/config/iosched/as.h | 0 .../include/config/iosched/cfq.h | 0 .../include/config/iosched/deadline.h | 0 .../include/config/iosched/noop.h | 0 .../include/config/ip/fib/hash.h | 0 .../include/config/ip/multicast.h | 0 .../linux-26-headers/include/config/ip/pnp.h | 0 .../include/config/ip/pnp/dhcp.h | 0 l4/pkg/linux-26-headers/include/config/ipv6.h | 0 .../include/config/ipv6/ndisc/nodetype.h | 0 .../include/config/ipv6/sit.h | 0 .../include/config/isa/dma/api.h | 0 .../include/config/iso9660/fs.h | 0 l4/pkg/linux-26-headers/include/config/jbd.h | 0 .../linux-26-headers/include/config/k8/nb.h | 0 .../include/config/kallsyms.h | 0 .../include/config/kallsyms/all.h | 0 .../include/config/kernel.release | 1 - .../include/config/keyboard/atkbd.h | 0 l4/pkg/linux-26-headers/include/config/kmod.h | 0 .../linux-26-headers/include/config/kprobes.h | 0 .../include/config/kretprobes.h | 0 .../include/config/ktime/scalar.h | 0 l4/pkg/linux-26-headers/include/config/kvm.h | 0 .../include/config/kvm/intel.h | 0 l4/pkg/linux-26-headers/include/config/lbd.h | 0 .../include/config/legacy/pty/count.h | 0 .../include/config/legacy/ptys.h | 0 .../include/config/localversion.h | 0 .../include/config/localversion/auto.h | 0 .../include/config/lock/kernel.h | 0 .../linux-26-headers/include/config/lockd.h | 0 .../include/config/lockd/v4.h | 0 .../include/config/lockdep/support.h | 0 .../include/config/log/buf/shift.h | 0 .../include/config/macintosh/drivers.h | 0 .../include/config/magic/sysrq.h | 0 .../include/config/max/raw/devs.h | 0 .../linux-26-headers/include/config/mcore2.h | 0 l4/pkg/linux-26-headers/include/config/md.h | 0 .../include/config/microcode.h | 0 .../include/config/microcode/old/interface.h | 0 l4/pkg/linux-26-headers/include/config/mii.h | 0 .../include/config/misc/devices.h | 0 l4/pkg/linux-26-headers/include/config/mmu.h | 0 .../include/config/mmu/notifier.h | 0 .../include/config/module/force/unload.h | 0 .../include/config/module/unload.h | 0 .../linux-26-headers/include/config/modules.h | 0 .../include/config/mouse/ps2.h | 0 .../include/config/mouse/ps2/alps.h | 0 .../include/config/mouse/ps2/lifebook.h | 0 .../include/config/mouse/ps2/logips2pp.h | 0 .../include/config/mouse/ps2/synaptics.h | 0 .../include/config/mouse/ps2/trackpoint.h | 0 .../include/config/msdos/fs.h | 0 .../include/config/msdos/partition.h | 0 l4/pkg/linux-26-headers/include/config/mtrr.h | 0 .../include/config/namespaces.h | 0 l4/pkg/linux-26-headers/include/config/net.h | 0 .../include/config/net/ethernet.h | 0 .../linux-26-headers/include/config/net/pci.h | 0 .../include/config/net/poll/controller.h | 0 .../include/config/net/tulip.h | 0 .../include/config/net/vendor/3com.h | 0 .../include/config/netconsole.h | 0 .../include/config/netdev/1000.h | 0 .../include/config/netdev/10000.h | 0 .../include/config/netdevices.h | 0 .../linux-26-headers/include/config/netpoll.h | 0 .../include/config/network/filesystems.h | 0 .../include/config/nfs/common.h | 0 .../linux-26-headers/include/config/nfs/fs.h | 0 .../linux-26-headers/include/config/nfs/v3.h | 0 l4/pkg/linux-26-headers/include/config/nfsd.h | 0 .../linux-26-headers/include/config/nfsd/v3.h | 0 l4/pkg/linux-26-headers/include/config/nls.h | 0 .../include/config/nls/ascii.h | 0 .../include/config/nls/codepage/437.h | 0 .../include/config/nls/default.h | 0 .../include/config/nls/iso8859/1.h | 0 .../include/config/nls/iso8859/15.h | 0 .../include/config/nls/utf8.h | 0 .../linux-26-headers/include/config/no/hz.h | 0 .../linux-26-headers/include/config/nr/cpus.h | 0 .../include/config/oprofile.h | 0 .../linux-26-headers/include/config/packet.h | 0 .../include/config/page/offset.h | 0 .../include/config/pageflags/extended.h | 0 l4/pkg/linux-26-headers/include/config/pci.h | 0 .../include/config/pci/bios.h | 0 .../include/config/pci/direct.h | 0 .../include/config/pci/domains.h | 0 .../include/config/pci/goany.h | 0 .../include/config/pci/legacy.h | 0 .../include/config/pci/mmconfig.h | 0 .../linux-26-headers/include/config/pci/msi.h | 0 .../include/config/pcspkr/platform.h | 0 .../linux-26-headers/include/config/phylib.h | 0 .../include/config/physical/align.h | 0 .../include/config/physical/start.h | 0 .../linux-26-headers/include/config/plist.h | 0 l4/pkg/linux-26-headers/include/config/pm.h | 0 .../include/config/pm/sleep.h | 0 .../include/config/pm/sleep/smp.h | 0 l4/pkg/linux-26-headers/include/config/pnp.h | 0 .../linux-26-headers/include/config/pnpacpi.h | 0 .../include/config/posix/mqueue.h | 0 .../include/config/power/supply.h | 0 .../include/config/preempt/notifiers.h | 0 .../include/config/preempt/voluntary.h | 0 .../include/config/prevent/firmware/build.h | 0 .../linux-26-headers/include/config/printk.h | 0 .../linux-26-headers/include/config/proc/fs.h | 0 .../include/config/proc/kcore.h | 0 .../include/config/proc/page/monitor.h | 0 .../include/config/proc/sysctl.h | 0 .../include/config/profiling.h | 0 .../linux-26-headers/include/config/r8169.h | 0 .../include/config/raw/driver.h | 0 .../include/config/reiserfs/fs.h | 0 .../include/config/reiserfs/fs/posix/acl.h | 0 .../include/config/reiserfs/fs/xattr.h | 0 .../linux-26-headers/include/config/relay.h | 0 .../include/config/resources/64bit.h | 0 .../include/config/root/nfs.h | 0 .../include/config/rt/mutexes.h | 0 l4/pkg/linux-26-headers/include/config/rtc.h | 0 .../include/config/rwsem/xchgadd/algorithm.h | 0 .../include/config/sata/ahci.h | 0 .../linux-26-headers/include/config/sata/nv.h | 0 .../include/config/sata/pmp.h | 0 .../include/config/sata/sil.h | 0 .../include/config/sata/svw.h | 0 .../include/config/sata/via.h | 0 .../include/config/sched/hrtick.h | 0 .../include/config/sched/mc.h | 0 .../config/sched/no/no/omit/frame/pointer.h | 0 .../include/config/sched/smt.h | 0 l4/pkg/linux-26-headers/include/config/scsi.h | 0 .../include/config/scsi/aic79xx.h | 0 .../include/config/scsi/aic7xxx.h | 0 .../include/config/scsi/dma.h | 0 .../include/config/scsi/fc/attrs.h | 0 .../include/config/scsi/lowlevel.h | 0 .../include/config/scsi/netlink.h | 0 .../include/config/scsi/spi/attrs.h | 0 .../include/config/scsi/wait/scan.h | 0 .../linux-26-headers/include/config/seccomp.h | 0 .../include/config/select/memory/model.h | 0 .../include/config/serial/8250.h | 0 .../include/config/serial/8250/console.h | 0 .../include/config/serial/8250/nr/uarts.h | 0 .../include/config/serial/8250/pci.h | 0 .../include/config/serial/8250/pnp.h | 0 .../config/serial/8250/runtime/uarts.h | 0 .../include/config/serial/core.h | 0 .../include/config/serial/core/console.h | 0 .../linux-26-headers/include/config/serio.h | 0 .../include/config/serio/i8042.h | 0 .../include/config/serio/libps2.h | 0 .../linux-26-headers/include/config/shmem.h | 0 .../include/config/signalfd.h | 0 l4/pkg/linux-26-headers/include/config/sky2.h | 0 .../include/config/slabinfo.h | 0 l4/pkg/linux-26-headers/include/config/slub.h | 0 .../include/config/slub/debug.h | 0 l4/pkg/linux-26-headers/include/config/smp.h | 0 .../linux-26-headers/include/config/sound.h | 0 .../include/config/sound/prime.h | 0 .../include/config/split/ptlock/cpus.h | 0 l4/pkg/linux-26-headers/include/config/ssb.h | 0 .../include/config/ssb/driver/pcicore.h | 0 .../config/ssb/driver/pcicore/possible.h | 0 .../include/config/ssb/pcihost.h | 0 .../include/config/ssb/pcihost/possible.h | 0 .../include/config/ssb/possible.h | 0 .../include/config/ssb/sprom.h | 0 .../include/config/stacktrace/support.h | 0 .../include/config/standalone.h | 0 .../include/config/stop/machine.h | 0 .../linux-26-headers/include/config/sunrpc.h | 0 .../linux-26-headers/include/config/suspend.h | 0 .../include/config/suspend/freezer.h | 0 l4/pkg/linux-26-headers/include/config/swap.h | 0 .../linux-26-headers/include/config/sysctl.h | 0 .../include/config/sysctl/syscall.h | 0 .../include/config/sysctl/syscall/check.h | 0 .../linux-26-headers/include/config/sysfs.h | 0 .../include/config/sysfs/deprecated.h | 0 .../include/config/sysfs/deprecated/v2.h | 0 .../linux-26-headers/include/config/sysvipc.h | 0 .../include/config/sysvipc/sysctl.h | 0 .../include/config/tcp/cong/cubic.h | 0 .../linux-26-headers/include/config/thermal.h | 0 .../include/config/tick/oneshot.h | 0 .../linux-26-headers/include/config/tigon3.h | 0 .../include/config/timer/stats.h | 0 .../linux-26-headers/include/config/timerfd.h | 0 .../linux-26-headers/include/config/tmpfs.h | 0 .../include/config/tmpfs/posix/acl.h | 0 .../include/config/trace/irqflags/support.h | 0 .../linux-26-headers/include/config/tulip.h | 0 .../include/config/uevent/helper/path.h | 0 .../linux-26-headers/include/config/uid16.h | 0 l4/pkg/linux-26-headers/include/config/unix.h | 0 .../include/config/unix98/ptys.h | 0 .../include/config/unused/symbols.h | 0 l4/pkg/linux-26-headers/include/config/usb.h | 0 .../include/config/usb/announce/new/devices.h | 0 .../include/config/usb/arch/has/ehci.h | 0 .../include/config/usb/arch/has/hcd.h | 0 .../include/config/usb/arch/has/ohci.h | 0 .../include/config/usb/devicefs.h | 0 .../include/config/usb/ehci/hcd.h | 0 .../linux-26-headers/include/config/usb/hid.h | 0 .../linux-26-headers/include/config/usb/mon.h | 0 .../include/config/usb/ohci/hcd.h | 0 .../include/config/usb/ohci/little/endian.h | 0 .../include/config/usb/printer.h | 0 .../include/config/usb/serial.h | 0 .../include/config/usb/serial/generic.h | 0 .../include/config/usb/serial/pl2303.h | 0 .../include/config/usb/storage.h | 0 .../include/config/usb/support.h | 0 .../include/config/usb/uhci/hcd.h | 0 .../include/config/use/generic/smp/helpers.h | 0 .../linux-26-headers/include/config/vfat/fs.h | 0 .../include/config/vga/console.h | 0 .../include/config/vgacon/soft/scrollback.h | 0 .../config/vgacon/soft/scrollback/size.h | 0 .../include/config/video/select.h | 0 .../include/config/virt/to/bus.h | 0 .../include/config/virtualization.h | 0 .../include/config/vm/event/counters.h | 0 l4/pkg/linux-26-headers/include/config/vm86.h | 0 .../linux-26-headers/include/config/vortex.h | 0 l4/pkg/linux-26-headers/include/config/vt.h | 0 .../include/config/vt/console.h | 0 l4/pkg/linux-26-headers/include/config/x86.h | 0 .../linux-26-headers/include/config/x86/32.h | 0 .../include/config/x86/32/smp.h | 0 .../include/config/x86/acpi/cpufreq.h | 0 .../config/x86/acpi/cpufreq/proc/intf.h | 0 .../include/config/x86/bios/reboot.h | 0 .../include/config/x86/bswap.h | 0 .../include/config/x86/cmpxchg.h | 0 .../linux-26-headers/include/config/x86/cpu.h | 0 .../include/config/x86/cpuid.h | 0 .../include/config/x86/cyclone/timer.h | 0 .../include/config/x86/debugctlmsr.h | 0 .../include/config/x86/find/smp/config.h | 0 .../include/config/x86/generic.h | 0 .../include/config/x86/genericarch.h | 0 .../linux-26-headers/include/config/x86/ht.h | 0 .../include/config/x86/intel/usercopy.h | 0 .../include/config/x86/invlpg.h | 0 .../include/config/x86/io/apic.h | 0 .../include/config/x86/l1/cache/shift.h | 0 .../include/config/x86/local/apic.h | 0 .../linux-26-headers/include/config/x86/mce.h | 0 .../include/config/x86/mce/nonfatal.h | 0 .../include/config/x86/mce/p4thermal.h | 0 .../include/config/x86/minimum/cpu/family.h | 0 .../include/config/x86/mpparse.h | 0 .../linux-26-headers/include/config/x86/msr.h | 0 .../include/config/x86/pm/timer.h | 0 .../include/config/x86/popad/ok.h | 0 .../include/config/x86/powernow/k8.h | 0 .../include/config/x86/powernow/k8/acpi.h | 0 .../linux-26-headers/include/config/x86/smp.h | 0 .../include/config/x86/trampoline.h | 0 .../linux-26-headers/include/config/x86/tsc.h | 0 .../include/config/x86/use/ppro/checksum.h | 0 .../include/config/x86/verbose/bootup.h | 0 .../include/config/x86/wp/works/ok.h | 0 .../include/config/x86/xadd.h | 0 l4/pkg/linux-26-headers/include/config/xfrm.h | 0 .../include/config/zlib/inflate.h | 0 .../include/config/zone/dma.h | 0 .../include/config/zone/dma/flag.h | 0 l4/pkg/linux-26-headers/include/crypto/aead.h | 105 - l4/pkg/linux-26-headers/include/crypto/aes.h | 35 - .../linux-26-headers/include/crypto/algapi.h | 318 - .../linux-26-headers/include/crypto/authenc.h | 27 - .../linux-26-headers/include/crypto/b128ops.h | 80 - l4/pkg/linux-26-headers/include/crypto/ctr.h | 20 - l4/pkg/linux-26-headers/include/crypto/des.h | 19 - .../include/crypto/gf128mul.h | 200 - l4/pkg/linux-26-headers/include/crypto/hash.h | 172 - .../include/crypto/internal/aead.h | 80 - .../include/crypto/internal/hash.h | 78 - .../include/crypto/internal/skcipher.h | 116 - .../include/crypto/scatterwalk.h | 123 - l4/pkg/linux-26-headers/include/crypto/sha.h | 65 - .../include/crypto/skcipher.h | 110 - .../linux-26-headers/include/crypto/twofish.h | 22 - l4/pkg/linux-26-headers/include/drm/Kbuild | 10 - l4/pkg/linux-26-headers/include/drm/drmP.h | 1154 - .../linux-26-headers/include/drm/drm_core.h | 34 - .../include/drm/drm_hashtab.h | 67 - .../linux-26-headers/include/drm/drm_memory.h | 61 - .../include/drm/drm_memory_debug.h | 309 - .../include/drm/drm_os_linux.h | 108 - .../linux-26-headers/include/drm/drm_pciids.h | 415 - .../linux-26-headers/include/drm/drm_sman.h | 176 - .../linux-26-headers/include/drm/i830_drm.h | 342 - .../include/keys/rxrpc-type.h | 24 - .../linux-26-headers/include/keys/user-type.h | 47 - .../linux-26-headers/include/linux/8250_pci.h | 37 - l4/pkg/linux-26-headers/include/linux/Kbuild | 371 - .../include/linux/ac97_codec.h | 362 - l4/pkg/linux-26-headers/include/linux/acpi.h | 281 - .../include/linux/acpi_pmtmr.h | 40 - .../include/linux/adfs_fs_i.h | 24 - .../include/linux/adfs_fs_sb.h | 38 - l4/pkg/linux-26-headers/include/linux/aer.h | 36 - .../include/linux/agp_backend.h | 109 - l4/pkg/linux-26-headers/include/linux/aio.h | 227 - .../linux-26-headers/include/linux/amba/bus.h | 55 - .../include/linux/amba/clcd.h | 280 - .../linux-26-headers/include/linux/amba/kmi.h | 92 - .../include/linux/amba/serial.h | 167 - l4/pkg/linux-26-headers/include/linux/amifd.h | 62 - .../linux-26-headers/include/linux/amifdreg.h | 81 - .../linux-26-headers/include/linux/amigaffs.h | 144 - .../include/linux/anon_inodes.h | 15 - .../include/linux/apm-emulation.h | 62 - .../include/linux/arcdevice.h | 341 - .../linux-26-headers/include/linux/async_tx.h | 150 - l4/pkg/linux-26-headers/include/linux/ata.h | 762 - .../include/linux/ata_platform.h | 37 - .../linux-26-headers/include/linux/atm_suni.h | 12 - .../include/linux/atmel-pwm-bl.h | 43 - .../include/linux/atmel-ssc.h | 312 - .../include/linux/atmel_pdc.h | 36 - .../include/linux/atmel_pwm.h | 70 - .../include/linux/atmel_serial.h | 127 - .../linux-26-headers/include/linux/atmel_tc.h | 252 - .../include/linux/attribute_container.h | 71 - .../linux-26-headers/include/linux/autoconf.h | 516 - .../linux-26-headers/include/linux/b1pcmcia.h | 21 - .../include/linux/backing-dev.h | 261 - .../include/linux/backlight.h | 104 - l4/pkg/linux-26-headers/include/linux/bcd.h | 25 - l4/pkg/linux-26-headers/include/linux/bio.h | 507 - .../include/linux/bit_spinlock.h | 95 - .../linux-26-headers/include/linux/bitmap.h | 292 - .../linux-26-headers/include/linux/bitops.h | 164 - .../linux-26-headers/include/linux/bitrev.h | 16 - .../linux-26-headers/include/linux/blkdev.h | 1027 - .../include/linux/blockgroup_lock.h | 59 - .../linux-26-headers/include/linux/bootmem.h | 158 - .../include/linux/bottom_half.h | 10 - .../linux-26-headers/include/linux/bounds.h | 13 - .../linux-26-headers/include/linux/brcmphy.h | 6 - .../include/linux/buffer_head.h | 350 - l4/pkg/linux-26-headers/include/linux/bug.h | 50 - .../include/linux/byteorder.h | 372 - .../include/linux/byteorder/Kbuild | 3 - .../include/linux/byteorder/generic.h | 173 - .../include/linux/byteorder/swab.h | 222 - .../include/linux/byteorder/swabb.h | 135 - l4/pkg/linux-26-headers/include/linux/cache.h | 67 - .../linux-26-headers/include/linux/can/Kbuild | 3 - .../linux-26-headers/include/linux/can/core.h | 64 - .../linux-26-headers/include/linux/cd1400.h | 292 - l4/pkg/linux-26-headers/include/linux/cdev.h | 35 - l4/pkg/linux-26-headers/include/linux/cdk.h | 486 - .../include/linux/cfag12864b.h | 82 - .../linux-26-headers/include/linux/cgroup.h | 425 - .../include/linux/cgroup_subsys.h | 50 - .../linux-26-headers/include/linux/circ_buf.h | 32 - l4/pkg/linux-26-headers/include/linux/clk.h | 124 - .../include/linux/clockchips.h | 144 - .../include/linux/clocksource.h | 239 - .../include/linux/cnt32_to_63.h | 80 - .../include/linux/coda_cache.h | 22 - .../include/linux/coda_fs_i.h | 53 - .../include/linux/coda_linux.h | 95 - .../linux-26-headers/include/linux/com20020.h | 115 - .../linux-26-headers/include/linux/compat.h | 282 - .../linux-26-headers/include/linux/compile.h | 9 - .../include/linux/compiler-gcc.h | 63 - .../include/linux/compiler-gcc3.h | 24 - .../include/linux/compiler-gcc4.h | 35 - .../include/linux/compiler-intel.h | 31 - .../linux-26-headers/include/linux/compiler.h | 197 - .../include/linux/completion.h | 61 - .../linux-26-headers/include/linux/comstats.h | 119 - .../linux-26-headers/include/linux/concap.h | 112 - .../linux-26-headers/include/linux/configfs.h | 260 - .../linux-26-headers/include/linux/console.h | 156 - .../include/linux/console_struct.h | 139 - .../include/linux/consolemap.h | 34 - l4/pkg/linux-26-headers/include/linux/cpu.h | 153 - .../linux-26-headers/include/linux/cpufreq.h | 382 - .../linux-26-headers/include/linux/cpuidle.h | 191 - .../linux-26-headers/include/linux/cpumask.h | 530 - .../linux-26-headers/include/linux/cpuset.h | 168 - .../include/linux/cramfs_fs_sb.h | 20 - .../include/linux/crash_dump.h | 40 - .../include/linux/crc-ccitt.h | 15 - .../include/linux/crc-itu-t.h | 28 - .../include/linux/crc-t10dif.h | 8 - l4/pkg/linux-26-headers/include/linux/crc16.h | 30 - l4/pkg/linux-26-headers/include/linux/crc32.h | 27 - .../linux-26-headers/include/linux/crc32c.h | 11 - l4/pkg/linux-26-headers/include/linux/crc7.h | 14 - l4/pkg/linux-26-headers/include/linux/cred.h | 50 - .../linux-26-headers/include/linux/crypto.h | 1308 - .../include/linux/cryptohash.h | 12 - l4/pkg/linux-26-headers/include/linux/ctype.h | 54 - .../linux-26-headers/include/linux/cyclomx.h | 77 - .../linux-26-headers/include/linux/cycx_drv.h | 64 - .../linux-26-headers/include/linux/cycx_x25.h | 125 - l4/pkg/linux-26-headers/include/linux/dca.h | 52 - .../linux-26-headers/include/linux/dcache.h | 368 - .../linux-26-headers/include/linux/dcookies.h | 68 - .../include/linux/debug_locks.h | 72 - .../linux-26-headers/include/linux/debugfs.h | 179 - .../include/linux/debugobjects.h | 90 - l4/pkg/linux-26-headers/include/linux/delay.h | 54 - .../include/linux/delayacct.h | 153 - .../include/linux/device-mapper.h | 351 - .../linux-26-headers/include/linux/device.h | 563 - .../include/linux/device_cgroup.h | 12 - .../include/linux/devpts_fs.h | 38 - l4/pkg/linux-26-headers/include/linux/dio.h | 280 - .../linux-26-headers/include/linux/dirent.h | 12 - .../linux-26-headers/include/linux/display.h | 61 - .../include/linux/dm-dirty-log.h | 131 - l4/pkg/linux-26-headers/include/linux/dm-io.h | 85 - .../include/linux/dm-kcopyd.h | 47 - .../linux-26-headers/include/linux/dm9000.h | 40 - .../include/linux/dma-attrs.h | 75 - .../include/linux/dma-mapping.h | 166 - .../include/linux/dmaengine.h | 506 - .../linux-26-headers/include/linux/dmapool.h | 35 - l4/pkg/linux-26-headers/include/linux/dmar.h | 86 - l4/pkg/linux-26-headers/include/linux/dmi.h | 102 - .../linux-26-headers/include/linux/dnotify.h | 62 - .../linux-26-headers/include/linux/dqblk_v1.h | 24 - .../linux-26-headers/include/linux/dqblk_v2.h | 26 - .../linux-26-headers/include/linux/ds1286.h | 54 - .../include/linux/ds17287rtc.h | 66 - l4/pkg/linux-26-headers/include/linux/ds1wm.h | 12 - l4/pkg/linux-26-headers/include/linux/dtlk.h | 104 - .../linux-26-headers/include/linux/dvb/Kbuild | 9 - .../linux-26-headers/include/linux/dw_dmac.h | 62 - l4/pkg/linux-26-headers/include/linux/edac.h | 41 - .../include/linux/eeprom_93cx6.h | 73 - l4/pkg/linux-26-headers/include/linux/efi.h | 400 - .../linux-26-headers/include/linux/efs_vh.h | 53 - l4/pkg/linux-26-headers/include/linux/eisa.h | 111 - .../linux-26-headers/include/linux/elevator.h | 211 - .../include/linux/elfcore-compat.h | 55 - .../linux-26-headers/include/linux/elfnote.h | 98 - .../include/linux/enclosure.h | 130 - l4/pkg/linux-26-headers/include/linux/err.h | 52 - .../include/linux/etherdevice.h | 141 - .../linux-26-headers/include/linux/eventfd.h | 32 - .../linux-26-headers/include/linux/exportfs.h | 173 - .../linux-26-headers/include/linux/ext2_fs.h | 566 - .../include/linux/ext2_fs_sb.h | 111 - .../linux-26-headers/include/linux/ext3_fs.h | 897 - .../include/linux/ext3_fs_i.h | 147 - .../include/linux/ext3_fs_sb.h | 86 - .../linux-26-headers/include/linux/ext3_jbd.h | 226 - .../linux-26-headers/include/linux/f75375s.h | 21 - .../include/linux/fault-inject.h | 84 - .../linux-26-headers/include/linux/fcdevice.h | 33 - .../include/linux/fddidevice.h | 33 - .../linux-26-headers/include/linux/fdtable.h | 100 - l4/pkg/linux-26-headers/include/linux/file.h | 44 - .../include/linux/firmware-map.h | 48 - .../linux-26-headers/include/linux/firmware.h | 66 - l4/pkg/linux-26-headers/include/linux/font.h | 58 - .../linux-26-headers/include/linux/freezer.h | 196 - .../include/linux/fs_enet_pd.h | 164 - .../linux-26-headers/include/linux/fs_stack.h | 31 - .../include/linux/fs_struct.h | 27 - .../include/linux/fs_uart_pd.h | 71 - .../include/linux/fsl_devices.h | 135 - .../linux-26-headers/include/linux/fsnotify.h | 297 - .../linux-26-headers/include/linux/ftrace.h | 165 - .../linux-26-headers/include/linux/genalloc.h | 36 - .../include/linux/generic_acl.h | 36 - .../include/linux/generic_serial.h | 96 - l4/pkg/linux-26-headers/include/linux/genhd.h | 566 - .../linux-26-headers/include/linux/getcpu.h | 18 - l4/pkg/linux-26-headers/include/linux/gfp.h | 253 - l4/pkg/linux-26-headers/include/linux/gpio.h | 111 - .../include/linux/gpio_keys.h | 20 - .../include/linux/gpio_mouse.h | 61 - .../linux-26-headers/include/linux/hardirq.h | 167 - l4/pkg/linux-26-headers/include/linux/hash.h | 70 - .../linux-26-headers/include/linux/hayesesp.h | 115 - .../include/linux/hdlc/Kbuild | 1 - .../include/linux/hdpu_features.h | 26 - .../include/linux/hid-debug.h | 45 - .../linux-26-headers/include/linux/highmem.h | 188 - .../linux-26-headers/include/linux/highuid.h | 97 - l4/pkg/linux-26-headers/include/linux/hil.h | 483 - .../linux-26-headers/include/linux/hil_mlc.h | 168 - .../include/linux/hippidevice.h | 39 - .../linux-26-headers/include/linux/hp_sdc.h | 301 - .../linux-26-headers/include/linux/hrtimer.h | 416 - l4/pkg/linux-26-headers/include/linux/htirq.h | 23 - .../linux-26-headers/include/linux/hugetlb.h | 282 - .../include/linux/hw_random.h | 48 - .../include/linux/hwmon-sysfs.h | 55 - .../include/linux/hwmon-vid.h | 45 - l4/pkg/linux-26-headers/include/linux/hwmon.h | 35 - .../include/linux/i2c-algo-bit.h | 51 - .../include/linux/i2c-algo-pca.h | 41 - .../include/linux/i2c-algo-pcf.h | 45 - .../include/linux/i2c-algo-sgi.h | 26 - .../linux-26-headers/include/linux/i2c-gpio.h | 38 - .../linux-26-headers/include/linux/i2c-id.h | 166 - .../include/linux/i2c-ocores.h | 19 - .../include/linux/i2c-pca-platform.h | 12 - .../linux-26-headers/include/linux/i2c-pnx.h | 45 - .../linux-26-headers/include/linux/i2c-pxa.h | 17 - .../linux-26-headers/include/linux/i2c/at24.h | 28 - .../include/linux/i2c/max732x.h | 19 - .../include/linux/i2c/pca953x.h | 18 - .../include/linux/i2c/pcf857x.h | 44 - .../include/linux/i2c/tps65010.h | 186 - l4/pkg/linux-26-headers/include/linux/i2o.h | 1256 - l4/pkg/linux-26-headers/include/linux/i8042.h | 35 - l4/pkg/linux-26-headers/include/linux/ibmtr.h | 373 - l4/pkg/linux-26-headers/include/linux/ide.h | 1462 - l4/pkg/linux-26-headers/include/linux/idr.h | 145 - .../include/linux/ieee80211.h | 1036 - l4/pkg/linux-26-headers/include/linux/if_ec.h | 72 - .../include/linux/if_macvlan.h | 6 - .../linux-26-headers/include/linux/if_strip.h | 25 - l4/pkg/linux-26-headers/include/linux/if_tr.h | 102 - l4/pkg/linux-26-headers/include/linux/ihex.h | 74 - l4/pkg/linux-26-headers/include/linux/inet.h | 57 - .../linux-26-headers/include/linux/inet_lro.h | 184 - .../include/linux/inetdevice.h | 223 - l4/pkg/linux-26-headers/include/linux/init.h | 334 - .../include/linux/init_ohci1394_dma.h | 4 - .../include/linux/init_task.h | 193 - .../linux-26-headers/include/linux/initrd.h | 20 - .../include/linux/input-polldev.h | 46 - .../include/linux/interrupt.h | 444 - l4/pkg/linux-26-headers/include/linux/io.h | 70 - l4/pkg/linux-26-headers/include/linux/ioc3.h | 93 - l4/pkg/linux-26-headers/include/linux/ioc4.h | 184 - .../include/linux/iocontext.h | 120 - .../include/linux/iommu-helper.h | 10 - .../linux-26-headers/include/linux/ioport.h | 171 - .../linux-26-headers/include/linux/ioprio.h | 89 - .../include/linux/ipc_namespace.h | 102 - .../linux-26-headers/include/linux/ipmi_smi.h | 235 - l4/pkg/linux-26-headers/include/linux/irq.h | 385 - .../include/linux/irq_cpustat.h | 31 - .../linux-26-headers/include/linux/irqflags.h | 129 - .../include/linux/irqreturn.h | 25 - l4/pkg/linux-26-headers/include/linux/isa.h | 39 - .../linux-26-headers/include/linux/isapnp.h | 131 - .../include/linux/iscsi_ibft.h | 50 - .../include/linux/isdn/Kbuild | 1 - .../include/linux/isdn/capilli.h | 113 - .../include/linux/isdn/capiutil.h | 521 - .../linux-26-headers/include/linux/isicom.h | 83 - .../include/linux/istallion.h | 125 - l4/pkg/linux-26-headers/include/linux/jbd.h | 1080 - l4/pkg/linux-26-headers/include/linux/jbd2.h | 1234 - l4/pkg/linux-26-headers/include/linux/jhash.h | 143 - .../linux-26-headers/include/linux/jiffies.h | 303 - .../include/linux/journal-head.h | 92 - .../linux-26-headers/include/linux/kallsyms.h | 114 - .../include/linux/kbd_diacr.h | 8 - .../linux-26-headers/include/linux/kbd_kern.h | 167 - .../linux-26-headers/include/linux/kbuild.h | 15 - .../linux-26-headers/include/linux/kdebug.h | 22 - .../include/linux/kernel_stat.h | 61 - .../linux-26-headers/include/linux/key-type.h | 112 - .../linux-26-headers/include/linux/key-ui.h | 66 - l4/pkg/linux-26-headers/include/linux/key.h | 321 - l4/pkg/linux-26-headers/include/linux/kfifo.h | 152 - l4/pkg/linux-26-headers/include/linux/kgdb.h | 283 - l4/pkg/linux-26-headers/include/linux/klist.h | 71 - .../include/linux/kmalloc_sizes.h | 45 - l4/pkg/linux-26-headers/include/linux/kmod.h | 102 - .../linux-26-headers/include/linux/kobj_map.h | 10 - .../linux-26-headers/include/linux/kobject.h | 226 - .../linux-26-headers/include/linux/kprobes.h | 320 - l4/pkg/linux-26-headers/include/linux/kref.h | 30 - .../linux-26-headers/include/linux/ks0108.h | 49 - .../linux-26-headers/include/linux/kthread.h | 37 - l4/pkg/linux-26-headers/include/linux/ktime.h | 336 - .../linux-26-headers/include/linux/kvm_host.h | 359 - .../include/linux/kvm_types.h | 56 - l4/pkg/linux-26-headers/include/linux/lapb.h | 56 - .../include/linux/latencytop.h | 44 - l4/pkg/linux-26-headers/include/linux/lcd.h | 89 - .../include/linux/leds-pca9532.h | 45 - l4/pkg/linux-26-headers/include/linux/leds.h | 152 - .../linux-26-headers/include/linux/lguest.h | 60 - .../include/linux/lguest_launcher.h | 62 - .../linux-26-headers/include/linux/libata.h | 1609 - .../linux-26-headers/include/linux/libps2.h | 51 - .../linux-26-headers/include/linux/license.h | 14 - .../linux-26-headers/include/linux/linkage.h | 98 - .../include/linux/linux_logo.h | 45 - l4/pkg/linux-26-headers/include/linux/list.h | 695 - .../include/linux/lm_interface.h | 277 - l4/pkg/linux-26-headers/include/linux/lmb.h | 87 - .../include/linux/lockd/bind.h | 67 - .../include/linux/lockd/debug.h | 57 - .../include/linux/lockd/lockd.h | 263 - .../include/linux/lockd/nlm.h | 57 - .../include/linux/lockd/share.h | 31 - .../include/linux/lockd/sm_inter.h | 48 - .../include/linux/lockd/xdr.h | 113 - .../include/linux/lockd/xdr4.h | 47 - .../linux-26-headers/include/linux/lockdep.h | 483 - l4/pkg/linux-26-headers/include/linux/log2.h | 209 - l4/pkg/linux-26-headers/include/linux/lzo.h | 44 - .../linux-26-headers/include/linux/m48t86.h | 16 - .../linux-26-headers/include/linux/mISDNdsp.h | 37 - .../linux-26-headers/include/linux/mISDNhw.h | 193 - .../linux-26-headers/include/linux/mISDNif.h | 509 - l4/pkg/linux-26-headers/include/linux/maple.h | 85 - .../linux-26-headers/include/linux/marker.h | 163 - .../linux-26-headers/include/linux/math64.h | 105 - .../linux-26-headers/include/linux/mbcache.h | 52 - l4/pkg/linux-26-headers/include/linux/mbus.h | 36 - .../include/linux/mc146818rtc.h | 119 - .../linux-26-headers/include/linux/mc6821.h | 51 - .../include/linux/mca-legacy.h | 66 - l4/pkg/linux-26-headers/include/linux/mca.h | 148 - .../include/linux/mdio-bitbang.h | 42 - .../include/linux/memcontrol.h | 176 - .../linux-26-headers/include/linux/memory.h | 102 - .../include/linux/memory_hotplug.h | 223 - .../linux-26-headers/include/linux/mempool.h | 79 - .../linux-26-headers/include/linux/memstick.h | 347 - .../include/linux/mfd/asic3.h | 502 - .../linux-26-headers/include/linux/mfd/core.h | 55 - .../include/linux/mfd/htc-egpio.h | 57 - .../include/linux/mfd/htc-pasic3.h | 55 - .../include/linux/mfd/t7l66xb.h | 36 - .../include/linux/mfd/tc6387xb.h | 23 - .../include/linux/mfd/tc6393xb.h | 46 - .../linux-26-headers/include/linux/mfd/tmio.h | 28 - .../linux-26-headers/include/linux/migrate.h | 47 - .../include/linux/miscdevice.h | 51 - .../linux-26-headers/include/linux/mlx4/cmd.h | 179 - .../linux-26-headers/include/linux/mlx4/cq.h | 150 - .../include/linux/mlx4/device.h | 429 - .../include/linux/mlx4/doorbell.h | 86 - .../include/linux/mlx4/driver.h | 58 - .../linux-26-headers/include/linux/mlx4/qp.h | 320 - .../linux-26-headers/include/linux/mlx4/srq.h | 42 - l4/pkg/linux-26-headers/include/linux/mm.h | 1290 - .../include/linux/mm_inline.h | 40 - .../linux-26-headers/include/linux/mm_types.h | 262 - .../linux-26-headers/include/linux/mmc/card.h | 153 - .../linux-26-headers/include/linux/mmc/core.h | 154 - .../linux-26-headers/include/linux/mmc/host.h | 194 - .../linux-26-headers/include/linux/mmc/mmc.h | 283 - .../linux-26-headers/include/linux/mmc/sd.h | 83 - .../linux-26-headers/include/linux/mmc/sdio.h | 159 - .../include/linux/mmc/sdio_func.h | 154 - .../include/linux/mmc/sdio_ids.h | 29 - .../include/linux/mmiotrace.h | 85 - .../include/linux/mmu_notifier.h | 279 - .../linux-26-headers/include/linux/mmzone.h | 1007 - .../include/linux/mnt_namespace.h | 53 - .../include/linux/mod_devicetable.h | 392 - .../linux-26-headers/include/linux/module.h | 608 - .../include/linux/moduleloader.h | 47 - .../include/linux/moduleparam.h | 204 - l4/pkg/linux-26-headers/include/linux/mount.h | 117 - l4/pkg/linux-26-headers/include/linux/mpage.h | 34 - l4/pkg/linux-26-headers/include/linux/msi.h | 50 - .../linux-26-headers/include/linux/mtd/bbm.h | 132 - .../include/linux/mtd/blktrans.h | 71 - .../linux-26-headers/include/linux/mtd/cfi.h | 511 - .../include/linux/mtd/cfi_endian.h | 52 - .../include/linux/mtd/compatmac.h | 10 - .../include/linux/mtd/concat.h | 21 - .../include/linux/mtd/doc2000.h | 193 - .../include/linux/mtd/flashchip.h | 88 - .../linux-26-headers/include/linux/mtd/ftl.h | 74 - .../include/linux/mtd/gen_probe.h | 22 - .../include/linux/mtd/inftl.h | 63 - .../linux-26-headers/include/linux/mtd/map.h | 443 - .../linux-26-headers/include/linux/mtd/mtd.h | 283 - .../include/linux/mtd/mtdram.h | 8 - .../linux-26-headers/include/linux/mtd/nand.h | 623 - .../include/linux/mtd/nand_ecc.h | 28 - .../linux-26-headers/include/linux/mtd/ndfc.h | 67 - .../linux-26-headers/include/linux/mtd/nftl.h | 57 - .../include/linux/mtd/onenand.h | 193 - .../include/linux/mtd/onenand_regs.h | 199 - .../include/linux/mtd/partitions.h | 80 - .../include/linux/mtd/physmap.h | 51 - .../include/linux/mtd/plat-ram.h | 34 - .../include/linux/mtd/pmc551.h | 78 - .../include/linux/mtd/super.h | 30 - .../linux-26-headers/include/linux/mtd/ubi.h | 187 - .../linux-26-headers/include/linux/mtd/xip.h | 99 - .../include/linux/mutex-debug.h | 23 - l4/pkg/linux-26-headers/include/linux/mutex.h | 151 - .../linux-26-headers/include/linux/mv643xx.h | 979 - .../include/linux/mv643xx_eth.h | 75 - .../include/linux/mv643xx_i2c.h | 22 - l4/pkg/linux-26-headers/include/linux/namei.h | 93 - .../linux-26-headers/include/linux/ncp_fs_i.h | 29 - .../include/linux/ncp_fs_sb.h | 160 - .../include/linux/netfilter/Kbuild | 49 - .../linux/netfilter/nf_conntrack_amanda.h | 10 - .../linux/netfilter/nf_conntrack_dccp.h | 40 - .../linux/netfilter/nf_conntrack_h323.h | 92 - .../linux/netfilter/nf_conntrack_h323_asn1.h | 98 - .../linux/netfilter/nf_conntrack_h323_types.h | 934 - .../linux/netfilter/nf_conntrack_irc.h | 15 - .../linux/netfilter/nf_conntrack_pptp.h | 324 - .../linux/netfilter/nf_conntrack_proto_gre.h | 94 - .../linux/netfilter/nf_conntrack_sane.h | 21 - .../linux/netfilter/nf_conntrack_sip.h | 169 - .../linux/netfilter/nf_conntrack_tftp.h | 20 - .../include/linux/netfilter_arp/Kbuild | 3 - .../include/linux/netfilter_bridge/Kbuild | 17 - .../include/linux/netfilter_ipv4/Kbuild | 47 - .../include/linux/netfilter_ipv4/ip_queue.h | 72 - .../linux/netfilter_ipv4/ipt_CLASSIFY.h | 7 - .../linux/netfilter_ipv4/ipt_CONNMARK.h | 19 - .../include/linux/netfilter_ipv4/ipt_DSCP.h | 18 - .../include/linux/netfilter_ipv4/ipt_MARK.h | 18 - .../linux/netfilter_ipv4/ipt_NFQUEUE.h | 16 - .../include/linux/netfilter_ipv4/ipt_SAME.h | 19 - .../include/linux/netfilter_ipv4/ipt_TCPMSS.h | 9 - .../include/linux/netfilter_ipv4/ipt_TOS.h | 12 - .../linux/netfilter_ipv4/ipt_addrtype.h | 25 - .../linux/netfilter_ipv4/ipt_comment.h | 10 - .../linux/netfilter_ipv4/ipt_connbytes.h | 18 - .../linux/netfilter_ipv4/ipt_connmark.h | 7 - .../linux/netfilter_ipv4/ipt_conntrack.h | 28 - .../include/linux/netfilter_ipv4/ipt_dccp.h | 15 - .../include/linux/netfilter_ipv4/ipt_dscp.h | 21 - .../include/linux/netfilter_ipv4/ipt_esp.h | 10 - .../linux/netfilter_ipv4/ipt_hashlimit.h | 14 - .../include/linux/netfilter_ipv4/ipt_helper.h | 7 - .../linux/netfilter_ipv4/ipt_iprange.h | 21 - .../include/linux/netfilter_ipv4/ipt_length.h | 7 - .../include/linux/netfilter_ipv4/ipt_limit.h | 8 - .../include/linux/netfilter_ipv4/ipt_mac.h | 7 - .../include/linux/netfilter_ipv4/ipt_mark.h | 9 - .../linux/netfilter_ipv4/ipt_multiport.h | 15 - .../include/linux/netfilter_ipv4/ipt_owner.h | 20 - .../linux/netfilter_ipv4/ipt_physdev.h | 17 - .../linux/netfilter_ipv4/ipt_pkttype.h | 7 - .../include/linux/netfilter_ipv4/ipt_policy.h | 21 - .../include/linux/netfilter_ipv4/ipt_realm.h | 7 - .../include/linux/netfilter_ipv4/ipt_recent.h | 27 - .../include/linux/netfilter_ipv4/ipt_sctp.h | 105 - .../include/linux/netfilter_ipv4/ipt_state.h | 15 - .../include/linux/netfilter_ipv4/ipt_string.h | 10 - .../include/linux/netfilter_ipv4/ipt_tcpmss.h | 7 - .../include/linux/netfilter_ipv4/ipt_tos.h | 13 - .../include/linux/netfilter_ipv6/Kbuild | 21 - .../include/linux/netfilter_ipv6/ip6t_MARK.h | 9 - .../include/linux/netfilter_ipv6/ip6t_esp.h | 10 - .../linux/netfilter_ipv6/ip6t_length.h | 8 - .../include/linux/netfilter_ipv6/ip6t_limit.h | 8 - .../include/linux/netfilter_ipv6/ip6t_mac.h | 7 - .../include/linux/netfilter_ipv6/ip6t_mark.h | 9 - .../linux/netfilter_ipv6/ip6t_multiport.h | 14 - .../include/linux/netfilter_ipv6/ip6t_owner.h | 18 - .../linux/netfilter_ipv6/ip6t_physdev.h | 17 - .../linux/netfilter_ipv6/ip6t_policy.h | 21 - .../linux-26-headers/include/linux/netpoll.h | 123 - .../linux-26-headers/include/linux/nfs4_acl.h | 61 - .../linux-26-headers/include/linux/nfs_fs_i.h | 24 - .../include/linux/nfs_fs_sb.h | 139 - .../include/linux/nfs_iostat.h | 119 - .../linux-26-headers/include/linux/nfs_page.h | 138 - .../linux-26-headers/include/linux/nfs_xdr.h | 857 - .../include/linux/nfsd/Kbuild | 6 - .../include/linux/nfsd/cache.h | 79 - .../include/linux/nfsd/const.h | 55 - .../include/linux/nfsd/nfsd.h | 336 - .../include/linux/nfsd/state.h | 308 - .../include/linux/nfsd/syscall.h | 123 - .../linux-26-headers/include/linux/nfsd/xdr.h | 177 - .../include/linux/nfsd/xdr3.h | 346 - .../include/linux/nfsd/xdr4.h | 485 - .../include/linux/nfsd_idmap.h | 64 - l4/pkg/linux-26-headers/include/linux/nls.h | 64 - l4/pkg/linux-26-headers/include/linux/nmi.h | 35 - l4/pkg/linux-26-headers/include/linux/node.h | 59 - .../linux-26-headers/include/linux/nodemask.h | 463 - .../linux-26-headers/include/linux/notifier.h | 260 - .../linux-26-headers/include/linux/nsc_gpio.h | 40 - .../linux-26-headers/include/linux/nsproxy.h | 93 - l4/pkg/linux-26-headers/include/linux/numa.h | 13 - l4/pkg/linux-26-headers/include/linux/of.h | 75 - .../include/linux/of_device.h | 30 - .../linux-26-headers/include/linux/of_gpio.h | 69 - .../linux-26-headers/include/linux/of_i2c.h | 20 - .../include/linux/of_platform.h | 61 - .../linux-26-headers/include/linux/of_spi.h | 18 - .../linux-26-headers/include/linux/oprofile.h | 164 - .../include/linux/page-flags.h | 353 - .../include/linux/page-isolation.h | 37 - .../include/linux/pageblock-flags.h | 73 - .../linux-26-headers/include/linux/pagemap.h | 427 - .../linux-26-headers/include/linux/pagevec.h | 90 - .../include/linux/parport_pc.h | 237 - .../linux-26-headers/include/linux/parser.h | 33 - l4/pkg/linux-26-headers/include/linux/path.h | 15 - .../linux-26-headers/include/linux/pci-acpi.h | 82 - .../linux-26-headers/include/linux/pci-aspm.h | 61 - .../include/linux/pci_hotplug.h | 230 - .../linux-26-headers/include/linux/pci_ids.h | 2572 - .../include/linux/pcieport_if.h | 80 - .../include/linux/pda_power.h | 36 - .../linux-26-headers/include/linux/percpu.h | 109 - .../include/linux/percpu_counter.h | 153 - l4/pkg/linux-26-headers/include/linux/pfn.h | 9 - .../linux-26-headers/include/linux/phonedev.h | 25 - l4/pkg/linux-26-headers/include/linux/phy.h | 456 - .../include/linux/phy_fixed.h | 31 - l4/pkg/linux-26-headers/include/linux/pid.h | 173 - .../include/linux/pid_namespace.h | 96 - l4/pkg/linux-26-headers/include/linux/pim.h | 27 - .../include/linux/pipe_fs_i.h | 151 - .../include/linux/platform_device.h | 72 - l4/pkg/linux-26-headers/include/linux/plist.h | 240 - l4/pkg/linux-26-headers/include/linux/pm.h | 445 - .../include/linux/pm_qos_params.h | 25 - .../include/linux/pm_wakeup.h | 78 - l4/pkg/linux-26-headers/include/linux/pnp.h | 496 - .../linux-26-headers/include/linux/poison.h | 71 - .../include/linux/posix-timers.h | 118 - .../include/linux/posix_acl.h | 86 - .../include/linux/posix_acl_xattr.h | 58 - .../include/linux/power_supply.h | 175 - .../include/linux/ppp_channel.h | 81 - .../linux-26-headers/include/linux/preempt.h | 139 - .../linux-26-headers/include/linux/prefetch.h | 64 - .../include/linux/prio_heap.h | 58 - .../include/linux/prio_tree.h | 120 - .../linux-26-headers/include/linux/proc_fs.h | 321 - .../linux-26-headers/include/linux/profile.h | 143 - .../include/linux/proportions.h | 132 - l4/pkg/linux-26-headers/include/linux/pwm.h | 31 - .../include/linux/pwm_backlight.h | 17 - .../include/linux/quicklist.h | 93 - .../include/linux/quotaio_v1.h | 33 - .../include/linux/quotaio_v2.h | 79 - .../linux-26-headers/include/linux/quotaops.h | 369 - .../include/linux/radix-tree.h | 193 - .../include/linux/raid/Kbuild | 2 - .../include/linux/raid/bitmap.h | 288 - .../include/linux/raid/linear.h | 29 - .../linux-26-headers/include/linux/raid/md.h | 103 - .../include/linux/raid/md_k.h | 390 - .../include/linux/raid/multipath.h | 42 - .../include/linux/raid/raid0.h | 30 - .../include/linux/raid/raid1.h | 134 - .../include/linux/raid/raid10.h | 123 - .../include/linux/raid/raid5.h | 402 - .../linux-26-headers/include/linux/raid/xor.h | 24 - .../include/linux/raid_class.h | 82 - l4/pkg/linux-26-headers/include/linux/ramfs.h | 23 - .../include/linux/ratelimit.h | 27 - .../linux-26-headers/include/linux/rbtree.h | 161 - .../include/linux/rcuclassic.h | 167 - .../linux-26-headers/include/linux/rculist.h | 401 - .../linux-26-headers/include/linux/rcupdate.h | 256 - .../include/linux/rcupreempt.h | 140 - .../include/linux/rcupreempt_trace.h | 97 - .../include/linux/reciprocal_div.h | 32 - .../linux-26-headers/include/linux/regset.h | 368 - .../include/linux/regulator/bq24022.h | 21 - .../include/linux/regulator/consumer.h | 284 - .../include/linux/regulator/driver.h | 99 - .../include/linux/regulator/fixed.h | 22 - .../include/linux/regulator/machine.h | 104 - .../include/linux/reiserfs_acl.h | 107 - .../include/linux/reiserfs_fs_i.h | 67 - .../include/linux/reiserfs_fs_sb.h | 531 - l4/pkg/linux-26-headers/include/linux/relay.h | 291 - .../include/linux/res_counter.h | 177 - .../include/linux/resume-trace.h | 25 - l4/pkg/linux-26-headers/include/linux/rio.h | 334 - .../linux-26-headers/include/linux/rio_drv.h | 466 - .../linux-26-headers/include/linux/rio_ids.h | 24 - .../linux-26-headers/include/linux/rio_regs.h | 215 - l4/pkg/linux-26-headers/include/linux/rmap.h | 144 - .../linux-26-headers/include/linux/root_dev.h | 23 - l4/pkg/linux-26-headers/include/linux/rslib.h | 109 - .../include/linux/rtc-v3020.h | 35 - .../include/linux/rtc/m48t59.h | 57 - .../linux-26-headers/include/linux/rtmutex.h | 107 - .../include/linux/rwsem-spinlock.h | 78 - l4/pkg/linux-26-headers/include/linux/rwsem.h | 91 - l4/pkg/linux-26-headers/include/linux/rxrpc.h | 62 - .../linux-26-headers/include/linux/sc26198.h | 533 - .../include/linux/scatterlist.h | 265 - l4/pkg/linux-26-headers/include/linux/sctp.h | 710 - .../linux-26-headers/include/linux/scx200.h | 51 - .../include/linux/scx200_gpio.h | 88 - .../linux-26-headers/include/linux/security.h | 2810 - .../include/linux/selection.h | 43 - .../linux-26-headers/include/linux/selinux.h | 89 - .../include/linux/semaphore.h | 49 - .../linux-26-headers/include/linux/seq_file.h | 82 - .../include/linux/seq_file_net.h | 30 - .../linux-26-headers/include/linux/seqlock.h | 197 - .../include/linux/serial167.h | 157 - .../linux-26-headers/include/linux/serialP.h | 142 - .../include/linux/serial_8250.h | 71 - .../include/linux/serial_pnx8xxx.h | 81 - .../include/linux/serial_sci.h | 32 - .../linux-26-headers/include/linux/shmem_fs.h | 65 - .../linux-26-headers/include/linux/skbuff.h | 1729 - l4/pkg/linux-26-headers/include/linux/slab.h | 296 - .../linux-26-headers/include/linux/slab_def.h | 98 - .../linux-26-headers/include/linux/slob_def.h | 36 - .../linux-26-headers/include/linux/slub_def.h | 249 - .../include/linux/sm501-regs.h | 386 - l4/pkg/linux-26-headers/include/linux/sm501.h | 174 - l4/pkg/linux-26-headers/include/linux/smb.h | 118 - .../linux-26-headers/include/linux/smb_fs.h | 153 - .../linux-26-headers/include/linux/smb_fs_i.h | 37 - .../include/linux/smb_fs_sb.h | 97 - .../include/linux/smb_mount.h | 65 - l4/pkg/linux-26-headers/include/linux/smbno.h | 363 - .../linux-26-headers/include/linux/smc911x.h | 12 - .../linux-26-headers/include/linux/smc91x.h | 23 - l4/pkg/linux-26-headers/include/linux/smp.h | 171 - .../linux-26-headers/include/linux/smp_lock.h | 52 - .../include/linux/sony-laptop.h | 34 - l4/pkg/linux-26-headers/include/linux/sort.h | 10 - .../linux-26-headers/include/linux/spi/Kbuild | 1 - .../include/linux/spi/ad7877.h | 24 - .../include/linux/spi/ads7846.h | 52 - .../include/linux/spi/at73c213.h | 25 - .../include/linux/spi/ds1305.h | 35 - .../include/linux/spi/eeprom.h | 22 - .../include/linux/spi/flash.h | 31 - .../include/linux/spi/max7301.h | 9 - .../include/linux/spi/mcp23s08.h | 31 - .../include/linux/spi/mmc_spi.h | 44 - .../include/linux/spi/orion_spi.h | 17 - .../linux-26-headers/include/linux/spi/spi.h | 804 - .../include/linux/spi/spi_bitbang.h | 143 - .../include/linux/spi/tle62x0.h | 24 - .../linux-26-headers/include/linux/spinlock.h | 367 - .../include/linux/spinlock_api_smp.h | 63 - .../include/linux/spinlock_api_up.h | 81 - .../include/linux/spinlock_types.h | 100 - .../include/linux/spinlock_types_up.h | 37 - .../include/linux/spinlock_up.h | 75 - .../linux-26-headers/include/linux/splice.h | 74 - l4/pkg/linux-26-headers/include/linux/srcu.h | 53 - .../linux-26-headers/include/linux/ssb/ssb.h | 596 - .../include/linux/ssb/ssb_driver_chipcommon.h | 409 - .../include/linux/ssb/ssb_driver_extif.h | 214 - .../include/linux/ssb/ssb_driver_gige.h | 174 - .../include/linux/ssb/ssb_driver_mips.h | 46 - .../include/linux/ssb/ssb_driver_pci.h | 130 - .../include/linux/ssb/ssb_embedded.h | 18 - .../include/linux/ssb/ssb_regs.h | 357 - .../include/linux/stacktrace.h | 24 - .../linux-26-headers/include/linux/stallion.h | 147 - .../include/linux/start_kernel.h | 12 - .../linux-26-headers/include/linux/statfs.h | 22 - .../include/linux/stop_machine.h | 50 - .../include/linux/stringify.h | 12 - .../include/linux/sunrpc/Kbuild | 1 - .../include/linux/sunrpc/auth.h | 165 - .../include/linux/sunrpc/auth_gss.h | 90 - .../include/linux/sunrpc/cache.h | 202 - .../include/linux/sunrpc/clnt.h | 151 - .../include/linux/sunrpc/gss_api.h | 134 - .../include/linux/sunrpc/gss_asn1.h | 81 - .../include/linux/sunrpc/gss_err.h | 167 - .../include/linux/sunrpc/gss_krb5.h | 159 - .../include/linux/sunrpc/gss_spkm3.h | 55 - .../include/linux/sunrpc/metrics.h | 89 - .../include/linux/sunrpc/msg_prot.h | 195 - .../include/linux/sunrpc/rpc_pipe_fs.h | 56 - .../include/linux/sunrpc/rpc_rdma.h | 116 - .../include/linux/sunrpc/sched.h | 259 - .../include/linux/sunrpc/stats.h | 77 - .../include/linux/sunrpc/svc.h | 419 - .../include/linux/sunrpc/svc_rdma.h | 285 - .../include/linux/sunrpc/svc_xprt.h | 159 - .../include/linux/sunrpc/svcauth.h | 172 - .../include/linux/sunrpc/svcauth_gss.h | 25 - .../include/linux/sunrpc/svcsock.h | 56 - .../include/linux/sunrpc/timer.h | 49 - .../include/linux/sunrpc/types.h | 22 - .../include/linux/sunrpc/xdr.h | 225 - .../include/linux/sunrpc/xprt.h | 335 - .../include/linux/sunrpc/xprtrdma.h | 85 - .../include/linux/sunrpc/xprtsock.h | 45 - .../include/linux/superhyway.h | 107 - .../linux-26-headers/include/linux/suspend.h | 283 - l4/pkg/linux-26-headers/include/linux/svga.h | 124 - l4/pkg/linux-26-headers/include/linux/swap.h | 357 - .../linux-26-headers/include/linux/swapops.h | 133 - l4/pkg/linux-26-headers/include/linux/sys.h | 29 - .../linux-26-headers/include/linux/syscalls.h | 628 - .../linux-26-headers/include/linux/sysdev.h | 156 - l4/pkg/linux-26-headers/include/linux/sysfs.h | 236 - l4/pkg/linux-26-headers/include/linux/sysrq.h | 77 - .../linux-26-headers/include/linux/sysv_fs.h | 202 - .../include/linux/task_io_accounting.h | 45 - .../include/linux/task_io_accounting_ops.h | 113 - .../include/linux/taskstats_kern.h | 43 - l4/pkg/linux-26-headers/include/linux/tc.h | 141 - .../include/linux/tc_act/Kbuild | 5 - .../include/linux/tc_act/tc_defact.h | 21 - .../include/linux/tc_ematch/Kbuild | 4 - .../include/linux/textsearch.h | 177 - .../include/linux/textsearch_fsm.h | 48 - l4/pkg/linux-26-headers/include/linux/tfrc.h | 55 - .../linux-26-headers/include/linux/thermal.h | 120 - .../include/linux/thread_info.h | 122 - .../linux-26-headers/include/linux/threads.h | 36 - l4/pkg/linux-26-headers/include/linux/tick.h | 132 - l4/pkg/linux-26-headers/include/linux/tifm.h | 164 - l4/pkg/linux-26-headers/include/linux/timer.h | 189 - .../linux-26-headers/include/linux/timerfd.h | 23 - .../linux-26-headers/include/linux/topology.h | 195 - .../include/linux/tracehook.h | 582 - .../include/linux/transport_class.h | 101 - .../linux-26-headers/include/linux/trdevice.h | 37 - .../include/linux/tsacct_kern.h | 34 - .../include/linux/tty_driver.h | 340 - .../linux-26-headers/include/linux/tty_flip.h | 23 - .../include/linux/tty_ldisc.h | 157 - .../include/linux/typecheck.h | 24 - .../linux-26-headers/include/linux/uaccess.h | 109 - .../include/linux/uio_driver.h | 95 - .../include/linux/unaligned/access_ok.h | 67 - .../include/linux/unaligned/be_byteshift.h | 70 - .../include/linux/unaligned/be_memmove.h | 36 - .../include/linux/unaligned/be_struct.h | 36 - .../include/linux/unaligned/generic.h | 68 - .../include/linux/unaligned/le_byteshift.h | 70 - .../include/linux/unaligned/le_memmove.h | 36 - .../include/linux/unaligned/le_struct.h | 36 - .../include/linux/unaligned/memmove.h | 45 - .../include/linux/unaligned/packed_struct.h | 46 - .../linux-26-headers/include/linux/unwind.h | 68 - l4/pkg/linux-26-headers/include/linux/usb.h | 1723 - .../linux-26-headers/include/linux/usb/Kbuild | 7 - .../include/linux/usb/association.h | 150 - .../include/linux/usb/atmel_usba_udc.h | 22 - .../include/linux/usb/c67x00.h | 48 - .../include/linux/usb/composite.h | 338 - .../include/linux/usb/gadget.h | 893 - .../include/linux/usb/input.h | 25 - .../include/linux/usb/iowarrior.h | 42 - .../linux-26-headers/include/linux/usb/irda.h | 151 - .../include/linux/usb/isp116x.h | 33 - .../linux-26-headers/include/linux/usb/musb.h | 98 - .../include/linux/usb/net2280.h | 443 - .../linux-26-headers/include/linux/usb/otg.h | 135 - .../include/linux/usb/quirks.h | 19 - .../include/linux/usb/rndis_host.h | 272 - .../include/linux/usb/serial.h | 330 - .../include/linux/usb/sl811.h | 29 - .../include/linux/usb/usbnet.h | 212 - .../include/linux/usb_usual.h | 139 - l4/pkg/linux-26-headers/include/linux/user.h | 1 - .../include/linux/user_namespace.h | 61 - l4/pkg/linux-26-headers/include/linux/uts.h | 19 - .../include/linux/utsrelease.h | 1 - .../linux-26-headers/include/linux/vermagic.h | 34 - l4/pkg/linux-26-headers/include/linux/vfs.h | 6 - l4/pkg/linux-26-headers/include/linux/via.h | 22 - .../include/linux/video_decoder.h | 46 - .../include/linux/video_encoder.h | 21 - .../include/linux/video_output.h | 42 - .../linux-26-headers/include/linux/videodev.h | 321 - .../include/linux/videotext.h | 125 - .../linux-26-headers/include/linux/virtio.h | 120 - .../linux-26-headers/include/linux/vmalloc.h | 95 - .../linux-26-headers/include/linux/vmstat.h | 273 - .../include/linux/vt_buffer.h | 63 - .../linux-26-headers/include/linux/vt_kern.h | 119 - .../linux-26-headers/include/linux/w1-gpio.h | 23 - .../linux-26-headers/include/linux/wm97xx.h | 315 - .../include/linux/workqueue.h | 241 - .../include/linux/writeback.h | 155 - .../linux-26-headers/include/linux/xilinxfb.h | 30 - l4/pkg/linux-26-headers/include/linux/yam.h | 82 - l4/pkg/linux-26-headers/include/linux/zconf.h | 57 - l4/pkg/linux-26-headers/include/linux/zlib.h | 706 - l4/pkg/linux-26-headers/include/linux/zorro.h | 254 - .../include/linux/zorro_ids.h | 552 - l4/pkg/linux-26-headers/include/linux/zutil.h | 106 - .../include/math-emu/double.h | 205 - .../linux-26-headers/include/math-emu/op-1.h | 303 - .../linux-26-headers/include/math-emu/op-2.h | 613 - .../linux-26-headers/include/math-emu/op-4.h | 692 - .../linux-26-headers/include/math-emu/op-8.h | 107 - .../include/math-emu/op-common.h | 865 - .../linux-26-headers/include/math-emu/quad.h | 208 - .../include/math-emu/single.h | 116 - .../include/math-emu/soft-fp.h | 188 - .../linux-26-headers/include/media/cs5345.h | 39 - .../linux-26-headers/include/media/cs53l32a.h | 34 - .../linux-26-headers/include/media/cx2341x.h | 196 - .../linux-26-headers/include/media/cx25840.h | 87 - .../linux-26-headers/include/media/i2c-addr.h | 44 - .../include/media/ir-common.h | 157 - .../include/media/ir-kbd-i2c.h | 22 - .../linux-26-headers/include/media/m52790.h | 93 - .../linux-26-headers/include/media/msp3400.h | 226 - .../include/media/ovcamchip.h | 90 - .../include/media/pwc-ioctl.h | 324 - l4/pkg/linux-26-headers/include/media/rds.h | 44 - .../include/media/saa6752hs.h | 26 - .../linux-26-headers/include/media/saa7115.h | 49 - .../linux-26-headers/include/media/saa7127.h | 41 - .../linux-26-headers/include/media/saa7146.h | 458 - .../include/media/saa7146_vv.h | 276 - .../include/media/sh_mobile_ceu.h | 12 - .../include/media/soc_camera.h | 182 - .../include/media/soc_camera_platform.h | 15 - .../include/media/tuner-types.h | 131 - l4/pkg/linux-26-headers/include/media/tuner.h | 194 - .../linux-26-headers/include/media/tvaudio.h | 30 - .../linux-26-headers/include/media/tveeprom.h | 38 - .../linux-26-headers/include/media/tvp5150.h | 34 - .../include/media/upd64031a.h | 40 - .../linux-26-headers/include/media/upd64083.h | 58 - .../include/media/v4l2-chip-ident.h | 168 - .../include/media/v4l2-common.h | 239 - .../linux-26-headers/include/media/v4l2-dev.h | 118 - .../include/media/v4l2-i2c-drv-legacy.h | 141 - .../include/media/v4l2-i2c-drv.h | 70 - .../include/media/v4l2-int-device.h | 277 - .../include/media/v4l2-ioctl.h | 301 - .../include/media/videobuf-core.h | 247 - .../include/media/videobuf-dma-contig.h | 32 - .../include/media/videobuf-dma-sg.h | 119 - .../include/media/videobuf-dvb.h | 38 - .../include/media/videobuf-vmalloc.h | 45 - .../linux-26-headers/include/media/wm8775.h | 35 - l4/pkg/linux-26-headers/include/mtd/Kbuild | 6 - .../linux-26-headers/include/mtd/jffs2-user.h | 33 - l4/pkg/linux-26-headers/include/net/9p/9p.h | 600 - .../linux-26-headers/include/net/9p/client.h | 117 - .../include/net/9p/transport.h | 104 - l4/pkg/linux-26-headers/include/net/act_api.h | 124 - .../linux-26-headers/include/net/addrconf.h | 264 - .../linux-26-headers/include/net/af_rxrpc.h | 57 - l4/pkg/linux-26-headers/include/net/af_unix.h | 69 - l4/pkg/linux-26-headers/include/net/ah.h | 48 - l4/pkg/linux-26-headers/include/net/arp.h | 31 - l4/pkg/linux-26-headers/include/net/atmclip.h | 62 - l4/pkg/linux-26-headers/include/net/ax25.h | 450 - l4/pkg/linux-26-headers/include/net/ax88796.h | 28 - .../include/net/bluetooth/bluetooth.h | 181 - .../include/net/bluetooth/hci.h | 1023 - .../include/net/bluetooth/hci_core.h | 673 - .../include/net/bluetooth/l2cap.h | 265 - .../include/net/bluetooth/rfcomm.h | 357 - .../include/net/bluetooth/sco.h | 79 - .../linux-26-headers/include/net/cfg80211.h | 375 - .../linux-26-headers/include/net/checksum.h | 121 - .../linux-26-headers/include/net/cipso_ipv4.h | 246 - l4/pkg/linux-26-headers/include/net/compat.h | 49 - .../linux-26-headers/include/net/datalink.h | 18 - l4/pkg/linux-26-headers/include/net/dn.h | 234 - l4/pkg/linux-26-headers/include/net/dn_dev.h | 194 - l4/pkg/linux-26-headers/include/net/dn_fib.h | 189 - .../linux-26-headers/include/net/dn_neigh.h | 28 - l4/pkg/linux-26-headers/include/net/dn_nsp.h | 209 - .../linux-26-headers/include/net/dn_route.h | 109 - l4/pkg/linux-26-headers/include/net/dsfield.h | 54 - l4/pkg/linux-26-headers/include/net/dst.h | 293 - l4/pkg/linux-26-headers/include/net/esp.h | 25 - .../linux-26-headers/include/net/fib_rules.h | 117 - l4/pkg/linux-26-headers/include/net/flow.h | 100 - l4/pkg/linux-26-headers/include/net/garp.h | 128 - .../linux-26-headers/include/net/gen_stats.h | 49 - .../linux-26-headers/include/net/genetlink.h | 252 - l4/pkg/linux-26-headers/include/net/icmp.h | 62 - .../linux-26-headers/include/net/ieee80211.h | 1323 - .../include/net/ieee80211_crypt.h | 108 - .../include/net/ieee80211_radiotap.h | 268 - .../linux-26-headers/include/net/if_inet6.h | 287 - .../include/net/inet6_connection_sock.h | 42 - .../include/net/inet6_hashtables.h | 99 - .../include/net/inet_common.h | 55 - .../include/net/inet_connection_sock.h | 334 - .../linux-26-headers/include/net/inet_ecn.h | 130 - .../linux-26-headers/include/net/inet_frag.h | 72 - .../include/net/inet_hashtables.h | 381 - .../linux-26-headers/include/net/inet_sock.h | 213 - .../include/net/inet_timewait_sock.h | 231 - .../linux-26-headers/include/net/inetpeer.h | 53 - l4/pkg/linux-26-headers/include/net/ip.h | 393 - .../include/net/ip6_checksum.h | 94 - l4/pkg/linux-26-headers/include/net/ip6_fib.h | 234 - .../linux-26-headers/include/net/ip6_route.h | 151 - .../linux-26-headers/include/net/ip6_tunnel.h | 33 - l4/pkg/linux-26-headers/include/net/ip_fib.h | 279 - l4/pkg/linux-26-headers/include/net/ip_vs.h | 771 - l4/pkg/linux-26-headers/include/net/ipcomp.h | 29 - .../linux-26-headers/include/net/ipconfig.h | 25 - l4/pkg/linux-26-headers/include/net/ipip.h | 55 - l4/pkg/linux-26-headers/include/net/ipv6.h | 616 - l4/pkg/linux-26-headers/include/net/ipx.h | 161 - .../include/net/irda/af_irda.h | 87 - .../linux-26-headers/include/net/irda/crc.h | 29 - .../include/net/irda/discovery.h | 97 - .../include/net/irda/ircomm_core.h | 108 - .../include/net/irda/ircomm_event.h | 85 - .../include/net/irda/ircomm_lmp.h | 38 - .../include/net/irda/ircomm_param.h | 149 - .../include/net/irda/ircomm_ttp.h | 39 - .../include/net/irda/ircomm_tty.h | 138 - .../include/net/irda/ircomm_tty_attach.h | 94 - .../linux-26-headers/include/net/irda/irda.h | 135 - .../include/net/irda/irda_device.h | 285 - .../linux-26-headers/include/net/irda/iriap.h | 108 - .../include/net/irda/iriap_event.h | 85 - .../include/net/irda/irias_object.h | 108 - .../include/net/irda/irlan_client.h | 42 - .../include/net/irda/irlan_common.h | 230 - .../include/net/irda/irlan_eth.h | 32 - .../include/net/irda/irlan_event.h | 81 - .../include/net/irda/irlan_filter.h | 35 - .../include/net/irda/irlan_provider.h | 52 - .../linux-26-headers/include/net/irda/irlap.h | 311 - .../include/net/irda/irlap_event.h | 131 - .../include/net/irda/irlap_frame.h | 169 - .../linux-26-headers/include/net/irda/irlmp.h | 294 - .../include/net/irda/irlmp_event.h | 98 - .../include/net/irda/irlmp_frame.h | 62 - .../linux-26-headers/include/net/irda/irmod.h | 109 - .../include/net/irda/irqueue.h | 96 - .../linux-26-headers/include/net/irda/irttp.h | 210 - .../include/net/irda/parameters.h | 102 - .../linux-26-headers/include/net/irda/qos.h | 103 - .../linux-26-headers/include/net/irda/timer.h | 105 - .../include/net/irda/wrapper.h | 58 - .../include/net/iucv/af_iucv.h | 95 - .../linux-26-headers/include/net/iucv/iucv.h | 415 - .../linux-26-headers/include/net/iw_handler.h | 589 - l4/pkg/linux-26-headers/include/net/lapb.h | 152 - l4/pkg/linux-26-headers/include/net/llc.h | 130 - .../linux-26-headers/include/net/llc_c_ac.h | 202 - .../linux-26-headers/include/net/llc_c_ev.h | 269 - .../linux-26-headers/include/net/llc_c_st.h | 48 - .../linux-26-headers/include/net/llc_conn.h | 120 - l4/pkg/linux-26-headers/include/net/llc_if.h | 99 - l4/pkg/linux-26-headers/include/net/llc_pdu.h | 437 - .../linux-26-headers/include/net/llc_s_ac.h | 39 - .../linux-26-headers/include/net/llc_s_ev.h | 67 - .../linux-26-headers/include/net/llc_s_st.h | 32 - l4/pkg/linux-26-headers/include/net/llc_sap.h | 36 - .../linux-26-headers/include/net/mac80211.h | 1761 - l4/pkg/linux-26-headers/include/net/mip6.h | 54 - l4/pkg/linux-26-headers/include/net/ndisc.h | 154 - .../linux-26-headers/include/net/neighbour.h | 377 - .../include/net/net_namespace.h | 226 - l4/pkg/linux-26-headers/include/net/netdma.h | 43 - .../linux-26-headers/include/net/netevent.h | 33 - .../net/netfilter/ipv4/nf_conntrack_icmp.h | 11 - .../net/netfilter/ipv4/nf_conntrack_ipv4.h | 24 - .../net/netfilter/ipv6/nf_conntrack_icmpv6.h | 27 - .../net/netfilter/ipv6/nf_conntrack_ipv6.h | 23 - .../include/net/netfilter/nf_conntrack.h | 290 - .../include/net/netfilter/nf_conntrack_acct.h | 51 - .../include/net/netfilter/nf_conntrack_core.h | 78 - .../net/netfilter/nf_conntrack_ecache.h | 76 - .../net/netfilter/nf_conntrack_expect.h | 97 - .../net/netfilter/nf_conntrack_extend.h | 87 - .../net/netfilter/nf_conntrack_helper.h | 60 - .../net/netfilter/nf_conntrack_l3proto.h | 89 - .../net/netfilter/nf_conntrack_l4proto.h | 136 - .../net/netfilter/nf_conntrack_tuple.h | 220 - .../include/net/netfilter/nf_log.h | 59 - .../include/net/netfilter/nf_nat.h | 97 - .../include/net/netfilter/nf_nat_core.h | 28 - .../include/net/netfilter/nf_nat_helper.h | 35 - .../include/net/netfilter/nf_nat_protocol.h | 78 - .../include/net/netfilter/nf_nat_rule.h | 17 - .../include/net/netfilter/nf_queue.h | 34 - .../include/net/netfilter/xt_rateest.h | 17 - .../linux-26-headers/include/net/netlabel.h | 485 - l4/pkg/linux-26-headers/include/net/netlink.h | 1130 - .../linux-26-headers/include/net/netns/core.h | 16 - .../linux-26-headers/include/net/netns/dccp.h | 11 - .../include/net/netns/generic.h | 49 - .../linux-26-headers/include/net/netns/hash.h | 21 - .../linux-26-headers/include/net/netns/ipv4.h | 53 - .../linux-26-headers/include/net/netns/ipv6.h | 59 - .../linux-26-headers/include/net/netns/mib.h | 16 - .../include/net/netns/packet.h | 15 - .../linux-26-headers/include/net/netns/unix.h | 13 - .../include/net/netns/x_tables.h | 10 - l4/pkg/linux-26-headers/include/net/netrom.h | 271 - l4/pkg/linux-26-headers/include/net/nexthop.h | 33 - l4/pkg/linux-26-headers/include/net/p8022.h | 13 - l4/pkg/linux-26-headers/include/net/pkt_cls.h | 365 - .../linux-26-headers/include/net/pkt_sched.h | 113 - .../linux-26-headers/include/net/protocol.h | 110 - l4/pkg/linux-26-headers/include/net/psnap.h | 7 - l4/pkg/linux-26-headers/include/net/raw.h | 59 - l4/pkg/linux-26-headers/include/net/rawv6.h | 24 - l4/pkg/linux-26-headers/include/net/red.h | 324 - .../include/net/request_sock.h | 248 - l4/pkg/linux-26-headers/include/net/rose.h | 235 - l4/pkg/linux-26-headers/include/net/route.h | 207 - .../linux-26-headers/include/net/rtnetlink.h | 88 - .../include/net/sch_generic.h | 536 - l4/pkg/linux-26-headers/include/net/scm.h | 114 - .../linux-26-headers/include/net/sctp/auth.h | 127 - .../include/net/sctp/checksum.h | 83 - .../include/net/sctp/command.h | 221 - .../include/net/sctp/constants.h | 443 - .../linux-26-headers/include/net/sctp/sctp.h | 702 - l4/pkg/linux-26-headers/include/net/sctp/sm.h | 446 - .../include/net/sctp/structs.h | 1998 - .../include/net/sctp/tsnmap.h | 207 - .../include/net/sctp/ulpevent.h | 168 - .../include/net/sctp/ulpqueue.h | 94 - .../linux-26-headers/include/net/sctp/user.h | 759 - l4/pkg/linux-26-headers/include/net/slhc_vj.h | 183 - l4/pkg/linux-26-headers/include/net/snmp.h | 164 - l4/pkg/linux-26-headers/include/net/sock.h | 1349 - l4/pkg/linux-26-headers/include/net/stp.h | 14 - l4/pkg/linux-26-headers/include/net/syncppp.h | 102 - .../include/net/tc_act/tc_defact.h | 14 - .../include/net/tc_act/tc_gact.h | 17 - .../include/net/tc_act/tc_ipt.h | 17 - .../include/net/tc_act/tc_mirred.h | 16 - .../include/net/tc_act/tc_nat.h | 21 - .../include/net/tc_act/tc_pedit.h | 15 - l4/pkg/linux-26-headers/include/net/tcp.h | 1405 - .../linux-26-headers/include/net/tcp_states.h | 50 - .../include/net/timewait_sock.h | 41 - .../linux-26-headers/include/net/tipc/tipc.h | 257 - .../include/net/tipc/tipc_bearer.h | 138 - .../include/net/tipc/tipc_msg.h | 207 - .../include/net/tipc/tipc_port.h | 103 - .../linux-26-headers/include/net/transp_v6.h | 60 - l4/pkg/linux-26-headers/include/net/udp.h | 210 - l4/pkg/linux-26-headers/include/net/udplite.h | 121 - l4/pkg/linux-26-headers/include/net/wext.h | 38 - .../linux-26-headers/include/net/wireless.h | 331 - l4/pkg/linux-26-headers/include/net/x25.h | 306 - .../linux-26-headers/include/net/x25device.h | 16 - l4/pkg/linux-26-headers/include/net/xfrm.h | 1558 - .../linux-26-headers/include/pcmcia/ciscode.h | 131 - .../linux-26-headers/include/pcmcia/cisreg.h | 120 - .../linux-26-headers/include/pcmcia/cistpl.h | 616 - l4/pkg/linux-26-headers/include/pcmcia/cs.h | 402 - .../include/pcmcia/cs_types.h | 49 - .../include/pcmcia/device_id.h | 258 - l4/pkg/linux-26-headers/include/pcmcia/ds.h | 225 - .../linux-26-headers/include/pcmcia/mem_op.h | 116 - l4/pkg/linux-26-headers/include/pcmcia/ss.h | 310 - l4/pkg/linux-26-headers/include/rdma/Kbuild | 1 - .../linux-26-headers/include/rdma/ib_addr.h | 160 - .../linux-26-headers/include/rdma/ib_cache.h | 116 - l4/pkg/linux-26-headers/include/rdma/ib_cm.h | 589 - .../include/rdma/ib_fmr_pool.h | 93 - l4/pkg/linux-26-headers/include/rdma/ib_mad.h | 655 - .../include/rdma/ib_marshall.h | 53 - .../linux-26-headers/include/rdma/ib_pack.h | 243 - l4/pkg/linux-26-headers/include/rdma/ib_sa.h | 382 - l4/pkg/linux-26-headers/include/rdma/ib_smi.h | 128 - .../linux-26-headers/include/rdma/ib_umem.h | 83 - .../linux-26-headers/include/rdma/ib_verbs.h | 2034 - l4/pkg/linux-26-headers/include/rdma/iw_cm.h | 258 - .../linux-26-headers/include/rdma/rdma_cm.h | 333 - .../include/rdma/rdma_cm_ib.h | 54 - .../linux-26-headers/include/rxrpc/packet.h | 214 - l4/pkg/linux-26-headers/include/rxrpc/types.h | 41 - .../linux-26-headers/include/scsi/iscsi_if.h | 396 - .../include/scsi/iscsi_proto.h | 620 - .../linux-26-headers/include/scsi/libiscsi.h | 404 - l4/pkg/linux-26-headers/include/scsi/libsas.h | 681 - l4/pkg/linux-26-headers/include/scsi/libsrp.h | 77 - l4/pkg/linux-26-headers/include/scsi/sas.h | 630 - .../linux-26-headers/include/scsi/sas_ata.h | 60 - l4/pkg/linux-26-headers/include/scsi/scsi.h | 530 - .../linux-26-headers/include/scsi/scsi_cmnd.h | 297 - .../linux-26-headers/include/scsi/scsi_dbg.h | 24 - .../include/scsi/scsi_device.h | 437 - .../include/scsi/scsi_devinfo.h | 33 - .../linux-26-headers/include/scsi/scsi_dh.h | 80 - .../include/scsi/scsi_driver.h | 36 - .../linux-26-headers/include/scsi/scsi_eh.h | 95 - .../linux-26-headers/include/scsi/scsi_host.h | 848 - .../include/scsi/scsi_ioctl.h | 48 - .../linux-26-headers/include/scsi/scsi_tcq.h | 168 - .../linux-26-headers/include/scsi/scsi_tgt.h | 21 - .../include/scsi/scsi_tgt_if.h | 108 - .../include/scsi/scsi_transport.h | 120 - .../include/scsi/scsi_transport_fc.h | 737 - .../include/scsi/scsi_transport_iscsi.h | 246 - .../include/scsi/scsi_transport_sas.h | 220 - .../include/scsi/scsi_transport_spi.h | 157 - .../include/scsi/scsi_transport_srp.h | 39 - .../linux-26-headers/include/scsi/scsicam.h | 19 - l4/pkg/linux-26-headers/include/scsi/sg.h | 308 - l4/pkg/linux-26-headers/include/scsi/srp.h | 242 - l4/pkg/linux-26-headers/include/sound/Kbuild | 10 - .../include/sound/ac97_codec.h | 643 - .../linux-26-headers/include/sound/ad1816a.h | 173 - .../linux-26-headers/include/sound/ad1843.h | 46 - .../linux-26-headers/include/sound/ad1848.h | 218 - .../linux-26-headers/include/sound/ak4114.h | 203 - .../linux-26-headers/include/sound/ak4117.h | 189 - .../include/sound/ak4531_codec.h | 85 - .../include/sound/ak4xxx-adda.h | 96 - .../linux-26-headers/include/sound/asoundef.h | 235 - .../linux-26-headers/include/sound/control.h | 176 - l4/pkg/linux-26-headers/include/sound/core.h | 465 - .../include/sound/cs4231-regs.h | 188 - .../linux-26-headers/include/sound/cs4231.h | 175 - .../linux-26-headers/include/sound/cs46xx.h | 1745 - .../include/sound/cs46xx_dsp_scb_types.h | 1213 - .../include/sound/cs46xx_dsp_spos.h | 232 - .../include/sound/cs46xx_dsp_task_types.h | 252 - .../linux-26-headers/include/sound/cs8403.h | 257 - .../linux-26-headers/include/sound/cs8427.h | 201 - .../linux-26-headers/include/sound/driver.h | 1 - .../include/sound/emu10k1_synth.h | 39 - .../linux-26-headers/include/sound/emu8000.h | 121 - .../include/sound/emu8000_reg.h | 207 - .../include/sound/emux_legacy.h | 146 - .../include/sound/emux_synth.h | 244 - .../linux-26-headers/include/sound/es1688.h | 121 - l4/pkg/linux-26-headers/include/sound/gus.h | 631 - .../include/sound/hda_hwdep.h | 44 - l4/pkg/linux-26-headers/include/sound/hwdep.h | 72 - l4/pkg/linux-26-headers/include/sound/i2c.h | 104 - l4/pkg/linux-26-headers/include/sound/info.h | 194 - .../linux-26-headers/include/sound/initval.h | 90 - .../linux-26-headers/include/sound/memalloc.h | 118 - .../linux-26-headers/include/sound/minors.h | 108 - .../include/sound/mixer_oss.h | 78 - .../linux-26-headers/include/sound/mpu401.h | 137 - l4/pkg/linux-26-headers/include/sound/opl3.h | 393 - l4/pkg/linux-26-headers/include/sound/opl4.h | 32 - .../include/sound/pcm-indirect.h | 177 - l4/pkg/linux-26-headers/include/sound/pcm.h | 1013 - .../linux-26-headers/include/sound/pcm_oss.h | 89 - .../include/sound/pcm_params.h | 341 - .../linux-26-headers/include/sound/pt2258.h | 37 - .../linux-26-headers/include/sound/rawmidi.h | 186 - l4/pkg/linux-26-headers/include/sound/sb.h | 367 - .../include/sound/seq_device.h | 84 - .../include/sound/seq_kernel.h | 116 - .../include/sound/seq_midi_emul.h | 197 - .../include/sound/seq_midi_event.h | 54 - .../linux-26-headers/include/sound/seq_oss.h | 96 - .../include/sound/seq_oss_legacy.h | 31 - .../include/sound/seq_virmidi.h | 81 - .../include/sound/snd_wavefront.h | 143 - .../linux-26-headers/include/sound/soc-dapm.h | 336 - l4/pkg/linux-26-headers/include/sound/soc.h | 530 - .../include/sound/soundfont.h | 129 - .../include/sound/sscape_ioctl.h | 21 - .../include/sound/tea575x-tuner.h | 53 - .../linux-26-headers/include/sound/tea6330t.h | 31 - l4/pkg/linux-26-headers/include/sound/timer.h | 143 - l4/pkg/linux-26-headers/include/sound/tlv.h | 60 - .../linux-26-headers/include/sound/trident.h | 445 - .../linux-26-headers/include/sound/uda1341.h | 126 - .../linux-26-headers/include/sound/util_mem.h | 64 - .../linux-26-headers/include/sound/version.h | 3 - .../linux-26-headers/include/sound/vx_core.h | 566 - .../include/sound/wavefront.h | 695 - .../linux-26-headers/include/sound/ymfpci.h | 387 - l4/pkg/linux-26-headers/include/video/Kbuild | 2 - .../include/video/atmel_lcdc.h | 217 - .../linux-26-headers/include/video/aty128.h | 422 - .../linux-26-headers/include/video/cirrus.h | 122 - .../include/video/cvisionppc.h | 51 - .../linux-26-headers/include/video/cyblafb.h | 175 - .../include/video/epson1355.h | 64 - l4/pkg/linux-26-headers/include/video/gbe.h | 317 - .../linux-26-headers/include/video/hecubafb.h | 51 - l4/pkg/linux-26-headers/include/video/iga.h | 24 - .../linux-26-headers/include/video/ili9320.h | 201 - l4/pkg/linux-26-headers/include/video/kyro.h | 93 - .../linux-26-headers/include/video/mach64.h | 1378 - .../linux-26-headers/include/video/maxinefb.h | 38 - l4/pkg/linux-26-headers/include/video/mbxfb.h | 98 - .../include/video/metronomefb.h | 62 - .../linux-26-headers/include/video/neomagic.h | 193 - .../linux-26-headers/include/video/newport.h | 583 - .../include/video/permedia2.h | 254 - .../include/video/platform_lcd.h | 21 - l4/pkg/linux-26-headers/include/video/pm3fb.h | 1061 - .../include/video/pmag-ba-fb.h | 27 - .../include/video/pmagb-b-fb.h | 58 - .../linux-26-headers/include/video/radeon.h | 1990 - .../include/video/s1d13xxxfb.h | 166 - l4/pkg/linux-26-headers/include/video/sgivw.h | 682 - l4/pkg/linux-26-headers/include/video/sstfb.h | 355 - l4/pkg/linux-26-headers/include/video/tdfx.h | 182 - l4/pkg/linux-26-headers/include/video/tgafb.h | 280 - .../linux-26-headers/include/video/trident.h | 146 - l4/pkg/linux-26-headers/include/video/vga.h | 481 - .../linux-26-headers/include/video/w100fb.h | 150 - l4/pkg/linux-26-headers/include/xen/balloon.h | 61 - l4/pkg/linux-26-headers/include/xen/events.h | 54 - .../linux-26-headers/include/xen/features.h | 23 - .../include/xen/grant_table.h | 117 - .../include/xen/hvc-console.h | 16 - .../include/xen/interface/callback.h | 102 - .../include/xen/interface/elfnote.h | 153 - .../include/xen/interface/event_channel.h | 195 - .../include/xen/interface/features.h | 46 - .../include/xen/interface/grant_table.h | 380 - .../include/xen/interface/io/blkif.h | 94 - .../include/xen/interface/io/console.h | 23 - .../include/xen/interface/io/fbif.h | 143 - .../include/xen/interface/io/kbdif.h | 116 - .../include/xen/interface/io/netif.h | 158 - .../include/xen/interface/io/protocols.h | 21 - .../include/xen/interface/io/ring.h | 260 - .../include/xen/interface/io/xenbus.h | 44 - .../include/xen/interface/io/xs_wire.h | 87 - .../include/xen/interface/memory.h | 145 - .../include/xen/interface/physdev.h | 145 - .../include/xen/interface/sched.h | 77 - .../include/xen/interface/vcpu.h | 173 - .../include/xen/interface/version.h | 60 - .../include/xen/interface/xen.h | 471 - .../include/xen/interface/xencomm.h | 41 - l4/pkg/linux-26-headers/include/xen/page.h | 1 - l4/pkg/linux-26-headers/include/xen/xen-ops.h | 17 - l4/pkg/linux-26-headers/include/xen/xenbus.h | 235 - l4/pkg/linux-26-headers/include/xen/xencomm.h | 77 - 4798 files changed, 853792 deletions(-) delete mode 100644 kernel/fiasco/src/kern/mp_lock.cpp delete mode 100644 kernel/fiasco/src/kern/obj_ref_ptr.cpp delete mode 100644 kernel/fiasco/src/kern/ref_ptr.cpp delete mode 100644 l4/pkg/libsdl/contrib/Borland.zip delete mode 100644 l4/pkg/libsdl/contrib/README.CVS delete mode 100644 l4/pkg/libsdl/contrib/README.SVN delete mode 100644 l4/pkg/libsdl/contrib/VisualC.zip delete mode 100644 l4/pkg/libsdl/contrib/VisualCE.zip delete mode 100644 l4/pkg/libsdl/contrib/Watcom-OS2.zip delete mode 100644 l4/pkg/libsdl/contrib/Watcom-Win32.zip delete mode 100644 l4/pkg/libsdl/contrib/src/joystick/darwin/10.3.9-FIX/IOHIDLib.h delete mode 100644 l4/pkg/libsdl/contrib/src/joystick/os2/SDL_sysjoystick.c delete mode 100644 l4/pkg/libsdl/contrib/src/joystick/os2/joyos2.h delete mode 100644 l4/pkg/libsdl/contrib/symbian.zip delete mode 100644 l4/pkg/libstdc++-headers/include/bits/gthr-posix.h delete mode 100644 l4/pkg/libstdc++-headers/include/bits/gthr-single.h delete mode 100644 l4/pkg/libstdc++-headers/include/bits/gthr.h delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/Makefile.am delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/Makefile.in delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/doxygen/Intro.3 delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/doxygen/TODO delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/doxygen/doxygroups.cc delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/doxygen/mainpage.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/doxygen/stdheader.cc delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/doxygen/tables.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/doxygen/user.cfg.in delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/README delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/api.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/bk02.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/bk03.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/lwg-active.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/lwg-closed.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/lwg-defects.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/PythonPoweredSmall.gif delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/acks.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/assoc_container_tag_cd.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/assoc_container_tag_cd.svg delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/assoc_container_traits.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/assoc_design.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/assoc_examples.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/assoc_performance_tests.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/assoc_regression_tests.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/assoc_tests.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/associative_container_tag.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/balls_and_bins.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/basic_hash_table.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/basic_hash_tag.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/basic_invalidation_guarantee.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/basic_tree.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/basic_tree_assoc_container_const_node_iterator.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/basic_tree_tag.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/binary_heap_tag.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/binary_priority_queue_random_int_push_timing_test_gcc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/binary_priority_queue_random_int_push_timing_test_local.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/binary_priority_queue_random_int_push_timing_test_msvc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/binomial_heap_tag.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/cc_hash_max_collision_check_resize_trigger.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/cc_hash_random_int_find_timing_test_gcc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/cc_hash_random_int_find_timing_test_local.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/cc_hash_random_int_find_timing_test_msvc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/cc_hash_random_int_subscript_timing_test_find_gcc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/cc_hash_random_int_subscript_timing_test_find_local.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/cc_hash_random_int_subscript_timing_test_find_msvc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/cc_hash_random_int_subscript_timing_test_insert_gcc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/cc_hash_random_int_subscript_timing_test_insert_local.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/cc_hash_random_int_subscript_timing_test_insert_msvc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/cc_hash_table.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/cc_hash_tag.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/ccgp_hash_random_int_subscript_timing_test_insert_gcc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/ccgp_hash_random_int_subscript_timing_test_insert_local.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/ccgp_hash_random_int_subscript_timing_test_insert_msvc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/checked_by_tidy.gif delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/concepts.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/contact.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/container_base.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/container_cd.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/container_cd.svg delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/container_tag.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/counter_lu_policy.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/design.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/different_underlying_dss.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/direct_mask_range_hashing.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/direct_mod_range_hashing.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/disclaimer.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/ds_gen.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/embedded_lists_1.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/embedded_lists_2.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/embedded_lists_3.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/examples.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/exceptions.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/gp_hash_random_int_find_timing_test_gcc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/gp_hash_random_int_find_timing_test_local.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/gp_hash_random_int_find_timing_test_msvc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/gp_hash_random_int_subscript_timing_test_find_gcc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/gp_hash_random_int_subscript_timing_test_find_local.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/gp_hash_random_int_subscript_timing_test_find_msvc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/gp_hash_random_int_subscript_timing_test_insert_gcc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/gp_hash_random_int_subscript_timing_test_insert_local.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/gp_hash_random_int_subscript_timing_test_insert_msvc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/gp_hash_table.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/gp_hash_tag.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/hash_based_containers.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/hash_exponential_size_policy.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/hash_load_check_resize_trigger.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/hash_policy_cd.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/hash_prime_size_policy.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/hash_random_int_erase_mem_usage_test.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/hash_random_int_erase_mem_usage_test_gcc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/hash_random_int_erase_mem_usage_test_local.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/hash_random_int_erase_mem_usage_test_msvc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/hash_random_int_find_find_timing_test.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/hash_random_int_subscript_find_timing_test.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/hash_random_int_subscript_insert_timing_test.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/hash_range_hashing_seq_diagram.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/hash_range_hashing_seq_diagram2.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/hash_ranged_hash_range_hashing_fns.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/hash_standard_resize_policy.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/hash_text_find_find_timing_test.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/hash_zlob_random_int_find_find_timing_test.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/hash_zlob_random_int_find_timing_test_gcc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/hash_zlob_random_int_find_timing_test_local.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/hash_zlob_random_int_find_timing_test_msvc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/index.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/insert_error.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/insert_resize_sequence_diagram1.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/insert_resize_sequence_diagram2.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/insert_resize_sequence_diagram3.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/interface.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/introduction.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/invalidation_guarantee_cd.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/invalidation_guarantee_erase.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/join_error.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/linear_probe_fn.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/list_update.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/list_update_tag.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/lu.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/lu_based_containers.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/misc.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/motivation.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/move_to_front_lu_policy.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/multimap_text_find_timing_test_large.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/multimap_text_find_timing_test_large_s2p_hash_gcc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/multimap_text_find_timing_test_large_s2p_hash_local.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/multimap_text_find_timing_test_large_s2p_hash_msvc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/multimap_text_find_timing_test_large_s2p_tree_gcc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/multimap_text_find_timing_test_large_s2p_tree_local.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/multimap_text_find_timing_test_large_s2p_tree_msvc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/multimap_text_find_timing_test_small.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/multimap_text_find_timing_test_small_s2p_hash_gcc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/multimap_text_find_timing_test_small_s2p_hash_local.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/multimap_text_find_timing_test_small_s2p_hash_msvc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/multimap_text_find_timing_test_small_s2p_tree_gcc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/multimap_text_find_timing_test_small_s2p_tree_local.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/multimap_text_find_timing_test_small_s2p_tree_msvc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large_s2p_hash_gcc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large_s2p_hash_local.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large_s2p_hash_msvc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large_s2p_tree_gcc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large_s2p_tree_local.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large_s2p_tree_msvc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_small.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_small_s2p_hash_gcc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_small_s2p_hash_local.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_small_s2p_hash_msvc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_small_s2p_tree_gcc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_small_s2p_tree_local.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_small_s2p_tree_msvc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/multimap_text_insert_timing_test_large.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/multimap_text_insert_timing_test_large_s2p_hash_gcc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/multimap_text_insert_timing_test_large_s2p_hash_local.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/multimap_text_insert_timing_test_large_s2p_hash_msvc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/multimap_text_insert_timing_test_large_s2p_tree_gcc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/multimap_text_insert_timing_test_large_s2p_tree_local.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/multimap_text_insert_timing_test_large_s2p_tree_msvc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/multimap_text_insert_timing_test_small.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/multimap_text_insert_timing_test_small_s2p_hash_gcc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/multimap_text_insert_timing_test_small_s2p_hash_local.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/multimap_text_insert_timing_test_small_s2p_hash_msvc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/multimap_text_insert_timing_test_small_s2p_tree_gcc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/multimap_text_insert_timing_test_small_s2p_tree_local.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/multimap_text_insert_timing_test_small_s2p_tree_msvc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/node_invariant_invalidations.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/node_invariants.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/null_hash_fn.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/null_lu_metadata.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/null_mapped_type.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/null_probe_fn.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/null_tree_node_update.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/null_trie_node_update.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/ov_tree_tag.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/pairing_heap_tag.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/pairing_priority_queue_text_push_pop_timing_test_gcc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/pairing_priority_queue_text_push_pop_timing_test_local.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/pairing_priority_queue_text_push_pop_timing_test_msvc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/pairing_priority_queue_text_push_timing_test_gcc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/pairing_priority_queue_text_push_timing_test_local.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/pairing_priority_queue_text_push_timing_test_msvc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/pat_trie.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/pat_trie_tag.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/point_invalidation_guarantee.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/point_iterators_cd.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/point_iterators_range_ops_1.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/point_iterators_range_ops_2.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/pq_container_traits.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/pq_design.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/pq_different_underlying_dss.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/pq_examples.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/pq_performance_tests.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/pq_regression_tests.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/pq_tests.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/prerequisites.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/priority_queue.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/priority_queue_random_int_push_pop_timing_test.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/priority_queue_random_int_push_pop_timing_test_gcc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/priority_queue_random_int_push_pop_timing_test_local.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/priority_queue_random_int_push_pop_timing_test_msvc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/priority_queue_random_int_push_timing_test.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/priority_queue_random_int_push_timing_test_gcc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/priority_queue_random_int_push_timing_test_local.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/priority_queue_random_int_push_timing_test_msvc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/priority_queue_tag.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/priority_queue_tag_cd.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/priority_queue_tag_cd.svg delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/priority_queue_text_join_timing_test.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/priority_queue_text_join_timing_test_gcc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/priority_queue_text_join_timing_test_local.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/priority_queue_text_join_timing_test_msvc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/priority_queue_text_modify_down_timing_test.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/priority_queue_text_modify_down_timing_test_gcc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/priority_queue_text_modify_down_timing_test_local.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/priority_queue_text_modify_down_timing_test_msvc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/priority_queue_text_modify_down_timing_test_pairing_thin_gcc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/priority_queue_text_modify_down_timing_test_pairing_thin_local.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/priority_queue_text_modify_down_timing_test_pairing_thin_msvc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/priority_queue_text_modify_up_timing_test.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/priority_queue_text_modify_up_timing_test_gcc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/priority_queue_text_modify_up_timing_test_local.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/priority_queue_text_modify_up_timing_test_msvc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/priority_queue_text_modify_up_timing_test_pairing_thin_gcc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/priority_queue_text_modify_up_timing_test_pairing_thin_local.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/priority_queue_text_modify_up_timing_test_pairing_thin_msvc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/priority_queue_text_pop_mem_usage_test.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/priority_queue_text_pop_mem_usage_test_gcc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/priority_queue_text_pop_mem_usage_test_local.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/priority_queue_text_pop_mem_usage_test_msvc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/priority_queue_text_push_pop_timing_test.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/priority_queue_text_push_pop_timing_test_gcc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/priority_queue_text_push_pop_timing_test_local.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/priority_queue_text_push_pop_timing_test_msvc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/priority_queue_text_push_timing_test.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/priority_queue_text_push_timing_test_gcc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/priority_queue_text_push_timing_test_local.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/priority_queue_text_push_timing_test_msvc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/quadratic_probe_fn.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/random_int_find_find_timing_test_tree_gcc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/random_int_find_find_timing_test_tree_local.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/random_int_find_find_timing_test_tree_msvc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/range_invalidation_guarantee.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/rationale_null_node_updator.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/rb_tree_tag.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/rc_binomial_heap_tag.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/references.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/resize_error.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/resize_policy_cd.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/restoring_node_invariants.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/sample_probe_fn.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/sample_range_hashing.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/sample_ranged_hash_fn.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/sample_ranged_probe_fn.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/sample_resize_policy.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/sample_resize_trigger.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/sample_size_policy.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/sample_tree_node_update.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/sample_trie_e_access_traits.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/sample_trie_node_update.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/sample_update_policy.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/simple_list.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/splay_tree_tag.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/string_trie_e_access_traits.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/tests.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/text_find_timing_test_hash_gcc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/text_find_timing_test_hash_local.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/text_find_timing_test_hash_msvc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/text_find_timing_test_tree_like_gcc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/text_find_timing_test_tree_like_local.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/text_find_timing_test_tree_like_msvc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/thin_heap_tag.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/tree.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/tree_based_containers.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/tree_node_iterator.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/tree_node_updator_policy_cd.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/tree_order_statistics_node_update.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/tree_order_statistics_timing_test.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/tree_order_statistics_timing_test_gcc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/tree_order_statistics_timing_test_local.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/tree_order_statistics_timing_test_msvc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/tree_random_int_find_find_timing_test.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/tree_split_join_timing_test.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/tree_split_join_timing_test_gcc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/tree_split_join_timing_test_local.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/tree_split_join_timing_test_msvc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/tree_tag.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/tree_text_find_find_timing_test.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/tree_text_insert_timing_test.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/tree_text_insert_timing_test_node_tree_gcc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/tree_text_insert_timing_test_node_tree_local.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/tree_text_insert_timing_test_node_tree_msvc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/tree_text_insert_timing_test_pat_trie_gcc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/tree_text_insert_timing_test_pat_trie_local.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/tree_text_insert_timing_test_pat_trie_msvc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/tree_text_insert_timing_test_vector_tree_gcc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/tree_text_insert_timing_test_vector_tree_local.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/tree_text_insert_timing_test_vector_tree_msvc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/tree_text_lor_find_find_timing_test.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/tree_text_lor_find_timing_test_gcc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/tree_text_lor_find_timing_test_local.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/tree_text_lor_find_timing_test_msvc.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/trie.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/trie_based_containers.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/trie_const_node_iterator.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/trie_node_iterator.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/trie_node_updator_policy_cd.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/trie_order_statistics_node_update.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/trie_prefix_search_node_update.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/trie_tag.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/trivial_iterator_tag.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/tutorial.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/update_policy_cd.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/update_seq_diagram.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/faq.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/index.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/abi.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/algorithms.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/api.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/appendix_contributing.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/appendix_free.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/appendix_gfdl.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/appendix_gpl.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/appendix_porting.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/associative.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/auto_ptr.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/backwards.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/bitmap_allocator.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/bitset.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/bk01ix01.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/bk01pt02ch04s02.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/bk01pt02ch04s03.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/bk01pt02pr01.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/bk01pt03ch07s02.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/bk01pt03ch07s03.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/bk01pt03ch08.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/bk01pt05ch13.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/bk01pt05ch13s02.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/bk01pt05ch13s03.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/bk01pt05ch13s04.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/bk01pt05ch13s05.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/bk01pt05ch13s06.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/bk01pt08ch19.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/bk01pt08ch19s02.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/bk01pt09ch20.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/bk01pt09pr02.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/bk01pt10ch23s02.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/bk01pt11ch25s02.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/bk01pt11ch27s02.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/bk01pt11ch27s03.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/bk01pt11ch28s02.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/bk01pt12ch30s02.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/bk01pt12ch30s03.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/bk01pt12ch30s04.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/bk01pt12ch31s02.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/bk01pt12ch31s03.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/bk01pt12ch31s04.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/bk01pt12ch31s05.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/bk01pt12ch33s02.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/bk01pt12ch33s03.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/bk01pt12ch40s02.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/bk01pt12ch40s03.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/bk01pt12pr03.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/bugs.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/codecvt.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/complex.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/configure.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/containers.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/containers_and_c.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/debug.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/debug_mode.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/diagnostics.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/documentation_style.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/dynamic_memory.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/exceptions.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/ext_algorithms.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/ext_allocators.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/ext_compile_checks.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/ext_concurrency.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/ext_containers.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/ext_demangling.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/ext_io.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/ext_iterators.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/ext_numerics.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/ext_utilities.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/extensions.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/facets.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/fstreams.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/functors.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/fundamental_types.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/generalized_numeric_operations.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/internals.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/intro.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/io.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/io_and_c.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/iostream_objects.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/iterators.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/license.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/locales.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/localization.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/make.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/memory.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/messages.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/numerics.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/numerics_and_c.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/pairs.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/parallel_mode.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/sequences.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/setup.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/shared_ptr.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/source_code_style.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/source_design_notes.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/source_organization.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/spine.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/status.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/streambufs.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/strings.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/stringstreams.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/support.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/termination.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/test.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/traits.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/using.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/using_concurrency.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/using_exceptions.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/using_headers.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/using_macros.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/using_namespaces.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/utilities.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/vector.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/manual/verbose_termination.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/spine.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/xml/api.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/xml/authors.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/xml/book.txml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/xml/chapter.txml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/xml/class.txml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/xml/faq.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/xml/gnu/fdl-1.2.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/xml/gnu/gpl-2.0.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/xml/gnu/gpl-3.0.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/xml/images/confdeps.dot delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/xml/images/confdeps.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/xml/manual/abi.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/xml/manual/algorithms.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/xml/manual/allocator.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/xml/manual/appendix_contributing.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/xml/manual/appendix_free.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/xml/manual/appendix_porting.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/xml/manual/auto_ptr.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/xml/manual/backwards_compatibility.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/xml/manual/bitmap_allocator.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/xml/manual/build_hacking.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/xml/manual/codecvt.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/xml/manual/concurrency.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/xml/manual/configure.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/xml/manual/containers.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/xml/manual/ctype.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/xml/manual/debug.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/xml/manual/debug_mode.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/xml/manual/diagnostics.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/xml/manual/evolution.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/xml/manual/extensions.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/xml/manual/internals.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/xml/manual/intro.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/xml/manual/io.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/xml/manual/iterators.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/xml/manual/locale.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/xml/manual/localization.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/xml/manual/messages.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/xml/manual/mt_allocator.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/xml/manual/numerics.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/xml/manual/parallel_mode.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/xml/manual/prerequisites.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/xml/manual/shared_ptr.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/xml/manual/spine.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/xml/manual/status_cxx1998.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/xml/manual/status_cxx200x.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/xml/manual/status_cxxtr1.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/xml/manual/strings.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/xml/manual/support.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/xml/manual/test.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/xml/manual/using.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/xml/manual/utilities.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/xml/spine.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/Makefile.am delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/Makefile.in delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/doxygen/Intro.3 delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/doxygen/doxygroups.cc delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/doxygen/mainpage.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/doxygen/stdheader.cc delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/doxygen/tables.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/doxygen/user.cfg.in delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/README delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/api.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/bk02.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/bk03.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/ext/lwg-active.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/ext/lwg-closed.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/ext/lwg-defects.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/faq.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/confdeps.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_balls_and_bins.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_binary_priority_queue_int_push.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_binary_priority_queue_int_push_pop.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_cc_hash_int_find.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_cc_hash_int_subscript_find.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_cc_hash_int_subscript_insert.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_ccgp_hash_int_subscript_insert.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_container_tag_hierarchy.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_different_underlying_dss_1.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_different_underlying_dss_2.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_embedded_lists_1.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_embedded_lists_2.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_embedded_lists_3.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_exception_hierarchy.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_gp_hash_int_find.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_gp_hash_int_subscript_find.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_gp_hash_int_subscript_insert.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_hash_int_erase_mem.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_hash_policy_cd.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_hash_range_hashing_seq_diagram.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_hash_range_hashing_seq_diagram2.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_hash_ranged_hash_range_hashing_fns.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_hash_text_find.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_hash_zlob_int_find.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_insert_resize_sequence_diagram1.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_insert_resize_sequence_diagram2.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_insert_resize_sequence_diagram3.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_invalidation_guarantee_erase.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_invalidation_tag_hierarchy.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_list_update.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_multimap_text_find_large_s2p_hash.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_multimap_text_find_large_s2p_tree.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_multimap_text_find_small_s2p_hash.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_multimap_text_find_small_s2p_tree.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_multimap_text_insert_large_s2p_hash.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_multimap_text_insert_large_s2p_tree.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_multimap_text_insert_mem_large_s2p_hash.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_multimap_text_insert_mem_large_s2p_tree.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_multimap_text_insert_mem_small_s2p_hash.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_multimap_text_insert_mem_small_s2p_tree.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_multimap_text_insert_small_s2p_hash.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_multimap_text_insert_small_s2p_tree.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_node_invariants.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_pairing_priority_queue_text_modify_down_thin.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_pairing_priority_queue_text_modify_up_thin.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_pairing_priority_queue_text_push.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_pairing_priority_queue_text_push_pop.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_pat_trie.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_point_iterator_hierarchy.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_point_iterators_range_ops_1.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_point_iterators_range_ops_2.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_priority_queue_different_underlying_dss.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_priority_queue_int_push.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_priority_queue_int_push_pop.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_priority_queue_tag_hierarchy.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_priority_queue_text_join.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_priority_queue_text_modify_down.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_priority_queue_text_modify_up.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_priority_queue_text_pop_mem.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_priority_queue_text_push.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_priority_queue_text_push_pop.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_rationale_null_node_updator.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_resize_policy_cd.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_restoring_node_invariants.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_simple_list.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_tree_int_find.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_tree_node_invalidations.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_tree_node_invariants.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_tree_node_updator_policy_cd.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_tree_order_statistics.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_tree_split_join.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_tree_text_find.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_tree_text_insert_node.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_tree_text_insert_trie.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_tree_text_insert_vector.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_tree_text_lor_find.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_trie_node_updator_policy_cd.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/images/pbds_update_seq_diagram.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/index.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/abi.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/algorithms.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/api.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/appendix_contributing.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/appendix_free.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/appendix_gfdl.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/appendix_gpl.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/appendix_porting.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/associative.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/atomics.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/backwards.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/bitmap_allocator.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/bk01pt02.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/bk01pt02ch05s02.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/bk01pt03ch17s02.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/bk01pt03ch17s03.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/bk01pt03ch17s04.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/bk01pt03ch18s02.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/bk01pt03ch18s03.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/bk01pt03ch18s04.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/bk01pt03ch18s05.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/bk01pt03ch19s02.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/bk01pt03ch19s03.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/bk01pt03ch19s04.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/bk01pt03ch19s05.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/bk01pt03ch19s06.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/bk01pt03ch19s07.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/bk01pt03ch20s02.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/bk01pt03ch20s03.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/bk01pt03ch20s04.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/bk01pt03ch20s05.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/bk01pt03ch21s02.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/bk01pt03ch23s02.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/bk01pt03ch30s02.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/bk01pt03ch30s03.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/bk01pt03pr01.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/bk01pt04.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/bugs.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/concurrency.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/configure.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/containers.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/containers_and_c.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/debug.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/debug_mode.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/diagnostics.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/documentation_hacking.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/dynamic_memory.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/ext_algorithms.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/ext_compile_checks.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/ext_concurrency.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/ext_containers.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/ext_demangling.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/ext_io.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/ext_iterators.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/ext_numerics.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/ext_utilities.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/extensions.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/facets.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/fstreams.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/generalized_numeric_operations.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/index.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/internals.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/intro.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/io.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/io_and_c.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/iterators.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/license.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/localization.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/make.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/memory.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/mt_allocator.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/numerics.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/numerics_and_c.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/pairs.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/parallel_mode.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/policy_based_data_structures_test.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/policy_data_structures.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/policy_data_structures_biblio.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/policy_data_structures_design.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/policy_data_structures_using.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/profile_mode.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/setup.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/source_code_style.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/source_design_notes.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/source_organization.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/status.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/streambufs.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/strings.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/stringstreams.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/support.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/termination.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/test.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/traits.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/using.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/using_concurrency.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/using_dynamic_or_shared.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/using_exceptions.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/using_headers.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/using_macros.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/using_namespaces.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/html/manual/utilities.html delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/api.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/authors.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/book.txml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/chapter.txml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/class.txml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/faq.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/gnu/fdl-1.3.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/gnu/gpl-3.0.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/confdeps.dot delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/confdeps.pdf delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/confdeps.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_balls_and_bins.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_binary_priority_queue_int_push.pdf delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_binary_priority_queue_int_push.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_binary_priority_queue_int_push.svg delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_binary_priority_queue_int_push_pop.pdf delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_binary_priority_queue_int_push_pop.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_binary_priority_queue_int_push_pop.svg delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_cc_hash_int_find.pdf delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_cc_hash_int_find.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_cc_hash_int_find.svg delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_cc_hash_int_subscript_find.pdf delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_cc_hash_int_subscript_find.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_cc_hash_int_subscript_find.svg delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_cc_hash_int_subscript_insert.pdf delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_cc_hash_int_subscript_insert.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_cc_hash_int_subscript_insert.svg delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_ccgp_hash_int_subscript_insert.pdf delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_ccgp_hash_int_subscript_insert.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_ccgp_hash_int_subscript_insert.svg delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_container_tag_hierarchy.pdf delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_container_tag_hierarchy.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_container_tag_hierarchy.svg delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_different_underlying_dss_1.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_different_underlying_dss_2.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_embedded_lists_1.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_embedded_lists_2.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_embedded_lists_3.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_exception_hierarchy.pdf delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_exception_hierarchy.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_exception_hierarchy.svg delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_gp_hash_int_find.pdf delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_gp_hash_int_find.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_gp_hash_int_find.svg delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_gp_hash_int_subscript_find.pdf delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_gp_hash_int_subscript_find.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_gp_hash_int_subscript_find.svg delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_gp_hash_int_subscript_insert.pdf delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_gp_hash_int_subscript_insert.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_gp_hash_int_subscript_insert.svg delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_hash_int_erase_mem.pdf delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_hash_int_erase_mem.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_hash_int_erase_mem.svg delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_hash_policy_cd.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_hash_range_hashing_seq_diagram.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_hash_range_hashing_seq_diagram2.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_hash_ranged_hash_range_hashing_fns.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_hash_text_find.pdf delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_hash_text_find.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_hash_text_find.svg delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_hash_zlob_int_find.pdf delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_hash_zlob_int_find.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_hash_zlob_int_find.svg delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_insert_resize_sequence_diagram1.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_insert_resize_sequence_diagram2.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_insert_resize_sequence_diagram3.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_invalidation_guarantee_erase.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_invalidation_tag_hierarchy.pdf delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_invalidation_tag_hierarchy.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_invalidation_tag_hierarchy.svg delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_list_update.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_multimap_text_find_large_s2p_hash.pdf delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_multimap_text_find_large_s2p_hash.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_multimap_text_find_large_s2p_hash.svg delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_multimap_text_find_large_s2p_tree.pdf delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_multimap_text_find_large_s2p_tree.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_multimap_text_find_large_s2p_tree.svg delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_multimap_text_find_small_s2p_hash.pdf delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_multimap_text_find_small_s2p_hash.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_multimap_text_find_small_s2p_hash.svg delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_multimap_text_find_small_s2p_tree.pdf delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_multimap_text_find_small_s2p_tree.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_multimap_text_find_small_s2p_tree.svg delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_multimap_text_insert_large_s2p_hash.pdf delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_multimap_text_insert_large_s2p_hash.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_multimap_text_insert_large_s2p_hash.svg delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_multimap_text_insert_large_s2p_tree.pdf delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_multimap_text_insert_large_s2p_tree.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_multimap_text_insert_large_s2p_tree.svg delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_multimap_text_insert_mem_large_s2p_hash.pdf delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_multimap_text_insert_mem_large_s2p_hash.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_multimap_text_insert_mem_large_s2p_hash.svg delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_multimap_text_insert_mem_large_s2p_tree.pdf delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_multimap_text_insert_mem_large_s2p_tree.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_multimap_text_insert_mem_large_s2p_tree.svg delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_multimap_text_insert_mem_small_s2p_hash.pdf delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_multimap_text_insert_mem_small_s2p_hash.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_multimap_text_insert_mem_small_s2p_hash.svg delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_multimap_text_insert_mem_small_s2p_tree.pdf delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_multimap_text_insert_mem_small_s2p_tree.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_multimap_text_insert_mem_small_s2p_tree.svg delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_multimap_text_insert_small_s2p_hash.pdf delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_multimap_text_insert_small_s2p_hash.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_multimap_text_insert_small_s2p_hash.svg delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_multimap_text_insert_small_s2p_tree.pdf delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_multimap_text_insert_small_s2p_tree.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_multimap_text_insert_small_s2p_tree.svg delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_node_invariants.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_pairing_priority_queue_text_modify_down_thin.pdf delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_pairing_priority_queue_text_modify_down_thin.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_pairing_priority_queue_text_modify_down_thin.svg delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_pairing_priority_queue_text_modify_up_thin.pdf delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_pairing_priority_queue_text_modify_up_thin.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_pairing_priority_queue_text_modify_up_thin.svg delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_pairing_priority_queue_text_push.pdf delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_pairing_priority_queue_text_push.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_pairing_priority_queue_text_push.svg delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_pairing_priority_queue_text_push_pop.pdf delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_pairing_priority_queue_text_push_pop.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_pairing_priority_queue_text_push_pop.svg delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_pat_trie.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_point_iterator_hierarchy.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_point_iterators_range_ops_1.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_point_iterators_range_ops_2.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_priority_queue_different_underlying_dss.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_priority_queue_int_push.pdf delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_priority_queue_int_push.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_priority_queue_int_push.svg delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_priority_queue_int_push_pop.pdf delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_priority_queue_int_push_pop.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_priority_queue_int_push_pop.svg delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_priority_queue_tag_hierarchy.pdf delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_priority_queue_tag_hierarchy.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_priority_queue_tag_hierarchy.svg delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_priority_queue_text_join.pdf delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_priority_queue_text_join.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_priority_queue_text_join.svg delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_priority_queue_text_modify_down.pdf delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_priority_queue_text_modify_down.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_priority_queue_text_modify_down.svg delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_priority_queue_text_modify_up.pdf delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_priority_queue_text_modify_up.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_priority_queue_text_modify_up.svg delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_priority_queue_text_pop_mem.pdf delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_priority_queue_text_pop_mem.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_priority_queue_text_pop_mem.svg delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_priority_queue_text_push.pdf delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_priority_queue_text_push.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_priority_queue_text_push.svg delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_priority_queue_text_push_pop.pdf delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_priority_queue_text_push_pop.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_priority_queue_text_push_pop.svg delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_rationale_null_node_updator.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_resize_policy_cd.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_restoring_node_invariants.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_simple_list.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_tree_int_find.pdf delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_tree_int_find.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_tree_int_find.svg delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_tree_node_invalidations.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_tree_node_invariants.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_tree_node_updator_policy_cd.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_tree_order_statistics.pdf delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_tree_order_statistics.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_tree_order_statistics.svg delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_tree_split_join.pdf delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_tree_split_join.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_tree_split_join.svg delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_tree_text_find.pdf delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_tree_text_find.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_tree_text_find.svg delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_tree_text_insert_node.pdf delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_tree_text_insert_node.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_tree_text_insert_node.svg delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_tree_text_insert_trie.pdf delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_tree_text_insert_trie.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_tree_text_insert_trie.svg delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_tree_text_insert_vector.pdf delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_tree_text_insert_vector.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_tree_text_insert_vector.svg delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_tree_text_lor_find.pdf delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_tree_text_lor_find.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_tree_text_lor_find.svg delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_trie_node_updator_policy_cd.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/images/pbds_update_seq_diagram.png delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/manual/abi.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/manual/algorithms.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/manual/allocator.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/manual/appendix_contributing.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/manual/appendix_free.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/manual/appendix_porting.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/manual/atomics.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/manual/auto_ptr.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/manual/backwards_compatibility.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/manual/bitmap_allocator.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/manual/build_hacking.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/manual/codecvt.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/manual/concurrency.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/manual/concurrency_extensions.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/manual/configure.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/manual/containers.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/manual/ctype.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/manual/debug.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/manual/debug_mode.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/manual/diagnostics.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/manual/documentation_hacking.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/manual/evolution.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/manual/extensions.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/manual/internals.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/manual/intro.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/manual/io.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/manual/iterators.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/manual/locale.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/manual/localization.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/manual/messages.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/manual/mt_allocator.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/manual/numerics.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/manual/parallel_mode.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/manual/policy_data_structures.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/manual/prerequisites.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/manual/profile_mode.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/manual/shared_ptr.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/manual/spine.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/manual/status_cxx1998.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/manual/status_cxx2011.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/manual/status_cxxtr1.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/manual/status_cxxtr24733.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/manual/strings.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/manual/support.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/manual/test.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/manual/test_policy_data_structures.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/manual/using.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/manual/using_exceptions.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/manual/utilities.xml delete mode 100644 l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.7/doc/xml/spine.xml delete mode 100644 l4/pkg/linux-26-headers/include/Kbuild delete mode 100644 l4/pkg/linux-26-headers/include/acpi/acconfig.h delete mode 100644 l4/pkg/linux-26-headers/include/acpi/acdebug.h delete mode 100644 l4/pkg/linux-26-headers/include/acpi/acdisasm.h delete mode 100644 l4/pkg/linux-26-headers/include/acpi/acdispat.h delete mode 100644 l4/pkg/linux-26-headers/include/acpi/acevents.h delete mode 100644 l4/pkg/linux-26-headers/include/acpi/acexcep.h delete mode 100644 l4/pkg/linux-26-headers/include/acpi/acglobal.h delete mode 100644 l4/pkg/linux-26-headers/include/acpi/achware.h delete mode 100644 l4/pkg/linux-26-headers/include/acpi/acinterp.h delete mode 100644 l4/pkg/linux-26-headers/include/acpi/aclocal.h delete mode 100644 l4/pkg/linux-26-headers/include/acpi/acmacros.h delete mode 100644 l4/pkg/linux-26-headers/include/acpi/acnames.h delete mode 100644 l4/pkg/linux-26-headers/include/acpi/acnamesp.h delete mode 100644 l4/pkg/linux-26-headers/include/acpi/acobject.h delete mode 100644 l4/pkg/linux-26-headers/include/acpi/acopcode.h delete mode 100644 l4/pkg/linux-26-headers/include/acpi/acoutput.h delete mode 100644 l4/pkg/linux-26-headers/include/acpi/acparser.h delete mode 100644 l4/pkg/linux-26-headers/include/acpi/acpi.h delete mode 100644 l4/pkg/linux-26-headers/include/acpi/acpi_bus.h delete mode 100644 l4/pkg/linux-26-headers/include/acpi/acpi_drivers.h delete mode 100644 l4/pkg/linux-26-headers/include/acpi/acpi_numa.h delete mode 100644 l4/pkg/linux-26-headers/include/acpi/acpiosxf.h delete mode 100644 l4/pkg/linux-26-headers/include/acpi/acpixf.h delete mode 100644 l4/pkg/linux-26-headers/include/acpi/acresrc.h delete mode 100644 l4/pkg/linux-26-headers/include/acpi/acstruct.h delete mode 100644 l4/pkg/linux-26-headers/include/acpi/actables.h delete mode 100644 l4/pkg/linux-26-headers/include/acpi/actbl.h delete mode 100644 l4/pkg/linux-26-headers/include/acpi/actbl1.h delete mode 100644 l4/pkg/linux-26-headers/include/acpi/actypes.h delete mode 100644 l4/pkg/linux-26-headers/include/acpi/acutils.h delete mode 100644 l4/pkg/linux-26-headers/include/acpi/amlcode.h delete mode 100644 l4/pkg/linux-26-headers/include/acpi/amlresrc.h delete mode 100644 l4/pkg/linux-26-headers/include/acpi/container.h delete mode 100644 l4/pkg/linux-26-headers/include/acpi/pdc_intel.h delete mode 100644 l4/pkg/linux-26-headers/include/acpi/platform/acenv.h delete mode 100644 l4/pkg/linux-26-headers/include/acpi/platform/acgcc.h delete mode 100644 l4/pkg/linux-26-headers/include/acpi/platform/aclinux.h delete mode 100644 l4/pkg/linux-26-headers/include/acpi/processor.h delete mode 100644 l4/pkg/linux-26-headers/include/acpi/reboot.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-arm/.gitignore delete mode 100644 l4/pkg/linux-26-headers/include/asm-arm/plat-s3c/debug-macro.S delete mode 100644 l4/pkg/linux-26-headers/include/asm-arm/plat-s3c/iic.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-arm/plat-s3c/map.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-arm/plat-s3c/nand.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-arm/plat-s3c/regs-ac97.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-arm/plat-s3c/regs-adc.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-arm/plat-s3c/regs-iic.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-arm/plat-s3c/regs-nand.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-arm/plat-s3c/regs-rtc.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-arm/plat-s3c/regs-serial.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-arm/plat-s3c/regs-timer.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-arm/plat-s3c/regs-watchdog.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-arm/plat-s3c/uncompress.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-arm/plat-s3c24xx/clock.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-arm/plat-s3c24xx/common-smdk.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-arm/plat-s3c24xx/cpu.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-arm/plat-s3c24xx/devs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-arm/plat-s3c24xx/dma.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-arm/plat-s3c24xx/irq.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-arm/plat-s3c24xx/mci.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-arm/plat-s3c24xx/pm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-arm/plat-s3c24xx/regs-iis.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-arm/plat-s3c24xx/regs-s3c2412-iis.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-arm/plat-s3c24xx/regs-spi.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-arm/plat-s3c24xx/regs-udc.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-arm/plat-s3c24xx/s3c2400.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-arm/plat-s3c24xx/s3c2410.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-arm/plat-s3c24xx/s3c2412.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-arm/plat-s3c24xx/s3c2440.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-arm/plat-s3c24xx/s3c2442.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-arm/plat-s3c24xx/s3c2443.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-arm/plat-s3c24xx/udc.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/Kbuild delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/a.out.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v10/Kbuild delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v10/atomic.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v10/bitops.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v10/bug.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v10/byteorder.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v10/cache.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v10/checksum.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v10/delay.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v10/dma.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v10/elf.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v10/io.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v10/io_interface_mux.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v10/irq.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v10/memmap.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v10/mmu.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v10/offset.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v10/page.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v10/pgtable.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v10/processor.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v10/ptrace.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v10/sv_addr.agh delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v10/sv_addr_ag.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v10/svinto.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v10/system.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v10/thread_info.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v10/timex.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v10/tlb.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v10/uaccess.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v10/unistd.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v10/user.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/Kbuild delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/arbiter.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/atomic.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/bitops.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/bug.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/byteorder.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/cache.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/checksum.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/cryptocop.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/delay.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/dma.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/elf.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/Makefile delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/asm/ata_defs_asm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/asm/bif_core_defs_asm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/asm/bif_dma_defs_asm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/asm/bif_slave_defs_asm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/asm/config_defs_asm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/asm/cpu_vect.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/asm/cris_defs_asm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/asm/cris_supp_reg.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/asm/dma_defs_asm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/asm/eth_defs_asm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/asm/gio_defs_asm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/asm/intr_vect.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/asm/intr_vect_defs_asm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/asm/irq_nmi_defs_asm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/asm/marb_defs_asm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/asm/mmu_defs_asm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/asm/mmu_supp_reg.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/asm/pinmux_defs_asm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/asm/reg_map_asm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/asm/rt_trace_defs_asm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/asm/ser_defs_asm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/asm/sser_defs_asm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/asm/strcop_defs_asm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/asm/strmux_defs_asm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/asm/timer_defs_asm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/ata_defs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/bif_core_defs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/bif_dma_defs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/bif_slave_defs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/config_defs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/cpu_vect.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/dma.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/dma_defs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/eth_defs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/extmem_defs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/gio_defs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/intr_vect.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/iop/Makefile delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/iop/asm/iop_crc_par_defs_asm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/iop/asm/iop_dmc_in_defs_asm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/iop/asm/iop_dmc_out_defs_asm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/iop/asm/iop_fifo_in_defs_asm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/iop/asm/iop_fifo_in_extra_defs_asm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/iop/asm/iop_fifo_out_defs_asm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/iop/asm/iop_fifo_out_extra_defs_asm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/iop/asm/iop_mpu_defs_asm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/iop/asm/iop_reg_space_asm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/iop/asm/iop_sap_in_defs_asm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/iop/asm/iop_sap_out_defs_asm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/iop/asm/iop_scrc_in_defs_asm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/iop/asm/iop_scrc_out_defs_asm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/iop/asm/iop_spu_defs_asm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/iop/asm/iop_sw_cfg_defs_asm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/iop/asm/iop_sw_cpu_defs_asm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/iop/asm/iop_sw_mpu_defs_asm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/iop/asm/iop_sw_spu_defs_asm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/iop/asm/iop_timer_grp_defs_asm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/iop/asm/iop_trigger_grp_defs_asm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/iop/asm/iop_version_defs_asm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/iop/iop_crc_par_defs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/iop/iop_dmc_in_defs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/iop/iop_dmc_out_defs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/iop/iop_fifo_in_defs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/iop/iop_fifo_in_extra_defs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/iop/iop_fifo_out_defs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/iop/iop_fifo_out_extra_defs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/iop/iop_mpu_defs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/iop/iop_mpu_macros.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/iop/iop_reg_space.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/iop/iop_sap_in_defs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/iop/iop_sap_out_defs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/iop/iop_scrc_in_defs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/iop/iop_scrc_out_defs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/iop/iop_spu_defs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/iop/iop_sw_cfg_defs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/iop/iop_sw_cpu_defs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/iop/iop_sw_mpu_defs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/iop/iop_sw_spu_defs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/iop/iop_timer_grp_defs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/iop/iop_trigger_grp_defs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/iop/iop_version_defs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/irq_nmi_defs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/marb_bp_defs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/marb_defs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/pinmux_defs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/reg_rdwr.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/rt_trace_defs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/ser_defs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/sser_defs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/strcop.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/strcop_defs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/strmux_defs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/hwregs/supp_reg.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/intmem.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/io.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/irq.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/mach-a3/arbiter.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/mach-a3/dma.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/mach-a3/hwregs/asm/clkgen_defs_asm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/mach-a3/hwregs/asm/ddr2_defs_asm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/mach-a3/hwregs/asm/gio_defs_asm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/mach-a3/hwregs/asm/pinmux_defs_asm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/mach-a3/hwregs/asm/pio_defs_asm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/mach-a3/hwregs/asm/reg_map_asm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/mach-a3/hwregs/asm/timer_defs_asm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/mach-a3/hwregs/clkgen_defs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/mach-a3/hwregs/ddr2_defs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/mach-a3/hwregs/gio_defs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/mach-a3/hwregs/intr_vect.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/mach-a3/hwregs/intr_vect_defs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/mach-a3/hwregs/iop/asm/iop_reg_space_asm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/mach-a3/hwregs/iop/asm/iop_sap_in_defs_asm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/mach-a3/hwregs/iop/asm/iop_sap_out_defs_asm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/mach-a3/hwregs/iop/asm/iop_sw_cfg_defs_asm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/mach-a3/hwregs/iop/asm/iop_sw_cpu_defs_asm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/mach-a3/hwregs/iop/asm/iop_sw_mpu_defs_asm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/mach-a3/hwregs/iop/asm/iop_sw_spu_defs_asm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/mach-a3/hwregs/iop/asm/iop_version_defs_asm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/mach-a3/hwregs/iop/iop_reg_space.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/mach-a3/hwregs/iop/iop_sap_in_defs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/mach-a3/hwregs/iop/iop_sap_out_defs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/mach-a3/hwregs/iop/iop_sw_cfg_defs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/mach-a3/hwregs/iop/iop_sw_cpu_defs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/mach-a3/hwregs/iop/iop_sw_mpu_defs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/mach-a3/hwregs/iop/iop_sw_spu_defs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/mach-a3/hwregs/iop/iop_version_defs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/mach-a3/hwregs/l2cache_defs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/mach-a3/hwregs/marb_bar_defs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/mach-a3/hwregs/marb_foo_defs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/mach-a3/hwregs/pinmux_defs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/mach-a3/hwregs/pio_defs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/mach-a3/hwregs/reg_map.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/mach-a3/hwregs/strmux_defs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/mach-a3/hwregs/timer_defs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/mach-a3/memmap.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/mach-a3/pinmux.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/mach-a3/startup.inc delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/mach-fs/arbiter.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/mach-fs/hwregs/asm/bif_core_defs_asm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/mach-fs/hwregs/asm/config_defs_asm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/mach-fs/hwregs/asm/gio_defs_asm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/mach-fs/hwregs/asm/pinmux_defs_asm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/mach-fs/hwregs/asm/reg_map_asm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/mach-fs/hwregs/asm/timer_defs_asm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/mach-fs/hwregs/bif_core_defs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/mach-fs/hwregs/bif_dma_defs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/mach-fs/hwregs/bif_slave_defs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/mach-fs/hwregs/config_defs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/mach-fs/hwregs/gio_defs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/mach-fs/hwregs/intr_vect.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/mach-fs/hwregs/intr_vect_defs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/mach-fs/hwregs/marb_bp_defs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/mach-fs/hwregs/marb_defs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/mach-fs/hwregs/pinmux_defs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/mach-fs/hwregs/reg_map.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/mach-fs/hwregs/strmux_defs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/mach-fs/hwregs/timer_defs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/mach-fs/pinmux.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/mach-fs/startup.inc delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/memmap.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/mmu.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/offset.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/page.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/pgtable.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/pinmux.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/processor.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/ptrace.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/spinlock.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/system.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/thread_info.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/timex.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/tlb.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/uaccess.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/unistd.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/arch-v32/user.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/atomic.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/auxvec.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/axisflashmap.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/bitops.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/bug.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/bugs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/byteorder.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/cache.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/cacheflush.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/checksum.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/cputime.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/current.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/delay.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/device.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/div64.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/dma-mapping.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/dma.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/elf.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/emergency-restart.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/errno.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/eshlibld.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/ethernet.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/etraxgpio.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/etraxi2c.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/fasttimer.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/fb.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/fcntl.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/futex.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/hardirq.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/hw_irq.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/io.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/ioctl.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/ioctls.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/ipcbuf.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/irq.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/irq_regs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/kdebug.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/kmap_types.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/linkage.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/local.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/mman.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/mmu.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/mmu_context.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/module.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/msgbuf.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/mutex.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/page.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/param.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/pci.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/percpu.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/pgalloc.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/pgtable.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/poll.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/posix_types.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/processor.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/ptrace.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/resource.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/rs485.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/rtc.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/scatterlist.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/sections.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/segment.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/sembuf.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/setup.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/shmbuf.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/shmparam.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/sigcontext.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/siginfo.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/signal.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/smp.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/socket.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/sockios.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/spinlock.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/stat.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/statfs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/string.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/sync_serial.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/system.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/termbits.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/termios.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/thread_info.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/timex.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/tlb.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/tlbflush.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/topology.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/types.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/uaccess.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/ucontext.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/unaligned.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/unistd.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-cris/user.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/Kbuild delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/atomic.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/auxvec.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/ax88796.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/bitops.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/bug.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/bugs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/busctl-regs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/byteorder.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/cache.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/cacheflush.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/checksum.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/cpu-irqs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/cpumask.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/cputime.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/current.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/delay.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/device.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/div64.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/dm9000.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/dma-mapping.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/dma.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/elf.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/emergency-restart.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/errno.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/fb.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/fcntl.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/fpu.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/futex.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/gdb-stub.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/gpio-regs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/hardirq.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/highmem.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/hw_irq.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/ide.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/init.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/io.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/ioctl.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/ioctls.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/ipcbuf.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/irc-regs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/irq.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/irq_regs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/kdebug.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/kmap_types.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/linkage.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/local.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/math-emu.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/mb-regs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/mb86943a.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/mb93091-fpga-irqs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/mb93093-fpga-irqs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/mb93493-irqs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/mb93493-regs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/mc146818rtc.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/mem-layout.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/mman.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/mmu.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/mmu_context.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/module.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/msgbuf.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/mutex.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/page.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/param.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/pci.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/percpu.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/pgalloc.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/pgtable.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/poll.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/posix_types.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/processor.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/ptrace.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/registers.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/resource.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/scatterlist.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/sections.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/segment.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/sembuf.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/serial-regs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/serial.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/setup.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/shmbuf.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/shmparam.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/sigcontext.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/siginfo.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/signal.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/smp.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/socket.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/sockios.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/spinlock.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/spr-regs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/stat.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/statfs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/string.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/suspend.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/system.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/termbits.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/termios.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/thread_info.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/timer-regs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/timex.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/tlb.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/tlbflush.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/topology.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/types.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/uaccess.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/ucontext.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/unaligned.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/unistd.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/user.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/vga.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/virtconvert.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-frv/xor.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-generic/4level-fixup.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-generic/Kbuild delete mode 100644 l4/pkg/linux-26-headers/include/asm-generic/Kbuild.asm delete mode 100644 l4/pkg/linux-26-headers/include/asm-generic/atomic.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-generic/audit_change_attr.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-generic/audit_dir_write.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-generic/audit_read.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-generic/audit_signal.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-generic/audit_write.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-generic/bitops.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-generic/bitops/__ffs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-generic/bitops/__fls.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-generic/bitops/atomic.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-generic/bitops/ext2-atomic.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-generic/bitops/ext2-non-atomic.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-generic/bitops/ffs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-generic/bitops/ffz.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-generic/bitops/find.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-generic/bitops/fls.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-generic/bitops/fls64.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-generic/bitops/hweight.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-generic/bitops/le.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-generic/bitops/lock.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-generic/bitops/minix-le.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-generic/bitops/minix.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-generic/bitops/non-atomic.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-generic/bitops/sched.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-generic/bug.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-generic/cmpxchg-local.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-generic/cmpxchg.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-generic/cputime.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-generic/device.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-generic/div64.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-generic/dma-coherent.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-generic/dma-mapping-broken.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-generic/dma-mapping.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-generic/emergency-restart.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-generic/futex.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-generic/gpio.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-generic/ide_iops.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-generic/iomap.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-generic/irq_regs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-generic/kdebug.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-generic/libata-portmap.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-generic/local.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-generic/memory_model.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-generic/mm_hooks.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-generic/mutex-dec.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-generic/mutex-null.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-generic/mutex-xchg.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-generic/page.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-generic/pci-dma-compat.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-generic/pci.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-generic/percpu.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-generic/pgtable-nopmd.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-generic/pgtable-nopud.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-generic/pgtable.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-generic/rtc.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-generic/sections.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-generic/syscall.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-generic/tlb.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-generic/topology.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-generic/uaccess.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-generic/vmlinux.lds.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-generic/xor.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/Kbuild delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/a.out.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/addrspace.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/assembler.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/atomic.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/auxvec.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/bitops.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/bug.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/bugs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/byteorder.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/cache.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/cachectl.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/cacheflush.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/checksum.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/cputime.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/current.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/delay.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/device.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/div64.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/dma.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/elf.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/emergency-restart.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/errno.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/fb.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/fcntl.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/flat.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/futex.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/hardirq.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/hw_irq.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/io.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/ioctl.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/ioctls.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/ipcbuf.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/irq.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/irq_regs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/kdebug.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/kmap_types.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/linkage.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/local.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/m32102.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/m32104ut/m32104ut_pld.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/m32700ut/m32700ut_lan.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/m32700ut/m32700ut_lcd.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/m32700ut/m32700ut_pld.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/m32r.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/m32r_mp_fpga.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/mappi2/mappi2_pld.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/mappi3/mappi3_pld.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/mc146818rtc.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/mman.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/mmu.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/mmu_context.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/mmzone.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/module.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/msgbuf.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/mutex.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/opsput/opsput_lan.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/opsput/opsput_lcd.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/opsput/opsput_pld.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/page.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/param.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/pci.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/percpu.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/pgalloc.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/pgtable-2level.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/pgtable.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/poll.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/posix_types.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/processor.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/ptrace.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/resource.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/rtc.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/s1d13806.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/scatterlist.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/sections.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/segment.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/sembuf.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/serial.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/setup.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/shmbuf.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/shmparam.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/sigcontext.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/siginfo.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/signal.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/smp.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/socket.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/sockios.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/spinlock.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/spinlock_types.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/stat.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/statfs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/string.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/syscall.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/system.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/termbits.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/termios.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/thread_info.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/timex.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/tlb.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/tlbflush.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/topology.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/types.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/uaccess.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/ucontext.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/unaligned.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/unistd.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/user.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/vga.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m32r/xor.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/Kbuild delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/a.out-core.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/a.out.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/adb_iop.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/amigahw.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/amigaints.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/amigayle.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/amipcmcia.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/apollodma.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/apollohw.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/atafd.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/atafdreg.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/atari_joystick.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/atari_stdma.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/atari_stram.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/atarihw.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/atariints.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/atarikb.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/atomic.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/auxvec.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/bitops.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/blinken.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/bootinfo.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/bug.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/bugs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/bvme6000hw.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/byteorder.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/cache.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/cachectl.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/cacheflush.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/checksum.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/contregs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/cputime.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/current.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/delay.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/device.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/div64.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/dma-mapping.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/dma.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/dsp56k.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/dvma.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/elf.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/emergency-restart.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/entry.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/errno.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/fb.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/fbio.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/fcntl.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/floppy.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/fpu.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/futex.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/hardirq.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/hp300hw.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/hw_irq.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/hwtest.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/ide.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/idprom.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/intersil.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/io.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/ioctl.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/ioctls.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/ipcbuf.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/irq.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/irq_regs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/kdebug.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/kmap_types.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/linkage.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/local.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/mac_asc.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/mac_baboon.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/mac_iop.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/mac_mouse.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/mac_oss.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/mac_psc.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/mac_via.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/machdep.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/machines.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/machw.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/macintosh.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/macints.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/math-emu.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/mc146818rtc.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/md.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/mman.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/mmu.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/mmu_context.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/mmzone.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/module.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/motorola_pgalloc.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/motorola_pgtable.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/movs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/msgbuf.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/mutex.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/mvme147hw.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/mvme16xhw.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/nubus.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/openprom.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/oplib.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/page.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/page_offset.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/param.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/parport.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/pci.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/percpu.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/pgalloc.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/pgtable.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/poll.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/posix_types.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/processor.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/ptrace.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/q40_master.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/q40ints.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/raw_io.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/resource.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/rtc.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/sbus.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/scatterlist.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/sections.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/segment.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/sembuf.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/serial.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/setup.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/shm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/shmbuf.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/shmparam.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/sigcontext.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/siginfo.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/signal.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/socket.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/sockios.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/spinlock.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/stat.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/statfs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/string.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/sun3-head.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/sun3_pgalloc.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/sun3_pgtable.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/sun3ints.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/sun3mmu.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/sun3x.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/sun3xflop.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/sun3xprom.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/suspend.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/system.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/termbits.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/termios.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/thread_info.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/timex.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/tlb.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/tlbflush.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/topology.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/traps.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/types.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/uaccess.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/ucontext.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/unaligned.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/unistd.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/user.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/virtconvert.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/xor.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-m68k/zorro.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/Kbuild delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/a.out.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/abi.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/addrspace.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/asm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/asmmacro-32.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/asmmacro-64.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/asmmacro.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/atomic.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/auxvec.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/barrier.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/bcache.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/bitops.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/bootinfo.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/branch.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/break.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/bug.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/bugs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/byteorder.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/cache.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/cachectl.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/cacheflush.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/cacheops.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/cevt-r4k.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/checksum.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/cmp.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/cmpxchg.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/compat-signal.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/compat.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/compiler.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/cpu-features.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/cpu-info.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/cpu.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/cputime.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/current.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/debug.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/dec/ecc.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/dec/interrupts.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/dec/ioasic.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/dec/ioasic_addrs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/dec/ioasic_ints.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/dec/kn01.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/dec/kn02.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/dec/kn02ba.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/dec/kn02ca.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/dec/kn02xa.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/dec/kn03.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/dec/kn05.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/dec/kn230.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/dec/machtype.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/dec/prom.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/dec/system.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/delay.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/device.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/div64.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/dma-mapping.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/dma.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/ds1286.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/ds1287.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/dsp.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/edac.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/elf.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/emergency-restart.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/emma2rh/emma2rh.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/emma2rh/markeins.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/errno.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/fb.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/fcntl.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/fixmap.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/floppy.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/fpregdef.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/fpu.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/fpu_emulator.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/futex.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/fw/arc/hinv.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/fw/arc/types.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/fw/cfe/cfe_api.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/fw/cfe/cfe_error.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/gcmpregs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/gic.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/gpio.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/gt64120.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/hardirq.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/hazards.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/highmem.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/hw_irq.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/i8253.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/i8259.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/ide.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/inst.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/io.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/ioctl.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/ioctls.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/ip32/crime.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/ip32/ip32_ints.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/ip32/mace.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/ipcbuf.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/irq.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/irq_cpu.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/irq_gt641xx.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/irq_regs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/irqflags.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/isadep.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/jazz.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/jazzdma.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/kdebug.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/kexec.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/kgdb.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/kmap_types.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/kspd.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/lasat/ds1603.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/lasat/eeprom.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/lasat/head.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/lasat/lasat.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/lasat/lasatint.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/lasat/picvue.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/lasat/serial.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/linkage.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/local.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/m48t35.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/m48t37.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-au1x00/au1000.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-au1x00/au1000_dma.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-au1x00/au1000_gpio.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-au1x00/au1100_mmc.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-au1x00/au1550_spi.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-au1x00/au1xxx.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-au1x00/au1xxx_dbdma.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-au1x00/au1xxx_ide.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-au1x00/au1xxx_psc.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-au1x00/gpio.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-au1x00/ioremap.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-au1x00/prom.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-au1x00/war.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-bcm47xx/bcm47xx.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-bcm47xx/gpio.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-bcm47xx/war.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-cobalt/cobalt.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-cobalt/cpu-feature-overrides.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-cobalt/irq.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-cobalt/mach-gt64120.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-cobalt/war.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-db1x00/db1200.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-db1x00/db1x00.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-dec/mc146818rtc.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-dec/war.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-emma2rh/irq.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-emma2rh/war.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-excite/cpu-feature-overrides.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-excite/excite.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-excite/excite_fpga.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-excite/excite_nandflash.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-excite/rm9k_eth.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-excite/rm9k_wdt.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-excite/rm9k_xicap.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-excite/war.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-generic/cpu-feature-overrides.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-generic/dma-coherence.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-generic/floppy.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-generic/gpio.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-generic/ide.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-generic/ioremap.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-generic/irq.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-generic/kernel-entry-init.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-generic/kmalloc.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-generic/mangle-port.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-generic/mc146818rtc.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-generic/spaces.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-generic/topology.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-ip22/cpu-feature-overrides.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-ip22/ds1286.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-ip22/spaces.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-ip22/war.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-ip27/cpu-feature-overrides.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-ip27/dma-coherence.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-ip27/irq.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-ip27/kernel-entry-init.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-ip27/kmalloc.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-ip27/mangle-port.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-ip27/mmzone.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-ip27/spaces.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-ip27/topology.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-ip27/war.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-ip28/cpu-feature-overrides.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-ip28/ds1286.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-ip28/spaces.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-ip28/war.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-ip32/cpu-feature-overrides.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-ip32/dma-coherence.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-ip32/kmalloc.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-ip32/mangle-port.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-ip32/mc146818rtc.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-ip32/war.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-jazz/dma-coherence.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-jazz/floppy.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-jazz/mc146818rtc.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-jazz/war.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-lasat/irq.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-lasat/mach-gt64120.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-lasat/war.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-lemote/dma-coherence.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-lemote/mc146818rtc.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-lemote/war.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-malta/cpu-feature-overrides.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-malta/irq.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-malta/kernel-entry-init.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-malta/mach-gt64120.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-malta/mc146818rtc.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-malta/war.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-mipssim/cpu-feature-overrides.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-mipssim/war.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-pb1x00/mc146818rtc.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-pb1x00/pb1000.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-pb1x00/pb1100.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-pb1x00/pb1200.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-pb1x00/pb1500.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-pb1x00/pb1550.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-pnx8550/cm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-pnx8550/glb.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-pnx8550/int.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-pnx8550/kernel-entry-init.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-pnx8550/nand.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-pnx8550/pci.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-pnx8550/uart.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-pnx8550/usb.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-pnx8550/war.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-rc32434/cpu-feature-overrides.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-rc32434/ddr.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-rc32434/dma.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-rc32434/dma_v.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-rc32434/eth.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-rc32434/gpio.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-rc32434/integ.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-rc32434/irq.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-rc32434/pci.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-rc32434/prom.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-rc32434/rb.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-rc32434/rc32434.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-rc32434/timer.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-rc32434/war.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-rm/cpu-feature-overrides.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-rm/mc146818rtc.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-rm/war.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-sibyte/cpu-feature-overrides.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-sibyte/war.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-tx39xx/ioremap.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-tx39xx/mangle-port.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-tx39xx/war.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-tx49xx/cpu-feature-overrides.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-tx49xx/ioremap.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-tx49xx/kmalloc.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-tx49xx/war.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-vr41xx/irq.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-vr41xx/war.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-wrppmc/mach-gt64120.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-wrppmc/war.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-yosemite/cpu-feature-overrides.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mach-yosemite/war.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mc146818-time.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mc146818rtc.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mips-boards/bonito64.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mips-boards/generic.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mips-boards/launch.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mips-boards/malta.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mips-boards/maltaint.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mips-boards/msc01_pci.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mips-boards/piix4.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mips-boards/prom.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mips-boards/sim.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mips-boards/simint.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mips_mt.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mipsmtregs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mipsprom.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mipsregs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mman.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mmu.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mmu_context.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mmzone.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/module.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/msc01_ic.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/msgbuf.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/mutex.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/nile4.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/paccess.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/page.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/param.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/parport.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/pci.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/pci/bridge.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/percpu.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/pgalloc.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/pgtable-32.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/pgtable-64.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/pgtable-bits.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/pgtable.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/pmc-sierra/msp71xx/msp_cic_int.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/pmc-sierra/msp71xx/msp_int.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/pmc-sierra/msp71xx/msp_pci.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/pmc-sierra/msp71xx/msp_prom.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/pmc-sierra/msp71xx/msp_regops.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/pmc-sierra/msp71xx/msp_regs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/pmc-sierra/msp71xx/msp_slp_int.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/pmc-sierra/msp71xx/war.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/pmon.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/poll.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/posix_types.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/prefetch.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/processor.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/ptrace.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/r4k-timer.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/r4kcache.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/reboot.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/reg.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/regdef.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/resource.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/rm9k-ocd.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/rtlx.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/scatterlist.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/seccomp.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/sections.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/segment.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/sembuf.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/serial.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/setup.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/sgi/gio.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/sgi/hpc3.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/sgi/ioc.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/sgi/ip22.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/sgi/mc.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/sgi/pi1.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/sgi/seeq.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/sgi/sgi.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/sgi/wd.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/sgialib.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/sgiarcs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/sgidefs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/shmbuf.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/shmparam.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/sibyte/bcm1480_int.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/sibyte/bcm1480_l2c.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/sibyte/bcm1480_mc.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/sibyte/bcm1480_regs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/sibyte/bcm1480_scd.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/sibyte/bigsur.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/sibyte/board.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/sibyte/carmel.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/sibyte/sb1250.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/sibyte/sb1250_defs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/sibyte/sb1250_dma.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/sibyte/sb1250_genbus.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/sibyte/sb1250_int.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/sibyte/sb1250_l2c.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/sibyte/sb1250_ldt.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/sibyte/sb1250_mac.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/sibyte/sb1250_mc.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/sibyte/sb1250_regs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/sibyte/sb1250_scd.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/sibyte/sb1250_smbus.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/sibyte/sb1250_syncser.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/sibyte/sb1250_uart.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/sibyte/sentosa.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/sibyte/swarm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/sigcontext.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/siginfo.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/signal.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/sim.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/smp-ops.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/smp.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/smtc.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/smtc_ipi.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/smtc_proc.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/smvp.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/sn/addrs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/sn/agent.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/sn/arch.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/sn/fru.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/sn/gda.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/sn/hub.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/sn/intr.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/sn/io.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/sn/ioc3.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/sn/klconfig.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/sn/kldir.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/sn/klkernvars.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/sn/launch.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/sn/mapped_kernel.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/sn/nmi.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/sn/sn0/addrs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/sn/sn0/arch.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/sn/sn0/hub.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/sn/sn0/hubio.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/sn/sn0/hubmd.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/sn/sn0/hubni.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/sn/sn0/hubpi.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/sn/sn0/ip27.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/sn/sn_private.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/sn/types.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/sni.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/socket.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/sockios.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/sparsemem.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/spinlock.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/spinlock_types.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/stackframe.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/stacktrace.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/stat.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/statfs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/string.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/suspend.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/sysmips.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/system.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/termbits.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/termios.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/thread_info.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/time.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/timex.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/titan_dep.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/tlb.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/tlbdebug.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/tlbflush.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/topology.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/traps.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/txx9/generic.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/txx9/jmr3927.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/txx9/pci.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/txx9/rbtx4927.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/txx9/rbtx4938.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/txx9/smsc_fdc37m81x.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/txx9/spi.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/txx9/tx3927.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/txx9/tx4927.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/txx9/tx4927pcic.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/txx9/tx4938.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/txx9irq.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/txx9pio.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/txx9tmr.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/types.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/uaccess.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/ucontext.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/unaligned.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/unistd.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/user.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/vga.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/vpe.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/vr41xx/capcella.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/vr41xx/giu.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/vr41xx/irq.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/vr41xx/mpc30x.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/vr41xx/pci.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/vr41xx/siu.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/vr41xx/tb0219.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/vr41xx/tb0226.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/vr41xx/tb0287.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/vr41xx/vr41xx.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/war.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/wbflush.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/xor.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/xtalk/xtalk.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mips/xtalk/xwidget.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/.gitignore delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/Kbuild delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/atomic.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/auxvec.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/bitops.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/bug.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/bugs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/busctl-regs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/byteorder.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/cache.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/cacheflush.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/checksum.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/cpu-regs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/cputime.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/current.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/delay.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/device.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/div64.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/dma-mapping.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/dma.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/dmactl-regs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/elf.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/emergency-restart.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/errno.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/exceptions.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/fb.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/fcntl.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/fpu.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/frame.inc delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/futex.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/gdb-stub.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/hardirq.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/highmem.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/hw_irq.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/ide.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/intctl-regs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/io.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/ioctl.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/ioctls.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/ipc.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/ipcbuf.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/irq.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/irq_regs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/kdebug.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/kmap_types.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/kprobes.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/linkage.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/local.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/mc146818rtc.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/mman.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/mmu.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/mmu_context.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/module.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/msgbuf.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/mutex.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/nmi.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/page.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/page_offset.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/param.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/pci.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/percpu.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/pgalloc.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/pgtable.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/pio-regs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/poll.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/posix_types.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/proc-mn103e010/cache.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/proc-mn103e010/clock.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/proc-mn103e010/irq.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/proc-mn103e010/proc.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/processor.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/ptrace.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/reset-regs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/resource.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/rtc-regs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/rtc.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/scatterlist.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/sections.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/sembuf.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/serial-regs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/serial.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/setup.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/shmbuf.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/shmparam.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/sigcontext.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/siginfo.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/signal.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/smp.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/socket.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/sockios.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/spinlock.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/stat.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/statfs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/string.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/system.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/termbits.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/termios.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/thread_info.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/timer-regs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/timex.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/tlb.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/tlbflush.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/topology.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/types.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/uaccess.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/ucontext.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/unaligned.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/unistd.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/unit-asb2303/clock.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/unit-asb2303/leds.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/unit-asb2303/serial.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/unit-asb2303/smc91111.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/unit-asb2303/timex.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/unit-asb2305/clock.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/unit-asb2305/leds.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/unit-asb2305/serial.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/unit-asb2305/timex.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/user.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/vga.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-mn10300/xor.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/Kbuild delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/a.out.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/agp.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/asmregs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/assembly.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/atomic.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/auxvec.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/bitops.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/bug.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/bugs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/byteorder.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/cache.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/cacheflush.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/checksum.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/compat.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/compat_rt_sigframe.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/compat_signal.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/compat_ucontext.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/cputime.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/current.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/delay.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/device.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/div64.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/dma-mapping.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/dma.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/eisa_bus.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/eisa_eeprom.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/elf.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/emergency-restart.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/errno.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/fb.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/fcntl.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/fixmap.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/floppy.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/futex.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/grfioctl.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/hardirq.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/hardware.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/hw_irq.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/ide.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/io.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/ioctl.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/ioctls.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/ipcbuf.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/irq.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/irq_regs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/kdebug.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/kmap_types.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/led.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/linkage.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/local.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/machdep.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/mc146818rtc.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/mckinley.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/mman.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/mmu.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/mmu_context.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/mmzone.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/module.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/msgbuf.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/mutex.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/page.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/param.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/parisc-device.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/parport.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/pci.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/pdc.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/pdc_chassis.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/pdcpat.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/percpu.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/perf.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/pgalloc.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/pgtable.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/poll.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/posix_types.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/prefetch.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/processor.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/psw.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/ptrace.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/real.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/resource.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/ropes.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/rt_sigframe.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/rtc.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/runway.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/scatterlist.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/sections.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/segment.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/sembuf.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/serial.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/setup.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/shmbuf.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/shmparam.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/sigcontext.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/siginfo.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/signal.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/smp.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/socket.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/sockios.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/spinlock.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/spinlock_types.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/stat.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/statfs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/string.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/superio.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/system.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/termbits.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/termios.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/thread_info.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/timex.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/tlb.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/tlbflush.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/topology.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/traps.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/types.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/uaccess.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/ucontext.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/unaligned.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/unistd.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/unwind.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/user.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/vga.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-parisc/xor.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/a.out-core.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/a.out.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/alternative-asm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/alternative.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/apic.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/archparam-i386.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/archparam-ppc.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/archparam-x86_64.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/asm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/atomic.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/auxvec.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/bitops.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/boot.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/bug.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/bugs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/byteorder.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/cache.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/cacheflush.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/calling.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/checksum.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/cmpxchg.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/cobalt.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/common.lds.S delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/cpufeature.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/cputime.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/current.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/delay.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/desc.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/device.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/div64.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/dma-mapping.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/dma.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/dwarf2.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/elf-i386.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/elf-ppc.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/elf-x86_64.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/emergency-restart.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/errno.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/fcntl.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/fixmap.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/floppy.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/frame.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/futex.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/hardirq.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/highmem.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/host_ldt-i386.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/host_ldt-x86_64.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/hw_irq.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/ide.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/io.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/ioctl.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/ioctls.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/ipcbuf.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/irq.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/irq_regs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/irq_vectors.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/irqflags.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/kdebug.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/kmap_types.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/ldt.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/linkage.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/local.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/locks.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/mca_dma.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/mman.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/mmu.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/mmu_context.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/module-generic.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/module-i386.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/module-x86_64.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/msgbuf.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/mtrr.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/mutex.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/nops.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/page.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/page_offset.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/param.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/paravirt.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/pci.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/pda.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/percpu.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/pgalloc.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/pgtable-2level.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/pgtable-3level.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/pgtable.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/poll.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/posix_types.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/prctl.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/processor-generic.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/processor-i386.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/processor-ppc.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/processor-x86_64.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/ptrace-generic.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/ptrace-i386.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/ptrace-x86_64.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/required-features.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/resource.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/rwlock.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/rwsem.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/scatterlist.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/sections.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/segment.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/sembuf.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/serial.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/setup.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/shmbuf.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/shmparam.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/sigcontext-generic.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/sigcontext-i386.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/sigcontext-ppc.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/sigcontext-x86_64.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/siginfo.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/signal.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/smp.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/socket.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/sockios.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/spinlock.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/spinlock_types.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/stat.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/statfs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/string.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/suspend.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/system-generic.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/system-i386.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/system-ppc.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/system-x86_64.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/termbits.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/termios.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/thread_info.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/timex.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/tlb.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/tlbflush.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/topology.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/types.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/uaccess.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/ucontext.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/unaligned.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/unistd.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/user.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/vga.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/vm-flags-i386.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/vm-flags-x86_64.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/vm86.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-um/xor.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/Kbuild delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/a.out-core.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/acpi.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/agp.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/alternative-asm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/alternative.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/amd_iommu.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/amd_iommu_types.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/apic.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/apicdef.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/arch_hooks.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/asm-offsets.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/asm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/atomic.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/atomic_32.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/atomic_64.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/bios_ebda.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/bitops.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/bug.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/bugs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/cache.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/cacheflush.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/calgary.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/calling.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/checksum.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/checksum_32.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/checksum_64.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/cmpxchg.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/cmpxchg_32.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/cmpxchg_64.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/compat.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/cpu.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/cpufeature.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/cputime.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/current.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/delay.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/desc.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/desc_defs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/device.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/div64.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/dma-mapping.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/dma.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/dmi.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/ds.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/dwarf2.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/edac.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/efi.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/elf.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/emergency-restart.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/fb.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/fixmap.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/fixmap_32.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/fixmap_64.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/floppy.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/frame.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/ftrace.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/futex.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/gart.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/genapic.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/genapic_32.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/genapic_64.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/geode.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/gpio.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/hardirq.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/hardirq_32.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/hardirq_64.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/highmem.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/hpet.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/hugetlb.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/hw_irq.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/hypertransport.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/i387.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/i8253.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/i8259.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/ia32.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/ia32_unistd.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/idle.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/intel_arch_perfmon.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/io.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/io_32.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/io_64.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/io_apic.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/iommu.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/ipi.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/irq.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/irq_regs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/irq_regs_32.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/irq_regs_64.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/irq_vectors.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/irqflags.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/k8.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/kdebug.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/kexec.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/kgdb.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/kmap_types.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/kprobes.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/kvm_host.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/kvm_x86_emulate.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/lguest.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/lguest_hcall.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/linkage.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/local.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/mach-bigsmp/mach_apic.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/mach-bigsmp/mach_apicdef.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/mach-bigsmp/mach_ipi.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/mach-default/apm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/mach-default/do_timer.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/mach-default/entry_arch.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/mach-default/mach_apic.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/mach-default/mach_apicdef.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/mach-default/mach_ipi.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/mach-default/mach_mpparse.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/mach-default/mach_mpspec.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/mach-default/mach_timer.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/mach-default/mach_traps.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/mach-default/mach_wakecpu.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/mach-default/pci-functions.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/mach-default/setup_arch.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/mach-default/smpboot_hooks.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/mach-es7000/mach_apic.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/mach-es7000/mach_apicdef.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/mach-es7000/mach_ipi.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/mach-es7000/mach_mpparse.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/mach-es7000/mach_wakecpu.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/mach-generic/gpio.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/mach-generic/irq_vectors_limits.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/mach-generic/mach_apic.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/mach-generic/mach_apicdef.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/mach-generic/mach_ipi.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/mach-generic/mach_mpparse.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/mach-generic/mach_mpspec.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/mach-numaq/mach_apic.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/mach-numaq/mach_apicdef.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/mach-numaq/mach_ipi.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/mach-numaq/mach_mpparse.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/mach-numaq/mach_wakecpu.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/mach-rdc321x/gpio.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/mach-rdc321x/rdc321x_defs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/mach-summit/irq_vectors_limits.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/mach-summit/mach_apic.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/mach-summit/mach_apicdef.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/mach-summit/mach_ipi.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/mach-summit/mach_mpparse.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/mach-voyager/do_timer.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/mach-voyager/entry_arch.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/mach-voyager/setup_arch.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/math_emu.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/mc146818rtc.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/mca.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/mca_dma.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/mmconfig.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/mmu.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/mmu_context.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/mmu_context_32.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/mmu_context_64.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/mmx.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/mmzone.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/mmzone_32.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/mmzone_64.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/module.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/mpspec.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/mpspec_def.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/msidef.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/mutex.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/mutex_32.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/mutex_64.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/nmi.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/nops.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/numa.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/numa_32.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/numa_64.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/numaq.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/olpc.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/page.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/page_32.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/page_64.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/paravirt.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/parport.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/pat.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/pci-direct.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/pci.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/pci_32.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/pci_64.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/pda.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/percpu.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/pgalloc.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/pgtable-2level-defs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/pgtable-2level.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/pgtable-3level-defs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/pgtable-3level.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/pgtable.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/pgtable_32.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/pgtable_64.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/processor-cyrix.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/processor.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/proto.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/pvclock-abi.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/pvclock.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/reboot.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/reboot_fixups.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/required-features.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/resume-trace.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/rio.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/rtc.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/rwlock.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/rwsem.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/scatterlist.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/seccomp.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/seccomp_32.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/seccomp_64.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/sections.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/segment.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/serial.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/shmparam.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/smp.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/sparsemem.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/spinlock.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/spinlock_types.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/srat.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/stacktrace.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/string.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/string_32.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/string_64.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/suspend.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/suspend_32.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/suspend_64.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/swiotlb.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/sync_bitops.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/system.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/system_64.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/tce.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/therm_throt.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/thread_info.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/time.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/timer.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/timex.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/tlb.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/tlbflush.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/topology.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/trampoline.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/traps.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/tsc.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/uaccess.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/uaccess_32.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/uaccess_64.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/unaligned.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/unwind.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/user.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/user32.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/user_32.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/user_64.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/uv/bios.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/uv/uv_bau.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/uv/uv_hub.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/uv/uv_mmrs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/vdso.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/vga.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/vgtod.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/vic.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/visws/cobalt.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/visws/lithium.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/visws/piix4.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/visws/sgivw.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/vmi.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/vmi_time.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/voyager.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/xen/events.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/xen/grant_table.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/xen/hypercall.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/xen/hypervisor.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/xen/interface.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/xen/interface_32.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/xen/interface_64.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/xen/page.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/xor.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/xor_32.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-x86/xor_64.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/Kbuild delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/a.out.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/asmmacro.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/atomic.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/auxvec.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/bitops.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/bootparam.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/bug.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/bugs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/byteorder.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/cache.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/cacheasm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/cacheflush.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/checksum.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/coprocessor.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/cpumask.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/cputime.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/current.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/delay.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/device.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/div64.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/dma-mapping.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/dma.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/elf.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/emergency-restart.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/errno.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/fb.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/fcntl.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/futex.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/hardirq.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/highmem.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/hw_irq.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/io.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/ioctl.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/ioctls.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/ipcbuf.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/irq.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/irq_regs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/kdebug.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/kmap_types.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/linkage.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/local.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/mman.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/mmu.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/mmu_context.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/module.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/msgbuf.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/mutex.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/page.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/param.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/pci-bridge.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/pci.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/percpu.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/pgalloc.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/pgtable.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/platform-iss/hardware.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/platform-iss/simcall.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/platform.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/poll.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/posix_types.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/processor.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/ptrace.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/regs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/resource.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/rmap.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/rwsem.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/scatterlist.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/sections.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/segment.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/sembuf.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/serial.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/setup.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/shmbuf.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/shmparam.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/sigcontext.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/siginfo.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/signal.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/smp.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/socket.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/sockios.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/spinlock.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/stat.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/statfs.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/string.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/syscall.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/system.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/termbits.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/termios.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/thread_info.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/timex.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/tlb.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/tlbflush.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/topology.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/types.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/uaccess.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/ucontext.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/unaligned.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/unistd.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/user.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/variant-fsf/core.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/variant-fsf/tie-asm.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/variant-fsf/tie.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/vga.h delete mode 100644 l4/pkg/linux-26-headers/include/asm-xtensa/xor.h delete mode 100644 l4/pkg/linux-26-headers/include/config/8139cp.h delete mode 100644 l4/pkg/linux-26-headers/include/config/8139too.h delete mode 100644 l4/pkg/linux-26-headers/include/config/acpi.h delete mode 100644 l4/pkg/linux-26-headers/include/config/acpi/ac.h delete mode 100644 l4/pkg/linux-26-headers/include/config/acpi/battery.h delete mode 100644 l4/pkg/linux-26-headers/include/config/acpi/blacklist/year.h delete mode 100644 l4/pkg/linux-26-headers/include/config/acpi/button.h delete mode 100644 l4/pkg/linux-26-headers/include/config/acpi/container.h delete mode 100644 l4/pkg/linux-26-headers/include/config/acpi/debug.h delete mode 100644 l4/pkg/linux-26-headers/include/config/acpi/dock.h delete mode 100644 l4/pkg/linux-26-headers/include/config/acpi/ec.h delete mode 100644 l4/pkg/linux-26-headers/include/config/acpi/fan.h delete mode 100644 l4/pkg/linux-26-headers/include/config/acpi/hotplug/cpu.h delete mode 100644 l4/pkg/linux-26-headers/include/config/acpi/power.h delete mode 100644 l4/pkg/linux-26-headers/include/config/acpi/proc/event.h delete mode 100644 l4/pkg/linux-26-headers/include/config/acpi/processor.h delete mode 100644 l4/pkg/linux-26-headers/include/config/acpi/procfs.h delete mode 100644 l4/pkg/linux-26-headers/include/config/acpi/procfs/power.h delete mode 100644 l4/pkg/linux-26-headers/include/config/acpi/sleep.h delete mode 100644 l4/pkg/linux-26-headers/include/config/acpi/sysfs/power.h delete mode 100644 l4/pkg/linux-26-headers/include/config/acpi/system.h delete mode 100644 l4/pkg/linux-26-headers/include/config/acpi/thermal.h delete mode 100644 l4/pkg/linux-26-headers/include/config/agp.h delete mode 100644 l4/pkg/linux-26-headers/include/config/agp/amd64.h delete mode 100644 l4/pkg/linux-26-headers/include/config/agp/intel.h delete mode 100644 l4/pkg/linux-26-headers/include/config/aic79xx/cmds/per/device.h delete mode 100644 l4/pkg/linux-26-headers/include/config/aic79xx/debug/mask.h delete mode 100644 l4/pkg/linux-26-headers/include/config/aic79xx/reset/delay/ms.h delete mode 100644 l4/pkg/linux-26-headers/include/config/aic7xxx/cmds/per/device.h delete mode 100644 l4/pkg/linux-26-headers/include/config/aic7xxx/debug/enable.h delete mode 100644 l4/pkg/linux-26-headers/include/config/aic7xxx/debug/mask.h delete mode 100644 l4/pkg/linux-26-headers/include/config/aic7xxx/reg/pretty/print.h delete mode 100644 l4/pkg/linux-26-headers/include/config/aic7xxx/reset/delay/ms.h delete mode 100644 l4/pkg/linux-26-headers/include/config/anon/inodes.h delete mode 100644 l4/pkg/linux-26-headers/include/config/arch/defconfig.h delete mode 100644 l4/pkg/linux-26-headers/include/config/arch/enable/memory/hotplug.h delete mode 100644 l4/pkg/linux-26-headers/include/config/arch/has/cache/line/size.h delete mode 100644 l4/pkg/linux-26-headers/include/config/arch/has/cpu/idle/wait.h delete mode 100644 l4/pkg/linux-26-headers/include/config/arch/has/cpu/relax.h delete mode 100644 l4/pkg/linux-26-headers/include/config/arch/hibernation/possible.h delete mode 100644 l4/pkg/linux-26-headers/include/config/arch/may/have/pc/fdc.h delete mode 100644 l4/pkg/linux-26-headers/include/config/arch/populates/node/map.h delete mode 100644 l4/pkg/linux-26-headers/include/config/arch/supports/aout.h delete mode 100644 l4/pkg/linux-26-headers/include/config/arch/supports/msi.h delete mode 100644 l4/pkg/linux-26-headers/include/config/arch/supports/optimized/inlining.h delete mode 100644 l4/pkg/linux-26-headers/include/config/arch/suspend/possible.h delete mode 100644 l4/pkg/linux-26-headers/include/config/arch/want/optional/gpiolib.h delete mode 100644 l4/pkg/linux-26-headers/include/config/ata.h delete mode 100644 l4/pkg/linux-26-headers/include/config/ata/acpi.h delete mode 100644 l4/pkg/linux-26-headers/include/config/ata/piix.h delete mode 100644 l4/pkg/linux-26-headers/include/config/ata/sff.h delete mode 100644 l4/pkg/linux-26-headers/include/config/auto.conf delete mode 100644 l4/pkg/linux-26-headers/include/config/auto.conf.cmd delete mode 100644 l4/pkg/linux-26-headers/include/config/autofs4/fs.h delete mode 100644 l4/pkg/linux-26-headers/include/config/b44.h delete mode 100644 l4/pkg/linux-26-headers/include/config/b44/pci.h delete mode 100644 l4/pkg/linux-26-headers/include/config/b44/pci/autoselect.h delete mode 100644 l4/pkg/linux-26-headers/include/config/b44/pcicore/autoselect.h delete mode 100644 l4/pkg/linux-26-headers/include/config/base/full.h delete mode 100644 l4/pkg/linux-26-headers/include/config/base/small.h delete mode 100644 l4/pkg/linux-26-headers/include/config/binfmt/elf.h delete mode 100644 l4/pkg/linux-26-headers/include/config/bitreverse.h delete mode 100644 l4/pkg/linux-26-headers/include/config/blk/dev.h delete mode 100644 l4/pkg/linux-26-headers/include/config/blk/dev/3w/xxxx/raid.h delete mode 100644 l4/pkg/linux-26-headers/include/config/blk/dev/amd74xx.h delete mode 100644 l4/pkg/linux-26-headers/include/config/blk/dev/dm.h delete mode 100644 l4/pkg/linux-26-headers/include/config/blk/dev/fd.h delete mode 100644 l4/pkg/linux-26-headers/include/config/blk/dev/ide.h delete mode 100644 l4/pkg/linux-26-headers/include/config/blk/dev/ideacpi.h delete mode 100644 l4/pkg/linux-26-headers/include/config/blk/dev/idecd.h delete mode 100644 l4/pkg/linux-26-headers/include/config/blk/dev/idecd/verbose/errors.h delete mode 100644 l4/pkg/linux-26-headers/include/config/blk/dev/idedisk.h delete mode 100644 l4/pkg/linux-26-headers/include/config/blk/dev/idedma.h delete mode 100644 l4/pkg/linux-26-headers/include/config/blk/dev/idedma/pci.h delete mode 100644 l4/pkg/linux-26-headers/include/config/blk/dev/idedma/sff.h delete mode 100644 l4/pkg/linux-26-headers/include/config/blk/dev/idepci.h delete mode 100644 l4/pkg/linux-26-headers/include/config/blk/dev/initrd.h delete mode 100644 l4/pkg/linux-26-headers/include/config/blk/dev/loop.h delete mode 100644 l4/pkg/linux-26-headers/include/config/blk/dev/piix.h delete mode 100644 l4/pkg/linux-26-headers/include/config/blk/dev/ram.h delete mode 100644 l4/pkg/linux-26-headers/include/config/blk/dev/ram/count.h delete mode 100644 l4/pkg/linux-26-headers/include/config/blk/dev/ram/size.h delete mode 100644 l4/pkg/linux-26-headers/include/config/blk/dev/sd.h delete mode 100644 l4/pkg/linux-26-headers/include/config/blk/dev/sr.h delete mode 100644 l4/pkg/linux-26-headers/include/config/block.h delete mode 100644 l4/pkg/linux-26-headers/include/config/bnx2.h delete mode 100644 l4/pkg/linux-26-headers/include/config/bootparam/softlockup/panic/value.h delete mode 100644 l4/pkg/linux-26-headers/include/config/bounce.h delete mode 100644 l4/pkg/linux-26-headers/include/config/bug.h delete mode 100644 l4/pkg/linux-26-headers/include/config/cc/optimize/for/size.h delete mode 100644 l4/pkg/linux-26-headers/include/config/chr/dev/sg.h delete mode 100644 l4/pkg/linux-26-headers/include/config/classic/rcu.h delete mode 100644 l4/pkg/linux-26-headers/include/config/clocksource/watchdog.h delete mode 100644 l4/pkg/linux-26-headers/include/config/compat/brk.h delete mode 100644 l4/pkg/linux-26-headers/include/config/compat/vdso.h delete mode 100644 l4/pkg/linux-26-headers/include/config/console/translations.h delete mode 100644 l4/pkg/linux-26-headers/include/config/cpu/freq.h delete mode 100644 l4/pkg/linux-26-headers/include/config/cpu/freq/debug.h delete mode 100644 l4/pkg/linux-26-headers/include/config/cpu/freq/default/gov/performance.h delete mode 100644 l4/pkg/linux-26-headers/include/config/cpu/freq/gov/conservative.h delete mode 100644 l4/pkg/linux-26-headers/include/config/cpu/freq/gov/ondemand.h delete mode 100644 l4/pkg/linux-26-headers/include/config/cpu/freq/gov/performance.h delete mode 100644 l4/pkg/linux-26-headers/include/config/cpu/freq/gov/userspace.h delete mode 100644 l4/pkg/linux-26-headers/include/config/cpu/freq/stat.h delete mode 100644 l4/pkg/linux-26-headers/include/config/cpu/freq/table.h delete mode 100644 l4/pkg/linux-26-headers/include/config/cpu/idle.h delete mode 100644 l4/pkg/linux-26-headers/include/config/cpu/idle/gov/ladder.h delete mode 100644 l4/pkg/linux-26-headers/include/config/cpu/idle/gov/menu.h delete mode 100644 l4/pkg/linux-26-headers/include/config/crc32.h delete mode 100644 l4/pkg/linux-26-headers/include/config/crypto.h delete mode 100644 l4/pkg/linux-26-headers/include/config/crypto/hw.h delete mode 100644 l4/pkg/linux-26-headers/include/config/dab.h delete mode 100644 l4/pkg/linux-26-headers/include/config/debug/bugverbose.h delete mode 100644 l4/pkg/linux-26-headers/include/config/debug/kernel.h delete mode 100644 l4/pkg/linux-26-headers/include/config/debug/memory/init.h delete mode 100644 l4/pkg/linux-26-headers/include/config/debug/stackoverflow.h delete mode 100644 l4/pkg/linux-26-headers/include/config/default/cfq.h delete mode 100644 l4/pkg/linux-26-headers/include/config/default/io/delay/type.h delete mode 100644 l4/pkg/linux-26-headers/include/config/default/iosched.h delete mode 100644 l4/pkg/linux-26-headers/include/config/default/tcp/cong.h delete mode 100644 l4/pkg/linux-26-headers/include/config/defconfig/list.h delete mode 100644 l4/pkg/linux-26-headers/include/config/detect/softlockup.h delete mode 100644 l4/pkg/linux-26-headers/include/config/devkmem.h delete mode 100644 l4/pkg/linux-26-headers/include/config/devport.h delete mode 100644 l4/pkg/linux-26-headers/include/config/dmi.h delete mode 100644 l4/pkg/linux-26-headers/include/config/dmiid.h delete mode 100644 l4/pkg/linux-26-headers/include/config/dnotify.h delete mode 100644 l4/pkg/linux-26-headers/include/config/doublefault.h delete mode 100644 l4/pkg/linux-26-headers/include/config/dummy/console.h delete mode 100644 l4/pkg/linux-26-headers/include/config/e100.h delete mode 100644 l4/pkg/linux-26-headers/include/config/e1000.h delete mode 100644 l4/pkg/linux-26-headers/include/config/e1000e.h delete mode 100644 l4/pkg/linux-26-headers/include/config/early/printk.h delete mode 100644 l4/pkg/linux-26-headers/include/config/elf/core.h delete mode 100644 l4/pkg/linux-26-headers/include/config/enable/warn/deprecated.h delete mode 100644 l4/pkg/linux-26-headers/include/config/epoll.h delete mode 100644 l4/pkg/linux-26-headers/include/config/eventfd.h delete mode 100644 l4/pkg/linux-26-headers/include/config/experimental.h delete mode 100644 l4/pkg/linux-26-headers/include/config/exportfs.h delete mode 100644 l4/pkg/linux-26-headers/include/config/ext2/fs.h delete mode 100644 l4/pkg/linux-26-headers/include/config/ext2/fs/posix/acl.h delete mode 100644 l4/pkg/linux-26-headers/include/config/ext2/fs/xattr.h delete mode 100644 l4/pkg/linux-26-headers/include/config/ext3/fs.h delete mode 100644 l4/pkg/linux-26-headers/include/config/ext3/fs/posix/acl.h delete mode 100644 l4/pkg/linux-26-headers/include/config/ext3/fs/xattr.h delete mode 100644 l4/pkg/linux-26-headers/include/config/extra/firmware.h delete mode 100644 l4/pkg/linux-26-headers/include/config/fast/cmpxchg/local.h delete mode 100644 l4/pkg/linux-26-headers/include/config/fat/default/codepage.h delete mode 100644 l4/pkg/linux-26-headers/include/config/fat/default/iocharset.h delete mode 100644 l4/pkg/linux-26-headers/include/config/fat/fs.h delete mode 100644 l4/pkg/linux-26-headers/include/config/firmware/in/kernel.h delete mode 100644 l4/pkg/linux-26-headers/include/config/firmware/memmap.h delete mode 100644 l4/pkg/linux-26-headers/include/config/fix/earlycon/mem.h delete mode 100644 l4/pkg/linux-26-headers/include/config/flat/node/mem/map.h delete mode 100644 l4/pkg/linux-26-headers/include/config/flatmem.h delete mode 100644 l4/pkg/linux-26-headers/include/config/flatmem/manual.h delete mode 100644 l4/pkg/linux-26-headers/include/config/forcedeth.h delete mode 100644 l4/pkg/linux-26-headers/include/config/frame/warn.h delete mode 100644 l4/pkg/linux-26-headers/include/config/fs/mbcache.h delete mode 100644 l4/pkg/linux-26-headers/include/config/fs/posix/acl.h delete mode 100644 l4/pkg/linux-26-headers/include/config/fusion.h delete mode 100644 l4/pkg/linux-26-headers/include/config/fusion/max/sge.h delete mode 100644 l4/pkg/linux-26-headers/include/config/fusion/spi.h delete mode 100644 l4/pkg/linux-26-headers/include/config/futex.h delete mode 100644 l4/pkg/linux-26-headers/include/config/fw/loader.h delete mode 100644 l4/pkg/linux-26-headers/include/config/generic/acl.h delete mode 100644 l4/pkg/linux-26-headers/include/config/generic/bug.h delete mode 100644 l4/pkg/linux-26-headers/include/config/generic/calibrate/delay.h delete mode 100644 l4/pkg/linux-26-headers/include/config/generic/clockevents.h delete mode 100644 l4/pkg/linux-26-headers/include/config/generic/clockevents/broadcast.h delete mode 100644 l4/pkg/linux-26-headers/include/config/generic/clockevents/build.h delete mode 100644 l4/pkg/linux-26-headers/include/config/generic/cmos/update.h delete mode 100644 l4/pkg/linux-26-headers/include/config/generic/find/first/bit.h delete mode 100644 l4/pkg/linux-26-headers/include/config/generic/find/next/bit.h delete mode 100644 l4/pkg/linux-26-headers/include/config/generic/hardirqs.h delete mode 100644 l4/pkg/linux-26-headers/include/config/generic/hweight.h delete mode 100644 l4/pkg/linux-26-headers/include/config/generic/iomap.h delete mode 100644 l4/pkg/linux-26-headers/include/config/generic/irq/probe.h delete mode 100644 l4/pkg/linux-26-headers/include/config/generic/isa/dma.h delete mode 100644 l4/pkg/linux-26-headers/include/config/generic/pending/irq.h delete mode 100644 l4/pkg/linux-26-headers/include/config/generic/time.h delete mode 100644 l4/pkg/linux-26-headers/include/config/has/dma.h delete mode 100644 l4/pkg/linux-26-headers/include/config/has/iomem.h delete mode 100644 l4/pkg/linux-26-headers/include/config/has/ioport.h delete mode 100644 l4/pkg/linux-26-headers/include/config/have/arch/kgdb.h delete mode 100644 l4/pkg/linux-26-headers/include/config/have/dynamic/ftrace.h delete mode 100644 l4/pkg/linux-26-headers/include/config/have/efficient/unaligned/access.h delete mode 100644 l4/pkg/linux-26-headers/include/config/have/ftrace.h delete mode 100644 l4/pkg/linux-26-headers/include/config/have/generic/dma/coherent.h delete mode 100644 l4/pkg/linux-26-headers/include/config/have/ide.h delete mode 100644 l4/pkg/linux-26-headers/include/config/have/ioremap/prot.h delete mode 100644 l4/pkg/linux-26-headers/include/config/have/kprobes.h delete mode 100644 l4/pkg/linux-26-headers/include/config/have/kretprobes.h delete mode 100644 l4/pkg/linux-26-headers/include/config/have/kvm.h delete mode 100644 l4/pkg/linux-26-headers/include/config/have/latencytop/support.h delete mode 100644 l4/pkg/linux-26-headers/include/config/have/oprofile.h delete mode 100644 l4/pkg/linux-26-headers/include/config/have/setup/per/cpu/area.h delete mode 100644 l4/pkg/linux-26-headers/include/config/have/unstable/sched/clock.h delete mode 100644 l4/pkg/linux-26-headers/include/config/hid.h delete mode 100644 l4/pkg/linux-26-headers/include/config/hid/support.h delete mode 100644 l4/pkg/linux-26-headers/include/config/high/res/timers.h delete mode 100644 l4/pkg/linux-26-headers/include/config/highmem.h delete mode 100644 l4/pkg/linux-26-headers/include/config/highmem4g.h delete mode 100644 l4/pkg/linux-26-headers/include/config/hotplug.h delete mode 100644 l4/pkg/linux-26-headers/include/config/hotplug/cpu.h delete mode 100644 l4/pkg/linux-26-headers/include/config/hpet.h delete mode 100644 l4/pkg/linux-26-headers/include/config/hpet/emulate/rtc.h delete mode 100644 l4/pkg/linux-26-headers/include/config/hpet/mmap.h delete mode 100644 l4/pkg/linux-26-headers/include/config/hpet/rtc/irq.h delete mode 100644 l4/pkg/linux-26-headers/include/config/hpet/timer.h delete mode 100644 l4/pkg/linux-26-headers/include/config/hugetlb/page.h delete mode 100644 l4/pkg/linux-26-headers/include/config/hugetlbfs.h delete mode 100644 l4/pkg/linux-26-headers/include/config/hw/console.h delete mode 100644 l4/pkg/linux-26-headers/include/config/hw/random.h delete mode 100644 l4/pkg/linux-26-headers/include/config/hw/random/amd.h delete mode 100644 l4/pkg/linux-26-headers/include/config/hw/random/geode.h delete mode 100644 l4/pkg/linux-26-headers/include/config/hw/random/intel.h delete mode 100644 l4/pkg/linux-26-headers/include/config/hw/random/via.h delete mode 100644 l4/pkg/linux-26-headers/include/config/hz.h delete mode 100644 l4/pkg/linux-26-headers/include/config/hz/250.h delete mode 100644 l4/pkg/linux-26-headers/include/config/ide.h delete mode 100644 l4/pkg/linux-26-headers/include/config/ide/generic.h delete mode 100644 l4/pkg/linux-26-headers/include/config/ide/proc/fs.h delete mode 100644 l4/pkg/linux-26-headers/include/config/ide/timings.h delete mode 100644 l4/pkg/linux-26-headers/include/config/idedisk/multi/mode.h delete mode 100644 l4/pkg/linux-26-headers/include/config/idepci/pcibus/order.h delete mode 100644 l4/pkg/linux-26-headers/include/config/ieee1394.h delete mode 100644 l4/pkg/linux-26-headers/include/config/ieee1394/ohci1394.h delete mode 100644 l4/pkg/linux-26-headers/include/config/ieee1394/rawio.h delete mode 100644 l4/pkg/linux-26-headers/include/config/ikconfig.h delete mode 100644 l4/pkg/linux-26-headers/include/config/ikconfig/proc.h delete mode 100644 l4/pkg/linux-26-headers/include/config/inet.h delete mode 100644 l4/pkg/linux-26-headers/include/config/inet/diag.h delete mode 100644 l4/pkg/linux-26-headers/include/config/inet/tcp/diag.h delete mode 100644 l4/pkg/linux-26-headers/include/config/inet/tunnel.h delete mode 100644 l4/pkg/linux-26-headers/include/config/inet/xfrm/mode/transport.h delete mode 100644 l4/pkg/linux-26-headers/include/config/inet/xfrm/mode/tunnel.h delete mode 100644 l4/pkg/linux-26-headers/include/config/inet6/xfrm/mode/transport.h delete mode 100644 l4/pkg/linux-26-headers/include/config/inet6/xfrm/mode/tunnel.h delete mode 100644 l4/pkg/linux-26-headers/include/config/init/env/arg/limit.h delete mode 100644 l4/pkg/linux-26-headers/include/config/initramfs/source.h delete mode 100644 l4/pkg/linux-26-headers/include/config/inotify.h delete mode 100644 l4/pkg/linux-26-headers/include/config/inotify/user.h delete mode 100644 l4/pkg/linux-26-headers/include/config/input.h delete mode 100644 l4/pkg/linux-26-headers/include/config/input/evdev.h delete mode 100644 l4/pkg/linux-26-headers/include/config/input/keyboard.h delete mode 100644 l4/pkg/linux-26-headers/include/config/input/mouse.h delete mode 100644 l4/pkg/linux-26-headers/include/config/input/mousedev.h delete mode 100644 l4/pkg/linux-26-headers/include/config/input/mousedev/psaux.h delete mode 100644 l4/pkg/linux-26-headers/include/config/input/mousedev/screen/x.h delete mode 100644 l4/pkg/linux-26-headers/include/config/input/mousedev/screen/y.h delete mode 100644 l4/pkg/linux-26-headers/include/config/io/delay/0x80.h delete mode 100644 l4/pkg/linux-26-headers/include/config/io/delay/type/0x80.h delete mode 100644 l4/pkg/linux-26-headers/include/config/io/delay/type/0xed.h delete mode 100644 l4/pkg/linux-26-headers/include/config/io/delay/type/none.h delete mode 100644 l4/pkg/linux-26-headers/include/config/io/delay/type/udelay.h delete mode 100644 l4/pkg/linux-26-headers/include/config/iosched/as.h delete mode 100644 l4/pkg/linux-26-headers/include/config/iosched/cfq.h delete mode 100644 l4/pkg/linux-26-headers/include/config/iosched/deadline.h delete mode 100644 l4/pkg/linux-26-headers/include/config/iosched/noop.h delete mode 100644 l4/pkg/linux-26-headers/include/config/ip/fib/hash.h delete mode 100644 l4/pkg/linux-26-headers/include/config/ip/multicast.h delete mode 100644 l4/pkg/linux-26-headers/include/config/ip/pnp.h delete mode 100644 l4/pkg/linux-26-headers/include/config/ip/pnp/dhcp.h delete mode 100644 l4/pkg/linux-26-headers/include/config/ipv6.h delete mode 100644 l4/pkg/linux-26-headers/include/config/ipv6/ndisc/nodetype.h delete mode 100644 l4/pkg/linux-26-headers/include/config/ipv6/sit.h delete mode 100644 l4/pkg/linux-26-headers/include/config/isa/dma/api.h delete mode 100644 l4/pkg/linux-26-headers/include/config/iso9660/fs.h delete mode 100644 l4/pkg/linux-26-headers/include/config/jbd.h delete mode 100644 l4/pkg/linux-26-headers/include/config/k8/nb.h delete mode 100644 l4/pkg/linux-26-headers/include/config/kallsyms.h delete mode 100644 l4/pkg/linux-26-headers/include/config/kallsyms/all.h delete mode 100644 l4/pkg/linux-26-headers/include/config/kernel.release delete mode 100644 l4/pkg/linux-26-headers/include/config/keyboard/atkbd.h delete mode 100644 l4/pkg/linux-26-headers/include/config/kmod.h delete mode 100644 l4/pkg/linux-26-headers/include/config/kprobes.h delete mode 100644 l4/pkg/linux-26-headers/include/config/kretprobes.h delete mode 100644 l4/pkg/linux-26-headers/include/config/ktime/scalar.h delete mode 100644 l4/pkg/linux-26-headers/include/config/kvm.h delete mode 100644 l4/pkg/linux-26-headers/include/config/kvm/intel.h delete mode 100644 l4/pkg/linux-26-headers/include/config/lbd.h delete mode 100644 l4/pkg/linux-26-headers/include/config/legacy/pty/count.h delete mode 100644 l4/pkg/linux-26-headers/include/config/legacy/ptys.h delete mode 100644 l4/pkg/linux-26-headers/include/config/localversion.h delete mode 100644 l4/pkg/linux-26-headers/include/config/localversion/auto.h delete mode 100644 l4/pkg/linux-26-headers/include/config/lock/kernel.h delete mode 100644 l4/pkg/linux-26-headers/include/config/lockd.h delete mode 100644 l4/pkg/linux-26-headers/include/config/lockd/v4.h delete mode 100644 l4/pkg/linux-26-headers/include/config/lockdep/support.h delete mode 100644 l4/pkg/linux-26-headers/include/config/log/buf/shift.h delete mode 100644 l4/pkg/linux-26-headers/include/config/macintosh/drivers.h delete mode 100644 l4/pkg/linux-26-headers/include/config/magic/sysrq.h delete mode 100644 l4/pkg/linux-26-headers/include/config/max/raw/devs.h delete mode 100644 l4/pkg/linux-26-headers/include/config/mcore2.h delete mode 100644 l4/pkg/linux-26-headers/include/config/md.h delete mode 100644 l4/pkg/linux-26-headers/include/config/microcode.h delete mode 100644 l4/pkg/linux-26-headers/include/config/microcode/old/interface.h delete mode 100644 l4/pkg/linux-26-headers/include/config/mii.h delete mode 100644 l4/pkg/linux-26-headers/include/config/misc/devices.h delete mode 100644 l4/pkg/linux-26-headers/include/config/mmu.h delete mode 100644 l4/pkg/linux-26-headers/include/config/mmu/notifier.h delete mode 100644 l4/pkg/linux-26-headers/include/config/module/force/unload.h delete mode 100644 l4/pkg/linux-26-headers/include/config/module/unload.h delete mode 100644 l4/pkg/linux-26-headers/include/config/modules.h delete mode 100644 l4/pkg/linux-26-headers/include/config/mouse/ps2.h delete mode 100644 l4/pkg/linux-26-headers/include/config/mouse/ps2/alps.h delete mode 100644 l4/pkg/linux-26-headers/include/config/mouse/ps2/lifebook.h delete mode 100644 l4/pkg/linux-26-headers/include/config/mouse/ps2/logips2pp.h delete mode 100644 l4/pkg/linux-26-headers/include/config/mouse/ps2/synaptics.h delete mode 100644 l4/pkg/linux-26-headers/include/config/mouse/ps2/trackpoint.h delete mode 100644 l4/pkg/linux-26-headers/include/config/msdos/fs.h delete mode 100644 l4/pkg/linux-26-headers/include/config/msdos/partition.h delete mode 100644 l4/pkg/linux-26-headers/include/config/mtrr.h delete mode 100644 l4/pkg/linux-26-headers/include/config/namespaces.h delete mode 100644 l4/pkg/linux-26-headers/include/config/net.h delete mode 100644 l4/pkg/linux-26-headers/include/config/net/ethernet.h delete mode 100644 l4/pkg/linux-26-headers/include/config/net/pci.h delete mode 100644 l4/pkg/linux-26-headers/include/config/net/poll/controller.h delete mode 100644 l4/pkg/linux-26-headers/include/config/net/tulip.h delete mode 100644 l4/pkg/linux-26-headers/include/config/net/vendor/3com.h delete mode 100644 l4/pkg/linux-26-headers/include/config/netconsole.h delete mode 100644 l4/pkg/linux-26-headers/include/config/netdev/1000.h delete mode 100644 l4/pkg/linux-26-headers/include/config/netdev/10000.h delete mode 100644 l4/pkg/linux-26-headers/include/config/netdevices.h delete mode 100644 l4/pkg/linux-26-headers/include/config/netpoll.h delete mode 100644 l4/pkg/linux-26-headers/include/config/network/filesystems.h delete mode 100644 l4/pkg/linux-26-headers/include/config/nfs/common.h delete mode 100644 l4/pkg/linux-26-headers/include/config/nfs/fs.h delete mode 100644 l4/pkg/linux-26-headers/include/config/nfs/v3.h delete mode 100644 l4/pkg/linux-26-headers/include/config/nfsd.h delete mode 100644 l4/pkg/linux-26-headers/include/config/nfsd/v3.h delete mode 100644 l4/pkg/linux-26-headers/include/config/nls.h delete mode 100644 l4/pkg/linux-26-headers/include/config/nls/ascii.h delete mode 100644 l4/pkg/linux-26-headers/include/config/nls/codepage/437.h delete mode 100644 l4/pkg/linux-26-headers/include/config/nls/default.h delete mode 100644 l4/pkg/linux-26-headers/include/config/nls/iso8859/1.h delete mode 100644 l4/pkg/linux-26-headers/include/config/nls/iso8859/15.h delete mode 100644 l4/pkg/linux-26-headers/include/config/nls/utf8.h delete mode 100644 l4/pkg/linux-26-headers/include/config/no/hz.h delete mode 100644 l4/pkg/linux-26-headers/include/config/nr/cpus.h delete mode 100644 l4/pkg/linux-26-headers/include/config/oprofile.h delete mode 100644 l4/pkg/linux-26-headers/include/config/packet.h delete mode 100644 l4/pkg/linux-26-headers/include/config/page/offset.h delete mode 100644 l4/pkg/linux-26-headers/include/config/pageflags/extended.h delete mode 100644 l4/pkg/linux-26-headers/include/config/pci.h delete mode 100644 l4/pkg/linux-26-headers/include/config/pci/bios.h delete mode 100644 l4/pkg/linux-26-headers/include/config/pci/direct.h delete mode 100644 l4/pkg/linux-26-headers/include/config/pci/domains.h delete mode 100644 l4/pkg/linux-26-headers/include/config/pci/goany.h delete mode 100644 l4/pkg/linux-26-headers/include/config/pci/legacy.h delete mode 100644 l4/pkg/linux-26-headers/include/config/pci/mmconfig.h delete mode 100644 l4/pkg/linux-26-headers/include/config/pci/msi.h delete mode 100644 l4/pkg/linux-26-headers/include/config/pcspkr/platform.h delete mode 100644 l4/pkg/linux-26-headers/include/config/phylib.h delete mode 100644 l4/pkg/linux-26-headers/include/config/physical/align.h delete mode 100644 l4/pkg/linux-26-headers/include/config/physical/start.h delete mode 100644 l4/pkg/linux-26-headers/include/config/plist.h delete mode 100644 l4/pkg/linux-26-headers/include/config/pm.h delete mode 100644 l4/pkg/linux-26-headers/include/config/pm/sleep.h delete mode 100644 l4/pkg/linux-26-headers/include/config/pm/sleep/smp.h delete mode 100644 l4/pkg/linux-26-headers/include/config/pnp.h delete mode 100644 l4/pkg/linux-26-headers/include/config/pnpacpi.h delete mode 100644 l4/pkg/linux-26-headers/include/config/posix/mqueue.h delete mode 100644 l4/pkg/linux-26-headers/include/config/power/supply.h delete mode 100644 l4/pkg/linux-26-headers/include/config/preempt/notifiers.h delete mode 100644 l4/pkg/linux-26-headers/include/config/preempt/voluntary.h delete mode 100644 l4/pkg/linux-26-headers/include/config/prevent/firmware/build.h delete mode 100644 l4/pkg/linux-26-headers/include/config/printk.h delete mode 100644 l4/pkg/linux-26-headers/include/config/proc/fs.h delete mode 100644 l4/pkg/linux-26-headers/include/config/proc/kcore.h delete mode 100644 l4/pkg/linux-26-headers/include/config/proc/page/monitor.h delete mode 100644 l4/pkg/linux-26-headers/include/config/proc/sysctl.h delete mode 100644 l4/pkg/linux-26-headers/include/config/profiling.h delete mode 100644 l4/pkg/linux-26-headers/include/config/r8169.h delete mode 100644 l4/pkg/linux-26-headers/include/config/raw/driver.h delete mode 100644 l4/pkg/linux-26-headers/include/config/reiserfs/fs.h delete mode 100644 l4/pkg/linux-26-headers/include/config/reiserfs/fs/posix/acl.h delete mode 100644 l4/pkg/linux-26-headers/include/config/reiserfs/fs/xattr.h delete mode 100644 l4/pkg/linux-26-headers/include/config/relay.h delete mode 100644 l4/pkg/linux-26-headers/include/config/resources/64bit.h delete mode 100644 l4/pkg/linux-26-headers/include/config/root/nfs.h delete mode 100644 l4/pkg/linux-26-headers/include/config/rt/mutexes.h delete mode 100644 l4/pkg/linux-26-headers/include/config/rtc.h delete mode 100644 l4/pkg/linux-26-headers/include/config/rwsem/xchgadd/algorithm.h delete mode 100644 l4/pkg/linux-26-headers/include/config/sata/ahci.h delete mode 100644 l4/pkg/linux-26-headers/include/config/sata/nv.h delete mode 100644 l4/pkg/linux-26-headers/include/config/sata/pmp.h delete mode 100644 l4/pkg/linux-26-headers/include/config/sata/sil.h delete mode 100644 l4/pkg/linux-26-headers/include/config/sata/svw.h delete mode 100644 l4/pkg/linux-26-headers/include/config/sata/via.h delete mode 100644 l4/pkg/linux-26-headers/include/config/sched/hrtick.h delete mode 100644 l4/pkg/linux-26-headers/include/config/sched/mc.h delete mode 100644 l4/pkg/linux-26-headers/include/config/sched/no/no/omit/frame/pointer.h delete mode 100644 l4/pkg/linux-26-headers/include/config/sched/smt.h delete mode 100644 l4/pkg/linux-26-headers/include/config/scsi.h delete mode 100644 l4/pkg/linux-26-headers/include/config/scsi/aic79xx.h delete mode 100644 l4/pkg/linux-26-headers/include/config/scsi/aic7xxx.h delete mode 100644 l4/pkg/linux-26-headers/include/config/scsi/dma.h delete mode 100644 l4/pkg/linux-26-headers/include/config/scsi/fc/attrs.h delete mode 100644 l4/pkg/linux-26-headers/include/config/scsi/lowlevel.h delete mode 100644 l4/pkg/linux-26-headers/include/config/scsi/netlink.h delete mode 100644 l4/pkg/linux-26-headers/include/config/scsi/spi/attrs.h delete mode 100644 l4/pkg/linux-26-headers/include/config/scsi/wait/scan.h delete mode 100644 l4/pkg/linux-26-headers/include/config/seccomp.h delete mode 100644 l4/pkg/linux-26-headers/include/config/select/memory/model.h delete mode 100644 l4/pkg/linux-26-headers/include/config/serial/8250.h delete mode 100644 l4/pkg/linux-26-headers/include/config/serial/8250/console.h delete mode 100644 l4/pkg/linux-26-headers/include/config/serial/8250/nr/uarts.h delete mode 100644 l4/pkg/linux-26-headers/include/config/serial/8250/pci.h delete mode 100644 l4/pkg/linux-26-headers/include/config/serial/8250/pnp.h delete mode 100644 l4/pkg/linux-26-headers/include/config/serial/8250/runtime/uarts.h delete mode 100644 l4/pkg/linux-26-headers/include/config/serial/core.h delete mode 100644 l4/pkg/linux-26-headers/include/config/serial/core/console.h delete mode 100644 l4/pkg/linux-26-headers/include/config/serio.h delete mode 100644 l4/pkg/linux-26-headers/include/config/serio/i8042.h delete mode 100644 l4/pkg/linux-26-headers/include/config/serio/libps2.h delete mode 100644 l4/pkg/linux-26-headers/include/config/shmem.h delete mode 100644 l4/pkg/linux-26-headers/include/config/signalfd.h delete mode 100644 l4/pkg/linux-26-headers/include/config/sky2.h delete mode 100644 l4/pkg/linux-26-headers/include/config/slabinfo.h delete mode 100644 l4/pkg/linux-26-headers/include/config/slub.h delete mode 100644 l4/pkg/linux-26-headers/include/config/slub/debug.h delete mode 100644 l4/pkg/linux-26-headers/include/config/smp.h delete mode 100644 l4/pkg/linux-26-headers/include/config/sound.h delete mode 100644 l4/pkg/linux-26-headers/include/config/sound/prime.h delete mode 100644 l4/pkg/linux-26-headers/include/config/split/ptlock/cpus.h delete mode 100644 l4/pkg/linux-26-headers/include/config/ssb.h delete mode 100644 l4/pkg/linux-26-headers/include/config/ssb/driver/pcicore.h delete mode 100644 l4/pkg/linux-26-headers/include/config/ssb/driver/pcicore/possible.h delete mode 100644 l4/pkg/linux-26-headers/include/config/ssb/pcihost.h delete mode 100644 l4/pkg/linux-26-headers/include/config/ssb/pcihost/possible.h delete mode 100644 l4/pkg/linux-26-headers/include/config/ssb/possible.h delete mode 100644 l4/pkg/linux-26-headers/include/config/ssb/sprom.h delete mode 100644 l4/pkg/linux-26-headers/include/config/stacktrace/support.h delete mode 100644 l4/pkg/linux-26-headers/include/config/standalone.h delete mode 100644 l4/pkg/linux-26-headers/include/config/stop/machine.h delete mode 100644 l4/pkg/linux-26-headers/include/config/sunrpc.h delete mode 100644 l4/pkg/linux-26-headers/include/config/suspend.h delete mode 100644 l4/pkg/linux-26-headers/include/config/suspend/freezer.h delete mode 100644 l4/pkg/linux-26-headers/include/config/swap.h delete mode 100644 l4/pkg/linux-26-headers/include/config/sysctl.h delete mode 100644 l4/pkg/linux-26-headers/include/config/sysctl/syscall.h delete mode 100644 l4/pkg/linux-26-headers/include/config/sysctl/syscall/check.h delete mode 100644 l4/pkg/linux-26-headers/include/config/sysfs.h delete mode 100644 l4/pkg/linux-26-headers/include/config/sysfs/deprecated.h delete mode 100644 l4/pkg/linux-26-headers/include/config/sysfs/deprecated/v2.h delete mode 100644 l4/pkg/linux-26-headers/include/config/sysvipc.h delete mode 100644 l4/pkg/linux-26-headers/include/config/sysvipc/sysctl.h delete mode 100644 l4/pkg/linux-26-headers/include/config/tcp/cong/cubic.h delete mode 100644 l4/pkg/linux-26-headers/include/config/thermal.h delete mode 100644 l4/pkg/linux-26-headers/include/config/tick/oneshot.h delete mode 100644 l4/pkg/linux-26-headers/include/config/tigon3.h delete mode 100644 l4/pkg/linux-26-headers/include/config/timer/stats.h delete mode 100644 l4/pkg/linux-26-headers/include/config/timerfd.h delete mode 100644 l4/pkg/linux-26-headers/include/config/tmpfs.h delete mode 100644 l4/pkg/linux-26-headers/include/config/tmpfs/posix/acl.h delete mode 100644 l4/pkg/linux-26-headers/include/config/trace/irqflags/support.h delete mode 100644 l4/pkg/linux-26-headers/include/config/tulip.h delete mode 100644 l4/pkg/linux-26-headers/include/config/uevent/helper/path.h delete mode 100644 l4/pkg/linux-26-headers/include/config/uid16.h delete mode 100644 l4/pkg/linux-26-headers/include/config/unix.h delete mode 100644 l4/pkg/linux-26-headers/include/config/unix98/ptys.h delete mode 100644 l4/pkg/linux-26-headers/include/config/unused/symbols.h delete mode 100644 l4/pkg/linux-26-headers/include/config/usb.h delete mode 100644 l4/pkg/linux-26-headers/include/config/usb/announce/new/devices.h delete mode 100644 l4/pkg/linux-26-headers/include/config/usb/arch/has/ehci.h delete mode 100644 l4/pkg/linux-26-headers/include/config/usb/arch/has/hcd.h delete mode 100644 l4/pkg/linux-26-headers/include/config/usb/arch/has/ohci.h delete mode 100644 l4/pkg/linux-26-headers/include/config/usb/devicefs.h delete mode 100644 l4/pkg/linux-26-headers/include/config/usb/ehci/hcd.h delete mode 100644 l4/pkg/linux-26-headers/include/config/usb/hid.h delete mode 100644 l4/pkg/linux-26-headers/include/config/usb/mon.h delete mode 100644 l4/pkg/linux-26-headers/include/config/usb/ohci/hcd.h delete mode 100644 l4/pkg/linux-26-headers/include/config/usb/ohci/little/endian.h delete mode 100644 l4/pkg/linux-26-headers/include/config/usb/printer.h delete mode 100644 l4/pkg/linux-26-headers/include/config/usb/serial.h delete mode 100644 l4/pkg/linux-26-headers/include/config/usb/serial/generic.h delete mode 100644 l4/pkg/linux-26-headers/include/config/usb/serial/pl2303.h delete mode 100644 l4/pkg/linux-26-headers/include/config/usb/storage.h delete mode 100644 l4/pkg/linux-26-headers/include/config/usb/support.h delete mode 100644 l4/pkg/linux-26-headers/include/config/usb/uhci/hcd.h delete mode 100644 l4/pkg/linux-26-headers/include/config/use/generic/smp/helpers.h delete mode 100644 l4/pkg/linux-26-headers/include/config/vfat/fs.h delete mode 100644 l4/pkg/linux-26-headers/include/config/vga/console.h delete mode 100644 l4/pkg/linux-26-headers/include/config/vgacon/soft/scrollback.h delete mode 100644 l4/pkg/linux-26-headers/include/config/vgacon/soft/scrollback/size.h delete mode 100644 l4/pkg/linux-26-headers/include/config/video/select.h delete mode 100644 l4/pkg/linux-26-headers/include/config/virt/to/bus.h delete mode 100644 l4/pkg/linux-26-headers/include/config/virtualization.h delete mode 100644 l4/pkg/linux-26-headers/include/config/vm/event/counters.h delete mode 100644 l4/pkg/linux-26-headers/include/config/vm86.h delete mode 100644 l4/pkg/linux-26-headers/include/config/vortex.h delete mode 100644 l4/pkg/linux-26-headers/include/config/vt.h delete mode 100644 l4/pkg/linux-26-headers/include/config/vt/console.h delete mode 100644 l4/pkg/linux-26-headers/include/config/x86.h delete mode 100644 l4/pkg/linux-26-headers/include/config/x86/32.h delete mode 100644 l4/pkg/linux-26-headers/include/config/x86/32/smp.h delete mode 100644 l4/pkg/linux-26-headers/include/config/x86/acpi/cpufreq.h delete mode 100644 l4/pkg/linux-26-headers/include/config/x86/acpi/cpufreq/proc/intf.h delete mode 100644 l4/pkg/linux-26-headers/include/config/x86/bios/reboot.h delete mode 100644 l4/pkg/linux-26-headers/include/config/x86/bswap.h delete mode 100644 l4/pkg/linux-26-headers/include/config/x86/cmpxchg.h delete mode 100644 l4/pkg/linux-26-headers/include/config/x86/cpu.h delete mode 100644 l4/pkg/linux-26-headers/include/config/x86/cpuid.h delete mode 100644 l4/pkg/linux-26-headers/include/config/x86/cyclone/timer.h delete mode 100644 l4/pkg/linux-26-headers/include/config/x86/debugctlmsr.h delete mode 100644 l4/pkg/linux-26-headers/include/config/x86/find/smp/config.h delete mode 100644 l4/pkg/linux-26-headers/include/config/x86/generic.h delete mode 100644 l4/pkg/linux-26-headers/include/config/x86/genericarch.h delete mode 100644 l4/pkg/linux-26-headers/include/config/x86/ht.h delete mode 100644 l4/pkg/linux-26-headers/include/config/x86/intel/usercopy.h delete mode 100644 l4/pkg/linux-26-headers/include/config/x86/invlpg.h delete mode 100644 l4/pkg/linux-26-headers/include/config/x86/io/apic.h delete mode 100644 l4/pkg/linux-26-headers/include/config/x86/l1/cache/shift.h delete mode 100644 l4/pkg/linux-26-headers/include/config/x86/local/apic.h delete mode 100644 l4/pkg/linux-26-headers/include/config/x86/mce.h delete mode 100644 l4/pkg/linux-26-headers/include/config/x86/mce/nonfatal.h delete mode 100644 l4/pkg/linux-26-headers/include/config/x86/mce/p4thermal.h delete mode 100644 l4/pkg/linux-26-headers/include/config/x86/minimum/cpu/family.h delete mode 100644 l4/pkg/linux-26-headers/include/config/x86/mpparse.h delete mode 100644 l4/pkg/linux-26-headers/include/config/x86/msr.h delete mode 100644 l4/pkg/linux-26-headers/include/config/x86/pm/timer.h delete mode 100644 l4/pkg/linux-26-headers/include/config/x86/popad/ok.h delete mode 100644 l4/pkg/linux-26-headers/include/config/x86/powernow/k8.h delete mode 100644 l4/pkg/linux-26-headers/include/config/x86/powernow/k8/acpi.h delete mode 100644 l4/pkg/linux-26-headers/include/config/x86/smp.h delete mode 100644 l4/pkg/linux-26-headers/include/config/x86/trampoline.h delete mode 100644 l4/pkg/linux-26-headers/include/config/x86/tsc.h delete mode 100644 l4/pkg/linux-26-headers/include/config/x86/use/ppro/checksum.h delete mode 100644 l4/pkg/linux-26-headers/include/config/x86/verbose/bootup.h delete mode 100644 l4/pkg/linux-26-headers/include/config/x86/wp/works/ok.h delete mode 100644 l4/pkg/linux-26-headers/include/config/x86/xadd.h delete mode 100644 l4/pkg/linux-26-headers/include/config/xfrm.h delete mode 100644 l4/pkg/linux-26-headers/include/config/zlib/inflate.h delete mode 100644 l4/pkg/linux-26-headers/include/config/zone/dma.h delete mode 100644 l4/pkg/linux-26-headers/include/config/zone/dma/flag.h delete mode 100644 l4/pkg/linux-26-headers/include/crypto/aead.h delete mode 100644 l4/pkg/linux-26-headers/include/crypto/aes.h delete mode 100644 l4/pkg/linux-26-headers/include/crypto/algapi.h delete mode 100644 l4/pkg/linux-26-headers/include/crypto/authenc.h delete mode 100644 l4/pkg/linux-26-headers/include/crypto/b128ops.h delete mode 100644 l4/pkg/linux-26-headers/include/crypto/ctr.h delete mode 100644 l4/pkg/linux-26-headers/include/crypto/des.h delete mode 100644 l4/pkg/linux-26-headers/include/crypto/gf128mul.h delete mode 100644 l4/pkg/linux-26-headers/include/crypto/hash.h delete mode 100644 l4/pkg/linux-26-headers/include/crypto/internal/aead.h delete mode 100644 l4/pkg/linux-26-headers/include/crypto/internal/hash.h delete mode 100644 l4/pkg/linux-26-headers/include/crypto/internal/skcipher.h delete mode 100644 l4/pkg/linux-26-headers/include/crypto/scatterwalk.h delete mode 100644 l4/pkg/linux-26-headers/include/crypto/sha.h delete mode 100644 l4/pkg/linux-26-headers/include/crypto/skcipher.h delete mode 100644 l4/pkg/linux-26-headers/include/crypto/twofish.h delete mode 100644 l4/pkg/linux-26-headers/include/drm/Kbuild delete mode 100644 l4/pkg/linux-26-headers/include/drm/drmP.h delete mode 100644 l4/pkg/linux-26-headers/include/drm/drm_core.h delete mode 100644 l4/pkg/linux-26-headers/include/drm/drm_hashtab.h delete mode 100644 l4/pkg/linux-26-headers/include/drm/drm_memory.h delete mode 100644 l4/pkg/linux-26-headers/include/drm/drm_memory_debug.h delete mode 100644 l4/pkg/linux-26-headers/include/drm/drm_os_linux.h delete mode 100644 l4/pkg/linux-26-headers/include/drm/drm_pciids.h delete mode 100644 l4/pkg/linux-26-headers/include/drm/drm_sman.h delete mode 100644 l4/pkg/linux-26-headers/include/drm/i830_drm.h delete mode 100644 l4/pkg/linux-26-headers/include/keys/rxrpc-type.h delete mode 100644 l4/pkg/linux-26-headers/include/keys/user-type.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/8250_pci.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/Kbuild delete mode 100644 l4/pkg/linux-26-headers/include/linux/ac97_codec.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/acpi.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/acpi_pmtmr.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/adfs_fs_i.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/adfs_fs_sb.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/aer.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/agp_backend.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/aio.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/amba/bus.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/amba/clcd.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/amba/kmi.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/amba/serial.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/amifd.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/amifdreg.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/amigaffs.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/anon_inodes.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/apm-emulation.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/arcdevice.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/async_tx.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/ata.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/ata_platform.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/atm_suni.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/atmel-pwm-bl.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/atmel-ssc.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/atmel_pdc.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/atmel_pwm.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/atmel_serial.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/atmel_tc.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/attribute_container.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/autoconf.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/b1pcmcia.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/backing-dev.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/backlight.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/bcd.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/bio.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/bit_spinlock.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/bitmap.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/bitops.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/bitrev.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/blkdev.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/blockgroup_lock.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/bootmem.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/bottom_half.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/bounds.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/brcmphy.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/buffer_head.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/bug.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/byteorder.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/byteorder/Kbuild delete mode 100644 l4/pkg/linux-26-headers/include/linux/byteorder/generic.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/byteorder/swab.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/byteorder/swabb.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/cache.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/can/Kbuild delete mode 100644 l4/pkg/linux-26-headers/include/linux/can/core.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/cd1400.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/cdev.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/cdk.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/cfag12864b.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/cgroup.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/cgroup_subsys.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/circ_buf.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/clk.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/clockchips.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/clocksource.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/cnt32_to_63.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/coda_cache.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/coda_fs_i.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/coda_linux.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/com20020.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/compat.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/compile.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/compiler-gcc.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/compiler-gcc3.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/compiler-gcc4.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/compiler-intel.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/compiler.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/completion.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/comstats.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/concap.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/configfs.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/console.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/console_struct.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/consolemap.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/cpu.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/cpufreq.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/cpuidle.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/cpumask.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/cpuset.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/cramfs_fs_sb.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/crash_dump.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/crc-ccitt.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/crc-itu-t.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/crc-t10dif.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/crc16.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/crc32.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/crc32c.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/crc7.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/cred.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/crypto.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/cryptohash.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/ctype.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/cyclomx.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/cycx_drv.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/cycx_x25.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/dca.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/dcache.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/dcookies.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/debug_locks.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/debugfs.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/debugobjects.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/delay.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/delayacct.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/device-mapper.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/device.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/device_cgroup.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/devpts_fs.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/dio.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/dirent.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/display.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/dm-dirty-log.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/dm-io.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/dm-kcopyd.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/dm9000.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/dma-attrs.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/dma-mapping.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/dmaengine.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/dmapool.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/dmar.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/dmi.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/dnotify.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/dqblk_v1.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/dqblk_v2.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/ds1286.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/ds17287rtc.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/ds1wm.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/dtlk.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/dvb/Kbuild delete mode 100644 l4/pkg/linux-26-headers/include/linux/dw_dmac.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/edac.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/eeprom_93cx6.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/efi.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/efs_vh.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/eisa.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/elevator.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/elfcore-compat.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/elfnote.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/enclosure.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/err.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/etherdevice.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/eventfd.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/exportfs.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/ext2_fs.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/ext2_fs_sb.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/ext3_fs.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/ext3_fs_i.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/ext3_fs_sb.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/ext3_jbd.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/f75375s.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/fault-inject.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/fcdevice.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/fddidevice.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/fdtable.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/file.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/firmware-map.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/firmware.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/font.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/freezer.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/fs_enet_pd.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/fs_stack.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/fs_struct.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/fs_uart_pd.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/fsl_devices.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/fsnotify.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/ftrace.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/genalloc.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/generic_acl.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/generic_serial.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/genhd.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/getcpu.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/gfp.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/gpio.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/gpio_keys.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/gpio_mouse.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/hardirq.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/hash.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/hayesesp.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/hdlc/Kbuild delete mode 100644 l4/pkg/linux-26-headers/include/linux/hdpu_features.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/hid-debug.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/highmem.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/highuid.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/hil.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/hil_mlc.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/hippidevice.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/hp_sdc.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/hrtimer.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/htirq.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/hugetlb.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/hw_random.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/hwmon-sysfs.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/hwmon-vid.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/hwmon.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/i2c-algo-bit.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/i2c-algo-pca.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/i2c-algo-pcf.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/i2c-algo-sgi.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/i2c-gpio.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/i2c-id.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/i2c-ocores.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/i2c-pca-platform.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/i2c-pnx.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/i2c-pxa.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/i2c/at24.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/i2c/max732x.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/i2c/pca953x.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/i2c/pcf857x.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/i2c/tps65010.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/i2o.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/i8042.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/ibmtr.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/ide.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/idr.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/ieee80211.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/if_ec.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/if_macvlan.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/if_strip.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/if_tr.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/ihex.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/inet.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/inet_lro.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/inetdevice.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/init.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/init_ohci1394_dma.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/init_task.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/initrd.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/input-polldev.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/interrupt.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/io.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/ioc3.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/ioc4.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/iocontext.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/iommu-helper.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/ioport.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/ioprio.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/ipc_namespace.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/ipmi_smi.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/irq.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/irq_cpustat.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/irqflags.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/irqreturn.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/isa.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/isapnp.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/iscsi_ibft.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/isdn/Kbuild delete mode 100644 l4/pkg/linux-26-headers/include/linux/isdn/capilli.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/isdn/capiutil.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/isicom.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/istallion.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/jbd.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/jbd2.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/jhash.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/jiffies.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/journal-head.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/kallsyms.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/kbd_diacr.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/kbd_kern.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/kbuild.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/kdebug.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/kernel_stat.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/key-type.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/key-ui.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/key.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/kfifo.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/kgdb.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/klist.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/kmalloc_sizes.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/kmod.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/kobj_map.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/kobject.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/kprobes.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/kref.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/ks0108.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/kthread.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/ktime.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/kvm_host.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/kvm_types.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/lapb.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/latencytop.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/lcd.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/leds-pca9532.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/leds.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/lguest.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/lguest_launcher.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/libata.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/libps2.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/license.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/linkage.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/linux_logo.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/list.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/lm_interface.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/lmb.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/lockd/bind.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/lockd/debug.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/lockd/lockd.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/lockd/nlm.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/lockd/share.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/lockd/sm_inter.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/lockd/xdr.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/lockd/xdr4.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/lockdep.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/log2.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/lzo.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/m48t86.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mISDNdsp.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mISDNhw.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mISDNif.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/maple.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/marker.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/math64.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mbcache.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mbus.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mc146818rtc.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mc6821.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mca-legacy.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mca.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mdio-bitbang.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/memcontrol.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/memory.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/memory_hotplug.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mempool.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/memstick.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mfd/asic3.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mfd/core.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mfd/htc-egpio.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mfd/htc-pasic3.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mfd/t7l66xb.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mfd/tc6387xb.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mfd/tc6393xb.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mfd/tmio.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/migrate.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/miscdevice.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mlx4/cmd.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mlx4/cq.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mlx4/device.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mlx4/doorbell.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mlx4/driver.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mlx4/qp.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mlx4/srq.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mm.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mm_inline.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mm_types.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mmc/card.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mmc/core.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mmc/host.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mmc/mmc.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mmc/sd.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mmc/sdio.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mmc/sdio_func.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mmc/sdio_ids.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mmiotrace.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mmu_notifier.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mmzone.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mnt_namespace.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mod_devicetable.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/module.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/moduleloader.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/moduleparam.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mount.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mpage.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/msi.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mtd/bbm.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mtd/blktrans.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mtd/cfi.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mtd/cfi_endian.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mtd/compatmac.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mtd/concat.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mtd/doc2000.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mtd/flashchip.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mtd/ftl.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mtd/gen_probe.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mtd/inftl.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mtd/map.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mtd/mtd.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mtd/mtdram.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mtd/nand.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mtd/nand_ecc.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mtd/ndfc.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mtd/nftl.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mtd/onenand.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mtd/onenand_regs.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mtd/partitions.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mtd/physmap.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mtd/plat-ram.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mtd/pmc551.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mtd/super.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mtd/ubi.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mtd/xip.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mutex-debug.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mutex.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mv643xx.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mv643xx_eth.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/mv643xx_i2c.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/namei.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/ncp_fs_i.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/ncp_fs_sb.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/netfilter/Kbuild delete mode 100644 l4/pkg/linux-26-headers/include/linux/netfilter/nf_conntrack_amanda.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/netfilter/nf_conntrack_dccp.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/netfilter/nf_conntrack_h323.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/netfilter/nf_conntrack_h323_asn1.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/netfilter/nf_conntrack_h323_types.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/netfilter/nf_conntrack_irc.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/netfilter/nf_conntrack_pptp.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/netfilter/nf_conntrack_proto_gre.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/netfilter/nf_conntrack_sane.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/netfilter/nf_conntrack_sip.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/netfilter/nf_conntrack_tftp.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/netfilter_arp/Kbuild delete mode 100644 l4/pkg/linux-26-headers/include/linux/netfilter_bridge/Kbuild delete mode 100644 l4/pkg/linux-26-headers/include/linux/netfilter_ipv4/Kbuild delete mode 100644 l4/pkg/linux-26-headers/include/linux/netfilter_ipv4/ip_queue.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/netfilter_ipv4/ipt_CLASSIFY.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/netfilter_ipv4/ipt_CONNMARK.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/netfilter_ipv4/ipt_DSCP.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/netfilter_ipv4/ipt_MARK.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/netfilter_ipv4/ipt_NFQUEUE.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/netfilter_ipv4/ipt_SAME.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/netfilter_ipv4/ipt_TCPMSS.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/netfilter_ipv4/ipt_TOS.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/netfilter_ipv4/ipt_addrtype.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/netfilter_ipv4/ipt_comment.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/netfilter_ipv4/ipt_connbytes.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/netfilter_ipv4/ipt_connmark.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/netfilter_ipv4/ipt_conntrack.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/netfilter_ipv4/ipt_dccp.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/netfilter_ipv4/ipt_dscp.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/netfilter_ipv4/ipt_esp.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/netfilter_ipv4/ipt_hashlimit.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/netfilter_ipv4/ipt_helper.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/netfilter_ipv4/ipt_iprange.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/netfilter_ipv4/ipt_length.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/netfilter_ipv4/ipt_limit.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/netfilter_ipv4/ipt_mac.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/netfilter_ipv4/ipt_mark.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/netfilter_ipv4/ipt_multiport.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/netfilter_ipv4/ipt_owner.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/netfilter_ipv4/ipt_physdev.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/netfilter_ipv4/ipt_pkttype.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/netfilter_ipv4/ipt_policy.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/netfilter_ipv4/ipt_realm.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/netfilter_ipv4/ipt_recent.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/netfilter_ipv4/ipt_sctp.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/netfilter_ipv4/ipt_state.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/netfilter_ipv4/ipt_string.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/netfilter_ipv4/ipt_tcpmss.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/netfilter_ipv4/ipt_tos.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/netfilter_ipv6/Kbuild delete mode 100644 l4/pkg/linux-26-headers/include/linux/netfilter_ipv6/ip6t_MARK.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/netfilter_ipv6/ip6t_esp.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/netfilter_ipv6/ip6t_length.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/netfilter_ipv6/ip6t_limit.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/netfilter_ipv6/ip6t_mac.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/netfilter_ipv6/ip6t_mark.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/netfilter_ipv6/ip6t_multiport.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/netfilter_ipv6/ip6t_owner.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/netfilter_ipv6/ip6t_physdev.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/netfilter_ipv6/ip6t_policy.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/netpoll.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/nfs4_acl.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/nfs_fs_i.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/nfs_fs_sb.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/nfs_iostat.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/nfs_page.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/nfs_xdr.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/nfsd/Kbuild delete mode 100644 l4/pkg/linux-26-headers/include/linux/nfsd/cache.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/nfsd/const.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/nfsd/nfsd.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/nfsd/state.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/nfsd/syscall.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/nfsd/xdr.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/nfsd/xdr3.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/nfsd/xdr4.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/nfsd_idmap.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/nls.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/nmi.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/node.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/nodemask.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/notifier.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/nsc_gpio.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/nsproxy.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/numa.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/of.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/of_device.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/of_gpio.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/of_i2c.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/of_platform.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/of_spi.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/oprofile.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/page-flags.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/page-isolation.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/pageblock-flags.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/pagemap.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/pagevec.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/parport_pc.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/parser.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/path.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/pci-acpi.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/pci-aspm.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/pci_hotplug.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/pci_ids.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/pcieport_if.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/pda_power.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/percpu.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/percpu_counter.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/pfn.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/phonedev.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/phy.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/phy_fixed.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/pid.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/pid_namespace.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/pim.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/pipe_fs_i.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/platform_device.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/plist.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/pm.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/pm_qos_params.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/pm_wakeup.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/pnp.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/poison.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/posix-timers.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/posix_acl.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/posix_acl_xattr.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/power_supply.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/ppp_channel.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/preempt.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/prefetch.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/prio_heap.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/prio_tree.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/proc_fs.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/profile.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/proportions.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/pwm.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/pwm_backlight.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/quicklist.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/quotaio_v1.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/quotaio_v2.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/quotaops.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/radix-tree.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/raid/Kbuild delete mode 100644 l4/pkg/linux-26-headers/include/linux/raid/bitmap.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/raid/linear.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/raid/md.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/raid/md_k.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/raid/multipath.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/raid/raid0.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/raid/raid1.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/raid/raid10.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/raid/raid5.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/raid/xor.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/raid_class.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/ramfs.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/ratelimit.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/rbtree.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/rcuclassic.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/rculist.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/rcupdate.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/rcupreempt.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/rcupreempt_trace.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/reciprocal_div.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/regset.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/regulator/bq24022.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/regulator/consumer.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/regulator/driver.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/regulator/fixed.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/regulator/machine.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/reiserfs_acl.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/reiserfs_fs_i.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/reiserfs_fs_sb.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/relay.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/res_counter.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/resume-trace.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/rio.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/rio_drv.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/rio_ids.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/rio_regs.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/rmap.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/root_dev.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/rslib.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/rtc-v3020.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/rtc/m48t59.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/rtmutex.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/rwsem-spinlock.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/rwsem.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/rxrpc.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/sc26198.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/scatterlist.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/sctp.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/scx200.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/scx200_gpio.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/security.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/selection.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/selinux.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/semaphore.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/seq_file.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/seq_file_net.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/seqlock.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/serial167.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/serialP.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/serial_8250.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/serial_pnx8xxx.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/serial_sci.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/shmem_fs.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/skbuff.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/slab.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/slab_def.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/slob_def.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/slub_def.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/sm501-regs.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/sm501.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/smb.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/smb_fs.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/smb_fs_i.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/smb_fs_sb.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/smb_mount.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/smbno.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/smc911x.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/smc91x.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/smp.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/smp_lock.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/sony-laptop.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/sort.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/spi/Kbuild delete mode 100644 l4/pkg/linux-26-headers/include/linux/spi/ad7877.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/spi/ads7846.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/spi/at73c213.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/spi/ds1305.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/spi/eeprom.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/spi/flash.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/spi/max7301.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/spi/mcp23s08.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/spi/mmc_spi.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/spi/orion_spi.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/spi/spi.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/spi/spi_bitbang.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/spi/tle62x0.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/spinlock.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/spinlock_api_smp.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/spinlock_api_up.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/spinlock_types.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/spinlock_types_up.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/spinlock_up.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/splice.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/srcu.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/ssb/ssb.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/ssb/ssb_driver_chipcommon.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/ssb/ssb_driver_extif.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/ssb/ssb_driver_gige.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/ssb/ssb_driver_mips.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/ssb/ssb_driver_pci.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/ssb/ssb_embedded.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/ssb/ssb_regs.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/stacktrace.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/stallion.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/start_kernel.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/statfs.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/stop_machine.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/stringify.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/sunrpc/Kbuild delete mode 100644 l4/pkg/linux-26-headers/include/linux/sunrpc/auth.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/sunrpc/auth_gss.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/sunrpc/cache.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/sunrpc/clnt.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/sunrpc/gss_api.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/sunrpc/gss_asn1.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/sunrpc/gss_err.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/sunrpc/gss_krb5.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/sunrpc/gss_spkm3.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/sunrpc/metrics.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/sunrpc/msg_prot.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/sunrpc/rpc_pipe_fs.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/sunrpc/rpc_rdma.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/sunrpc/sched.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/sunrpc/stats.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/sunrpc/svc.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/sunrpc/svc_rdma.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/sunrpc/svc_xprt.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/sunrpc/svcauth.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/sunrpc/svcauth_gss.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/sunrpc/svcsock.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/sunrpc/timer.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/sunrpc/types.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/sunrpc/xdr.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/sunrpc/xprt.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/sunrpc/xprtrdma.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/sunrpc/xprtsock.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/superhyway.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/suspend.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/svga.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/swap.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/swapops.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/sys.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/syscalls.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/sysdev.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/sysfs.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/sysrq.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/sysv_fs.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/task_io_accounting.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/task_io_accounting_ops.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/taskstats_kern.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/tc.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/tc_act/Kbuild delete mode 100644 l4/pkg/linux-26-headers/include/linux/tc_act/tc_defact.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/tc_ematch/Kbuild delete mode 100644 l4/pkg/linux-26-headers/include/linux/textsearch.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/textsearch_fsm.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/tfrc.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/thermal.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/thread_info.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/threads.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/tick.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/tifm.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/timer.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/timerfd.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/topology.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/tracehook.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/transport_class.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/trdevice.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/tsacct_kern.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/tty_driver.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/tty_flip.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/tty_ldisc.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/typecheck.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/uaccess.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/uio_driver.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/unaligned/access_ok.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/unaligned/be_byteshift.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/unaligned/be_memmove.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/unaligned/be_struct.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/unaligned/generic.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/unaligned/le_byteshift.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/unaligned/le_memmove.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/unaligned/le_struct.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/unaligned/memmove.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/unaligned/packed_struct.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/unwind.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/usb.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/usb/Kbuild delete mode 100644 l4/pkg/linux-26-headers/include/linux/usb/association.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/usb/atmel_usba_udc.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/usb/c67x00.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/usb/composite.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/usb/gadget.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/usb/input.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/usb/iowarrior.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/usb/irda.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/usb/isp116x.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/usb/musb.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/usb/net2280.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/usb/otg.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/usb/quirks.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/usb/rndis_host.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/usb/serial.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/usb/sl811.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/usb/usbnet.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/usb_usual.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/user.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/user_namespace.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/uts.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/utsrelease.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/vermagic.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/vfs.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/via.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/video_decoder.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/video_encoder.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/video_output.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/videodev.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/videotext.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/virtio.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/vmalloc.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/vmstat.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/vt_buffer.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/vt_kern.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/w1-gpio.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/wm97xx.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/workqueue.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/writeback.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/xilinxfb.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/yam.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/zconf.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/zlib.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/zorro.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/zorro_ids.h delete mode 100644 l4/pkg/linux-26-headers/include/linux/zutil.h delete mode 100644 l4/pkg/linux-26-headers/include/math-emu/double.h delete mode 100644 l4/pkg/linux-26-headers/include/math-emu/op-1.h delete mode 100644 l4/pkg/linux-26-headers/include/math-emu/op-2.h delete mode 100644 l4/pkg/linux-26-headers/include/math-emu/op-4.h delete mode 100644 l4/pkg/linux-26-headers/include/math-emu/op-8.h delete mode 100644 l4/pkg/linux-26-headers/include/math-emu/op-common.h delete mode 100644 l4/pkg/linux-26-headers/include/math-emu/quad.h delete mode 100644 l4/pkg/linux-26-headers/include/math-emu/single.h delete mode 100644 l4/pkg/linux-26-headers/include/math-emu/soft-fp.h delete mode 100644 l4/pkg/linux-26-headers/include/media/cs5345.h delete mode 100644 l4/pkg/linux-26-headers/include/media/cs53l32a.h delete mode 100644 l4/pkg/linux-26-headers/include/media/cx2341x.h delete mode 100644 l4/pkg/linux-26-headers/include/media/cx25840.h delete mode 100644 l4/pkg/linux-26-headers/include/media/i2c-addr.h delete mode 100644 l4/pkg/linux-26-headers/include/media/ir-common.h delete mode 100644 l4/pkg/linux-26-headers/include/media/ir-kbd-i2c.h delete mode 100644 l4/pkg/linux-26-headers/include/media/m52790.h delete mode 100644 l4/pkg/linux-26-headers/include/media/msp3400.h delete mode 100644 l4/pkg/linux-26-headers/include/media/ovcamchip.h delete mode 100644 l4/pkg/linux-26-headers/include/media/pwc-ioctl.h delete mode 100644 l4/pkg/linux-26-headers/include/media/rds.h delete mode 100644 l4/pkg/linux-26-headers/include/media/saa6752hs.h delete mode 100644 l4/pkg/linux-26-headers/include/media/saa7115.h delete mode 100644 l4/pkg/linux-26-headers/include/media/saa7127.h delete mode 100644 l4/pkg/linux-26-headers/include/media/saa7146.h delete mode 100644 l4/pkg/linux-26-headers/include/media/saa7146_vv.h delete mode 100644 l4/pkg/linux-26-headers/include/media/sh_mobile_ceu.h delete mode 100644 l4/pkg/linux-26-headers/include/media/soc_camera.h delete mode 100644 l4/pkg/linux-26-headers/include/media/soc_camera_platform.h delete mode 100644 l4/pkg/linux-26-headers/include/media/tuner-types.h delete mode 100644 l4/pkg/linux-26-headers/include/media/tuner.h delete mode 100644 l4/pkg/linux-26-headers/include/media/tvaudio.h delete mode 100644 l4/pkg/linux-26-headers/include/media/tveeprom.h delete mode 100644 l4/pkg/linux-26-headers/include/media/tvp5150.h delete mode 100644 l4/pkg/linux-26-headers/include/media/upd64031a.h delete mode 100644 l4/pkg/linux-26-headers/include/media/upd64083.h delete mode 100644 l4/pkg/linux-26-headers/include/media/v4l2-chip-ident.h delete mode 100644 l4/pkg/linux-26-headers/include/media/v4l2-common.h delete mode 100644 l4/pkg/linux-26-headers/include/media/v4l2-dev.h delete mode 100644 l4/pkg/linux-26-headers/include/media/v4l2-i2c-drv-legacy.h delete mode 100644 l4/pkg/linux-26-headers/include/media/v4l2-i2c-drv.h delete mode 100644 l4/pkg/linux-26-headers/include/media/v4l2-int-device.h delete mode 100644 l4/pkg/linux-26-headers/include/media/v4l2-ioctl.h delete mode 100644 l4/pkg/linux-26-headers/include/media/videobuf-core.h delete mode 100644 l4/pkg/linux-26-headers/include/media/videobuf-dma-contig.h delete mode 100644 l4/pkg/linux-26-headers/include/media/videobuf-dma-sg.h delete mode 100644 l4/pkg/linux-26-headers/include/media/videobuf-dvb.h delete mode 100644 l4/pkg/linux-26-headers/include/media/videobuf-vmalloc.h delete mode 100644 l4/pkg/linux-26-headers/include/media/wm8775.h delete mode 100644 l4/pkg/linux-26-headers/include/mtd/Kbuild delete mode 100644 l4/pkg/linux-26-headers/include/mtd/jffs2-user.h delete mode 100644 l4/pkg/linux-26-headers/include/net/9p/9p.h delete mode 100644 l4/pkg/linux-26-headers/include/net/9p/client.h delete mode 100644 l4/pkg/linux-26-headers/include/net/9p/transport.h delete mode 100644 l4/pkg/linux-26-headers/include/net/act_api.h delete mode 100644 l4/pkg/linux-26-headers/include/net/addrconf.h delete mode 100644 l4/pkg/linux-26-headers/include/net/af_rxrpc.h delete mode 100644 l4/pkg/linux-26-headers/include/net/af_unix.h delete mode 100644 l4/pkg/linux-26-headers/include/net/ah.h delete mode 100644 l4/pkg/linux-26-headers/include/net/arp.h delete mode 100644 l4/pkg/linux-26-headers/include/net/atmclip.h delete mode 100644 l4/pkg/linux-26-headers/include/net/ax25.h delete mode 100644 l4/pkg/linux-26-headers/include/net/ax88796.h delete mode 100644 l4/pkg/linux-26-headers/include/net/bluetooth/bluetooth.h delete mode 100644 l4/pkg/linux-26-headers/include/net/bluetooth/hci.h delete mode 100644 l4/pkg/linux-26-headers/include/net/bluetooth/hci_core.h delete mode 100644 l4/pkg/linux-26-headers/include/net/bluetooth/l2cap.h delete mode 100644 l4/pkg/linux-26-headers/include/net/bluetooth/rfcomm.h delete mode 100644 l4/pkg/linux-26-headers/include/net/bluetooth/sco.h delete mode 100644 l4/pkg/linux-26-headers/include/net/cfg80211.h delete mode 100644 l4/pkg/linux-26-headers/include/net/checksum.h delete mode 100644 l4/pkg/linux-26-headers/include/net/cipso_ipv4.h delete mode 100644 l4/pkg/linux-26-headers/include/net/compat.h delete mode 100644 l4/pkg/linux-26-headers/include/net/datalink.h delete mode 100644 l4/pkg/linux-26-headers/include/net/dn.h delete mode 100644 l4/pkg/linux-26-headers/include/net/dn_dev.h delete mode 100644 l4/pkg/linux-26-headers/include/net/dn_fib.h delete mode 100644 l4/pkg/linux-26-headers/include/net/dn_neigh.h delete mode 100644 l4/pkg/linux-26-headers/include/net/dn_nsp.h delete mode 100644 l4/pkg/linux-26-headers/include/net/dn_route.h delete mode 100644 l4/pkg/linux-26-headers/include/net/dsfield.h delete mode 100644 l4/pkg/linux-26-headers/include/net/dst.h delete mode 100644 l4/pkg/linux-26-headers/include/net/esp.h delete mode 100644 l4/pkg/linux-26-headers/include/net/fib_rules.h delete mode 100644 l4/pkg/linux-26-headers/include/net/flow.h delete mode 100644 l4/pkg/linux-26-headers/include/net/garp.h delete mode 100644 l4/pkg/linux-26-headers/include/net/gen_stats.h delete mode 100644 l4/pkg/linux-26-headers/include/net/genetlink.h delete mode 100644 l4/pkg/linux-26-headers/include/net/icmp.h delete mode 100644 l4/pkg/linux-26-headers/include/net/ieee80211.h delete mode 100644 l4/pkg/linux-26-headers/include/net/ieee80211_crypt.h delete mode 100644 l4/pkg/linux-26-headers/include/net/ieee80211_radiotap.h delete mode 100644 l4/pkg/linux-26-headers/include/net/if_inet6.h delete mode 100644 l4/pkg/linux-26-headers/include/net/inet6_connection_sock.h delete mode 100644 l4/pkg/linux-26-headers/include/net/inet6_hashtables.h delete mode 100644 l4/pkg/linux-26-headers/include/net/inet_common.h delete mode 100644 l4/pkg/linux-26-headers/include/net/inet_connection_sock.h delete mode 100644 l4/pkg/linux-26-headers/include/net/inet_ecn.h delete mode 100644 l4/pkg/linux-26-headers/include/net/inet_frag.h delete mode 100644 l4/pkg/linux-26-headers/include/net/inet_hashtables.h delete mode 100644 l4/pkg/linux-26-headers/include/net/inet_sock.h delete mode 100644 l4/pkg/linux-26-headers/include/net/inet_timewait_sock.h delete mode 100644 l4/pkg/linux-26-headers/include/net/inetpeer.h delete mode 100644 l4/pkg/linux-26-headers/include/net/ip.h delete mode 100644 l4/pkg/linux-26-headers/include/net/ip6_checksum.h delete mode 100644 l4/pkg/linux-26-headers/include/net/ip6_fib.h delete mode 100644 l4/pkg/linux-26-headers/include/net/ip6_route.h delete mode 100644 l4/pkg/linux-26-headers/include/net/ip6_tunnel.h delete mode 100644 l4/pkg/linux-26-headers/include/net/ip_fib.h delete mode 100644 l4/pkg/linux-26-headers/include/net/ip_vs.h delete mode 100644 l4/pkg/linux-26-headers/include/net/ipcomp.h delete mode 100644 l4/pkg/linux-26-headers/include/net/ipconfig.h delete mode 100644 l4/pkg/linux-26-headers/include/net/ipip.h delete mode 100644 l4/pkg/linux-26-headers/include/net/ipv6.h delete mode 100644 l4/pkg/linux-26-headers/include/net/ipx.h delete mode 100644 l4/pkg/linux-26-headers/include/net/irda/af_irda.h delete mode 100644 l4/pkg/linux-26-headers/include/net/irda/crc.h delete mode 100644 l4/pkg/linux-26-headers/include/net/irda/discovery.h delete mode 100644 l4/pkg/linux-26-headers/include/net/irda/ircomm_core.h delete mode 100644 l4/pkg/linux-26-headers/include/net/irda/ircomm_event.h delete mode 100644 l4/pkg/linux-26-headers/include/net/irda/ircomm_lmp.h delete mode 100644 l4/pkg/linux-26-headers/include/net/irda/ircomm_param.h delete mode 100644 l4/pkg/linux-26-headers/include/net/irda/ircomm_ttp.h delete mode 100644 l4/pkg/linux-26-headers/include/net/irda/ircomm_tty.h delete mode 100644 l4/pkg/linux-26-headers/include/net/irda/ircomm_tty_attach.h delete mode 100644 l4/pkg/linux-26-headers/include/net/irda/irda.h delete mode 100644 l4/pkg/linux-26-headers/include/net/irda/irda_device.h delete mode 100644 l4/pkg/linux-26-headers/include/net/irda/iriap.h delete mode 100644 l4/pkg/linux-26-headers/include/net/irda/iriap_event.h delete mode 100644 l4/pkg/linux-26-headers/include/net/irda/irias_object.h delete mode 100644 l4/pkg/linux-26-headers/include/net/irda/irlan_client.h delete mode 100644 l4/pkg/linux-26-headers/include/net/irda/irlan_common.h delete mode 100644 l4/pkg/linux-26-headers/include/net/irda/irlan_eth.h delete mode 100644 l4/pkg/linux-26-headers/include/net/irda/irlan_event.h delete mode 100644 l4/pkg/linux-26-headers/include/net/irda/irlan_filter.h delete mode 100644 l4/pkg/linux-26-headers/include/net/irda/irlan_provider.h delete mode 100644 l4/pkg/linux-26-headers/include/net/irda/irlap.h delete mode 100644 l4/pkg/linux-26-headers/include/net/irda/irlap_event.h delete mode 100644 l4/pkg/linux-26-headers/include/net/irda/irlap_frame.h delete mode 100644 l4/pkg/linux-26-headers/include/net/irda/irlmp.h delete mode 100644 l4/pkg/linux-26-headers/include/net/irda/irlmp_event.h delete mode 100644 l4/pkg/linux-26-headers/include/net/irda/irlmp_frame.h delete mode 100644 l4/pkg/linux-26-headers/include/net/irda/irmod.h delete mode 100644 l4/pkg/linux-26-headers/include/net/irda/irqueue.h delete mode 100644 l4/pkg/linux-26-headers/include/net/irda/irttp.h delete mode 100644 l4/pkg/linux-26-headers/include/net/irda/parameters.h delete mode 100644 l4/pkg/linux-26-headers/include/net/irda/qos.h delete mode 100644 l4/pkg/linux-26-headers/include/net/irda/timer.h delete mode 100644 l4/pkg/linux-26-headers/include/net/irda/wrapper.h delete mode 100644 l4/pkg/linux-26-headers/include/net/iucv/af_iucv.h delete mode 100644 l4/pkg/linux-26-headers/include/net/iucv/iucv.h delete mode 100644 l4/pkg/linux-26-headers/include/net/iw_handler.h delete mode 100644 l4/pkg/linux-26-headers/include/net/lapb.h delete mode 100644 l4/pkg/linux-26-headers/include/net/llc.h delete mode 100644 l4/pkg/linux-26-headers/include/net/llc_c_ac.h delete mode 100644 l4/pkg/linux-26-headers/include/net/llc_c_ev.h delete mode 100644 l4/pkg/linux-26-headers/include/net/llc_c_st.h delete mode 100644 l4/pkg/linux-26-headers/include/net/llc_conn.h delete mode 100644 l4/pkg/linux-26-headers/include/net/llc_if.h delete mode 100644 l4/pkg/linux-26-headers/include/net/llc_pdu.h delete mode 100644 l4/pkg/linux-26-headers/include/net/llc_s_ac.h delete mode 100644 l4/pkg/linux-26-headers/include/net/llc_s_ev.h delete mode 100644 l4/pkg/linux-26-headers/include/net/llc_s_st.h delete mode 100644 l4/pkg/linux-26-headers/include/net/llc_sap.h delete mode 100644 l4/pkg/linux-26-headers/include/net/mac80211.h delete mode 100644 l4/pkg/linux-26-headers/include/net/mip6.h delete mode 100644 l4/pkg/linux-26-headers/include/net/ndisc.h delete mode 100644 l4/pkg/linux-26-headers/include/net/neighbour.h delete mode 100644 l4/pkg/linux-26-headers/include/net/net_namespace.h delete mode 100644 l4/pkg/linux-26-headers/include/net/netdma.h delete mode 100644 l4/pkg/linux-26-headers/include/net/netevent.h delete mode 100644 l4/pkg/linux-26-headers/include/net/netfilter/ipv4/nf_conntrack_icmp.h delete mode 100644 l4/pkg/linux-26-headers/include/net/netfilter/ipv4/nf_conntrack_ipv4.h delete mode 100644 l4/pkg/linux-26-headers/include/net/netfilter/ipv6/nf_conntrack_icmpv6.h delete mode 100644 l4/pkg/linux-26-headers/include/net/netfilter/ipv6/nf_conntrack_ipv6.h delete mode 100644 l4/pkg/linux-26-headers/include/net/netfilter/nf_conntrack.h delete mode 100644 l4/pkg/linux-26-headers/include/net/netfilter/nf_conntrack_acct.h delete mode 100644 l4/pkg/linux-26-headers/include/net/netfilter/nf_conntrack_core.h delete mode 100644 l4/pkg/linux-26-headers/include/net/netfilter/nf_conntrack_ecache.h delete mode 100644 l4/pkg/linux-26-headers/include/net/netfilter/nf_conntrack_expect.h delete mode 100644 l4/pkg/linux-26-headers/include/net/netfilter/nf_conntrack_extend.h delete mode 100644 l4/pkg/linux-26-headers/include/net/netfilter/nf_conntrack_helper.h delete mode 100644 l4/pkg/linux-26-headers/include/net/netfilter/nf_conntrack_l3proto.h delete mode 100644 l4/pkg/linux-26-headers/include/net/netfilter/nf_conntrack_l4proto.h delete mode 100644 l4/pkg/linux-26-headers/include/net/netfilter/nf_conntrack_tuple.h delete mode 100644 l4/pkg/linux-26-headers/include/net/netfilter/nf_log.h delete mode 100644 l4/pkg/linux-26-headers/include/net/netfilter/nf_nat.h delete mode 100644 l4/pkg/linux-26-headers/include/net/netfilter/nf_nat_core.h delete mode 100644 l4/pkg/linux-26-headers/include/net/netfilter/nf_nat_helper.h delete mode 100644 l4/pkg/linux-26-headers/include/net/netfilter/nf_nat_protocol.h delete mode 100644 l4/pkg/linux-26-headers/include/net/netfilter/nf_nat_rule.h delete mode 100644 l4/pkg/linux-26-headers/include/net/netfilter/nf_queue.h delete mode 100644 l4/pkg/linux-26-headers/include/net/netfilter/xt_rateest.h delete mode 100644 l4/pkg/linux-26-headers/include/net/netlabel.h delete mode 100644 l4/pkg/linux-26-headers/include/net/netlink.h delete mode 100644 l4/pkg/linux-26-headers/include/net/netns/core.h delete mode 100644 l4/pkg/linux-26-headers/include/net/netns/dccp.h delete mode 100644 l4/pkg/linux-26-headers/include/net/netns/generic.h delete mode 100644 l4/pkg/linux-26-headers/include/net/netns/hash.h delete mode 100644 l4/pkg/linux-26-headers/include/net/netns/ipv4.h delete mode 100644 l4/pkg/linux-26-headers/include/net/netns/ipv6.h delete mode 100644 l4/pkg/linux-26-headers/include/net/netns/mib.h delete mode 100644 l4/pkg/linux-26-headers/include/net/netns/packet.h delete mode 100644 l4/pkg/linux-26-headers/include/net/netns/unix.h delete mode 100644 l4/pkg/linux-26-headers/include/net/netns/x_tables.h delete mode 100644 l4/pkg/linux-26-headers/include/net/netrom.h delete mode 100644 l4/pkg/linux-26-headers/include/net/nexthop.h delete mode 100644 l4/pkg/linux-26-headers/include/net/p8022.h delete mode 100644 l4/pkg/linux-26-headers/include/net/pkt_cls.h delete mode 100644 l4/pkg/linux-26-headers/include/net/pkt_sched.h delete mode 100644 l4/pkg/linux-26-headers/include/net/protocol.h delete mode 100644 l4/pkg/linux-26-headers/include/net/psnap.h delete mode 100644 l4/pkg/linux-26-headers/include/net/raw.h delete mode 100644 l4/pkg/linux-26-headers/include/net/rawv6.h delete mode 100644 l4/pkg/linux-26-headers/include/net/red.h delete mode 100644 l4/pkg/linux-26-headers/include/net/request_sock.h delete mode 100644 l4/pkg/linux-26-headers/include/net/rose.h delete mode 100644 l4/pkg/linux-26-headers/include/net/route.h delete mode 100644 l4/pkg/linux-26-headers/include/net/rtnetlink.h delete mode 100644 l4/pkg/linux-26-headers/include/net/sch_generic.h delete mode 100644 l4/pkg/linux-26-headers/include/net/scm.h delete mode 100644 l4/pkg/linux-26-headers/include/net/sctp/auth.h delete mode 100644 l4/pkg/linux-26-headers/include/net/sctp/checksum.h delete mode 100644 l4/pkg/linux-26-headers/include/net/sctp/command.h delete mode 100644 l4/pkg/linux-26-headers/include/net/sctp/constants.h delete mode 100644 l4/pkg/linux-26-headers/include/net/sctp/sctp.h delete mode 100644 l4/pkg/linux-26-headers/include/net/sctp/sm.h delete mode 100644 l4/pkg/linux-26-headers/include/net/sctp/structs.h delete mode 100644 l4/pkg/linux-26-headers/include/net/sctp/tsnmap.h delete mode 100644 l4/pkg/linux-26-headers/include/net/sctp/ulpevent.h delete mode 100644 l4/pkg/linux-26-headers/include/net/sctp/ulpqueue.h delete mode 100644 l4/pkg/linux-26-headers/include/net/sctp/user.h delete mode 100644 l4/pkg/linux-26-headers/include/net/slhc_vj.h delete mode 100644 l4/pkg/linux-26-headers/include/net/snmp.h delete mode 100644 l4/pkg/linux-26-headers/include/net/sock.h delete mode 100644 l4/pkg/linux-26-headers/include/net/stp.h delete mode 100644 l4/pkg/linux-26-headers/include/net/syncppp.h delete mode 100644 l4/pkg/linux-26-headers/include/net/tc_act/tc_defact.h delete mode 100644 l4/pkg/linux-26-headers/include/net/tc_act/tc_gact.h delete mode 100644 l4/pkg/linux-26-headers/include/net/tc_act/tc_ipt.h delete mode 100644 l4/pkg/linux-26-headers/include/net/tc_act/tc_mirred.h delete mode 100644 l4/pkg/linux-26-headers/include/net/tc_act/tc_nat.h delete mode 100644 l4/pkg/linux-26-headers/include/net/tc_act/tc_pedit.h delete mode 100644 l4/pkg/linux-26-headers/include/net/tcp.h delete mode 100644 l4/pkg/linux-26-headers/include/net/tcp_states.h delete mode 100644 l4/pkg/linux-26-headers/include/net/timewait_sock.h delete mode 100644 l4/pkg/linux-26-headers/include/net/tipc/tipc.h delete mode 100644 l4/pkg/linux-26-headers/include/net/tipc/tipc_bearer.h delete mode 100644 l4/pkg/linux-26-headers/include/net/tipc/tipc_msg.h delete mode 100644 l4/pkg/linux-26-headers/include/net/tipc/tipc_port.h delete mode 100644 l4/pkg/linux-26-headers/include/net/transp_v6.h delete mode 100644 l4/pkg/linux-26-headers/include/net/udp.h delete mode 100644 l4/pkg/linux-26-headers/include/net/udplite.h delete mode 100644 l4/pkg/linux-26-headers/include/net/wext.h delete mode 100644 l4/pkg/linux-26-headers/include/net/wireless.h delete mode 100644 l4/pkg/linux-26-headers/include/net/x25.h delete mode 100644 l4/pkg/linux-26-headers/include/net/x25device.h delete mode 100644 l4/pkg/linux-26-headers/include/net/xfrm.h delete mode 100644 l4/pkg/linux-26-headers/include/pcmcia/ciscode.h delete mode 100644 l4/pkg/linux-26-headers/include/pcmcia/cisreg.h delete mode 100644 l4/pkg/linux-26-headers/include/pcmcia/cistpl.h delete mode 100644 l4/pkg/linux-26-headers/include/pcmcia/cs.h delete mode 100644 l4/pkg/linux-26-headers/include/pcmcia/cs_types.h delete mode 100644 l4/pkg/linux-26-headers/include/pcmcia/device_id.h delete mode 100644 l4/pkg/linux-26-headers/include/pcmcia/ds.h delete mode 100644 l4/pkg/linux-26-headers/include/pcmcia/mem_op.h delete mode 100644 l4/pkg/linux-26-headers/include/pcmcia/ss.h delete mode 100644 l4/pkg/linux-26-headers/include/rdma/Kbuild delete mode 100644 l4/pkg/linux-26-headers/include/rdma/ib_addr.h delete mode 100644 l4/pkg/linux-26-headers/include/rdma/ib_cache.h delete mode 100644 l4/pkg/linux-26-headers/include/rdma/ib_cm.h delete mode 100644 l4/pkg/linux-26-headers/include/rdma/ib_fmr_pool.h delete mode 100644 l4/pkg/linux-26-headers/include/rdma/ib_mad.h delete mode 100644 l4/pkg/linux-26-headers/include/rdma/ib_marshall.h delete mode 100644 l4/pkg/linux-26-headers/include/rdma/ib_pack.h delete mode 100644 l4/pkg/linux-26-headers/include/rdma/ib_sa.h delete mode 100644 l4/pkg/linux-26-headers/include/rdma/ib_smi.h delete mode 100644 l4/pkg/linux-26-headers/include/rdma/ib_umem.h delete mode 100644 l4/pkg/linux-26-headers/include/rdma/ib_verbs.h delete mode 100644 l4/pkg/linux-26-headers/include/rdma/iw_cm.h delete mode 100644 l4/pkg/linux-26-headers/include/rdma/rdma_cm.h delete mode 100644 l4/pkg/linux-26-headers/include/rdma/rdma_cm_ib.h delete mode 100644 l4/pkg/linux-26-headers/include/rxrpc/packet.h delete mode 100644 l4/pkg/linux-26-headers/include/rxrpc/types.h delete mode 100644 l4/pkg/linux-26-headers/include/scsi/iscsi_if.h delete mode 100644 l4/pkg/linux-26-headers/include/scsi/iscsi_proto.h delete mode 100644 l4/pkg/linux-26-headers/include/scsi/libiscsi.h delete mode 100644 l4/pkg/linux-26-headers/include/scsi/libsas.h delete mode 100644 l4/pkg/linux-26-headers/include/scsi/libsrp.h delete mode 100644 l4/pkg/linux-26-headers/include/scsi/sas.h delete mode 100644 l4/pkg/linux-26-headers/include/scsi/sas_ata.h delete mode 100644 l4/pkg/linux-26-headers/include/scsi/scsi.h delete mode 100644 l4/pkg/linux-26-headers/include/scsi/scsi_cmnd.h delete mode 100644 l4/pkg/linux-26-headers/include/scsi/scsi_dbg.h delete mode 100644 l4/pkg/linux-26-headers/include/scsi/scsi_device.h delete mode 100644 l4/pkg/linux-26-headers/include/scsi/scsi_devinfo.h delete mode 100644 l4/pkg/linux-26-headers/include/scsi/scsi_dh.h delete mode 100644 l4/pkg/linux-26-headers/include/scsi/scsi_driver.h delete mode 100644 l4/pkg/linux-26-headers/include/scsi/scsi_eh.h delete mode 100644 l4/pkg/linux-26-headers/include/scsi/scsi_host.h delete mode 100644 l4/pkg/linux-26-headers/include/scsi/scsi_ioctl.h delete mode 100644 l4/pkg/linux-26-headers/include/scsi/scsi_tcq.h delete mode 100644 l4/pkg/linux-26-headers/include/scsi/scsi_tgt.h delete mode 100644 l4/pkg/linux-26-headers/include/scsi/scsi_tgt_if.h delete mode 100644 l4/pkg/linux-26-headers/include/scsi/scsi_transport.h delete mode 100644 l4/pkg/linux-26-headers/include/scsi/scsi_transport_fc.h delete mode 100644 l4/pkg/linux-26-headers/include/scsi/scsi_transport_iscsi.h delete mode 100644 l4/pkg/linux-26-headers/include/scsi/scsi_transport_sas.h delete mode 100644 l4/pkg/linux-26-headers/include/scsi/scsi_transport_spi.h delete mode 100644 l4/pkg/linux-26-headers/include/scsi/scsi_transport_srp.h delete mode 100644 l4/pkg/linux-26-headers/include/scsi/scsicam.h delete mode 100644 l4/pkg/linux-26-headers/include/scsi/sg.h delete mode 100644 l4/pkg/linux-26-headers/include/scsi/srp.h delete mode 100644 l4/pkg/linux-26-headers/include/sound/Kbuild delete mode 100644 l4/pkg/linux-26-headers/include/sound/ac97_codec.h delete mode 100644 l4/pkg/linux-26-headers/include/sound/ad1816a.h delete mode 100644 l4/pkg/linux-26-headers/include/sound/ad1843.h delete mode 100644 l4/pkg/linux-26-headers/include/sound/ad1848.h delete mode 100644 l4/pkg/linux-26-headers/include/sound/ak4114.h delete mode 100644 l4/pkg/linux-26-headers/include/sound/ak4117.h delete mode 100644 l4/pkg/linux-26-headers/include/sound/ak4531_codec.h delete mode 100644 l4/pkg/linux-26-headers/include/sound/ak4xxx-adda.h delete mode 100644 l4/pkg/linux-26-headers/include/sound/asoundef.h delete mode 100644 l4/pkg/linux-26-headers/include/sound/control.h delete mode 100644 l4/pkg/linux-26-headers/include/sound/core.h delete mode 100644 l4/pkg/linux-26-headers/include/sound/cs4231-regs.h delete mode 100644 l4/pkg/linux-26-headers/include/sound/cs4231.h delete mode 100644 l4/pkg/linux-26-headers/include/sound/cs46xx.h delete mode 100644 l4/pkg/linux-26-headers/include/sound/cs46xx_dsp_scb_types.h delete mode 100644 l4/pkg/linux-26-headers/include/sound/cs46xx_dsp_spos.h delete mode 100644 l4/pkg/linux-26-headers/include/sound/cs46xx_dsp_task_types.h delete mode 100644 l4/pkg/linux-26-headers/include/sound/cs8403.h delete mode 100644 l4/pkg/linux-26-headers/include/sound/cs8427.h delete mode 100644 l4/pkg/linux-26-headers/include/sound/driver.h delete mode 100644 l4/pkg/linux-26-headers/include/sound/emu10k1_synth.h delete mode 100644 l4/pkg/linux-26-headers/include/sound/emu8000.h delete mode 100644 l4/pkg/linux-26-headers/include/sound/emu8000_reg.h delete mode 100644 l4/pkg/linux-26-headers/include/sound/emux_legacy.h delete mode 100644 l4/pkg/linux-26-headers/include/sound/emux_synth.h delete mode 100644 l4/pkg/linux-26-headers/include/sound/es1688.h delete mode 100644 l4/pkg/linux-26-headers/include/sound/gus.h delete mode 100644 l4/pkg/linux-26-headers/include/sound/hda_hwdep.h delete mode 100644 l4/pkg/linux-26-headers/include/sound/hwdep.h delete mode 100644 l4/pkg/linux-26-headers/include/sound/i2c.h delete mode 100644 l4/pkg/linux-26-headers/include/sound/info.h delete mode 100644 l4/pkg/linux-26-headers/include/sound/initval.h delete mode 100644 l4/pkg/linux-26-headers/include/sound/memalloc.h delete mode 100644 l4/pkg/linux-26-headers/include/sound/minors.h delete mode 100644 l4/pkg/linux-26-headers/include/sound/mixer_oss.h delete mode 100644 l4/pkg/linux-26-headers/include/sound/mpu401.h delete mode 100644 l4/pkg/linux-26-headers/include/sound/opl3.h delete mode 100644 l4/pkg/linux-26-headers/include/sound/opl4.h delete mode 100644 l4/pkg/linux-26-headers/include/sound/pcm-indirect.h delete mode 100644 l4/pkg/linux-26-headers/include/sound/pcm.h delete mode 100644 l4/pkg/linux-26-headers/include/sound/pcm_oss.h delete mode 100644 l4/pkg/linux-26-headers/include/sound/pcm_params.h delete mode 100644 l4/pkg/linux-26-headers/include/sound/pt2258.h delete mode 100644 l4/pkg/linux-26-headers/include/sound/rawmidi.h delete mode 100644 l4/pkg/linux-26-headers/include/sound/sb.h delete mode 100644 l4/pkg/linux-26-headers/include/sound/seq_device.h delete mode 100644 l4/pkg/linux-26-headers/include/sound/seq_kernel.h delete mode 100644 l4/pkg/linux-26-headers/include/sound/seq_midi_emul.h delete mode 100644 l4/pkg/linux-26-headers/include/sound/seq_midi_event.h delete mode 100644 l4/pkg/linux-26-headers/include/sound/seq_oss.h delete mode 100644 l4/pkg/linux-26-headers/include/sound/seq_oss_legacy.h delete mode 100644 l4/pkg/linux-26-headers/include/sound/seq_virmidi.h delete mode 100644 l4/pkg/linux-26-headers/include/sound/snd_wavefront.h delete mode 100644 l4/pkg/linux-26-headers/include/sound/soc-dapm.h delete mode 100644 l4/pkg/linux-26-headers/include/sound/soc.h delete mode 100644 l4/pkg/linux-26-headers/include/sound/soundfont.h delete mode 100644 l4/pkg/linux-26-headers/include/sound/sscape_ioctl.h delete mode 100644 l4/pkg/linux-26-headers/include/sound/tea575x-tuner.h delete mode 100644 l4/pkg/linux-26-headers/include/sound/tea6330t.h delete mode 100644 l4/pkg/linux-26-headers/include/sound/timer.h delete mode 100644 l4/pkg/linux-26-headers/include/sound/tlv.h delete mode 100644 l4/pkg/linux-26-headers/include/sound/trident.h delete mode 100644 l4/pkg/linux-26-headers/include/sound/uda1341.h delete mode 100644 l4/pkg/linux-26-headers/include/sound/util_mem.h delete mode 100644 l4/pkg/linux-26-headers/include/sound/version.h delete mode 100644 l4/pkg/linux-26-headers/include/sound/vx_core.h delete mode 100644 l4/pkg/linux-26-headers/include/sound/wavefront.h delete mode 100644 l4/pkg/linux-26-headers/include/sound/ymfpci.h delete mode 100644 l4/pkg/linux-26-headers/include/video/Kbuild delete mode 100644 l4/pkg/linux-26-headers/include/video/atmel_lcdc.h delete mode 100644 l4/pkg/linux-26-headers/include/video/aty128.h delete mode 100644 l4/pkg/linux-26-headers/include/video/cirrus.h delete mode 100644 l4/pkg/linux-26-headers/include/video/cvisionppc.h delete mode 100644 l4/pkg/linux-26-headers/include/video/cyblafb.h delete mode 100644 l4/pkg/linux-26-headers/include/video/epson1355.h delete mode 100644 l4/pkg/linux-26-headers/include/video/gbe.h delete mode 100644 l4/pkg/linux-26-headers/include/video/hecubafb.h delete mode 100644 l4/pkg/linux-26-headers/include/video/iga.h delete mode 100644 l4/pkg/linux-26-headers/include/video/ili9320.h delete mode 100644 l4/pkg/linux-26-headers/include/video/kyro.h delete mode 100644 l4/pkg/linux-26-headers/include/video/mach64.h delete mode 100644 l4/pkg/linux-26-headers/include/video/maxinefb.h delete mode 100644 l4/pkg/linux-26-headers/include/video/mbxfb.h delete mode 100644 l4/pkg/linux-26-headers/include/video/metronomefb.h delete mode 100644 l4/pkg/linux-26-headers/include/video/neomagic.h delete mode 100644 l4/pkg/linux-26-headers/include/video/newport.h delete mode 100644 l4/pkg/linux-26-headers/include/video/permedia2.h delete mode 100644 l4/pkg/linux-26-headers/include/video/platform_lcd.h delete mode 100644 l4/pkg/linux-26-headers/include/video/pm3fb.h delete mode 100644 l4/pkg/linux-26-headers/include/video/pmag-ba-fb.h delete mode 100644 l4/pkg/linux-26-headers/include/video/pmagb-b-fb.h delete mode 100644 l4/pkg/linux-26-headers/include/video/radeon.h delete mode 100644 l4/pkg/linux-26-headers/include/video/s1d13xxxfb.h delete mode 100644 l4/pkg/linux-26-headers/include/video/sgivw.h delete mode 100644 l4/pkg/linux-26-headers/include/video/sstfb.h delete mode 100644 l4/pkg/linux-26-headers/include/video/tdfx.h delete mode 100644 l4/pkg/linux-26-headers/include/video/tgafb.h delete mode 100644 l4/pkg/linux-26-headers/include/video/trident.h delete mode 100644 l4/pkg/linux-26-headers/include/video/vga.h delete mode 100644 l4/pkg/linux-26-headers/include/video/w100fb.h delete mode 100644 l4/pkg/linux-26-headers/include/xen/balloon.h delete mode 100644 l4/pkg/linux-26-headers/include/xen/events.h delete mode 100644 l4/pkg/linux-26-headers/include/xen/features.h delete mode 100644 l4/pkg/linux-26-headers/include/xen/grant_table.h delete mode 100644 l4/pkg/linux-26-headers/include/xen/hvc-console.h delete mode 100644 l4/pkg/linux-26-headers/include/xen/interface/callback.h delete mode 100644 l4/pkg/linux-26-headers/include/xen/interface/elfnote.h delete mode 100644 l4/pkg/linux-26-headers/include/xen/interface/event_channel.h delete mode 100644 l4/pkg/linux-26-headers/include/xen/interface/features.h delete mode 100644 l4/pkg/linux-26-headers/include/xen/interface/grant_table.h delete mode 100644 l4/pkg/linux-26-headers/include/xen/interface/io/blkif.h delete mode 100644 l4/pkg/linux-26-headers/include/xen/interface/io/console.h delete mode 100644 l4/pkg/linux-26-headers/include/xen/interface/io/fbif.h delete mode 100644 l4/pkg/linux-26-headers/include/xen/interface/io/kbdif.h delete mode 100644 l4/pkg/linux-26-headers/include/xen/interface/io/netif.h delete mode 100644 l4/pkg/linux-26-headers/include/xen/interface/io/protocols.h delete mode 100644 l4/pkg/linux-26-headers/include/xen/interface/io/ring.h delete mode 100644 l4/pkg/linux-26-headers/include/xen/interface/io/xenbus.h delete mode 100644 l4/pkg/linux-26-headers/include/xen/interface/io/xs_wire.h delete mode 100644 l4/pkg/linux-26-headers/include/xen/interface/memory.h delete mode 100644 l4/pkg/linux-26-headers/include/xen/interface/physdev.h delete mode 100644 l4/pkg/linux-26-headers/include/xen/interface/sched.h delete mode 100644 l4/pkg/linux-26-headers/include/xen/interface/vcpu.h delete mode 100644 l4/pkg/linux-26-headers/include/xen/interface/version.h delete mode 100644 l4/pkg/linux-26-headers/include/xen/interface/xen.h delete mode 100644 l4/pkg/linux-26-headers/include/xen/interface/xencomm.h delete mode 100644 l4/pkg/linux-26-headers/include/xen/page.h delete mode 100644 l4/pkg/linux-26-headers/include/xen/xen-ops.h delete mode 100644 l4/pkg/linux-26-headers/include/xen/xenbus.h delete mode 100644 l4/pkg/linux-26-headers/include/xen/xencomm.h diff --git a/kernel/fiasco/src/kern/mp_lock.cpp b/kernel/fiasco/src/kern/mp_lock.cpp deleted file mode 100644 index 5d695c3b1..000000000 --- a/kernel/fiasco/src/kern/mp_lock.cpp +++ /dev/null @@ -1,182 +0,0 @@ -INTERFACE: - -#include "queue.h" - -class Mp_lock -{ -public: - enum Status { Not_locked, Locked, Invalid }; - -private: - /** queue of blocked threads */ - Queue _q; -}; - - -//---------------------------------------------------------------------------- -IMPLEMENTATION: - -#include "context.h" -#include "cpu_lock.h" -#include "globals.h" -#include "kdb_ke.h" -#include "lock_guard.h" -#include "thread_state.h" -//#include "logdefs.h" - -PUBLIC inline NEEDS["context.h", "cpu_lock.h", "globals.h", - "kdb_ke.h", "lock_guard.h", "thread_state.h"] -Mp_lock::Status -Mp_lock::test_and_set() -{ - //assert_kdb (cpu_lock.test()); - - Context *const c = current(); - - auto g = lock_guard(cpu_lock); - - { - auto guard = lock_guard(_q.q_lock()); - if (EXPECT_FALSE(_q.invalid())) - return Invalid; - - if (!_q.blocked()) - { - // lock was free, take it - _q.block(); - return Not_locked; - } - - _q.enqueue(c->queue_item()); - } - // LOG_MSG_3VAL(c, "block", (Mword)this, current_cpu(), *((Mword*)this)); - assert_kdb (!(c->state() & Thread_drq_ready)); - while (1) - { - c->state_change_dirty(~Thread_ready, Thread_waiting); - c->schedule(); - - if (!c->queue_item()->queued()) - break; - } - - c->state_del_dirty(Thread_waiting); - - // LOG_MSG_3VAL(c, "woke", (Mword)this, current_cpu(), 0); - - switch (c->queue_item()->status()) - { - case Queue_item::Ok: return Not_locked; - case Queue_item::Invalid: return Invalid; - case Queue_item::Retry: assert_kdb (false); - } - - return Invalid; -} - -PUBLIC inline NEEDS[Mp_lock::test_and_set] -Mp_lock::Status -Mp_lock::lock() -{ return test_and_set(); } - -PUBLIC inline NEEDS["context.h", "cpu_lock.h", "globals.h", - "kdb_ke.h", "lock_guard.h"] -void -Mp_lock::clear() -{ - //assert_kdb (cpu_lock.test()); - - Queue_item *f; - - { - auto guard = lock_guard(_q.q_lock()); - //LOG_MSG_3VAL(current(), "clear", (Mword)this, current_cpu(), *((Mword*)this)); - assert_kdb (_q.blocked()); - - f = _q.first(); - if (!f) - { - _q.unblock(); - return; - } - - _q.dequeue(f, Queue_item::Ok); - } - // LOG_MSG_3VAL(current(), "wake", Mword(context_of(f)), (Mword)this, current_cpu()); - assert_kdb (current()->state() & Thread_ready_mask); - context_of(f)->activate(); -} - -PUBLIC inline NEEDS["kdb_ke.h"] -void -Mp_lock::wait_free() -{ - - Context *const c = current(); - - auto g = lock_guard(cpu_lock); - - { - auto guard = lock_guard(_q.q_lock()); - assert_kdb (invalid()); - - if (!_q.blocked()) - return; - - _q.enqueue(c->queue_item()); - } - - while (1) - { - c->state_change_dirty(~Thread_ready, Thread_waiting); - c->schedule(); - - if (!c->queue_item()->queued()) - break; - } - - c->state_del_dirty(Thread_waiting); -} - -PUBLIC inline -bool -Mp_lock::test() const -{ return _q.blocked(); } - - -PUBLIC inline NEEDS[Mp_lock::clear] -void -Mp_lock::set(Status s) -{ - if (s == Not_locked) - clear(); -} - -PUBLIC -void -Mp_lock::invalidate() -{ - { - auto guard = lock_guard(_q.q_lock()); - _q.invalidate(); - } - - Queue_item *f; - while (1) - { - auto guard = lock_guard(_q.q_lock()); - f = _q.first(); - - //LOG_MSG_3VAL(current(), "deq", Mword(f), 0, 0); - if (!f) - break; - - _q.dequeue(f, Queue_item::Invalid); - context_of(f)->activate(); - } -} - -PUBLIC inline -bool -Mp_lock::invalid() const -{ return _q.invalid(); } diff --git a/kernel/fiasco/src/kern/obj_ref_ptr.cpp b/kernel/fiasco/src/kern/obj_ref_ptr.cpp deleted file mode 100644 index f72596a31..000000000 --- a/kernel/fiasco/src/kern/obj_ref_ptr.cpp +++ /dev/null @@ -1,44 +0,0 @@ -INTERFACE: - -class Ram_quota; - -template< typename T > -class Ref_ptr -{ -public: - class Inv_ptr; - Ref_ptr(Ref_ptr const &o) : _o(o._o) { inc_ref_cnt(); } - Ref_ptr(T *o = 0) : _o(o) { inc_ref_cnt(); } - ~Ref_ptr() { dec_ref_cnt(); } - - void operator = (Ref_ptr const &o) - { dec_ref_cnt(); _o = o._o; inc_ref_cnt(); } - - void operator = (T *o) - { dec_ref_cnt(); _o = o; inc_ref_cnt(); } - - T *operator -> () const { return _o; } - T *operator * () const { return _o; } - operator Inv_ptr const * () const - { return reinterpret_cast(_o); } - -private: - T *_o; - - void inc_ref_cnt() - { - if (_o) - { - auto guard = lock_guard(cpu_lock); - _o->inc_ref_cnt(); - } - } - - void dec_ref_cnt() const - { - if (_o && _o->dec_ref_cnt() == 0) - delete _o; - } - -}; - diff --git a/kernel/fiasco/src/kern/ref_ptr.cpp b/kernel/fiasco/src/kern/ref_ptr.cpp deleted file mode 100644 index f2c406dad..000000000 --- a/kernel/fiasco/src/kern/ref_ptr.cpp +++ /dev/null @@ -1,70 +0,0 @@ -INTERFACE: - -#include "kdb_ke.h" -#include "context.h" -#include "cpu_lock.h" -#include "globals.h" - - -template -class Ref_ptr -{ -public: - Ref_ptr(T *o = 0) : _p(o) - { __take_ref(); } - - T *ptr() const - { - // assert_kdb (cpu_lock.test()); - return _p; - } - - ~Ref_ptr() - { __drop_ref(); } - - Ref_ptr(Ref_ptr const &o) - { - __drop_ref(); - _p = o._p; - __take_ref(); - } - - void operator = (Ref_ptr const &o) - { - __drop_ref(); - _p = o._p; - __take_ref(); - } - - void operator = (T *o) - { - __drop_ref(); - _p = o; - __take_ref(); - } - - T *operator -> () const { return _p; } - - struct Null_type; - - operator Null_type const * () const - { return reinterpret_cast(_p); } - -private: - void __drop_ref() - { - if (_p && (_p->dec_ref() == 0)) - { - current()->rcu_wait(); - delete _p; - } - } - - void __take_ref() - { - if (_p) - _p->inc_ref(); - } - - T *_p; -}; diff --git a/l4/pkg/libsdl/contrib/Borland.zip b/l4/pkg/libsdl/contrib/Borland.zip deleted file mode 100644 index ed8f45d27e7c83640a90aa121f4e35b0a2c23179..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 157899 zcmd43Wl$X4wzZ491cDRX-2()N5L|-0JHb7;yEX3a!QI{6-CcrvklVcZvhAF`@BOoH zeN;^fit4V}RM&dum}`udl>mo;19|(hmtLd)>xcjI4G{z#M9|9io35n+gPy+LM+QX& zSP<}3GZ4PFQgns@fdn%Ekp(^;4fqHc5J`j++PSTZa#`SS2EfAn*T?IAGc~ldqt~-G z`sd!MNhE*bY5h6f3p}uTBN2LVY#ZfELLJf7ShvrPvIkAfrEs!xmsqcE# zb`x(?J?xBH$4qrXs>(x~@`pF(WikC=T%-hOJejv;IE^u6zYlKvduR16i}b47ljESAQ&7247}D#rorcNdTv9KH=pXU@uH zRr2^zwH=Z8J>UH5yS?}Fn^L3+x;i!AYsEIcy!&`Q89+)E-gP)w!OkH-YEKdwaC|71 zz6y6HJ+XdKY3RNgWYeV6EEicNrK3QH&$<4>s?pxNQ2 zNgZE`^Jz(kk77C}iS-!q

c<#GU>tm0hsb8O{p}z-WGGT1(@64N2XN4Mg+--0 zo`B|E!pRy^?cUeth6Uzx-nz(=?QwqCj}L)a>FJc>wnU51YLLe1;bvER^w!!MoQyKS zQxDtVj1m~VT^bDNq?48ihu&f>^353HV23zKPWi%7rrdEu;-pRoWja5(cv(C-;d+7v zewE|eA|(dKl8KHDz8u=#5+zx^7QfBIGdIiFYeW*+Oe?X}kMgsZKK{pu(tZU?lIXM` zqo{Of=_v|@c72MJ{Acw=hKzR^8?iMhg0F=t8h}UE7C!U5>MC@2HT791$5G>7urlnH zCwY0|!xxBN34o7K;4Qv5z5azqb(K}Q-?bE2hJvlsuf8PIppQf-k-H9Q)4?NZ^4$$I z3?<}{RpY~DG8ZczJ$#jYJwOPZ=Q6ssDH&okQ#aAS7O$~a-eWdfa)RxNyT()>U#a1FVx@Rd>U*|U32`k*P+^EF;%vB6F71PgW; z3)S0gtXrAR(DkACrKEe3m1DLsfXkT!x6%$5uYFU>9*&XkULBf}QZ2kB&6qZ*Bj57# zebO-PoX9p+wg5su*1aKgF+3=Q>K&FlQMD5Dd-ANJ+e@BxIY`LLKzjOE>EWD4T{`h2 z6t%;nDmoiKQX%cG9$8w&0Ipb0KEW!zl6^+}&&x*C$wa})2DBL2^z}-2jpO@wA?|Hl z#AzU`N3=Nuuh;@^6kgiLEsgB0?*!Ek5+J8mX0>2)$*!ltT@IH{UM5asb18$0WB~KM zEQd}@2F&V3$t|o1rO8OoNLhqMRZ|F2p7g_*Sh)f9lL_76wI8 z?)8(5NMS3rO-&8L-Kjzd-Z!-kbLb}NL_%;h%6RL6g!(|SV8*MR;+EmI!*wsD)xEI9yH?T<)8w+uhigcYiG0I>u7aFaE5MlYx(RCzAMj@U_mjGJ}`h zMt2P!rpY4)%j3tS@cJF{|QOnbq0j(@#BolT{yLgYj8iH?j@1qS^D@aZsyEWEznK zFkz93FvD%3_zU+cxyLn$9OpxFL0V0`{baX8J&K6tC(@sQghX{>;)| zO#AU3E%0D5;Kj_ek|rD)`xEa*LQ*CXb^UDhD%QQJM?#3}45n>uo%XJC$300Ok^c@7 z1?Yc99L~QYPT#~(-`w2Ld*T>PY|n;$>fP|1E&P_R-B5o1f-^R? zhU)8aG5UjbP>*=j5=w1@nBnqW&uh#^Cfl=T7Q&3l^0c{bwLb<^Rp`_s@~W^vv-0XC zeK|1cKuPoPO8gr|m|zN6_0bgrK#vR?m{BsnL>i<_L1a>s{;XP&=&d?3<+h5NV5{0O zDjRR6R$nZLPJ5t_E0)5N!WX&RZc;MS3Hta-kLy`d5_b@dOoO4d|m z&hU>k&iT@6&5AowfXhX6-tCgbGLjKtejMWZ@_v8@GDFA<4k>(FV-B%jV?iA8(1?O= zyLqmR5v>KpuRer|Jk38nqtwJ4c5IkhLJGRO{COE)PfO>uZlUi%tqyUup%6YcJvWiG zbZ$DzcdZ9++KwR3qnudk8zUwHhO13wY)%!3$AeZ&RBY$xfZ<&}OBDy9_ zG)4~JMMdPJh-lMN7xGh^geY-F2fkP&zaR_kADgD`V2b{>hhM0nr?>ynlpj1?I&lVL8(n5L zYWc8T+)zZs(-LZljC`Ga=cNEc?%NH{xs4)vWuCmTze6O>&xZ{*+T{b)sQH1@=ZA%& z%{SOCaTAHNo*Dff2DEQN&h&~*7z`g=dJ1BG^CMVkhS*$3q&@ueOPbpxJO4y!1)Lr# zFD_|jOt&xghDcsfLPcUImkANoGr2VpI>A?}0x{92Dfnr&i#SRT>4nF1WiWOk8l0#d zCdgn|YAAeS4Hf53e}_1il>_VY0G}r?99tA{>IMUW4|gYeHG1h2%XoyM5Oij>9W{o}GsPSR9L3GOB?>%;Ut@?UZ( z!48Zp_{JKBgX)XBYY&+fj>pTWF~VRQYGuK~s49XWeqJ$Y{+tZ=n)t__szXt_0AQbiqm7NlSP+&v`g5lq{_8SQ%Kpec)pVms1U4h!?-5U}r z0w=yIBymrqQAgLF&i1RQqZniK93BeA;Tk(>T+hq&C;AQ z7-)f(jW}qV+%p|Bxp)o{y&waIQ(iz}XhYG;B|xx7fG_D0Lz>&-&P8L26@}ogg*7k+ zIO}1EB4q+!uH-cvLKXERhgY?stFOH?Hx5kblB!B- z+G>}lz~z=>+U6=r`1nA4&EDL}wgx-v9r~}HUu#QT$;;JNY)xh@KN@F7Fk_298Yl0= zsff*fD;>PK4_EnB!^V8QD1T3MW2reC#K;egQ%l@;tAV#Td8cb@u{g=!E@C)5MDbAN zuyntflpq(2{={_-;qUu7N(ar^XGzHqI7J|`L!?|Z?(T61 zY0!>|WQZ0mISlte=2z%dgY5&P{gv%#XN#i>X*>-GFo&Gc_o*Mz&%1lp=XwcO?+z?_ z)pKkrjv;-|x1n1`#h~7=2=onDUL+`oSg?;ePD)Fx55zA=v>cRt*d+@;p}#Fsu&8VD zGcq9mN!ziLq2!MDu3W>Zpl`xJ*>#bZgs7AAaLoHb%+8Mt(e%lh*K(Fd*-qz+gWXxC zn@z@n%5tZ-WH&Q#`W?hpC|Y5qVjN727chgndJ?~Os?Yrb#@i3&T6jVvl#2-9T~f{u$Q3St zcJ(OLI30wZ#6ZOFH#v7&p;Gb`ySXDUl+!q;(CHUd%a4NDvBQ2oTh!1~k>s=HPn^$jAoUE1DPVl$(3_3V(M?aO2^gct{7A zBTqy^M&79sYfVAT*ovY#fWnMZ zU_-byB;`dKv}fh!+=b+31a@*R>n=# zDw;VHW<2B@3ak0zO$Dm30&5cl<~S4p_6d_W?nDs72+*Wmi$X}K@Cs<$Dh-LQox;47 z&s`@rD;BA-7zbZVoKhmF;C=4|u3KoAC$lkoBkm0lBeN?@o zIH6nFxh3-bGGbkKOoV$A-ReOzdNs5|W@4uVT|zrmC2M+%(=^nq zhGtg(qIO3L4N~SH^(|EZHj7Awi_=i!LehAH`SvWU8yQ)N)0AU!c_Z!qP%hIe3z(i!FNHBd~PooRBY{k*pwV7L3T?;%&;k#B^L zd9=@^#*qGilW*I+u1gr?e`l*)sz1$351XF zU)wFUNP3>P`g6k9CU99TGrsG00)0fH24o@WWJ%S7eU-Tm%i$sJ>_yI9b9JL8nku_-=3od;geb$Hi$5`LwW zU(hD*Cnzho)oaj7KUK3n+w*+G`e2!(j2~>PIUsZKuC%=rBhsedUFoC(a~EW~Wpdp1 zo~opHt=f@WrD^xjvL8A8La%DAs&naHi%~<|k6y)sdrDH#zp_Ctt_nd3ZA9gJ3CHk? zPJ4+^j&Ku;G?J#0NuCkFd^CLZyeoWmMm*Dj4$jg_n83^uyxt@aJ&E#aDBM3|=Eb>X z^LA7)?>cnrKvEJ;DfTd-#jDI0?W@2~ty2{wN;~syAfN?N( zrkF1~X1ccNl-f}8U_%kK^((ioQ!B;74?ij)vF&XI=#=|hgaRKBbhL*U<~Z0w*+Hth z1yD>r&VG9oekuP{y{7k>M#350^7G&`5Wv4(ft;4@d|1iq{JFS8tIp9!Y%IwFdE!T8 zocR@U?1Y#CFOV=XSX72l9{oHvZ+zcW13Y={I#vt{L=JK%79%5Q`?X!oR?bT47*fskA>dNO0M^whn`4V-USUIe$8E@RU@fnTHJi_AsK zG8TF7Yo_}d!{6V5Gf@9L|6u>?knzpR%GycS(eQ5r5Pv8=&s+U@5B~QCAg7`wdYYT$ zH5K3hlmJx4|Eag%6A)O>FW$HM)7!sJK)`vl;3!C)vku(y8Ss<8M8f~$7;4?UqAOmP z`(w(@^1BA5xB2JU$k@@iFXb>$6DyNWj0HzzYtWhTlK|=EHe2||EwM36e6QE_Xx0H>=k&&In=KF#H?(jik5uhaQjY;)~2_s^lTgbqxNJ?ATesRp(&$=VND{rd>5pi(! zQp%xv98QLxbrUEmv@3Hd^NK^8RZ965xjti_QTL_kqbrUlzp{k#q>y9|=tLp9O&zoY zsmL;BjJZSv+#?UQI)G0MlaA7`QzuTg<|gG#Q%Y7&mX-KhtJ#2$O8KV_an&-fi6L!6 zUAZ77S>iZ63qQzg4L=mXbaL?u$jyuo~*CE;2g5KcLLF#q;V*zC{W%os1GSE)!!}N*=F$XgV zoQZ>%Z&SsXWk>usrh99s_glP^Nps=HoXIC?>mV*<$NL+Z^nn;AqREG9@FJGtO{Teu zw#%k)@^hH78)+ItJO$ANJLXfI-dEIv;?p#n`}g!dR`4}effk+f0DZGP;h2nbLQ;;O zVNhps4!3MS?H7{7<%e%|NE_3%684*BY)WpX1lh*BA@VbDP^)Iz2QQb^n}j?7gu3Y4 zA9K5|8ZN#`MOoMSB5&}*i*}rK;KSbWTT-Deu)Si5o=0bDm>b=l{PYOx*9NisaTVA_ zfa<(NyqV)}S}e-=NqC{V*0zX(Ab^Y2EirSG@9TcWqXc!k=eWM37B7)w7zBg&XTpro zgFxx5<}1Zg_RWJ&lD9aUk@#ceZecmw><*pjV4BFUW89FL)AY4YJ3g>8n&xtmI;WLM zMFl|tVyVn33FA5hU@)qlFKqx-iX^J~3ATAx?eS_spZo4ugc~u}tj1leyeAks$}wKC*OK3L5A1h)ZO%O*E(k!Mj<%+C%klH8{qt$k4G$G@5nO!)bE(XhsXVpg zlv#6y>o4ZJ!An!Q2zSA3?41dBX`xJQ__kZT+k2@FdYL9zsZFD}c9#QU!b`i>RZ=VD zrzV?WFQ|~jAy@U3MA0?(wZETidj)MzE-r3*e<%+QXYY`HNj$%Iy~vi?Vfr;x+65sJ zNsbik?93SW_*HbTfK~VDQdOK9xE%lb($8W@8g4C{Wnb0l{edEqYIUVjZ6nWFN-%ZJ zn6Q#x7_@U$m<-Oc_;|(GDAKhKtp^hjWJ3_uNj9pI%6oJkM|b99)^9O#8lrF+6dcvq zC(429d5)-(9O*gp1l#NfuW+bK{PJPX<)ds1l{A6tV%V?6mKWZ&{TfOV_A&X46DN(% z>aLxRs^@b~E?{&4MMOcr=bZ0{E9Z9mC-ll2!3y0$-kvJ000!m z5k#fcgqrIPpr#d0mV93rd%58v6%MW)$* z!lRYzYG^$w+{uKEZ^6qlt)`=gE6wx8ufxGnnY4)9r^{hNJ09rXsr@V>sjYL|D*2-6 zPOo6jmrN=aQSqr!S*4MS*j%E!!X$ZjZh%sJLe|S7Kej!C$4@Pd)HIgQT8TvY#gh)) z=(dTp@g2NIObTs}+xlu&$Df~B!r ziHcQMr-Cwb9(errLc!>Kd}% zg1Koyf#e?6-b8x7!$y=%hl3UXn&&u=1s1QwFA_^y|05F}Zp!aKKeoY>EgU5#Gv!6JabC=ly0y>Xc(U|P-b=%aLN-Z9bAy#tm-{h|7Oa&FnPAPDWW zPGLv<_TDeoq1xx06f%=XjM z;h_5<_I_zs${PzbZak)T0zZI`n>|gNRgLIqO;^dFGH%j?#$(2$Yix@YO-62uoNm1y zC;an<1os7uUZSZIpdF`0fpToA z5a)HolBK>Sz95F+sJ12RXwU+%Jjg3aS-AmT69mpQt8v2eb+yui)rErr1G1ieq6xIzSjBRUUu6Ez0 z5ax*TBBW<68^bS8xLdFFZVr5j1G{#&4vL1(qB+!ksZD zshOlXPV`WSmAd|H*QD4E!X0}vY5$}{jq@rrK&)o_wNI1@pYY2@Q(y$y4}1o@iMD8r zQs2kknrh19dcU-Ap_-o`s@i8y{MDOxPj8!AORTJZ-Hc^*#sobf?ZaFxCf#|GVJ+k3 z5o}N0Hf(5u>$%daBTZ5)emKl&)-!dSOB)Dj)W$QuOIF1+Ur)8;vtA3MU~%V8wnYXT zDkZWrx*0-^Q)$B*(-d1fB2FxUZV3GjnTAvA-zZi^Q!d^REN2x0LY;k-TckLf-1WYY zI8(lmnmDGAn0PvWj*vZz+SWsyjWSdIm=+a;!Q0;9Py#QiOaG_sp(QC-NN$9(Ty}3s-_T`n+Eh-^}m>@oK~<5qg>! zGKsrV;W()wcd`ITPEyknAFib3IH_XFk<+`1foZC~Z5Lh2?M+$yq7~=UIi<2sr}q6A z3hDZF9F*b*A{Es=uTV6Z<_pO%7i>Wb)m=F$kU<0B#n zFpGZAYql~DD@$kFRgnCP6SNpl`kGKtG>BjABn!N0|Nh$%QjmWORxzI0vhk#z8Rt>r z3{GUL{|MI6{m4*^BT-gP^&-zCrmLb4Cv{dD4TPW|+B9m`6Qlf!5X3YF(RWTk$sipy zVuh8icXE1#@uHLZ?v*l~QSk>+@Z^FYu_jTIo_IqSdQnE0U@bILQOcbWILVV9Lq7>h zBh12;E^!HLE&i+*u)YHWM4|Q8@E7j&O}7zxWiI8%pM>^M$K!oiRV5+_ zF^!fv1L1AOco={_k5=Dd`Q$ZTNXF|?6BtHN+fCZ8N%ztjrn9suRBjU*+0B@X_wk|D zh6pdjG*HHdPjetBYiYBmtS7Xa9L_BGtH*=ZNRZExuDw^i)!=OPJlt*L)a}zJk6_($ zeP~(NbiMWr4mix0yx_gZq9(c4koaoGYowB=y%t-7t$>xKr11VP9yi-9#Dv6}vqQ^7 zuWq?#)8gMN5Zcqz53W7liB@KM+I%NAHieP9WTqQKF16A{c=SM?vgDs8WIuFJPNl7& zZetF8AA@D{XzKTE{<5%3Q(a9 zuB5DrKxpCi-RYWB8Sba8&-uC-%Y`2Ims_yjtWqFk5Yh_-Dq2zG=fpDF zc4wlv`As&bc;re5V-OnejZBR|2ldl*4ZWWc+HS9Rhy;WqTvT^s;F5naitSQfYAg@A zX9Pbn3ae-tSTkT?kI|yb3bAV5TM_p85NEQvBh4?oBE=N=HGE@tCYlgg)^~wy7wZm* z81+WjHRw+QC_mwYCD`-AppE-u4??`7Sg66@$KT_=28;KB?S@NdhJmO+x19@toY~!a zohKPj(oGapo=Webh0#>`rQ>vH`AEt`R-bN~+-QbFqez^SVt3o__k{TOVKqX7jyBI0 zl06GJL`#AGFSk9wLE1w1A1d(Mh8c_+?#fas1C%Cp*fLH7bdr%1DgCvNO z^%Em1@u@bNmCCgE{x<)J#CgTGzuzW|?u7ynMLMmN{FUe%{?vpcZpvDyIz^_U2TU1- zm?r+wbY*g0?BzkH#2T!{gZ%O=AmP^*voQ7aLo(?}J2Z=bcpZ#?+xJcFY5l%TTf$f{ z(D08iodPB(BbeSc9WuPGP9oTuLR^Avp>7bKhSCLj?02ws91Y5NQjIQf{YZFr-zn{$@o54c;CsvOp0_u9Oumt$m2<|_%+ydnTc_N z)v@y!Lc)jRd7Hi`^zcarJQ5ltg2Du1fepBL3$4N`cnQCNCer2nm~!tXISUaM#2PY> zFCrrPE-UX}kAt_qwog%p(;$j;;&%C@k6Ye-+Pl}w)}1Yi{oV@c7PFvkz1sU8eoPuu zr*TB8dpWSRsPq%!bn9pN^JPGhSqqWE3~a&&I2{V%+L=|=NIqp(&qW$ti>CnXs0Bc2 zZSV()D#fV!AX>4u*nEpG@jGJ%!%O}rEp#SQ4iZZu_bpUayY-}iociDjBaLE5G8-G7 zG&_-6qOj!3{?;1JA3AQ9i4y&_Y>TC7FZEaAjlyCHtldoebwAqZbC(aw;#GzE>;_Ob zEay<+x%t#5=LpjXJOi4Z!d6HFMpDwNMKBd-_4- zNmBf9Y!vLW5WStSgYd-zd%vR1(~aEnf*Qr&=F5wUuiI!SdL9*}b(Nt-)3%2l;puzI zw1@1^M|xf%+~v>4qCh%xk{h7uc@_33Q&9NIUMSp>by?;-udjjeYAF<^>-Do=kZsgV zA50IgM_;KLZdsx zJh@@yYkTK_YI64J^!E}0_0K_+msZ{v1o>%Jwl#B?dtwq&(l0X`>Xtt<= zb!pBQC@p(2Z2)drZLsLMUKApp1K0bYbiwxwMqh^*o_*w(!Z#4TJnzNiaiDt`N*OiZ zYa`_(B$l2{hivv42(y!VNP6k}1bIU`VWKIW2UHBT%$UeRtAn;7BFdeDOEc;NPjm*X z7eH^T_LmjnLwAo@T2T>e1-d+3o9oR=O)Ml{%li|~yH81tbMtkJ9UvLp7VKL*lw>>3_av|qoAxu*>Q zXR05*5Q_d`HMGSrmR->x*(R)4h+fEzG&1Isy2mV8)zKWNbmX`PyZTk}{op*DsF5x} z{Ob-&WNe6+zpPfXe|4H4&LXbd{UkK^?){Lh|tMftYVC?Vb8I9c_sM!d8YsW<}I@~w6oX!W^JPTw=KFj&{y_W ze@?Xj-WI(ExJ4%pi>83`t2b?KlL>54k_$?&F!D+{rE*XtiI2@!A9@yT3o^O~4a&lgAyjhFq)SjL%+ymIpMJ)%-D*QD>PO z4327KI4Rau$&heeX;Leu(9`QA`-@c%$<7x%6qg<_tJfccnpfrgtd}X25ffjg`Q|o# zG6Z;_b>qfmJMzz2lyz^atcLL5V6YE(n6|Odv>EpVbIIGVvzCn$0#6-o+DwF3FOq0l z6dS%TtEEAJWXSANA4H286C58`s;Pz8H;m8Am+vmWu<%R7Txh4O1Jxd`%fiKU@R^E1 zi^-k+up%+KR%_n>tfY^V5)ZFAXlmhT7_b|!-Wr2Z?2JOrxC*@5Ctn+9ZEn_A-|1xn z#G{xB4)GwHkMF^VDXZUuo;LfDUc#P4U&HJK5Cv<8u74222h5nSnlQA@hF{!6>qJyK z7j6;x79axJ)Di*$a$QQ`xEj9DJMBE{gg(lU%)HWkqf>Gcy_x5$4$8ok2}&az3@1Vv z*e7-$>qrLs~AuOw28OG||{v)dU2RzS0>RYsf;^%rCYLK5sg=svPl9{JCF~!jE zkq+`a!n8p-e%%e(D6a4LJDL&i!$;Hx!~7xV@b2tpCv0I+k%iLD8SXHXlWtpNKV1=pDRGt&kV*OV z9ZLrJD^=87Wj%wJ+A21Fbsnzp%PW(!`@ku3Cey>6K-jOeWGorXPfD88J-bQ=P7sZv z%C$!IPd17xGg0_!!u5gB-zQ!9sUc!IH@#CYU~(VWq|WUw-;rfzAb1<;3iz(jM|=>N zt1ITHgU}_b$#c>>V%oxlt0Ur0D8>rKjNsmy9<;W0bac-A{DzE*ob@lnZ^mR?cWEns z#dk61i-e$QAMi&qJrt6^!-h6C_+kK1*}dV5?t>&br3AMUC?)56l(X+Sb&p-OU|0Np znD7Jo(MZV)u?YQ|EBODxS#}R}mTdwr_y5&dCiCVjllxzsWg!S~Ohkir6ji$HRrTZZ zn$lMQ>ulPK1IvCg?op{*|BvsFb&R;j8ioM%+0BES4}}%Z$IDfep)ero^dUfNnNT6j zR~bi)y_N}Gfd3j#?EPjZaUPp8di_6|%T#SYA`(mcw-|kHVw<*Ahk+A;)U?8d`C%6H z4hROG;Hr#*W7c&l>)>Ija_;smberHGnfW|%pnsXm#^20kBtUZ+$(y+*}4EV;l)DXgXp?qd!#v;)w0b-LjpPmg@%3pe)|6!)L_!lnV{_Ar5?da7r zwYSi<{u>yyfKYg=KWFcM4-8E}Fz8aLl)Raa34vhv&)xkdgBOqrZ}q3Uf9pCnh0PU< z&1KAi3{Raw6DpHRmAjojvpeMvT@bQ}ar(vcYv0)E$pZJ@LE+X#liA?x9|Cw-90GqpN*wPNHrQpU)$Gn_nL?MjG_-9=8Q0_o?eA`1^>YE3Ny z25Zhx8zaL*^A_+DzT^xod5mgI-ccGF_OV%^GXj1jifdk66qub%_le3El+&CSxtb5F zA+Htcf=dd~A2q0D=ba7>eiW7feMX9-5?9`8u@O&Px6=>#sP(+21VP3rEYziBDYe%# zWWgCfqzB=rF)jsk95;f*OhwFft>j<%J%x z4Cil5)F)QL!+{x6YrY)ut8|U^qa-v=%<9t5DarThy0g-%gk@j#e$Va z@aN~bIu|OLNPj^6>F_BTYPI$99BSN{WNl#bq5!U{fL|G!za+;eXBMHh`p^eL$fM-AX^H(F;6fg~IQSLJ6^StDz;6 z)XXUE*Uq8<5LUh2i&csdM2a}M-a;&P3sKn?cI=~3pQV^F;J+rQmpnP1tcv8{MaD$^ zPNuxZiXWdWCkT|DB9wof4<>$n#cJU-y`z{&eELP&_l!i}H=S2J7@=#j>-ZNK;^K_@ zpKLTW7NT(0M4SSl%_cqhhalg;kXQ)>gGKli{1et+V90+11N9i5^jsY?Uo(d;d2U|4 z{?^wMOt_{_+JvFxK5exf-3-Y9-|Fgaa4I#F_vPMr&mXrQoGyixcgR||l?1}NG4Y@c zY@Hdwp9V;8P;pp1(CJ9?)*(*wp1Nra-x4d|eT`)f+ z>7CXSOS?Na1(lW?P1qq~@N+uM-X7Q=M1(%ugF{`Z`=1bvv+h9N@o}r<=k8HkORzJW z&}YX6+nmTFCqz|?zGLdzW$PX;O;TDAl!c%^_`b}qrzqrCa}s!v)a?;nHtkl>Aw|#L zdixZTa4%J5%l4xP#$(IOa6e(yQ1pru%o}3Z>hFTV>0iL`Kk^=LV9+a~UjDMcc7Df~dno-AZuD^H?X!q59L(y&(w z_62}0RCLAjq7d%Bgr)27_z5(l%#sfKZX+D$qqWI^FkT^5@=;kLtq?2v#F;F1wmsPx zu58!S8g;(O_8c&XA`6gbB^^t|4t zEzZv0>Zl9_Hghnzm{0002gHKft-k@*8y4aw*qD3%3Zlp_6`+*%(#QRfOt4EdvYh(C zJo6Sr!B;grcI43!u89Q(Q7(dG0Jm`F$|0(%av1?KZ$XqAwD-j_vySl{$j5Qg)1GQ| zMdG&)GKA%1Zb(SQwkBTiUuS9EO~oC=*tty6*Xteq$v4RqoN1Eurc4hWlSI@cthJ0( z%|5X`VXS{SckzB+*26syH!&;zSpFU@-G4z$ZM3sZc0{w;am9))ztVDHBJRhWQG$`m zw?;)S)2xtvU9f2>L|D_U7s={hu1&(0A4qi3Ii*A!_jP}&5)f^Ehv(~X$Bf!=19c_k z25rm|)nR|C=l2PPc=$5A6l!G;v;u=B>W>gGdj@To`ua(13(7}Tm?-K(&kywe4x+gH z38GNF0)r@(z#vK`muQ8)D8yw_Ai-ZjlwPesU#9C@xJ{(=@h>frIomRdy+G4V?W>Xy zWac6e3;S=T8-2MOpy|f4xF871CYBK^fn5(13`V6Mv^_?ZCW)!Oqu9{16z4B21jFy% zya=+aYM_Mxv7qoPZW0AxKN=uaoLG!dP{{O#g(AC!h-^a}v^g>qiAOymGh6fU^@x_M z2K!f27yue1(~a0=2ACo2gv*|be2&Bd=fuLQpHfhR8@I5D0CJq_zc!58*LdW&-o z8kYVZB2l3Vs-}*^1oOR8h((+3_D;^37_HE`8jRQ<@Pn{J`IEJ$Iohr9b0Dr`h$dKR zO`=kIqq_%}l=k{DD8l?|u9YM;j_&<^EI-6c7=}H-i3r7zGdu*}frQKF#p(Xc{W5BZg{$t}H;~O;psI@di>#HMT{^Ij7|x^JtsE-I);_IGKL`vsLrr3Q!2#VJ8GZ#m?VGBafgLL!8=g# zr*oYoKypcldQ-H39ZH^Ln0`i+w5lyREb*6y79;2XDHv|v@my7D=l)GFXtr;Wc>o1N z6DK+-#rO2Mb-M(j(R~;Q)Rh4tC0HHTre2OUNbit9RqQ?biuYwK3!W>X!v_J@0$&fG zBGm?yzV;;O%Gsw%djiuap8u3a`3UpRZp{Cc3x>9~R|!f$d& zH%&MuECC{B+HaOVQr1s&o zjY-E>WkX80rUu4s5_x9Ry^xaCj6l6${g+;#uXeyiR*Av00O|#Iak(We-R%@3<@gcf z&F#g)uM8hXp{@`6q+y<{wGI%j3bvP;w$fiAF2y^4>jjPkhi)d!Iys?#*du{#mgqk1w zCcyO4$q>SDX~p*fT7?T@DV?S~A}Xnt3{yv^{l>DhRH;^5nRez zSF}xxmaYVC{4fGe+ZaCyhL|=~h_R_FZ=%&2iHOdAcm}J>IpOGnPYDS_x8qGftgY=U z7g=-B`2NZYDIDyR_`v!g6I>I~>JB?|Gml3fnzI#MNkFp8*cZb7FS$_2dV`8#X9MH{P%hBtZjn$!LIm_Mw7y+E1aIy8 zm7ckfS--E!1{K4Xk4ntc+aT)l_s7&wQBLX)N4hhk9AL;K!eq+yk%+&fbm==6w>o{c z?W5~DyOOJllF3v^o7Q1;*?;50y7`Mwt2dAfBOpPrV(DB-h|Ni@?ro=V$wFPhRXsV) z;0dRumQ@V3Nh;7R+ctfQ@hx$yQm5&WaG~{WbONddAZ@$ZDx}_Q5T9YV7gZCl1Ovq| zzTbgdbo;)A6v6&!j|9v4C#1OYw~%5zFr>)#`FBY1d(ph-^0QM5DRpUKc@eq zT=>)6Z!GKqk?>Z3n)|nM;s3__g*j3f(MU^EaK-{{<4<#`>?o6$Spo~m(*mqGn!Uf+ zFq11qip*HDTuQy76-K9y+#>lD^fNwwQORhN>@Xh273t-1&Iv$-f%h*2e+#ao|5I=s zk#f_+3Y(?o;^?l97;BUYL#|D2&OrJ{Je|%zVu2Dc6*1fO;SUxpy}looA^aaKc*~&! z^}=bMp6dV63;#B_UU)q1HmhWxRJwfQ#kM$kyG$`tK$`ax{bQS{qv4<%25)*e&P~_k zw?f|41ywM7vc~`;USn@F(jS%UkNTXSz#02hxD_sx>F>o7{VavzT~RC~rlDSD)%cKY6;gD7q0=u0fx7_N9oeG|(xe(cVl zaD#axBKQ>0UE%C!U(^xNy&PF)#?s-*Wu3ysW_|tpn~KtjF?zms>1s>{@xTyntU^6~ zF)B6a>jFED_|<4;(g+b8NHkuX@C$xa(p8HxVxnte74wUTC=(*)$0DO+>eTGH6JT;M zN4vu@7EdIzqG&*cY2R*9R^9yR`%YSa-kpq)Y%FC^l1$7in&|PuGA2K8jTE^!75;mT zWN-)lwnifCdzO|8D}cu6`Iw2FlUtN(YV2LRbL1?b7_(9#L0(EJMi|GdI0v>YtUAlx~STDQ? z{>7mI2L~4yw`?|g?Eucgq!kH@CxzB^IB!9H7j=->{kJGDX(VJLSw3p1R=-}26#;m$ z;FJ!31-H-nspLc#5@`A6TQpyvQY&tF${{QTl~@S}_2E$8D=y*A~e_HC7nH3%Erh25ylQ z{0b?!;O(>y7zYK<@ZaP@^wgVNXjBrg!_L!)(9dwmrTxPN;?-o+Mmh-p9G|j!Ldhxu1{J$tH`pcYV_BTCzyd%%(Q!hEXyy7dC}_cfAu`@w(y*sixV zlJU2{X@#(0YM!_HbMF54pl}U@0*(GEjS)~QOabo}{ztI!Z=L-n!U>QDZ}q3MQcP2; z6wzzf+^4`r$|cs~bM&9ZfS*cO6;fPK5FDnpMZ^g2jd9AlHaLDA-yyPxua4r2BUr6H z@8PjX@}7Vb{1gRDQKo7kxcb6>7G(c_*n7*UF4wl}mzI!_MnVvjPNf9_m6VX~6s5Za zDW#+vB&0z>LTQi&K{}L>ltwzF#eH6XKv}N1@BNIi_PgIPo;Aj~#`@&AzO4Ur9`l&L zW5cK{QTzUqwv(f$;Jcdw&krx7iaQ@TMBf{yM%#Z^-y)uB*=Q(^!}C<{>m`B@C^#t} zBqQ&Rw(6;#jE{KTL^B^=Gwz3tk2?1W#OO7xx13AYy2M*In)_G71dPkR4K>+N+Yj+tZmlet@1#<7*@yTl%VwY>kV# zE?iYr$Y{!Hbe*Ir@B$OX4BAZ=%X#Dm(f$Q^!9n|q=!+Gak`$gL%+@un; zmhbH>*p^^tlmVf_y2;1TfoOe^Z?DuNq@`;L%@m@R*2z5va4E*0b49aLAlgRlDmS}Q^^jHZt<#c5Cb5l5bFiEdQf4X?Cmn?v}*o2lzF}FOv zVBW{a>$>%7F9;V_!bqFNLl>p3DsYr^At+l5zVaP@eiT3X>?ed${~FS{J)&-_;JsV3*cY}| zLf3j!P0(?bbJbT{IGx@+T|MXW(H%I6Bt6D2S`i!hO==GFEd?!;Fw;~;aK>!b?jX!#3-mbsWdrO#bl>~Vc& z1Xw4Cm5)a%CxmJ%4322Sil02U!g{T~eUR;CbAA$AT9ZBz<&N#BCc)sfqJG874r?D8 zt-_QV0)?nAkGWDxRcQl^YG0)Ik{{W?PM;e(&nXy89){Z_F0?SlVjFg{SG1l;g1WrYg$5 zQ*pivsebX|Wm7u>li1yJS+x4^FW1hh+^p8-9ZyA?@1v@{&ZJu#-=z1xE>30k+~sp% zz%&mVFd=)ckVPBlO|KILYc@lutgm0UZUa;nkA^BR64pQXk3h4F_j_yklR>m3PFl*o zz6jorA$R4uQ`o0=J|if!N`DD&`{9%xNRu)ZBOhx%|~($j=2y0*9afp&HT_+GQmaEb?YhmkQ*~&4JzLKwsuk(1aAbxW>>C4 zHXYlG4sW|%Jp}m#)UwjGmB?vETZGg^>G7rpv+@-BizS};T?o!6dMvwmN6Orj4xhkk zG=4&r)4q;*k;-|ps#vnrcr4iJT!&h|R*kyUA(rN|ud{cNczZTqAI4Q<8CQ#WgibuY ze4hZ}frrN6dNk5!bO*!OoLZT(j^q#JgfTtjU;I)NcZnX9bENrY>8S@6cjClv<#ct` zoB=>O{pK*p|0=0Av3z7}XKY~lQ%~*#g8{wMU+sTSPxgSG?5&AkW(Ru00`%lRec!RF zfC7jh^iIDI_zcToE}S1Xg{l#Wkfff9xFM6GH(F3h*`!8CBT2}pGu;tx3v9TZFBv(t z)VKPw6qg^PqOQcwaxCm7#lm`)`9vC~v^=4AM1-ED)f1!nJB);Rw6r8OQGyA{vX`*2 z-`7as%8%6~J!seIL2^wrxPPTb;2Tdkjh^n%>_cg5&)Y^fVhD!qY%Z2Db~xDe36V}d zw6nRclv!1mR8=?eQb#Sa^Vc5JN?KOrwbc}{(xP?ttR%>4xZCt5me#x=yh{b17dV-xE76X_?suIOz3llDIl_*iUE-|J7!M}yqNOr52OHmi6%iX>V??;8|Z-+@Ke@*uMAUD}Q| zhazir(R2y=kQ=Y5RwlGQ-0qPgnr*9Twe^@Yi@4bY5`og35;= zS!+KbS>`<_kgU$V#q6?b0Lcofz63^4mk`d3pd7iu2+H;B2+9*Sg2Ko9uSQTu#IO+* z>lXcYme)^Wy<}0)=BL+mQFiYcf4#yqJE^ZOE?I*%BHtvY*lLW6TeDSfC;j+}e-ds< z^;A@?bc;U<7#j-fKk@hUMTHXU0FYR7^Nj>RiM5YrBS@^(TGOV{8W^j}H`_=`QES?y zK8Of<%G=94t(y*_)z=ezoU?ar8-+!wk^__qmoHZ11a8G8$o_(YE4-tYB$Y zK+(j<2m0jgfz2c;Y8&bf+~qEU3`}GDE~kk#oNCQXLz=si%GT&UH9W5*oeC@(|?!IjEW9{z^=-i@=Z3Chu3o;sN9HNyiQ(MB2yZ5vPyEnc0)Cy1vEc^N z)h~Qcztg5VC78d&!51g`F(%m=eEH4!h}0>&{kAfl@5KjaNF|=X3B;dR4A5Wb|3FW) z0m1;i(;we|PaM7jaac@lnqUIrfD6RopT6x_7>4~p39_qPm>1U1HZ7*^^? zIn9Jr>28y&Xq0@@;^mDtGff^(d3%2*{&5e_m626u1E1qHrZnCrkye$qxb|nC-p;5p z1YE#TcW%4xXWN5IDgXJ6daMinQ!B}9%J&S3leK*q@!(Ci#7pR<;a-aLvb0qxGUdE@ zzlnmXMJ;79yZM7)%Aoq|mC&#G?hh{9WPK6JFC0#Ki%PER&TgKPQP<;V z-}uM_Qwmim#wHfbXg>4s9m&B%`>lJW`}91YJLLE^SYqLz{Z`}vKYQ7q`>oh6pHS`j+->MZ)ogV9h!LL|oPk<$7>foi=(Zi~Htu>fB;n)0$ z@z8lhODtmt8}D@f6e+scILz(#hxwDvuQeu$_kG^MN(0xe%Q5%Kg;{!)a);>MH359`HQFa7I`Ro-F+)3%7-@)jNNYH9VXnkjW$nvD_Kpoo3b>ZPc*bRmqCU}SQX8D zAu-lD5aiY7s9hNh?9q)$e02&6kF?)I_lEqo7v&Wh}AB1jP~- zsUVh^xsLWs$62r9YBg?C7n;WSrsTxc`*#q-Z)8%k3pdr?^1{GiEqj&65kgA7@<}dK zN9Y!dz7TQ@)6Bh%z%Nl_BL_2q8eZdb8TYA@gkJGw)#+|@;uWx6svbB*c0nY1sr4Kl z2QU1FBL}I&HJ1akQG)BfUU-Jj#2nADjP{M(*D<;F2J6B5slXhjM~s#6BLc9vTI0#v z7P!Z4cixC2n4j_bNWu;G zF}_#Rk{5#3Td|MVTc6Rv)?1N#n{F2Uas1>yes=s6@ZV^HndKS7-~;pkdZ)j;|DGlw zWq)RIusSEq@K2g>@@>bOfZB8*2))y910yIY^D%3rlbfEJP2z4H= zsdu+Porlkj^oH)=1?RAe`~*I7J=)Q$*;xv%F+;p$ZWR8OE+GMopzv864aI_jR*SMZN8#) z{RzP$4LwTll5A5*Tw=4i@Dc{juR)6N5GcZi>t|Fw*L@DRBxXx80%(KjIwcc+dT=)L z@P1w_nN$hq#Hy~^+YRYzqe$G9ooM!3r1@@^j2=B?`cyMHhM2RpCPVT}&%MuiMUQb{ zP9_w2;nL5jO1E>O(~J){6Ejqyb(~Z`h9%Wwu%tTtIH}eHNwv?{zM#Y_ zfTdgai=|r&Sh`O=v&k+tmA@tpE-#3xNM96HfA5%^30S%w2$nPQuX!;9pjI1JLX1Ro zf(%+szon_4q35=FO3+5J8EJ*}y*XL|33dtfw7RN~OIp%^rJLCcSh~a#GC2c~O?dE4 zM*U^|omdY$1wh(@Hd|MMPi+Dked&$Y%qKR%c^udTS;~-fF}UAs!fLKXVDn9(6Put4 zY(mblP4F*B8|a?Fs`|y!?f6=u=>Gj$!0w}UuR*l%5s1&uQt!Ad;xf~wp5IVMeAOl6 z3+9VXQGLJ-!d3#@AWh64{Wp;BR9Y9?PCr5Ys6{Owq^tMl1>goDTSr>0G0qm8gGYMD z?>^r0I;ve&TzAy^rphK$7UeqIboq8_6=V~Tze6@*xs?oJ>CVeRjR&FA#=`@UNYMRi zJUHwYkHZuJ@l+A;Aw`(0dEhu=P+|vQ?Kcw!<`%&QQ`qqalkd7+ioqvNY0VPhnp-Ur z71^ALP*8p6G^lPGfzPHq396H4cdmItK{cE^2U4sz@_D;T9&;qsw(QA9T#u-3!f{wo z%?5(%gue=^J)od^mw){@sFwc~R6pH6aS0o0a*|bOBe$Ex?!#Qd#}k);S5iGkPYL!D|XGjskgsFf_ zSb;4tZ4Xtn8ENCnfW6jH^D;$Q+c4LZjz+;)l8|e8Z>MwTEo{DxFq)0+moT+nM(Aed z28qPdX(FMyb|#Uy2umb9e@i5uXj5Mvy=eTL8Pz)lA#WH3AqVBM*UX5RY$`0N=0{$! zET4~>Qz^T=5)zedENj>eOC%;iB9VUq2fr-P_uXY77iaIJPglJCeU(UNud<;HkZdIt zOj?(uJdsnZ*!5M`cffyU9*d8cbxr5}_phtN*u3gr2oa)CVX9Ep#g1wYkf`kFo1?? z=KFy$Xdg>=5AcdA4=$BQQ+XeiEc``_HUUHn5>uQL42FK}4IUIQvPKC-i z2Br_+>*xS>z`j2iQ2ejefK^qS4_cmM&OFM}j>NDw9678F*M8iFQ-ZWX_EZ~~>G^}#8Zs{%G$nKy-ZIbKZ0p$} ziyylwd+S~*8gaL*13sE+4UO%^(vcMLT)9DtI{FyB#o#QPg{XcFo)k9lM zhp;WCjWb(JQ^wF1lgUwFmFL0f784(Ai^;9?pSGByPq&zkwExyF!2Q3s3q%6wr*@(9 z)Go-Ju?z1{?SjRBviMR|G)2*V>F4FB+H$D%+C1Oa-dpZ4dx+Fpr1lK>^5TVKc{LOGt{VngF|FH=3M z1aM}`C%!TG^JtX0(+>OQSp53dCfE6HpLCKS>h=3Kh!ZJsAH9)HD|QMmk)MOBo(&vXo#FQ`I#0dd)2LvDq_Y8@IyfQH)N~E(q;46=T6m`NfjcLzs zkOm$R2a1X{sHe*3T|s$D3hEATCd0z4gi6v0xF71w#^v!@wlwGXDvv2AzIfc$gYSBC zPK0xtjljN>H=kre;vRD`K&)#m9~2Sv77w+pAy!maU+(fmWdL({Zs zcrJqbxwi1>{N6h`k#BViBC>Rs=^&*r>U|_VWZ~0QzE>IY>bR7 z|Dnf6)hJSin2I+yrS-fJYlo62-1SF|!-45?nF+npZB>!XIco1WOR)AuqCe(+dz56@ zcEA%}IM^iracBb}`guT6<#|q5^`$sj<-H0G>;eT3J zrMRpmz)$WV+WWCcGgeF{>(fj*i+#IERgqlKCL8=hmX8=gzJeG zd*#9k=0EDn=4VI=?6Zxee(6KP{1MC-|H<*y;gJeO;pPU~8v~j$G#Z3G&D%GNF-D{E z!C!O52K4dUPV;DraT`j+bTo-@M0OrkZ&yskZn`JhX11jZ=;4_!&0`K9DUEf6 z5{@?A#KJDJnT3nOYwY>r8CgjDvZ*O>3gZwbtCpx4uJ5Inr$x*;%yXn_-j|fg3gmmg z@T0BMVM(Hl>MF|t%qXkCwv|xh`aE>EDcDv23ukf!HXemLtM*pZjfXeO6k{jmhia)V zU}Mk9-9-QJF7j&NIG>bc25mh-q`OmQVEP3t2Ij=q)|Aa3Y$XSFUSBPv-2+U~!}AFyG~bg%gwrHb})YQDdEW6i0^c!2idE*KGX3d!l|bj~As2 z7YdGIcF&w@s`^bR{<4^CYh`16#zf2loq*oy5AwgK6*xdEkSk_dpnccBtxf;@x?{PZ z1X2OL)35u_9^(Hm$C_@qr(4(aEcY;*-)LVLcpl6-XC7m;*Ifn{UagJ)5~x9N=_gP_ z&GU~yjpk3$=B_F-!B>Va&O5$jQro+#b6o~)$E7VcB}k>Fl%UQ?=1u6vr?*#a^^47p zd(*J-l4cQ7Y^1|$!dVIcIS1n` z7z>_(=X$WM8aJ7(9wTSEhK4c8cyWn$$^^2|J0)rMMW(GovpX85R@%{^AV=x8Jid*C zhe%r1#ML?Q)_nf`9j%ltnkE|K;&VIlg^uRK)-|8v-)GK<7}%&+YCYF0Cs1CE^k&db zN4r~kohIYi&b5w}l|jNs)`97Ux8ou=S{nG?@{06+B6OSh+l5z^@vpOB;q~z`Py@P^ zaRSu9@FB1Hd!WV{3jqUa+=f|*QOH67phge`)S!ec1Y8l{v4w~~u@Gp$La6+-5O^>P zLB4x7aOgR)5cym%3(E7YCsm^cc2E` z$-=AV9Sn&DZci5g)R2S$HMC>%p5@B3wp#vBcE=D5Zf0qsqnO1gPQphlN+K1nH-K3RL+d_bfV! z>It7*mJ=QrM#0UwcsU&!FClDi+9l5NBU{*%FM#pVyUP~gQ8{3|v<4e5EuAjBMxR-D z#lbG*XuqY43-#kJ`!^5ypbLB2t-I$=FVW$)vC;F%WYq*7d`c>>f&XP8Dw)!~ zEHuvdhMSd?P? ze$vRSAFG8j_j);!7vsC*D%&h2eZl zE-_oI)VE<8>KCfHW%!|$Xzwj@#tq`vxFC(*9P39)LvFg<`d#T3p;ygUI7UNW1QABd zC~pZWb>S#Qhu0Sf{cLb#j5|%TZ4f_7IVw>K1zq~Ul}7(DJJhbvCLh1eBy&AA*Q+}0 zN~x`Dj|yzQ#N+^-QhMhF=1a>AxAc+-b7uRLs#p3?(&%1~@IVKUMyC!HU%^n_assE6 zq{IqS_U#NFqCE!t;U_Cf+J|r(>UBi0lLcj=pd}Ym(i>^_a5Fc&va&d_Z2$% z0^U*X7(c{h$-d4go$seJRf)RR@}UNS9kvv6}?o|B{eswB`1YTldIqBqv#}PdL!O|M$7Wcxw3rF zk~{aaB}eUs0kz~T?b0gum2bYEvh?76Kbhk1d;SHN_`aDI$;EKOM2@8|>g6L5*bU4V z1%rClR$msXey930?mo+2LzjdD(&%`h%b{I{TT(gQiF?_fuG@RnVrN!o1VJiLgD$@-vEzpu~6Wkn&G}kUb zEx8bTF-97wC6`k5S=Y$obAY_9S2SqJ6&<(aWTBQEP4O(OC5OwEzQlvz1Ksf}S8eh6 ztTr=XuzG{Ns#JfF;7MwuUOhtGQI-%N?RYiZMSDx9c4Z5)bKsI+2XEy~kN)ZLbL=GB z+4>wBU!k6yO1$169zN*Feg3{NVE;(tma`p^`^_8OZ7YcKRI$NW*wYEkl+1Z1Pjo_k zd62(voi`$ky56$9@$tfagBp^;}5XQUtRmrmi)*-J`G6f>wX%DIuH0@(9FwUYPp=-8MYh&oTIM47L5nMNn zMW#X~ioLx^ww<&F#SbEK$`!kX%GM5K0fw>B#~ho};XoB!C8JN>w0afk-O0KL9AZjZgSV4&nAVDH@73NytiFJIsvXm z7~pEWDX6WOa?69b8k2f0w#zestI_v@2yivn>~_3+F38_)@RrUVszA?r$;mI0Jv&cS zKyKK4fzFJ9L%DrVlj~#u#Ttr7bJh#r`*85DpzF_K?75?++b=C+Br7}mG@C7mhW&6q zuYKw50iw~}BUhX$x2&r__ml`u_mr5yo)S0b&pjoIvwKR?zwaqgi$Qxz!OZ{do|0b; z9_zknQlEw%K_ks$E^#4R-*eYqUW&@puGeQ-N%l@}l%5b_5WK7)6A`+51^w?XyrO<# zVUn}bJKkN*Ndfo4eKdDH&ck+BNub@;9oX(_mjblAstDU%P0Z2-yQ}#?7Emni!DK;v zW8|6HV9?U?rhQD`yWDx{Sw%Q+7CHV z5#zQ*RBZsOfex@5+5oHJ+{BY3g-!t32CZY;P#*xZ4fp<2f4c9#(uGG>hQDrqV+Di$ zGYAAj1hCS(IWfZpk+ z{SVhyzw8|Tf4#m6zy1wuC{508EkYYgK97Mpdn(6Dpr6NC}#MTEb;{QNd|)&Ikr`x=NxSkYG)$EO2C>3{Jw5Qsad zU_1?7EWp!f3RiPF!7NEg8HLIRe`?fBvw|>7$WagAoQ(lbBN>KSx?qSb$En0-nTOSui8m3;EqA;hCkLUj z)SIjII9^D60gD$fQJ{EXdC0nkGaSSV^*3zPHK2IGP85K8 zbF3WH3#rphg5BUX?m3X9JcR~Gyh&|7pR-p@^ZA1%R+GwAAe;v4{0}O>e!bEz*N&C4 z6Pv)3AJYFF{`%z~f_~ODeHc>srVSMc2m_B&A7?Xn0Dp6(Xs? zs>e=L+WAEOtMml=sZGcrJcH9fJ;iC@;xb9E3`Eu{R znGXS+MzRJWSYG{z!zZ!@*#s7+*!#dHFvDy@kWvS*3AI0MLJ7gnVHeT6N(1$;hC>tk!nTJH4kNtr&wHZD0QhVxz7EtCFGX#h91$b zkyJ$FoiAHvfY?oS(YYtiJAOg!{c48eLvRs!D(wSnxK|{&h)l9Ma9ucwh*(WxE6ABl zBAl(jY%?vh3|vH3Yw_OS=J-E$HyE(Dj76*)58**1f#M$qGQ-P>eJN>YquX&o0wL# za+%+NhDZ(DXyELNv5R+*Y@C)FN0N645rDJWT_^3%B6Xo!YkHJ&t)0KQ*uIH;9R5-6 z#CqbgKEV__Qnqdnl4=XM=pd!>DrIy`AqSAVZ-R>s@Qb-`{TCn-pXq1yKx;M2R}0B| z#qPtm+Hsbq35R*cTfjw!82eYp7aizE7(2#F-D$ro$H&D+V+gbwo4XhW&nT-_DS(R( zVc?=eFLcpCD{geWkQ^c|<@jCyxx>0heptI&2zFSpU>6;tsh*AdjUzx89Y{xw8frlR zy^s7@26oZmRyuRIpt=gU=x_%k&RblGOdS zr(;_3uhkQ)yUu`u1B+uw_Bqo-KD0m*)2J)QuFT7bPn1dA@ zh*j(iv2js(7E7isMfPVuxC|AcS97+Hi_ju2Rc+lPMMU0Tk(e<@T@4+cKt91>dO0bT)a- z#zj`}3$nKHVvdZ{&Uf493Sy@C0FDl2!8< z#-|Q3TAy#_{BU$XlR>v5{*lr8m!`q-%%QeWZx#XQo&E&>dkSF)6vBo5%Bz1g4ac8$ ztPa&c8K8IiY5zmh@PDB5w%%9|hDf3#Cveu#5CCU=2gn$EJ|K1mYpmC{*#MlC2U=tO z#FX3lZTHs9LD2=M1ikyS1Z^ZliRZze{WEs{Ech)wp2ELQ39k3 zdKA35$|?_3EuMb@)NXVlJ%nCqObO%3?{^C;`AhC-lTjO!gk4P^*(fM63l6m__P#WK zoG#o5r-1)0UC2F77ZMGaD6*Yebd8^;=l5r%P#KS9*9B|eis9e-Md9Q6Yu8YWu^h!J zRfToVAa*gz2S(wehbVmCoYAc~_cf;Q@t5C!>U@TA8BqAdIX%6boYRjfe0BN64HQT? zYb(31)P>3%22`H*&EGYH3KO0*HiXWpm;Tu`7|B9AN&KffNy?z|Hn02h$j|mp@c?;q z`cBsfqa=P~d)5bc^i=!7Wm}y>{uOqO3P=w+7t`$B;euLfumPL(W4%*FH%t#SlEoet#mraGlYJzSbCOY+S?!sAwh@b?oo>mn0f#u!pw@+36}tORXxrUdPOT7nj0_iPfn6^ntvT$TzeK`%uy z`ax_~F3P88*{n?vn-ws-Whs@8*{lmHe%RxTM+jA(m3=T~Hz+}0CUu~8InW$6yv}+I z#^BP-&MI#K%x?WlCtwU^JMMDl6#_0xR}F~SJs%wp!iDYAaN)!?9ES@*uyEm*Yd8)U z{^%Oa5j~XiH2BUv?SHJE74uW0?QttJkA z?{KI>Xsj7!e94SY>gkwqaE zPII1V`0zD7ODJm4+*|#485u;!jGg6*ls_vGIe`>j*|7^Lf(H*zk?)+8DP5!jyW;yi;@hQ}DbNRjHW)50z^oXgl zn|Ob2xzUUQ0LP~Dajw!cu_L&vCYoHM9yvXrB7y~TnGsqC5`?U&uOZ%{ctq2cxsNq!Nq zCY{wiwuif5&qv&#n1AD4-PDlyd26tQ^kk8~`_qJ_w1QPpe1-#-CL8<+=haVegclZ{ zIs2;uz@D#t6Vf)Nr-x(KDq~c!KM4lLYyOpHleigN8Va8q1AJg5Aya@gUCc;t-ePzX zl^%2&EFpJb+80MorDVH>VRRd~1B{=Tq(wWOyuA&Ah3{ES1W?r6HytDIwEY5H_GwO! zKsheCQ9pB+m{1|Qw8PJHx}AFE@ZcDSu@G95=Pw23N5k_60Ef{|dNyXJ1~K!9*clv# zV<3cMeV6qY+o^w&0$nlpz}rWOk9&yrBi)D~OgHUsnC?*+4`b!Ur0jpkNa8+WBxU@@ zNCG_8xfp)HV~v5V0Rqe#d>|cv46H%!Y}X)Z8P{^_c@My2eHAfO5I?lI`cX^RRvgA- zb)4uG0QcT9xbWsq21o;MD?f~GDt%e&AD5CNB=N9(L`NtwaUT8x!moR8MW6)GJN?c5_td}=sDZ5Rn&IDHZ#eUD z$AZuc!~lAyANMCgKofS%zTMmUhTN+14fC+4vY3+j(iOAyoNYd@gDvjG(pwYGU(qJP zSs(sF{%d1*1Cg5>Jt?!>ky4X7B~%S;bF zWfis_d4@&3AAbc=F%a9hZUQO>jYxzypkgR=*J_!GAKWL&z2)V zvS7L);HHr8`uU=sYe~FNEi^s4g^+?6q#ma0A_quGuI$I8q%=TEig-NqM4sZjG8*7w z?EQH+wfxs^YS_tc>V?zY)VxXtoaFb|_v3r;C6&Z0jLTL04LOIMdXz=RTf&E{s^@de zX08M+F>N33rUF%1roW|?L`eHs9!Go9B5NZm1VUlQ-PN5;xqz=c!A^&_RU*$I|)CXU64hQ3*1IjJ8aUBVR$)ts{WV z6I9*OnZ8vU?v0WUUuKmEE%KKjmH)E$dfhBI%&y8CdqPl3{PJoog#@;c1#$Rp&@NNx zG?heEPteL2jqk)EHE^@X^gJhk#YnR^G!j?0%P#OWow1P>JYQ+6UgxCE_Ic4Oe&?AJdOsNh8m$-`m=6K_3PIX^ok)5@9r#f?m# zt$CIsXQ$+t!gJ{&Y~Y9B>HI(C1_*;F~lGPM@DNEZ_f+$ph&)y!m-f#dMf^M^W;GM%Nrykn zPHesaiZPqP^kouDU6Nr0A6##c1yGEOVaX!EA$a1_%F+W&lKMnuV-}UfB@U?f?18hA zii=F7d~>I)XX*tr^1Ao+$@+8mt(rI}vSf*?-wq!nf3^--JGdNmV^Tp}Y3@3iwEG4# zw3YgL56cCk^rb6+Vr0^|e!b(+AF}jqXHoEUE42o;mCEYPMKq^7d*efSYwtj6CG$j6 zww2RjzS6zu3veZT_yOrwK5`dQUo72Va00D`kasS0;CzFjC}|#x#f&I&hf;zyuLQzu zSoXBp#rFy5j~e{!NHeEO@FRmID~!QbD#h_usy}Qibsk{42{H$?KX^pA zf;wAyn;(G-5(2Wt^o4xn?ibqS!S2YmBo4yjb;wtH_v|+N)DoJ$nBSUAff%W-5 zo5`)&w)?6-{LiBEt|I+$U_|jJD2AntoxP3W&t|{_B}FtiL>?a&0qC9n`u=;;U*wsGG-z$Nt@8{z_EJ>dIU7}(bu2t8hTU?Af!%Vjg>E@Sfm;r76(QpvO_NH%Er%+m z%epxlVog+fJ#a=J{gH-kp<517ziv4Qeu&9cXnk78pl3A2IX)bxTa>JNyS&Dv<;j`~ zd9$Qio=119hM}IkpE6u@YcOYheVQh?6`8eW_CzNqek2hkIX(;M zO+`Eyh-T95nc6E;VkJL0@$=XkDleQB2%Kb}TZ^aV1)+*@X-FVQfIxU`$OzB8FKofE zNpcAOlA2xAyJZDXdW%%sD9&XKC7s+*v&~Q;eT(J_&GLD)9mzsR`<45HB=UG*h$O?bu;l4EAM7b;A3if#^+~Jdshe$YJh!oNv1%^mH!unnLQEdWyur4$) z=8tE5zMpjDzkgr7F-tT93l{L8U?I@$D}DvP4t%u)7$U6~`*J(;T?$YO4j%vbQUJNa z4b#pCG~1Tt`RAZ!n|g#ZR)AlJE@-yhg*zOtf;;iRJ{K>Ho)8LWn!UQV%^w4 z){c(+y-1$BszQA_lJiYDRyvmjBD62Y=8o`S9fi=ih1TY?2$F2GaXe?Xe_fIJET^A% z8_64-i7s(Ds$j9S77tmO%m-(pc>|zG0TiJVHi^@l2%ty-Co4JW1$;+pIEWOgeUOF* zvnQ3VqB3TXS4GH$ge5B$V1DsdY*Kyvm$ikB)tLanp1Gx*v$cf@v5e<2Z@mHzjOkw; zW?HEcxTng?^!Xu05oMa<(phgLyajh0kS!!1Uku-3M|_6HfI@LuQ_;E3u)j;dVyjF= zO4yAms0N{Yyw#f9Zs`k$P z=dM3o0bCUxjkZ$(f~%H4^agO%*-5hY1X^AdwS9076k|tUiRaz70rW^ilnD)T&|BcS zCFE5bktl}DY8N{l=78)Z zg<&BRz*U_o0bJGfkVdzrrC+Uw-s;V1ZQ;#pEoqmlPm`7oWUP0zL|+d=ccP_2oR~ef zw_5EF8Hrm9FhtO)*q-(CZYB90*A^~o9s1?)@CP@s-)(!=7tb1@_Z?$Z2g;q%;h=vm z$A4yl{m03_aLx$C0~A{9Nby! zar#H-nHd{e*s_@GnZo|Ci&-oJ&^!IZnutunxMvMIx!|o%(4$8*|0+8<%*qUrIr3Z)cL7#8Yp(0TwzW6(OdC60R=D4!7FBnEikFOX-(@MC> z7LqE4zf67Pvq6%ro1(kNot%t69!?^SntG*{q?(Ey{Sp$!IObY6&I{!P&oDY!g+XlH zY@6$>&vd8t;4Zp04PgrNxX6jFSaHx^NhQ%Onszo}4Gi)fUe@GwgCj*dhZ;=kvKm-b z6{JCOkQQR4t=qsx$(u<)pF=N0_d(KieDE5UNh2jj?{Xl@C0Wfbw4+1;>>7LiYCO7a zi@AC`-@5tUQZgaaynarCACth}I!n za(MD)f!}I(W5j&UE6dA6EaF9bY!h%{5Ue5Td;&q+=tbL5@{t+p?H zQ)aY8cqKKu@b|*f`@lijKF7xWKv>kq-sDzTk$N~_t)((A-cXi_k>T5#sV*%hqysTsbO%7MIsx}buw zi2IyS3cHj!8qM4>AND zYE?Fq*}n>Qgoy6m^LgE^!P`5}pk}Al`S4nW(7k&eZ5-dI-jX%Ib84F=neU!^V@!=I ze{DR#?`Ck94^}U0atr>$QUiuH=?Wps73}W#oBAyuM5C&zFkSq@1nDWo2Z#I4N17jg zl5tvxUN7som#@7Ah@A71Th_kv^&=Z}P{$+N=HVqT0CU#GeMB`8bsKyUJPk}=) zfWKikX&FS)rtqdE3BzjYE82PNpp;)16QAD~-(x?9N0^ z+npWIz4!WIk!g@aF1wq|6jEHpL?m2+a@pO1P3M)hk@Y50FT`35+W67DhZMUEbUJsM zDEQYe`=XRAK0^s4CA&UtmnM*Lt5h>1|NXt3ClXl~!W2UKQ}YQtJIroR52hE-o8Ebx z6Xv0p9fmVqjL^M!5p9fs^g?;^eXe&+x*~$XF23)^xw_!S?r3zqk9xqQQQ*{RQ|2bN zHC-mJQ-kQp^GVS^WojV5^yAwE4rlS5=uMjaJGrf4$)%O)bUz#%Rmy~lIx-Se4L6!X z3yRmZuAysQ)Crihl5T&iTt3CnEj8FW6M%@i{q+vg({CFDh;3=jhkP|HKRya3*EDi| z2x@q}WgFN){w-nMlLMS#!g@6)Asg6ub6PxenQXYKWG3lBOkN=a>uQi1C&lvm4|BZF zjkX6G+yvV43_0`u^gWkf=^72=CE6Lku}Bv`CnGfKHP1^ z25j3Rh)Mh3&#=nR13hKQFfjB3e&!k8ACE?J$*qR6>u`9GUk8e!WjdAf5@ejf9-U*Xe!sS|(IuiNbXY<4Px zWy#_J<~mu-?L2{X(K<%eq!BreuDc` zi2h1OS-jrm->j5oS~01`Y4CBdEGP~wD9Fr4+jz)aeVje9`@Gt$wfeHFWh{(rT%;~B zMhMC&kzn3Ta;he+qKTAsez)NH|@`iNHg}!(qdw;B8 z>WX3CV#~U;lS7MPJIDQ3{&Tyz{FE}I$r*KuM&8=Df|w6R_{{x`%)D8aFj}o;$+~MEG*1^?gF3Pn#BB2MA~Y>ySJ|5cXbb9Le2H=;fEMXRK)e9l|+gKF_t&r4fZWae(_A6B$rpJ zR@Iw8&g$_X-VwbJ6T9`{xd26)cQ9>TX(~o1(Z@l5K1Cx()H0`p-t9QV1&#aw*GY}6 z)w%$7KAQJxB7r&QcJJvQ8sktOJtbDK$z?zie9vsPLd^b^b+?idMVw#f-9!Ub&65%Q z_xes%ck_+g;c&j2<>#sxZd9pv%q@A++<|x7Bz{{^^2!x?H7>**>qyP2h+qFPMG`U# zJInvW-dlcUxp!f^ba!{7NP{#;NJt}Hw;MrVtLNLdCbTG0R>d>nH%BR;y z#bQw${(=gUyHCq8fT;`Wv6I9)53Ym(i4~^vdQ+jP=HlgEsoNE*wO8&#+bA|KHLHRx zlIk{G852p}cA zrk90b+7fbUO=?V`@k$j3x_KFPm&#ivZW2KvnG%0wA)9l^qniOU>Mp1twft)*TQ6FlkKD!)7?&H7*2lSf2mEt5*yB_3zhsprEE9|wq{Wh^4XNd{y1mPtC(J%c4;5fadLVwxBIE&WakzCIU>dDr}%p2z}FwolIZr3bPN85Q9 z3JFSSM+{KV&g8sKCw0g%(vK^j(HMP>#~CB|hO6GKkkq$K9m-?>g8a`PIp_e_izua^ zMFL!p0l5DAeT{pro7n5Qffp?IRG$Ng4t{^9x^>UB-n(@A4JbM6O-E_-M+A~jMT=qO zUyaw~u`>RJ>RdE~0n&qOk7eP7607hS5%M zbvaX)dQL4G6-S6BFp9eG09YrrWBdS9$!jMuM+{(HDSE{$QK;Bbo}Or&@rz_~BoS9I z`!ys^5W4XhMH-HG(m;eD1-!3A*Pabh?Zbx-~6YO zqFLRe<$tz0N-?yur)s=)PE_8|Mz5N$EBOV1g$V2CyA9v84G*tH+h3H3%(8pD&(t*-s97@l-W%qGo%vxe%FKCd7BTiNYAP zRq5$Ik9+N}m6#4SS$YWOARA$$E4pC3ys_hHXC87Z`2uw?qy}w`B|&F_Kl7FcL5W^^hhv zhs$dtp~D(D?x2I>z*kxft>_#Z0K|#S^GEGo-dZ35NlyzY*t% ztZd|&8@{D_I`2o>B2$3s-zzDh&zAJMEp`Jttsx9kdT^!c>dRr0rUvq>g;vs5^JxEC! zs5!&L9%JaczQbeX{jKH0_L~B-1NE--)0dTTp;CmMj+k*SxV93-9m3E9Mo%q3YkTZ@ z4QNNLu{|a>VO$hYWIP0kZ!DrQR{Ge}@fh+&4(#a%-_JdJWd7MM^wN^lj>7ttvM@Bk z3N8sXn{3=zJm<9hkP=xBD`T{##&Jv@s?eRKrvPYe$b z;yGnBe;wjcNT4q=wU>KoHFRv#)b;9EaOKq*ng~0)EFwBT%*JzB30H{BS_0@^@0>NO zZV{F)#MM_D z?qYU9qOu5Om{vOd&3G}5#dqIGW%WR`UTV161sc1#CS2x)Fx)CF`2)lF`LGN&SPlIw zD%-asOExOrhJ`9HtcqHfVf2kPBM{Z4BMaZdkXX0WhGegoEO|Q?o;JTaBIx>o zG`ECdMY%S}h=-l9>;U3E)xgEbGHVj;`ar)Q95s5fIO)*=)YC4V*$qPCEY&oUyp z&tj_kT2V0SjoSyYb%XWHGBK$!=uKV|jgL z=_*y2yx?=)#7cMUo4FKrw577Phdc!^4Ep2RUUG$ud{=oYZfOhcvJKq1# zhjxPhi-z`t`s#?CTq*M0yiorX1%df6oyeXXAr)Fj>PH#$_;L7R8GS>}-j=J`9Z7w> zKc`Snvtp!e6<*s+?M0PtI<1^O5a3^7Hzq7q>2SEL;09*)mvX+JhL9TkiL{SvoMteF zr;uJu;m0f|r{d{GJTS4Yt}I!l;s3e2k8>Gb&_ftOqAO1}5h|~aEE}?;6;%hudl*A* zo6(BDtuagFut(U0A?rDr+|w_~B(DQjV}FS1L(Mk%f${FhC^Ir1N>+gEHdYS_osoQ^FKYM`ABj$M#cO49T)o7RRamIp)af`>?0L9Xaq=KwE@u18iy zypfGZwNnopozBVX2{J_WlW5zkUwM(!cBa6wEeQp((N5+)T`>3xwH}U{aplv5tnXER z(19#Svd_>hr^o0&+2<%@0Oz$~Qdgl9+jC;hnNkKHjRSi+V9@>4Liqw|j+6YF zR<7O5?7M%N*#-aG%wAcF<_rr8m6@52KuRp;!6p9AT*y1Q_u4~%7n?UH0+*zJFdnwQ zh(c$?J1?mj-VhQH`I;T)? z$xT&Cl+BkWKoLY%XKSV$rEC;mnVy4(8kEx9a zVSTFuEXfx0j34Eb>q1v1uz`LNGNq~&?XgF{uqt|tbo8S1F-2Y7Zs!qvCfjz;Yk{Y6 z;VyI?W;5|WbqY9rDuqbwQBW0FdE~GxkH5g`joFD@wP&m2e1QGfnLetK)L>`_r5r62 z3>!FMSMil`+r6cR*dFCAa^%}yoJ{4EyV4N}v zGfd>9(2}FoFyml9n()ss9X4BDk}fCc04Hxrq9pc19}77hHv7xtAK_o|yq-SvZ-O&j z;jUqT@M>&Y>pu9gbCM}s!9a^XjE}@iGd2BcqMxd;|3ms|HKp-h;ZloHYJ6lbXC|Eg zsEwGH%H;o7Gy4tI%K@tMugUkdGlHp}#%N9lruqShAI_u*=5*!cx06gupXQjIwmc?E zfZaws)W6T{z^rbhX9;|!TF>!jGtrF%DFlA^Ptdp5VJ=y-zzwiP3ni?+gM1yVHe1Yy9YfK8`m4&eg z8`}{F`mpR`u;;h1L&a1L87pRksZk6AExnc}F4%lKC5C-)PZOK5$TCrSlt3&cf_m7` zX%dY>n=SoGCeK4@8F+2Xo>lpoHYs2{uh?3p2E67Tscy38`WI~#G@mPdgn6z_9bWyW zgb@IL)anXnShWyt+B>8cTG41R1lX<)l30*z|k*% zf<*bwT0S;^U-e=^w@gE_S30NtKJd}c9~$WixAIDfV00|1FJR1jraP=DwqlvWA45C! zSawkI5D$sIKj9D;mi;(%q9+Iu<8K)C9IagsVpCwI1)A2mxc4KYm5m5?D^#k6k8`O` zH$1s@ol}msL4u@)@J6-AIm_AM;ew9D#4h${{L@Gygz$@)2b;e%9ve*_%oONdk7ns@ zEm!aak;cfAn@am;kqkDf!El7PRr?E7DbFrnUO0y|H$_*czhnX7*;kmjOKn$h5zN`g znPp(k*>BpjhzcGNqn>?#+v%?Pi4#(ByOa>VWgfM#g`ic}6Kgj<#krZ38|}4UN{XFh zsWeai2qL6tvqY^Cva&B}VAje&FlKG0NTRKqEcUTU+ZN8t^l3}~Mlrp8tH%nCoX9_> zthiPJLY{oTEO|LD`AE`gs$UK>KuR3tk~cID`kbgRI)+z)Boh0`d17cF`0UC$_K+>R zvM()Nb1%6^hH`;L>AZ9lgqS?!AD9b0>Ed(7f%m#y&6g96p4dWy<-N?AL^C64aB=(B z`ADg)1s?1H@8Q(FudMi}yH5kT^KmK#*MFeTf4O|1`WX-PQz2Ttx-Qr5%r{1_K#0lF z6}Na^u>pZNc?IGy+r5j1P`bJ>lt#1m2qGq)5FSJqxCcUrR`XTFR${jLuKe+6igBN2 z!$lh;9!n98j=5dNeKf@UVimxZc($fxB2(?)_PU8OKW3eb?MGZz!~s(WFvbNhh{Hg zc1~*^WZsEQEDQGlhwq)mw;2rq+o-I~U$YDw9g^=s2YUK;gZv94(@T)+&1118I>FE+;;&@I=*#@5d%|md%#3m#KtMPU>aA z)1COa3i})d+)MLNcFqm%?|G>YD+mR(C%JS-ri;k)PI)2HW1=d2HRkvU3;m3rpBUvp|@LKu0pDSM?#^i~UNntKx*3)$s4L>ry{Y(d63 z8c`{n^Tpo`k;q&mj4CAUR~M^w_r8viY?5?qc{qLjU?fyhf#L-_RaS1aXALD*u4&c? z^oCMJiwyTqWOxQb`w}mW(QUVxHABeqpV9?M16#0Ez{hHlXRSZzuHhWp70@!Xl=MEz zQd2Pr($&Kwr1}u6DNq!rA#gM?&0x5N)s!$r48xkn30G6!?d@DcqiNxd(I~g(aQrlh z&L?-FgW>W;e9;gyPO-LK4Dm>Bg(YXBz1CQnaDj|QIZLoc;I|?Fu!`{3!6J-qQtUTo zr!wBVI#`>d8?REaH{pU0NM@`bxgC7GemeIgCCcRu+;i6gE3>YyVj)W^IVuFGDL(aL zKK1Vl7r5~KWj+pD$tinZN(QAoHD_1tLne2#Sm+m?!YzKiT+U;dSvvS6lR*B~4hb*K zk#g|h?0rgaeK4=>b;Q)yEQfky^6=e)m!Xs2n!XM5v>?BxP6%icEyPfS0U3glS|RYv z5WZgdxG|4#A5XHv@fybw;{|fT5+tP;ar$VnbDyD-Vv#VqdGA ziwTaZLXj$q3YGefHy>|`*Et~)t7ZgYmm!ctvCC(>?CA)0kdw$sFE<~vGrbd>N+y!X zPk17b&1--)%Y5|X^bzDBh8Q?Rr6`xM+h9&|e4btj`gAEpEl$h|C1}ffxa-b^xNM8b zuVPRFVX5Q0pW@pzyRbc)FNj={xyecQ1`(+hN7tn?*+=pig9F`w<83-2>PAwQshR(< zuZ^5Te;!@CXgeCH#{d%6mrj(6e38nCOh&zE4~J$JtDoWssS{%@S0{+*#NSz|XnS?uds=@oA)1a-qVH*}# zeDb`H(fqx5RnHO(5_32Xs#mu2(xic$!LDZ2DJ>2c1Tq7$z_{;)njjqmxhm*Kdp;x4 z>0l#mOHHVpriZ$7<(ciPxU*F|!|YU~7x{s~<;n|_dCi7}s$x>Jk9I9o8J!9s-~QC{ zEwjK~Fx0kKsHsxJ^Z~6m19MsXvgrwQa^W`dQ-R0G>XF};h8fU6o+&{;zPFYz^u~YY z+amV8kSEh$SwFKm-O0|6Su7-#klcD~qsR^!pA6qG zi6qlOmjvSE=ADek^v(k08%(mRYx0-`TD+Jo&%Uh5W3{)@>$Hkpsjr*tlP5nI=2a2B z4t3~OlpDOLaoEdxTX3nL+qb>eG#-`eu&=m{_vG5ZQ}d&GR6Y8dYGME0$uVM=*yyEk z0Fw15fjo^KTp=n#c${B*?;Mxe_$8&**Q+uQqWHr|d9$T{Bx;?dYt?*d;;(m`Izt%L z`LxjY<_h`GSk+5ujCpmV%ts3N;SKR0VpU*9vC{i3Ruz7FAP9c&N{m~Rc| z4bXT|(2oR&wnS^@+gJ!OHcc~MB>J!RK308;AompS$owik@&N1LkA@?%UfmtV-b>15jR2@Mvk z*uqv1`BqQQV1w+}y@zASf&y(i=ZuO5TstS7Z3-rFR<9QF=@X6BR$4-BzC@l^*%)Iq z;*D%xR?a)f6-E6#kw{#1U1m_{=9gI4q-jTS(C161CMM*R8hD7(8^!<@L z42zL`%#N5FMK7r!@I4WhrrjOM@=vS}q7AIZva-0#Adii$w4O!QF{>%Idqz_91?rFe z@>ZQiM0j`H*BP7R6@{SH+$cpCTNr5IA%bUpM3+|OulR%|H zSmz|8fy#U>>1P93RLF(eLJ=D2?H9ITiUcEpx@*gbDUxJOD%V%C2R;#~3_&9{xi4bh z*zy{95vys(J_1%=A)@jTm$MvQR|}jIjGrbJ>Nv7JMb1iNIX65i7DA-t`7d-Npx3&_ z;pz@#TEtb)<}(tyXPl9huk!4b`AMRR>~WeWJ~7uREH7=*7iI5;-54eGSO@3uZp$Y>#!(y~X{gRzYyvKBKNl-n!d zm4i^0wl*8A3!qMNA4whG<;4u@I3#uKVcqKKVthG1zwr8Cph?rC5}}U6I1GME+kTQFWVLb5KbXp(Fc0d z!gL71*ezS*bC`!nSh0BwF5zIyOR6CU#(9=}W!4sfKST7NvZtuxjhZES^oFEGhaPVJ z=w*OIEX%lgw~WGBg3gD_0f(_{)&uQW^D7zBD>YohQq@loeq)O^s&+?e(8cNF7~duI zgiz}SO_}T#GzuU{rjiLgyPgs#V;ccy)PMnuilWH9-r`Zksc%+=q=a# zWP6M^TWeBu>LSrZg$okdPafDD^i{eQFwcK`IxT?9F5QUU2*rcyqln&*2 z08@L_P6KlP3{M#)Sl=qjn6&1dII3?U_bofudig*-0za#oJ`>#?%5vc1w_nb*z)wfC zdcmQ$0G9ug#Q^?dmY$`psoozyAmIQ#5d8iQ=Ku3R^xk4{{m&M|LqZIzomM^ySy7%j5iSuQaBJ_!4z`9HDA*Usd(G@h0 zA>sT8ugoJo+|OmMA|{6C-Qujowol)sluLL=KRB~TJcCH%dzc?=FM#OQK`&EBT8Z0CPcy4r0ZgjNDpGG9%f}#!00cNeM)rDrN z2hWo5xJ!PIL$P}A;?T_B;!xO}jwED0a2(nYqh+fKjzgnw^NS-PTN8SsijoM|%Q}EnnaX$LuS8rg{8T z8ML25B>E9v#7w&4q!Xq28z8O~_3Fv{WtU?K9!r({RB3k~(Px8r$>xDlyl;AaCC#!Q zhk51S4ih}n_WO2L#Gs|d^QPW1`He3z#TFvS5G7SrJD(5!r)|dw;Rya-M7`gy7I%#@ z+0WkO!IQ-C7Mk#NP|TgQKfXVMmD5NHMs>!YOxivbyn6Cm92#1D7l)eO#-TO;FXB){ z(7(i?Lq7Ot-}w54ix2bY;Jmt!7sR3B8H+GO1w@%MTbK^&#gwZ#vj`VH5;4i`9aC^5 z#-ByoP}K&Ny^ksl^%40h$`xU&S{5@NQREHkCn&rM#e1GV=}OpBSUE}f_MCZ|F!I|A z*X48Qk%XfaK{862F8-J$jvq2EMQX_DKhOh6B-(@sk{%#(U99`CZdFrUcl}!&x|Cb3 zWgU0au<#X?*S{6E`>9dc>_BVVb2!}I+}@l3*VuIL9XMPs2kiK4VT2h6L6mmECh}(n zNU3dFf5f4nd<2qor&D6pr|t!i8-@if)5N$hOA9z{;R;pT{l}*5gInG<@1H+QDzxAT zd0Yk^>7JpE0z&Ju`_`=Yf+89&2c=;_>z#TiNz>~(>MGdOp`gVoh_K5CF0c?oC)(ix z^H-hWwFc_0|-`eu$+dbWR1 z9R(md`2C&g)RH%K=UwSwUtasDQIFN)k_F8O|dEtBSPBG{!U~AW>1YHKrm&H4>?Yy zh;edFL5z5j=oscmrJo<+x3hYM+N68POT`FDKXg&7%;ePLeg0X3|Hq@yf`ELK!Xyem zv8RxW3!N=Hoh>aB4YEFaCb{^htSHqalc)v6R|zG?n6YrLQ+r+2l0QvXVY^5} zfqEFD)Vt8?_{-LVPy;QJv`6#3z0~Y`9>JzWB~98Ct`Eczp z^jUZj9Xdl=*(%BC60h-wCC(>Pi3}ohJ3>Clr0F9g4&64+&4{Le(dLTmXY+b)MsAS= z^ZU${v#sfLTF_=~2`ZyTxTjpUe2 z82aGxCBw|4u<+0i1l*eQ00ZM+@20_Qwh=3$3LX0Ddb$chIk!!*=0QvQWBr;1L_B`C`?Lpm&^Fz6Amfp6=bnaj?)y8mtI-b_ma9EM}C z!+`l(s}*dfc>oT>6NMNSL9m%7ceCZ<)aYwWx109*-Aro-%rqjskkVWtu$czO9U^gK zrWtUiJwo%}gUQhjL_G(vKF;IwRe-6n1r_56hMC=es9?ZI8N#L9P}Ap7{4gW;<(pHo z2}XR21^A_-&QW#I2HG-3g^IJX`qjU z{Jsa}88t=ALex(Er5V{QO-4(_6sgLX1HOASHH&bLOzfGND&y$`s3bat!_ZY6lqIrK zH@`lAqt9+0sJr@Nwnx}nPYZOGjcDq&bWCu}0d+wVP#40s(Iua3-YmKNUFh2GmR#YL zf+Y4dsMjxT@w%qIry#fHF8f@Pf6&pi#w*tjakgM{>si9drisTvhEY;%m}1o)jWKq=;? z@`;56;drNSzqzWrX7#wCH^IuF8p{%f8D}IUVtXxkUA4sqkx?6xIhiy*B(R zyRp$#!AGDy%${oDN%E9Ti-;c-v|E6gM&^*CYN=8_r!gvw#~BGW)5@Pmv`jNV3ZDJ? z?TdvB0M@_j>xTTVS>3?U-p1+=s$&5}2fu$%{SP-ydDGGSH#aTo?{3;ZXZ7LA6GAj+ zji=5rt~Qq8j1$r{(;+ ze>9E4=w-4IveIy_v75xc-&nC?%o+MZq>-x(_N{Te=+kLq6eJ*_(-%TKQ?>D*gw9ZopvY^{;+Jc)RR_owL2EJ} z1&0=2vR`>DRXguSKNq}aBRO@Zcn$(`K6h*Vm+n@&Q8(S4+wZzz*%8SaO9(?7o3VdmP$^}rp6zm&6EPFg_ z1NM#Mo-_i!v9f{lt#6DwdS>ozW@klR%pDxVk);P4Ta98#KKR|0J+Vkc=GD8MmVTH1 z>0uWQo%hT%osYlCbXOMB1$ULwz34d1Wm;8Smj1a5bL?2F>G3YfPLdJ1ily>XRvRq1o+0E0N>bci3sc)bMey5Xo{7CedF|B zpD>v&eN7$gpO9djnpQQ}7>MOJE$sN1QdqsVt49yGM6y>V2w6L1Z^&kY7CtO%sMLua zJ~5A_`R*+S_Kh*XzOe`FPH+f1GC5$Tg`1}2m;h!PcvyGjVg0*rd}pSq-TTJ3X4;>= zu`1X%w%1Jgjq1%VswV)bO>^}xO{)SYjfZA4a-KC`X( z1@ztnYSI*%YQftVNM0TwiZs$wo0ljdlrI2OM|+IH*gzi)xv&T28r4kOX8}X~B@)@p zRwg& zxZmi;U?J^ZH(tBZjmc34GY~%fau6YK0)#Y!QHDQ+G#1UImKZ=t^X8%d4Cux$y7;SJ z|E3#H#fzN%MK=a@Wiey;?EhUi-uy#1rUP_i+&6CMfTI7WZmg1C zbFUkZ{Y^LSUcb?eM?;E7{zW&=zt@c)Dy(t>x-s3~b>oP8-MIHgH lXR7#JH$MNL zx^XW6brL`~&Ws0iV`W{u@pv%QY1G6233Vm_>N;g`7yk?DM)vkL_J2Sf4*)v&{R8U% zWmISRi*WoeP`@43DfzcNYz)IVj35-)X}0Fxy8WE8PJKZP2h>Ogv5Znt<}4>qh?i#2 z5J@ez!hZpq`-U`{p8Fa}Ay6X`p!_3%`8ML06;q5fp;?~l!0x_6m4M2V)}o-5AuP4* zQRC;~_59;IRq+}Me@H_QY$Igp^zVv%H6bIo1qgj!`nWS@@_Lp}Kt{H!FqF3e44Nl5 z8aRN#3KaqeFnZ0m0Sr7-Up>bLv?|>4@H+OSLu{xrG~22UD}5*&W^cEEC9v%Qxk ztciFltd+^q>7|Y|Q*~Z4|CX!N^mo4UC(u`bkETyp8slx@4rV%O6VM?6CUw!oI zle#IG>6MRb0j6U+yt?a<_hHcS!!2)Z-4j=G)8`v_@|_Bm$D5Hg5MF z61&>O(SPZX5PGmd&mSqYQ4a4MQPHz)jy|?v7eOXf@Uij7Ph!apB6QAe-omim)OfSK+IyOS4yPE7s)VERVNLz70)!E48+o+L8*S=Mq|q)U zG~-pELy|zwwE3J6%ycu{_&cUAx-SDvM?L(`C{4^1!JIzUd(ZT^;Uwk^u#ZM?=cCE> zdNc-GG=Y7zy}tx7erI{1p9Z8U|9b!zE|RmwQ~8@k}nRbP3Htv{)Wc-B3#ivU(ObWR`{RVZq zNDcfT7A1zy`QM=qp3iSPB)Q-YNwd~}f%@^kLLD0nb?V6`wbehN&XMkZ5B2iD zL7i^lwnGw}%WnP84oTfT)VmZ`odBrk{sZcncO8<>Td1FeTNV5c_0InZ^}9*k$T9}p zA-SK_Y1IE^QfC36-h4KW^}nEQqGx6GXR1yF03H1P0rmersn;X^xBTUQP3ms{aZ=Be z99>FYMOGTk)f1Nw_Twm4RO#5}VxeBPI@L(QDq>#d6Ri5UQzt3Q zqYt|9artd;0{WlEQCslXGP?Xg3sj!f9(~!%?U9p}?eAutR4K;F=|Ox9Yc%~Zw`20% z^!p!0|30bP-%si)z@(1)+oax-c=%x6_x(;n8JOzqFC;@vYVWANs#qJkIb0j_tl%%r zKzp83{nO;-k8srK-zjkb5@~9JIa~iufi2^LGr%%V_bxx`*t@rk6G!_FgF8_m zhQA#5zIq`J#68i)@K~|5r%X?~TYIzjaqAhF1sOdEfM#I&>*QoNu3>O9aCosfvd?Au z-ZBOwkQN89T~40o8Xrf2kd#c?mhS4#z(S{wW! zKy>`;y>qF-6|Oa^t)+MQ3lz5|^)1zjMqzSV4TCe7ntxtS;ue@E3CSnp%rC$NzJkIh zq&6MzEPdp~uT#n)aZYuqs8THS3f&?ugmd@x-m7JMS_?h(=8p38kH1ngF_D!^T7I_r zJ1|XlG(9w-T0boD_kAy}){1b@8XE5Ji%k%QSCA1L%TuK#pU?fOhyLynrTj6T#1Ppyj6_Q6euWc8_q7VaLqc|F-te{9b~Ti@FbiI#`OI}DsY z`gFW}zhJ@R{mn($!luXuA!ANq86G>}cE=1)VU9-MJ zbf1Dlfm9vwKto1T{;n8ksnMGVE(X3rP#4Oky@UF90P3|e&Jy=fUrPSkMQ!-WH9#pT z`}O9}aV=ldgFC3NEBgHg_1INok^BnN3cTfb#=)CnpfCyU#I&*IlesEz|o(;kGSp_EaIoK?Y?2ip@ zrj!Pfm=11rA}@J0qND~z$Op61&?XDg;+B#hnQ{m~2#iIZ?VGhv%Xl91L)37;>S$iI zC7EO*QG=y2v+JGOE5vo{=-!*H;r0Sq){>ri6Q}wMsQ}x+@r0Or+ zE#V(23jV-eP2ew}YDhooOgt~mZ9F_HTcmw!|IbvN4S@QhMsrpukgA6RsrtWNKLMxe zCYFDU>0|)S!S6p49q0vuvzI{8+g@N+FwhHp@LSs(kh+0h;CS5L;P?8S;)8nXnPb7f zwgTUw1eUt!CC$by=TH7?E6}ME+zOn#Z3UM8wH4R|ji%{$!lCzw_Op)@-k_PR@fQ$G zJ|yOrzz7knG|_4Z>=?A)RuUsaFDx4>MaC@a2W2edFC#so3Cw2V8gMxIL-N>f8;=|> z8W?7Q;|8`~7}cJ;b)L4xPAu4OE@20eJvR6_x}4o^Ncvt} zK@)0&K-Hd9V6MS)GNta!?4Vp-oiZjH<))jH9Z4h4!!P;S#TA63-j^4aN$wD$A#ZNupJ(C zucG##8W<;ze!2+md<8LF@T*r{Rf2n*U1|zDC>SceTQs)^z&fhFBFIDIl$Bx#KK=Fk zBrw)fKW3UXnRKrPbYP$Dx=IROer&-kvec}ri!_rgH-j7&InJ=$HsS)QlNdYhx;h3< z!X8$6umJ(gEEwxH8-qs>AXBKpSnjv<6HBVtb$$^1Kq%3 z*5m~b`9U{auLll^k$d=Y_O%n8Ho8vR z)kIh9hBtR)W)}QPO}*hdS!?1A*YVk+9L_-^FO3`NUWU6Z`k?bafe|cR4>FEF0s#VBC~(lNX4CW z3ts&JVA9Tbp|~!+G`(tg^fZ#CFHq|<4ipf!G--Dc1t!el^g^7w!nQ~rMz3;GMUyWe zn>F7iFvc9vLqGyU=#0LUk=c*$flVo&(4p1Kjs$0iJ}uB@G@zs=)CB7>ENTiQFt%zo z;PQx35hua;eR;&GD+{Ou3X)RGbdX8gRRWd3f(nU|wPDJx5%93C=;&B2g#ky7zjEz* zGpy&Am~!GRPcq8u83ToHVM$!Ikb%;|<&U$1&s3@*G&B=kFU~*w_Pw z?-qmwa00XIvrkP9ryoB*08|2nfl8q8Z6#12s07mgQ3?EfR|%X3DuK|qmB5#`XtP5w9~FMoBZazZe>q?b$!*E>Kn!7 z>)D5)L6cjvD7YS3hUz8Z41!dI_@)=j?;L-W5N3*<)honc|11wZj8-H5G8P}OC6glb zK_{BwAy9;bNV&ZF?UKi10PKFMyv{)Y*rNfkQ~b+iEHK#3ZQL9j%?vF5z&jOycJTXG zyr+U|-+zhL?Z=#Yj7Z=3f*0*lzZR;B}S)O;c z%=ISE9PiuaVbrmE#$vodSB39&WM59zuVfo|rNViBZW0!P7pK{%hR>X}Xh0LCU6oxd zxhj7A+k9igfM>yx+X`cXB)eY)Nfd?+yw9ED1F z*9Oe&95*vNKKPnPOr()wZQ$l&UTVPYHIHF48Q_}722<&L9lOVuJ$WCkID4gbo_crqrr2^C(o@f$zP}NCG59?X-?oQSXL( zg(TLoWO_P8lN*Aj#*9j%k4r~Kz*}_aaA$>bmSyEH4`z5l6pv!edUVgYyVSwIu)jxaRELGA|^|vZaVDmsd zpu)73G~0%m`7G;kbQ0pf{BX4$4X~XGV7rYiwAd3c+Yc=b6xW+cnKg*0Uz5$PfqUQ0 zx4rNBxoS|a))cNS8?%{(5S?jztBPguMe!P_&uMRG`h7Ry>%4`R#)2#_ zMBTEz`G)POJInYP_iWb$vt6ZhT8@eE9l&-0#vS^F(3f{?ukK$K2ebVx!@GzjA}e7S z0b5p%iwPRaZhRv#CN(5)+~BDBuw_&+IU6Js2=96yeHx#heImskWCT$nh<7WriLC{X z1|UwyOwEF;;MtUv)*KpxSRekLuBQXVz?3z z3gNd;L5sSndnex1z29aJM8K0MfK3<)Os&UGd-DKwZ?7A+(7yzS9{3TJxFV<5TCuO3YaZXjB8s!j5sm5ol zxwtkAA#w{Ty6t$Qrrtm7(q{GXSwNMPBU<;yBu@a@E!!8^3TfJJ*zRlC`!g!5^2s%O zljTSC;d*X>?QwT(-@jq|N`XG9x`!A$^U!hE!_8iU$C5$&ZV`0PzM2tk(iTiijKzx| zWqnCOW$B5f22PlGDR^GP{;9%n0&MU98S(<0#QdkeH<;~zInwk1U^@8ygX{k#UH`vU zgsIMos1PB~WhaObOsP)BZlqA|_oVY}M$8IjuV#HAM4}592fZR~t(FZMbbb*2g(XYH z$9=0NBRnE>pip%7@j{a*GgTb53}JO;)iGTAr{y9uR@?;dS>SXlAGd-wRZ@aC^o399 zN9?hs?Y+Z(#0jp-B*R(47s)>JLA+0vqn7)6+N3uudArJ8!wLC_#px4=bN%^1{_+qe z&aVjvCT-=;mv|wukz9fq1rh~>0}1l4A_`DExiYC zOa%pL&NXEZZ#JgapRk{t`))k8FF--?IMiPF%9hTpyXzw27+Kj=eH9>j%XAm__d3G> z)6b`MG>h_2-5X?;kA;^?VVcBYG&QDGntWWw+XBMSvBRC89e#QDc%Jec7GQcFiY%Zv zy58xH4s=_+aSedpC@z)~ccVAXztWfcg1s7o4%Qn(ZkUcbQJP~4;#&AkZ{z^$jS^Go zjCpW?-Wb?2kdAqyHww#{22<+^wAA3~TLAOA8Ydb#w?fE0(mWMyc5ML9>m>{e`bxuto*E+w;_s(kx+u2QRIV@1zk3|zuu)^nny(SV z+H`3u641KwD!|QX!cPmBk{^J#oq#DZwUtoepIc*MWE~*qt@YLLscHMFZM;_ z&m5)`$YH#gBw*Bq((ZGZzlZDZZgLni*8ujr9EKVku6GUnBU}gPFm)BCRe0}!15JA1 z15LsNxZ}XQp1hsH583q`nAdYHJ?k`Gak^8X2vv^`F^ZHpcE6=V*;+4*U?7OR9t`lF zT0dDfm4kHD_=G@^<_su}6z>^uy+y~+-egF>EZ~6n_?hFj>>Ud?*c=-?70IV9&sL2g ztaA}K>h#vw&e$2k-sTV(vKM&@wRt`xij6GAL~ZNl11CI|t89Q19uPQ0!wsBw2b#+7 zPIx?o&3gfy@MwJAOxXgQ@Gy>1wE7ye+J(v%;)09L4Bg>A2|xW^g(^34`SO|6Ti#fvXZ{VcO9svJ87 zZk)+0fU}Nhu#|OKDGICm$Sq&v3odz7D6-?PJ*nE`DKw>Y&zXl?Y%W?I65`uooT!G1 z(3=M)Z8FG51W6583-9KyA^v1K55V+rDB^|x#dJ%X-)412fal=%|1%ws8@q!~CsNT> z2t%KxfG^PMMm{nYiV<1xQ<5MAB@~i}vq1Mj+S76~C^MVzV|T5`E77++Ir^&D^{mr) zGVKT9?mQ(vW?xhm3TRf_9eQbOZ;~ScslVCkQ;^xm4>?Sj^8L-;uSKQ@5zY6GTwkrh zSP*N=m;MN4R%qF2PfFhF-dkPKqjjuIGSCv}Lird*g*#xXB1+0E`q1lfU1R8)MfHPU zdndL;)f0ys{ES76=vd3zbF_xq8aP=7Zb?kougaNM6u1AhVCY-}RN!>`n_Yg5+Daa} zH-ys5o*(un$__p4dbjXl5q2HfT;HFRzL*aN#4rEJ{fBpX!DI*DUjOLHf;c%j)-T2f z=i|_qbi>zUL1e!~4hd`2;9vyL!B_W&KY*|9@k!3=g0Anb?xoiOSNFj8nE++|^Q7u! zgHHA%cM3aApLr@D;676xaGz;wv8^)z@mU@9`FhX$9gJU4%#k>%aM_?nZGlLalYo_P z^Sn4tMtyVN-cC`aE6DJWw!0_VJSoXu58Cg5KOsje5pNEQD@up6m{#UsCf;TEYJt%F zw$!2UJ8GgvNW3<+r6QgxG;p7(eZhD*@a8^K>I06BC?JCYA(wDoJBjBL1w?$v>A1ho zgmGS8V~Mm79>*vX*%;`FgZmwQzAbT8AN5igJg4`}famm2rY1s+X8q~1mc@0si=f$q z-JPEI-Mp_qFTPYOq0{p`8}>nqZ9(i8|1e?KAx)yilrv7;$c?reGR#rloAG&ke?y@6 zbGpapsmtuBP%~UwM@&^9TkpKj)|GI3*sU+Y*?LEp&0V$*+-G`+f!9Z$%>~ZZYk+K> z4UQ^H{Vl5(pN=pyRt1o)ORf-FQZkuJg@Cj5&@~8WAX{&n^{u8W2!;h8@K_B>E=jsG z)~Aa@IU|Z7wL=jKJ)g?l9o_o|9Nn`5j_&o`9^L!&@P1)xbh|LEkQkZ>0B-0l0v5~? z!S5DK-++&^#jrKggFhCgtn_*Ke_fbf0!R057p7ZxNB6{mqkDf{m?i>8_mqI6d$$Wy zb>QgU-NMuiIJ#$cdvuQhIJ(F1$I(5ndho&&>90rks%$lYg=xpXEKDuDZZjBDAcOgf zvF>$itkY%8R6pwb-B<^Sn!lX-B>^MpgxaI$eyO68WXX1+L@ZDy~|)s=d=&Z1$y?be_(gE%bZySAT=uOtCb|*WH1}&HyI3R zrr57?g)xJl<-uXW6T}uo-RW>6>tFoi@wV7_+-aL1HeLVry;DAb>F2N*tzcz60?1&< z|3e02t7mEC==kSpCRPCH;P-c||Cc5bipBqM*6;4AQuAxoa+e3x<~0Kmd!>us$GUL* zt;uXeDh`EdSyh$Q0cYSoLGp5Rcg4dwI#<~3cf``h;&Heqj4AIDAD}YWEA>m>JL~OL zj-Bk%8mQX>$)ho{Kd#3yExagh_XKH{C@BOheegC!nEGe1?yfa<0{BviTppCAs zTKJXK=f+uIYuQ-?JL{os!#B>l+?}&dw;ala%DD-x8VelW3tF!m?$hr$49N4drs+^w zZQb`VbtIf&j(jm}#=D#z&hHHE$)80A(wHZ97BI4WMatWV2-uC7Wh9z;OT1Szlo&bI z#elO8TvL^~y`~!U_iL&kz*(;(b#Vop^{$B(z*)C>gwBvP3U=0SuBigf`Z7`8Z`V{g z2}2v7y&Ecfc;l>JL?$#Jv)nlA6n*b3-;ZQC@&3hGAK=f-^C)R;MwZWjWcwM$UdX!n z?y)Y?a?CGglRl#*J@$c zRFU+w`?4W^+V+&HC180a(Q~Sr9-f@es@h3aMn!<;uO~HjPdWC^*o-ekZQ2A z?sMm?FXu_dOJN@Z&bp;w!0*m_u7(<-lLp|dV@LpYBNqmH1AQFi=^m6{)Gpwx`_X*a zMK&Am`}(&N`~AeO>p2w1h~Bv~+g~ zNOyND-QA&dNT(nvAq~<}BArsw-AF3k;+;RhCAwUDuYL9%=bm%Vag6C$e=Hr};b1)T zozM4qKaV^$idgG`Zdt(>s85z13~02x7?g>#mKb>cj5)HxO5EHn`DlplZ*#zs604Y@ z`1@1#bO;VlzOt(;fZ-}rLI@j!GL51u;zDyMAVw4F1QjAL85LshOb%GI#cMAn>(_sf znbJXICapBJq?fp!Q}^HL&e^huZD1g6Ktz_a8>~W&Ce-OJ9dAwIR?~p_N#FKB?C-F$ zRRIHg>d_PVX>#_9n3t)FI9@s(nyqMY*+Ice1IgA*Hp4+~l#-X0ym+xt#aEh6Lq zcza#<0p8xgHE+)|$HOiV!bCXnD9t6>(Sov5KVpTy4Ph$10Mc-)~ltxBy*WV3s)Y0d(C5(DmQZR6+iW zoxzX9Iy0c>pyyxEbPyx^ALd~G#K``2yOifIw@Wci)Thea`Aid-3p&IY$PmqAly)H5 ziG!`yl7Mg{_J~W}D<;OLS2>u@%N$Jf&p8;7rh8v&`i&gS-_!IQ6T^=%d6XIRpYHZK zW%LkT3%bw^L6sT#nb9$MJ%_mq$0GiXpZwq5ZD2KC(05CSk?jHRG6z6=oWZ+3#rmvJ6q(&Dd|<_moLF0oec>Of7% zPa&9@pYhoDRQ?i=Z4cnFC;kOIcEa!R*gppK-FMo(AUw7K+_PW+k6n6&$Nr1m(m3v$ zgE}BFW4gMM;@=1L7hi&RNiGL1hWml5Q3z*e9J#wU?WqPM7jWEzRVL@iw$7DWCj^A2j>Ik%Y*OcOHt4`qlq_YQ13DNKB!-YV9>iM(~v-edL=NZ zgF`oEsXhmG64C^)gtUImPX#R@>5W96Ir~!Mevu6tET@}(r*3v^?!mqU zhJDdE$1GMn{s_}ot{v*+5$n6sDeBd7jO3Ap%|8TPsMVoTZRE(?j%^7G9+Lnew#SMM z0a@UlB6&t$3f_WJ5OlqUB3Q4KW&#AEao-6&%GvodoI(muBr0_92jzg}0#9rQpi~1# z=B*Urwql`QMaM!LSt)vUR(@=_S0#VvzPwR41vDl^>ju6}O;P{Ps67M_YES(?g4$y& z>Paj;|94S)qyGSp?f54=_9)&YpZGOuFTbV0_}vZE9{+Dpd%S?46OVO>|FhjvJ8N5$ z8*@54py#0HU(odbf9Ld^?jV+-Ok_nR;pRTFlrO?`;^>3;d8jp!G4inp-3aLe2FA6# zj>Or^ArhCwfZ-TZYYh-FAiCrdpb8KJgg)3_mL8aS@FvwXCO|8sp}W$sRBqaBl#`^F zpw|@Bk+*a6(bVHf^-ft^=ym5hPR%b<9OG(4GvRU6r*jp=NXG$u>??q3`n^!IoYubq zP<5x4DK!ueA8F+>)dKOcQ>0Y@J~qjhh`ilact|?-Q0SH_wyvtCOqt%z9V{AqF1UJh zE$jMMZOTJw{IvoN!;3MMqj;jTu3DRSXE~oDYljRFGW4SAYH~M(qb|z$VC~?y#7CJa z5pFYBf>uihK&zz;yb~u2P~TTen>TK*mPUO!uw~UlCZ>?s)@X_FiG7HG+`LXu{^=8 z6@;+F2wg?e2!m=f6*pqX0syL(cUV^efU43W?C!4G&L5=*mKHRL5LL}2-SU}q3;04% zXFf;8hSjQ&kI>$*(W+blRH*=fsyF~py$b+TE!hEp>bVtI`7$%l@m!J7hoNetjjPy%`C4bS(6I)3rg!RUa}gGaBwd+J+2wy|Eq5&AmY z$o%orQ(ybxsV^FzH4}<}GB7tv4}icr$Wza*0EB(;d+7l$0s1K5sn=sB)e_$D)Umo= z@&D|pFMLFU<#YShQwL!Jt~_;+z>6Ed`AbjTTKn5?J#_?-r=EtXX?DX?=VUnl?y2wp z>Zx~JdFn50EN1@fsb3NUEXlBLt3P?_ssGede>y=n z0eI>phL@hYft&!yQ%^*n_>KP}0LZ$|9c*Co*x95{U*$1kKjYbPXLF?`@eNu-R)U)rh0pEsTZS4~Wh~bsc({`FUD$g7VOIl$ z-R3_o>@R;3_Ow3>JNe%ccGqiRulNrNd(VF_VYm33!kz^Zc1)nn#`4Y~sLe)c@zzhm zZuoBtJJxq$pT83J=zl}lZ~s=2`1yl%Sce~@5)!wjIqzG4R0{6T`LyCT8(3SW|7(i49}f?4_( zNicyR5)4p){m)4-Epq=kBp9#d|9K=B5kS<>aX6X&si?bH8~o^E76t?z^!zI7|0C~8 zjqxPZ6ZgIHx{QxcTK1+_Nz!yr1(f*NqWJTGayLHan%fqbzT^R|+y$@?#!CEmwioOEWrO z-Y@!1@nr1BHQO+g9W5$bwjf333>#p*G-L{;cM}Q#!3-q)W%1;)Sf%7|)=PgXp8N;S zI;eQ^|GKko_;;Q4pJR>J)W(?avBtkoZM=>(0@TLqSfixW+U@Kn z@m|pVd4(XnSCzh6(7w<)2=BFhh4%`$!h1CWAQ&3}?2c(9)`yiB<}dyl;=c(+7%FHxA0R4M7B zkmmGA!@WifNJQp1ghCso%NrXI^UPG02RV)o9Mkp zz&+R(+UTud+s@#1qH|H0h~AM#9e(9i2Ff73R~9o2NYp7nAegc|)om$3Hk%aed)*Y* z&18t(s(Z)S9jzhr>)GYL>hIdRMI9^N^^y-cb@qC0er~!yiXS07@!eVXzjoG9EC6Sn z{;!>N-P5R6I7u;D3XH&v1=o`Q3}?Oj|7&Nx?03$(I3VgM`79Ct?5fo9#+)t*$T{fw zUr7i2m#U1|8yH^JV6-b!9Zl|ssV-guWM6bIvoDvWlc4O2{-3ii_x@h?#s8=53+ZpN zFV;Vrg#R-8f^(gHx%bnQ{_byQU)KIxWM4p?ll4JB_C@4xW?xJ|*%zMytN?Z2ryvaP zFuTi7*%z^YJNx3Va-Dr4zskO}{2SR9x0_S?AK8~;5ZQ|!h4dZeGw_Zb2=mAYQ1*qe zj~>C~&L7zq(d+C>&{g)u>^IpL`hPL|vONxDU%>xX_C@GFDf<%iKQH?t2?)9zp2RSy zYw{mu8XZmaO)L$q{#YxO1q2=R{I95kL|u=f+sN;Ru4`jZWnHyRX8pjcZw5(s-@|kO zHN;O+9LzO=8saJRE*s*HzeEJbFL%hJ_w9@#d9geA0A<4bRQu|t=Hs76Oe6&LsO*6< z;V?IEP?>O2^*n$MDBG%P?pD}-SV?LGlnG0?s8S@;eu~GKtsrvB5EWv=9+eI4?m(RX zpiPi*f?e48WS=|1H-($y6senPGN9#Fr3c(N28Iy0T8e&m3|?Wk%TUdawn@{U+a_ad z{QjzKvK!Pk$^9?1O@cTue`=e&!GR%}-B>nn!xNQ%G50o*5COo6s%#gX99wVeG!A?Y z+;MTosA{S5L?9MYYK`i43WnMJd=XK1_Ans5$eg3L7DYocL<}z5$602tkZff4sa*Zi z+(k2?BV5(MuF{YW&BNec1A%9LZiwJjvW~s6@Axpyc5F9%X}Z!)8#o=G-A@{ zL697Y>9uAJX=9%w+8prE8pvy-SmHA~gJ$C$x?9zO#oJu@LJE9pKFWXsgjY}ZzQn6* zUgOoNuJG#U0A8I0z^gw8@ak+g@ail$A80X1ZkG~h_k-FdJ?)K?6$@I{hHcfqw@nJ< zbM>mzr1ma;pzUf8>aoJ^j90V~$Fy~S5dCZULacXjDpoVxHSs9>brXGtDHmewLzX?pNt zo5*}#yi;mlCvZ=Cu-^X2v@osw>wJWd$uW%2AaSGNH%$~_TmTp_w%=t7G{mdhs|T-1 zV35(1RA;IZLYD!mul^Sx zm;nF;vju=)P|H9d82{3oG!O`;2Y%}}3rNy{u*dZqXLv+_N?{Y&4_SbT?cn!L% zn7VKiH2=bNOg#e>Qy-%X)Jd>rFS@VJb`DO%dLyH57<+BJQ2sDpRC8Hrj5K>}+ASMo zGRwUL*4>(=eM6+)JZNW|f8R{2yA4sE=N$GP3Hn3s{Q?(jboI1RTfJ_cx6&G<*cxdF z8{T$Pcgq*{FC&fk8lNvCjf9^;k;X0{(rED7z9vae!+kVpDwGn~J<@EZ1w|S;+`I}_ z%*qXY29AtTT@RO5A4aHDB8S46e?zUI;R*`XbBUr+a4nx{%V3SsoJZUox38cl9Q%Tl zPx-ije%pJ{m^Z{NBZSKQbm;?L_<#UeRD{L=R2+h(xezXG`NP{doV_M)7W}6pN3A?N zg@Z>Ztys9Ii`0Z|pxq;e3+BK(-}pi(s+G|p@E0+NokFmBFweD6Aj^~Kw72IY@cBN& zn=#aBXRB~Ig2g|3t1`1ed7@2c#B|6TRq9(MbX!aHWT>9szNbCF2N^-W_CedH9kn^s zMF^w_MJ05Js4p1EOVeKoU5=cP5^HvsH$U@RFffpk=))YOtY}yjET8F~Mfsc|2RI8f zJO_4<#Tgu5CrEQiC)D zFB(EMp>`F1K>)%pRYRcgOBAR*n1vXWQUCLtPEt61nNcqQan+3qV{c^C(Il@k>U@me zB+wYEw3y1*8TBfoG;XFRF<` zIEy;I?R=!_?g^6K7%<_^qH{@Vh*?VT=0yXAUuv$yFQT5bo1leK7p$&yel?{7=I1Ko z%z?l{DXb;YrJlzDV6W~ohw>r->?L_Cq@Qy)l(hdt?DGafb&>i3;&K%X0PKaKSvLSi zI@twbG}k3aEt*L47K+PyuLpF(=U!#hQz%CeKpA!TX=fm# z{@{;{y3b`seKEz~Rzcw2o>4a_{BrA0%SW<+o*y37Zh)K@PaypAS7a}z9~pI3K*~YS zuX27}P4_GM#q|pP@{cp>|CFl!UzOFk$TPSGiHk(K*hdy-26LYz=p=l;;VmQu1CAzE z7^Woc(?RIc*n~K^xYEtst(^^Wr8)na-YUIE278xmuP+g59k%+2Fk#C@Pr+?Wui0MZ zLqh=DYw!hZmcLbV{VVFTTNTHyj1SAcR)o@IkCwK_WzRX8e&}^xI#%B;*5!OmOHWf| zaqCbxGAN6=APqXsYpeMsu8i;=i)!@Dk{kUVuASpP?hBPHgy%bwN2sMV)Ip^sT;g#I z-0GM+ISwRF&Jb>#S`=I;F|`6nFpqD~+SLs{5iEBryiFx}y7?hVdH}RddcP60O=@}z zw~OuJElmz-3SgUb2-qg&vIzxklP2PzZc!6WTyB$I3@(j90d_xa9jyX{0MtX?bPyo`puUXXq`ruh_YE=u)E5vTfD;GH_Jr2$CLy2# zAOrx^m)P%C`X%+{vH;2FJM|^?iu&?L0g@t!5FoCqe6>v~I7ezG=rm?aO)svOFh?IR zX_F2$7W1tpT`5$ry)$~@{uG#;%p8&4E!+uJRw(Osi5G36k9{8n!5@lz(dn@*fv%_1 zw$d!pr`d$BidQZ#!;fLs)uCh^(;BlbTCO=hT9RB!;u*1~FY6GG*VK+57_hd6xI2*U zpjd+1uGDREApGS3@?4i0v2d5(qC&FpQ^ITgji46kD;dtlxDnjiQm;UmdYp6 z77iWFNU3H#nX|Y~GX?``MsHm;p&?x$&8UX~gkEZRL-zCLptjo(;)NDsfzXQ&7bJD2 zAC=hUfIf)xMB3-Y3V`3eL!uP9BXx^K2hWV+hm$U$1~}=SLdf&$?cbgBSinhF1f2B1 zYbRZO>e5L^|B+D#RGEEg^&XH>=L-5IqYhvi3rBR%qgwA>I_a?KO`Ma|8=N!MTXsK+ zGTQ5Jcg6iwl)*{s;Dr+NYf%OW&v;#w0ivrPul#jU#{BSai!$;qi!vV0R1n=L%0TVW z`d*YV{Yz2C$yHH?>%EcF-xOu6e=o|2&fdiaiZWt;Ey`&BUX-zXS(HKL*8XDRW>Lo1 ze_E7r%~V&)Q~`=I{$Q$S%KnC_t^nxyh%h!hD5L(DrFO=)20HpTCvaq|0Rq5)W=ZGaC5))-mr6>$w~ zJRn!_*u8g%pu5V66Sk3{eBkg@;Um32>Bhbn5=`{Yr@H{lD=udDO4W0jf2ew;QW7Sd zN;yc??I;T8asXAoOLC>^&W>XSu-cw@NI2aV&ER&XZZyb6?#)ivmZtHa+Dw{nDFDPq zE$bIgy_J(vKJ=QuKPXw|(KtNbMO%;#9l!SmXI4gAS@KgpRAp;LXv0j7{Kpu7^vxE7 zCub35i=C$R&@>xT^)O7c3`QceUI2dA7=+*Lx0shR$LmhFM<2{^qzX@vwe@2wHX0mm z@_o|&aMOCbb(_2WA)>Hg?I=)ip4Hd;VGWJjo(Qh`j;3|>T$XVEyn9)5L*rsn=_qlg z<?vAoQMV2e?Bpm1^O4kBq)VE|pjpy+N6QeigJsU)7p*nFNsDFj>z!ZeE*a%*H z%Dx2Dj5et=XOFJ2gyVu`&2Cj3<%QI%fX4t)+h zba7o77p(P!BvuN56o~rr;`^Kqomg{dum#NNgad|9pgG+TnA7KLbkEW+=X8`3*zs3w|sC{YXJDWB)Et$zy&Fdx)2GKwIxebo8`XtqXs%l;Y;c1*BXA7He-;#I}qzmR;2c}JI4Y0f#JD8UEv8SSzNNSp1bM%0H8Co?7 z%Z5pllV6dj5B%Pg5m4o?t396wu)OdeLjp}1H~^=y80eP1>ToVm)(b= zlLhLkDZ}BqDI)?*YixYev21rNPUxgGZ`TC%O{ob=Eguw$rieTyET0Q4z5*U{H7?XUxQ&IOc6SDTy_;7HwT~NFW)_hdmN306EW}x z4#{aqqOqN^%ClWmEbxu(tuuw^`du?6uN@zJE3GnDP_%KeqRG3+Z2#sYiFKFm;O#xi zWARRfR@b!SKz+@$`{6PlS#?1uFOyXAb}nNO%8T`LE*;x&9D_$Cs40VR?AQ7uWkA&n z!N4ej0acF$rgXyJAp)#y?Hz0leo3k81F8;sepU9r48CwEVU7IMmcdHgD;ArSPm>4~ zNsqr&GfZJ?8JiJNavTfUG+vwO$6L>X_@>WW{tjVd%Arp7J*yN-noE~qUOJ^!<;EG} z4o;k45%-R8Bb93Elq@4vX+f3INzxFriE3oDt}yl(dH%vf>kgv&*GwpNq^-K(KwW7TL3hIUy3$WEEhnJ5QX>iVyDuPHP0I&U{!~}W@@rkGrSY^To6s;d z)x?w{v$WJHuaW`tx%7E9Ov_F}2$Ka9UvqCB_=#Zs^>q`bw`1|q;P{PV@qLhar^$6q{dAj^x2te}97D$e>Op#X*>2~c+Wk4*Zam^f z4^ls<2Z>WB81)q4CsM!(a9b)JIDplz>6?5S4!SK325w8w;l8`-lQ&)Uqrd5@^IUai zT#*9WzLNqZuWn0koBhX00il1~miFCn)xAKjx-EgVtCAoj!4ed~13pQ>RhLXj!}_Qj z|J_wDzIN3~uUz%D-?-|pu>Lhy9lQc?VFXN_y>F5N$bKxA-iW`v{!fa(jQ-2<7tCrZ zFwgq;D;;})3zNxPK}CW*fCvfpA(ma{JjXN z_s%9V?v)F(agu#vkXRSA@{Z-rN;J;5Ssoq9x|rF2VX@TM`A7WaF^K8~4+i?h_imi_ z@;|PBL%1RDW=wQSif~|%HL<5Wpy#`g|6qcZ-a4bE^wJ=+0{--C;6eZSPwSYQ7+BiT z>RKCK{yhy+{M?}D``@D!%7E%afBTl(`vuOKNPO9Ca1xA?=aE<%w8z{;zC^Kx%(ZV7 zx)AMXZ@+(M(_$Au(x&V%AE!f-#-@@JgG+pe#)K}6p@8w_eG-r3K8_>)cr>&Js|jol zE%(_L3*Ru!;Jyf(pZAV_{|Ti@T+R9h%B&bTcFm%z8w~JHv%T}z$F{vZb{%kJ(DVJ+ z6{>Cu8KNlP9;NE`+R79bf-lyjWIxxqMb8H(8Z|9a*_TKb*y|gPD#d$V{1>Hf5^S2&{Txq~J6$9h9NrUgcMxT+Zq7B;>d+)s4Zy z9Q9RxT1a`r8D9ac&TV%ol|I2|_8<9kn3kNiSfVIUFw-qX^SnPxk&#Y^;?3$gBF7(o zhE7CSO7QbslU?v9QQ1mP7B4kMGxyh-rz6s7F^s~}H9WNS-VqnlV#W?45kQf-+xC%@ z95$WwMWm%ACaI(NJ+*a~kWw40Vx(l^aKaAB)ig2*HoF>vM!VabY}vQ492PmVCHj2L zjgx30++JqboO6u6QS|Q6A>|P|Vh)jNx5c0^NQ_kbz!b(!VH_ve%FOaSDz*j!EVEc# z>x?0pE8;nBP1fTMFfB4Wfi$DjYEzoI0ngF$(xi4O_zBtms=SMK#IW8sPpsRv?}ZT@ zwmlWqCz2b!M_(PS+(sJhtPbf*ZR=m9&P9O4ARtfm%9eKBkH8_vO=Y*uKL>J`_;uc} z6t7 z?s&^|33S79r`VGf%r4RREW0^lFe2yne4)5uCA`P*4{#dv@QAp)c97;pe7_)kSagFAR`zRcQ9(ajaRQ(3k#JT-nOs7;tK^=A zh<0aQ2kM=_a`gw67vm=oCCF}pUky}-O=|95oZoXBusK9vID-v$_olBCnS~k^$}>Ib zl+$#MF<5Qz;}%75Fllk_fKO+=oj57vQRGUTv#P|9vXM>zPM${`R8-^h(PiY86UrPo zj=C5OgB?*pkKPgZ>759d6`kR5LvV(z%t;7?s~4B1poDLjf8V%3G^3^kdO^wHR-)n%33wRimOUg~I^ltigsp#MP6uUQXB{Vw zZICRwWN_p=TREnk1HJP^d=5mZo4qzZSFw8Gr(%{Fba#QaOep!9Hp5F zp3XT_kqGK=e_I>2NW?Pyc_o->EXKN3a;aeiuk8J4gDM8%C!UuJT863P9&WI1`2xog z({$5p`J3-)V`BN?e2JqlyN5>E|_ta3dkV3P9QY`sHjtn1I@OQG36K=yDkN~X|8RNSXl4ek7O zzXf6){et^!+KZQHM9;IUIyB#gygVYPemg^-h~68Ks;}J7S1st(&7XWcN*^VmD!~s`)svaDEk{i zTi~~2n|S#?k~=jD`k5k)P7B1adUG58jwHJyLNICdO*{UEh6)6hg3U3^=rrbZBtGv5 zAL)ll$IlGlX+Vf~!q0sO+}jsawn6OoSBZ+Aarm!4}pf6T=y*A%{S2D|Tb5h3- zyhiFp&_V-}#K4Q@k@(RAPLfYj@+0(|qnTUop?cd7v66Dl=V2GD8NJ600!ig$r2<^A zH5sMwHSWa<^`bd7KUlc)khCxeB!=)_dAo_(_wcw*$OMR zI?V@Y((+Oky4wrFF9lTbO_MTrcW(uiEIZsCE3<_ha;h65F>*n)e4v`s;mC1OTSJZ4 zxbGIsm7jN3koMV?dy$w-Vk+jeB2=SSmc&8P3jfh!e^>&fd8m+H_sh*Psq9s=8YqkO zb?o!kA3|L#>U~92?e5?q*TCpW-9c6}#1>51s-;HT==>6Lx6f;Xz`acH80i5{qh2Zz zm){QDJbF`bUdoPlQ~Ds9mSO(RyE7%;DmR31=we!@gy#!XPYZ%zsiZ;+#fH15CKw++ zCOSO9D)Fe5;veaOdw&rN-RZJ}%o6~sLCA-7$gtaJkDjOO-ep@z-Nk6%A&&3scgm~- zu_P#l?Ejf>_)(%IG?8$0h{abV6j^q}^mUH_@>ER3&nSG{o_u5*NRDDHg)Zxl1m1v` zhHw@5cTy8oA|NtlB-tj#Wo#Hkn|AlGp1rhDV=N4oSE%7<@+TbQup-PyxGfXHk+VI*KJF+C@r^UCH=kt%>tScgKkwvNKP7 zz|ez%#IIw!{1fv62*oQtxoUiK@4CErCVNFZ*dz5DKQdS6NLNZ3Aw&_344<{fw~3(? z>SHZDGD=Y_r=FHJJi_G>{i<*MF%p&W5q4e4-txzHd=!j6x;~RqZ4KNj@h6((=l7=D zt%iG=#$kPoo0kxVns&73TeGKkTvQ&We$#vVMb9-m6g8rDckv{v!vsg~-aWqJrg zaftfK@xWBxK5&ypwf4Vxf^$D^U z>Z3LSl4dE!xH=myg0jzJpZ%X!o?4#XXw&#rgE4;AU?X6=2IRW`msDUyzS=w9fC5(n z3jCMn{!9H;NK{1wX7Poh=pxQ!gf>T96(3xP_*Zq%ffM5noLoizFTj@XM1S3PBjA!^ ztQ?ts8R6E){eEw*&T~F{c}fHUl}sCp{tR;67(cQBPK(Z2|FCQyJoR&i4CcFeE35~f zzn;mhoX|cWNTw#FL3)o$CWHm~cyO4?i;2z^7SZ6vpwfd`2%871{yCJ!Iw$vZ4uz)z zIXTmyMcnM+$VsRg^vnxW>RuV$T6SGM`hZ>y>7xTKoEw}WOANoG%`=} z0i!eK-_ri}O5R3QkJx5NPTWXL@+>9!F*Kc=*qHx%0j;G?L%*sP*deKiUbUIyRA5W4 z%y?t~hIW)%{URMgSA~53#2bzxtpRYce2X;HWiku!4x87*2vbTWE<}}yx0DriJT0SN zrxTZ_%a<<~bIdarN_V(KMeK%xuD(hJlIGe(7qwO7q-Byl_( z>&hW6_AkDVcQ;iP&SY7#8e<=R^+bESa77A{FW}>ySW@oC@Ky5EjuiUMLS$DPfOy+m2>bKrztOZ+jk9LQc;aPlj32>Qz~l{^1bLs6l59mE+m>Mmnzb7ci+0e0u^3ZXYoqHC!n%{~Ky?RLK!Q ziCYosV&Eh1W<#o;!VFJYtPljQ0zZOM;=H_SEPl>OfM$OYeS|u%Q z{4Z&_L}%M6rb->+|4F0?=y}e6?>7KgQr0OO3*@{Dr6N-Vc*yl#j-VN{cG`NK&FrMz0t}vT zR?RJa;qbE#lh188(3|;jbkN%)U50Gu1RM-Z{`d?6J+L673!xA9oV z#LhF8U|9TJNKF9EYo$lIPln&^>qfy<*(?mf^`D=eQV~;a*|0~H7^J{;KHTfw^4@QL zR`|BIFA@LT>%GSe&FmE2Y^lZqT4|0Q^|51_i|*&{74h(zCg#!Dg5}w}Sq5*G9{D@a zBJA$Z;=eDl=n{|V!0h}$^XQq|d3oZVP~_Bf335KVM@Lx**_RHxZ&Q}_1u8NR6TdwX z^oV5X3yY5>IiyihXT!7+p3#|v8^-YqKP=4`Tx_OhtJ%GSoq_nRr|L1TppsuR%rc#a z{j4J+)z_wGtylI_CcaHY2+!4Tw^TBGv_$OqY%IG(7=xaGa)1au#PK=FfOdobZ0zfO zj|$#zW^dwZ+U}?|V&SE)6e@F`Zw5C0h zJ6-j5!gjsdMN6;jopA{U`UKP7YwqSTrCaptUa;Ib@I|LY5RaAMGoHW!#c}i$;QUo| z#8_rQC|gu_+lWX6&lm$r7AOWNZP5wsSNXTo$?lNCqB9BlJ{hH$pJ0M(EZJ)+N4&dW z!4!~|ub}&mt)YbscD@ng$pUAL^(QU*2`rL{mxLkpqJccfNA9HW7L7;f9W43lj#{x~ zbu%*Q^n>vH?_zyIqujUu=oROKEEh!2!-ta*_-gaf&p$vnjX=zw#}9KWD{ChmM}t3p z`hWcq`hWTbSjNRG;s?whv%viE*9ZUW0pz934>%sijGro0T1nHkv<#QDTMi4$=1Ys+u5{uWgM_CVdY3%=C4&M^0A77f4 z?zf!nJ9!@#a%I(b4R@=AWXz%yod>8S zJbD3m>drQ%Ct>fqC`QE#fbT!e+H}Y$#X(JyF69Y`h-LA7%qp1^eKB)3q=MomuxU~W zA%==3Ue!)*G7L0?N;2 z{xus1A<;?HHkFt|td=eUvBNs=-0E7=&{^7@7^6aHL`wTuEz;kt-Cez-)Qv)m{%kD& zfCQo`A$U7*123e!#J+=(HPoHTS}kWd`Vkgc%H`DI2bwy(+d)&u&iy7CSh_shHUwmh zXph$(DDgW_#f&8=zWeZorfd&gH?BSK>!by0sipM! zftz^r-U7Zm(w!9FTRLOy^k9QZIqEwU`4y!(l%UHkqI(ojn9f`c|#3rVcf`VsRqNp1~(@h0q<0yT#a~Wr3=+``sb7T{hZb zMX6GGG;EWbMs4WhNt!VUyHGJ-bI(;>9TWOr8-@fQa5F0{cXApc!zFNfK~mf+g?;nj zt1a^LC<^5H?VYTba1;p*RNkz3dwFBTPJ^43n2~!vhfrR<0)1oy`R~SdX(yKXAyxMp zhe%^i>1<#1RoV^UOBx6z87Igql1^roL8-;8cYU>6YK03;LBm>jZ&jcxQG?=jSp^EAEfc}kX=zzlo_y2^b3S9wch zcKsR12Yd#Wd~A3b8E6Lj45Z?1YSr^DN_DqV${~$>L8=3fFLY~MnM+{IXA;`=6Nct) z5mTsG;dah8e-(OlZ(ti7zJL8E)p1%zk36U5r|n4tuW`8gZO*ZLVj$RtG`H!2$;M+jCzj@UMf@R-%br20M29 z?3seG!pkjbDV>Fx!lIP&X@y(SzLvLXtv_QxPO9eM83)sg-bZHyfDi3#$iTOm<1(@vD)o8s4NrFTS_ILGida z;p7iPgxt2s@^qQ|=BW(J9ya!==1>h4GZh*v#K=3xOgM@7C5#xGz7*8`!RK>Jo9cCV z+V%L_7q)FiyvorKNb2_#399lCP)Zo^tv!m_RaNO*9N7cEK=s6T?wVFTH)oS#5)s6A8IyCPqf2m)ir$W zVuP%0e!d|R@bvsnT5-lRFox5z^|?D7^c5Cg9X6!Sw~yEbM68F=EmRl%9tA{Czuq9;+%VeUvcP${$#DDws|*^R}-cMG!!NEy#OB;^aEw2!2rgRxrylL;)4KiZ3&^1}ek-#R;n}#+(&v)2U8^tY| zGZGBgo0h0Be~HA5A}NCr5${6ph?jat)Hg%+oJMnejA=B6@WhtY&iAQZvJwrP_SEw| z7oNIjA0D?TS;SK;N6V$B$Y@yQGUL*AL5Y1)rwn{JB>%$EgGLDPlL^}(xv{McoqQi# z4)F?QpFS;`LRdI@FfATEY+FGqV{FkEE3twW!8`u?r1pG@1&m!eGxEgT8wAk0sHaBU0$C^0UjBubqG7vZN-h-<V*e5{oc0t&lF+ng~uM#HZ6P}di<5#U=T$d)#dY~aprrO(tB_Dwehqb zLuthhPu6WLRZdOZ4*F6Q{7}s5rAElfg2b+BB3%cY{;8i@ot*Ea+-JHZh|fAm>^;y^ z(@W=D$*j?|$MaptID=&_jP>uo85rxtsnYO&20IFc)Z~5EgY2mh*@xM%1^zZo0nE}z zG)*Z)W9I<=>yrGZ_mO5P9whIv3H$tzZ7e?TolD1pu~7-y6^L)G$-sN};^=vt=|^eHf|+_SMwwp+76R zL?-rm=HwzU21(R#k?eV&^xTUV_ji}@w`io-)gBP!yHhbPDVyDT-%`7vhDeWr7W+O` z9J3ZU zIYeY146XUS#g1+v0cfBMFoUJVb4Z;UW zr5Mh%;+1q(w|>!hg>{pH)G`gV-u*OkjWVN0X-R8Bay5Jn$}vn&$-CG{;uE?Q@$)`% zqc|RkM)K?vPtr&dDbSNCC{8Nrc0Z52Yict4UROLF_6r2bwsw>(MO?F>)2HuYSQ2njy4I~zdexI04QK&Ns ztKNMAa_+W9?PnRH$hM^q9!PRS4f?z~kB3)~f4R z9Y6v4=ee88q8rrd`7Dz-JE3MtHit~id9sk)-~xtEufC3hMH(rInpsNh?fS7T4{b!Y ze0}WE8E#V={wDga*SCYsjy3IzsoSaVkp&;^Hg(o|;qV{X?z+Y-Ib^)g&L9?R2}Kf_ zGUI&*J>-EQ8yY6fm)~&va5>C!Xn5eA|MX+p&5JWgiJpkNPi+$kcew`}nO80%TQ#4F zGH;xsslEH=s6_LWO^p;rqv=Djxn>>kK^6r%3hrw@=r))o_8IUbOka!0Rh){y% z0nabyFfh$n===jydvJ90HQwC9g1oetRQCr7rR`2hN^$DErG<~9DzKd@qLN~AqKcy3 zAHW)(Rka(lj+J)>SkcmEY-M_}`t7O6XJuh=BN3Zt%!a{CHX(#6-r((zSA zOG=EelvjQYvHn^@Z`ey4Ul#t<5oU~m%9DhWDiJzF3vz#_M^KqKpP&9VLMpN2I8MhY za|bJRe+s;|>Yilh`nIVbxs+{dBM*vTXN2ivm@ia!vsr{A+uK9Eo0gNG@eb6 zFANza1*Wq|F-|&tl_GR;G*#JG@ z`Fxus4R--Ff($RWzuI2MV=@!sW+4W#!qGxVioF=WB!G!?*Q-(+t_jmhqdY3n<8 zBr$nxwJzk{mKBfMHx)_q+AzYa)-5CEp@~@)9DSI*r;Vv z)o_o-=rp>Ofuh_KYZgC6sS?8&Fo@lH{I0eR^7c=iRWn*uW4tGEZTa$V0|x}zhHY!Z zF%r1G@SckHS8&*S>30#`*3tVYlCIyWK<+YAY8#f0P)D?y*JY*~z1J+@!Si%Fm3`N~ zAqQ}giM_}r8%+_qqS}WOl-#* z_f0q*jLfN2ZVr-srq7R9?HciHt-?Zrj`EpayRjx_K0|ARq1{RwDVnt@uwFm6$i9eU zLiR3{C97PtcsTYc`N_A>az|Fx$6KFpHPv7t!?U*K4bD0*lDi)jC5OwTGiysWdWt4( zEecgfAN-Aqu^VRPK*ENfp(^g6C$4fks4*_7Gu;2$z@N>_#R8%1lsUeEm!Gyrw+=$Km@>-^U= z$f7DUrkwzTY#XqK|G~+BuXFEI&Oi}~3vQ2AjAi)Ma@P5xK>nuA5-HtniAu;Mb^BdC zLbp$2JdgNSAJ6Vg5{h-(D7_}089!Mmd6;U%)-03n7ybeybRmZ@mk!x|S7v9NEu%F^ zo@tR(TG!^s^up(7M~fk+c)%qc(F1Pal8#LX%SRh<$Rgj;0+)2?VQkDy_}G`tQ>wbDQ zv=y4S^Ghn$l}26^hZ3<857}CFbNW(dZM!Z*u@9$1o$s>OmBB+mDtAkIx4<&M6JxKD`F$zunI2qAE>T0|73>kGn+OiX%H-o(q0C)30%@4 zK$&w=cg@`)bK6u@#NbevLJWT{v*~MZnx!2qjF`!TSkF@Pk^-9-SInY&?{!C3Az+Y^ zfDE#2TOV0=F_wy#jluVs11z2zTSs+uGZE;KZ8+-n=Q(Ya1KbDO%t^^}l*<(|s>5Q#xUJkql?t<_tnZVPI@m8fm;z;Wo>( zH>;cz;)VPQsZZPEt_KA!ureZFeR8t`1E?2$ORQk<5cIiEl5L`)jJ15NlwoIeeD#he zvSA-?pZjk!HFYQSIg9Chv=EDHH?{lXfr0XQwn+t2HT7YS)J`mql8|rg3q3RC9_F{K zJ+#V!PdSA*A8Ttw99TEKnJuH|rt={D1gk?u1l!C>3hrC22K7Lzqc^ z$OJ}0+eLe@@C&}_N0XM&q{14P0SVqD47sEC0*WEs&`yD#$SD0iwLV&KVn#_&GW}+} z1&(-z8TNR0Cw=^1N?0CfD$4Zr!2n-o21t8zrTXfavDvy1%a16t1L+=<+2`I9&m9wB zQYzK0p*pr;C+UM(P*X0y#!OFx2J(X=5vI8l z>pOC(EmpmH-CpGn0+622z$lb8^?N7*sRE7gd1um2@7E@_ozj(5pYBExux@_U6OU#N zNi}dL_UL_@Ypzz4-227NJsxUp^=(Q_RO`TMX!4t4yb#K0jtE3cwrU9Ec)b<9wQVDJ z{4c#BP=_Kq=g`^s7bNqetu9{bH5aa{$qbadkzMWI9>mT--_>7laXgOgjQi{{5GGYO;Z^BDSclKM~_OlzO3!p%ctwRrVj0$*87o+5AFP2Bt069Z|lu8F;cj`e>{@kJ1|pSK3YHyse) ze{}S}Qr|xUYWJ_ySNeDATZB)zmi^^;E23YUFVDB^;luYXn;$ke8Ba^KPmP5ZeEl1b zpLF2h6QEY5iTGsi@V($!D1+QzE@eA~(rfWJXYb7U5{WfU#rSb?`=O13FT=KjKrM#L zMrlC5=)AK4(;fxN+jJfAgdpY0)JPkTCYks}1w-d4BPw1JHAo;1fg}~@I7Cq1c@Rq+ zY>23Xg>hj^Fq!_cxDilaKPxP6=U67k5k8Rm+SppF=Chju>N_rft-g;GB3=@2@+0;} z9I`)IPa=eHi_5S(M`W`Qx|%rAFDFh1K49V;-HTe}V8M+jPr;y+`#;RRRaBO1+x;z~ zG}219G$KezE8QZYfFMW+NOwr5NC`-HgOUc_-Kli9gmfeS^SWWV*0Ua6@B5DNjq$Aw z_OGqUyyx+o^Q`K_bCVfVGn_K4j79Zn+1SDS1!=b&=kob^gkUT06&dh_pU5y)4widR7Jz|-LCV7vXH$wVj@BT zoL$80nHSC(08cY{VpP1n9&oJ)WyXx$M!W&@lps+YnM_iblV~W zcv}3nS01}C{at7FM>kh)<^Gnq^$itt$`F@E8ATmX%gUFU3pRv2 z)8@Uw_}lB9br-VxopL|Z)BuCu3QIt`Rws*E9$BJwqlSUnOoObY z;;HpD>i*D{CC&f{2hzh>n zoQ5bP&Y4W&{<7Jrt;E#2!E^JpFF*E@$G=FS z3Fbz^sbNL*&=Id;l%zU~+-KP`Jh(m5-Isr0P3By-gzj38|LXf>@EyVfuVh|XQJU9P zSS$cboBSBSsA>&4UXFVo(RdR9mZtvs*^gW*d7 zn_tpX+H3=-xJiFl5>L97X1S{uRl=F!hrW!y^BHJvsBEbPaJ=t;Y&Vgx@{=>n9zJXDg|gR*M^79y+hM)UxDU!zu=)Z z@tg6#1C7 zS#jd>_xv?oN}p}xS}7)N{gbtMdT74oQE2AW>Gmv1i+Z7xO)qD;-sWIG3|U;jLLKW_ zOnxl?W2!(p9l#mIV}i{W|2M^nuBkX}g_chAbHCtay?}w?A&@IG9PQyZ!0LU9q88$aMw5 zl1LdV4{T->-@Y(WP)-*9dPL5|o<@IzA~+o${|M3M%($Gu@39G+?Jlp7(DX;YvNMvD zXPTTP;AhJvgvtuu61+Fo3#tc5l?W{i;3S-hD)xkoP+!jBOUZjN!4}%xh*6VkRm zTOv2c#x3A>6?xmD#HrgtvCL&7OQl0Ss`vRBQBkq+b7H+GJPH(=iOk)f!eg7tAZiF+ zwbsa?>1gTW_C(~rXT_yTE;Ah?^8F-KdSX`}*$|iXt)^dbUlvzjsFL5To1#@YL zr&P=i5<*hm#mW>8vsZ-{PE$t7d|sX=Hv9vK^9$A0v$Qm`{CBEu*&u<6 z>F-tdk1zkV>ZU_o44}HziFLkZhz9dsMT`yi+8Jc;6SYW7qP$=4VUVpDC^rnX34OTU zKRFlQXW8s7Vidf{h0z_*tbd?aiPqy^;3YO~;95hnMuqM8M!w#+*CoQG8CJzGJ0NP3 zI61J0>#dqj(PgeNS{$kozfV8#?w znu=p;{;~Oyn^X}(8nq;{4%UlHO$Xl|D(IDqnG<8U-VHLVc`{JLJUrpXg(g|mL7=`u zPTra^Rx%`*rA*9;uS{S@H~+zF6E1!+kvaPbwoP(`7CkRf(8eKkMbe9D2!o=D3!+HW=p!H}JJq#Byee%kd z*ft}@kdywdSy+)ft2d{~A`!9lOLvN)k!wNJ!Ow9Z78vL17l;L>-Cj)&Q&7Hce5l7w z1!sZN*Bb4@tj-aFzrdKev3R`OU0^#?f9v|f*F_-FCFMe~`< z##C0E&fa;MpIsM#*K(d_ztQ+;K`9dJ>j>d!h*5-hpq@*q*vTyG%-Pzsfv=S%v#s_tq9k5(B~6Iepy01Oq;MQ@6y{e!N8j1B_Qb>ow8g%%UE=trcU!p~j3j+%6s_iw|=s zP;v|mVv?jy9E;JvR|Hg?t+>;PwMQX%RSpM}+~`9Uu)ahjFywKqnjjQsaWYMXBaBBD(Ove_yUVgubpk&+F}wXl}ScC(Md`wLOhkrw(7p) z?HpiqjW^1G(XAn|Iybr}WMxn1zN&FCZ<#-v@iV!*h4yL71Kkegkw9hFTRXK8sTirn z4n6ttG-pRvL$m6q6H%>pgfI0RC$;q$6Q1E7v3uVrA)>YsLR1!NFGgsQIK)|mo0#9P zd}bt0uTmxfxoxs&yQVR7TXgdRr?M0D%yv%X@&BQ@JH7r*$f%yZKiqgn#M#Y- zgRcgso-#R~*Wb(zP|r1&buyK;tY1mDY1-~v2B^QqMp)c@-6e{VoJ`{vp}h#|Z@TR& zXe7CQiM_oOkBP0sX~(7vg7YuE)kT*u3>65S4`sik^U@|et4M>2JIJ@1xS31qmhn`C zu~`j~5B1Z9fLt5Q5M4#nC#z%w4A+PPass%*w^XsW1!B)d*Y;PUYw^u$+b%@?eoNd~~-58M>K%`}Odkl;Y(>75n~$-FK(hNko&TBA@OVc%+OrbzsluviTMW zuyc#v_(FiI)4al2@cawHZt@T)R8k$ME4?H_>1UXWtxZ5g-bpc*)F9@Y=8!={KlNJ?&=HDg^ThV*Y|5_Fwsp&Iv3qk zYb?c?dq8xHA<;ejwdl_ORdlcZ??rd)?3+8CPrKhCyUPbM-dkypUM^kYd|7}_i*}l5 zsnue)%}U&jt89rT%=|9wd*7i4WvlG&4*@+%!lrHpv{o|Ir}XL(l6{TN@@OB(Nu1Z| z=`~0LCx#ADmTR-HRfP&`S7@G3!P#{<-@>aB-`}iWnow$~clWEaZ|_1KXxrtItu{)% zjGOoJNbt$B$xT_k?Wl%sNOL)UYVJwvPE~!I3SZ;xjmIb~<}-X+7E9_2YzJY_j$Bc!gw z?=OF(k^Ck;t?SxA3@mQhn?+ywuv0##2FT(zYMq?7jbo18#j&k3TO{OD%o;i|o5%;z z*QDlhU&Gzk@t#HRWQq_P^YfuMWKbKuCr9I?=+Z_Ue>*jm|1-is3~tC9b|)0VY|hHE zaNXXtXJC6G|571d=qtka6fyk9RG?{mzn~HE>b-$Rnv!Wa4vQfzUBi((Z3~8V6MDE8Z_fVsV;i@8fUAk~fU z8kO1wrQ@$#6|}4eB$vCCG~Xc2ShISL;rV@b>v`&{N5D5TCm%1>PWjxwd>R?qFFsVR zbKpg9l91p={r5m)ZGVK1;c1`e9q3Z;##(XBcp{K+gpCrqa=0SA8>vU1q=dDPwKtxf zVG6mB5ru&E@#V5lI4-f%9~^02mJmwCyV~?$25Kd9lsg~pFZefzbQNE75F0&tpB_^$ zWD!KhDPVe6`0aq|2fLF19bUuWVvZYukFKpnnfSIm?q`l7w@%uKWaA>@*kdEr?i98c zARz7F5arV)pq0AJyYqNyBy19&OT&FY^g!PeBG26uo&5{oyT2ntaK2CM{ciL9`oaH0ru;#I&$-Sd>ucxka3bvZ3 zzEL_}xl!b3$5Gx>F&Q~wiDdx7Q1v;KT)U@s($gJEvBDD$gHG%R$_awDL;=}Xcqy%b2>ab3}&U)Z$Ntsc zYHYjXOt)f$+xq2!w-atrs}``!<^^3HO-J>i_UkM>bY9O?4XZ*N-Pt+2qm%=auPy8CVI{*b^A#8GEYrnm-fsm~`T zUTWp{CU@n?IFiuj`_Hi2wB8vMeW$kF>SG?sj2Cq}Zrp2RrvXhcP{~JjtVGyf$hKaQHa>#rd=cekEk#(s$Z$B9UA|<%DuZUsX~P7|*$A&1p+| z2z}n}(FoP;L&kZg!{z41J9dAN#l1RPCQPLL1GjHJh6gdP2IXpfW1xWj+whn8Ob`3; z`EpXG%)DE*NYe>!G`oKvY25R-Un;32i)vp|MIocQ=`3|m+Gnup;dT?c8xw-0oq2%j z(eU<--v_-!|9xLGGIOx9Hq?3X?-XPQadR_EAjkzE>;31C|D7y5$&a270%4>hW~s&Y zpjd=FxcgZW&85}W?b|hF7be|oopKkiIf2u_Nx85wW%BsH+}KWv)D8?Jp&Q$hc}*NK zCG5tw*sC2OFug6jGoQnCf)2Z}bwM{aemdyJ=3N3M4H+TF6G)e#&Wc1PdbvPR`1d3ag}f{%SC&)z1kK`;Zs;Rj|Q+LMiMbbAGQQN$2o zqYGo^TQz;7nt!;X-k>~+kpQ6jhrtnWl5uP*fa(i$m$dcRMO_9YN z7_fMQ5X?PnMVngG5X%b%B(#h_`z;IONH?1TOQsit15G#1SE{j!$Pu^ za%W)UR4p^feiH-{#yoink;lufr zjbt}C16jDsSG3Bm zDborlH-5dYM{uN@i&6KJaS%SsT2C<%hQ~?;;X}lE_)uJ753yWG1`Mo@9jO(Cwdzun< zW$O$&HVh^rsqw+c(DzP0lfH&FY-;K=8%>QGk*^-J$Wpuc>2JOc>m@4JqTt6@rnI8tv)`IS`9! z+!LGB>St;MJP_xa>$~rKHob#&(lTRsR%A#y*M4 z=b2VtcX37gh*6h^h}I9TethZZ77$WxpDFn&kH|mhRLI!0Nh}74mY&XwiJflt;5Ze*{NkLof9^T2oal>T)yhc z65!Z>Te1|!l|iLrq7j|$IN$t-8@LRuR+k^L@qI#R|sR|%6p;doj8Xo>1U7` z4z4F_ki=@LxiG_|_k|%d+>!Z*86I{K6LZpW=>TTf6PV%4N};$Rq14Wlv1to0U|5+f ziWUSm;7b?EJWfULT}^u7L#_#n9xz2T-jjeD7oIN%P+XF9+W@2H9*tJuZ@D2BFw8LET+emBU=|eNl3UH>RY;}hNwaj z*(xmNT#a+l9plsmRQ_Oh2Sg7&K@8CDPB_@zp<0xc@?e#L?> zR%q2yB#bUAy`B>NR`hewyKDm%IKN(J28Wjdw!3rB9rP~cIn4C^5yFGgIF}DK?fd6; zV-K;Dj3&+OOU3Bo(qcwBrWzwfuPHcZX+v09R%1lJ?2~SWv&x#yJCSjCH%ne?C6kYS zIq3ejW$v|2#=I49eP2}=L=R0+^iT@*E+O|TS?P2VK*ehsl+S?|NFr|8!fEm>Yx(*P z(g@puG>}{)nB-Ez@?IdhMIC$r&b+YRB}+gU$a}%=4wUyoU;`zeFWB8duVYl}vY)R_ z=^uDv3U+tSWP#+O!Xy`p9$=Cy`^qNmn_k|Bj$4C%&H`eqlcr%Id3UGxtBWA4to8yc z6QF^M%1Ab9%*;_SQiwHM7~)JJLuG0 zEqSeJk$iROK+8x4|EPMdCd6d%8FzwYk(Oc16BW?9+`cM_xzcv3^X;Y~zL_q5sNjt% zrO%AxayRz*1v)&ecS>o~bsg9pbp{#J5L2ae;k*&LW8&NqJ6N|%l@3V9o6l0p--USB zV|s5!#NWtzJ8Sp1Fv->Ake(!gGp%oWne|j|3>Qpaj`!q=OqAi1v#W4V^mM!gRd<7^ z(2SH%B)YmqT=SV7y~uZXMs)sQ$>3~U*cvllQeSPf1X&}t*wB$qK z7kO9b1<92w3O9%leGxzT*CS9#_a{8$lzzs!5r1;$YP6)m4I^`(kM*GGj)pZfN*q6% zU#iN8oe4K9BA|9GsgGz{K>w%575>xX&a1s6bA-ZPP+l0h2z#-O#G$bFMc0aB*qd!m zT7KYhRe8T#p#8wR@VFWs7aq4y8|HC!&OPqRM%0xCISJb5-#!@(K%v9uqw5(4Ldz0H ze;n9iSm1K@)_fv~yy_%#vYF8|U#iYwe(^=1$*!nyQ(NU8Z`ysoHHk4!zTKj#;8Bir z9i>P;@a+993`CnMyOs}SCEaS@OxfAwP>SmAx(p4K%%dqkeBQafi4(M1!e90E3A-(E zE9>azSA`ksJyhQ!YM-`^84oN;J9u$mOdsmn-yX!>4ACPdM6_KheDIF8n$@)Ea^CBW zPK0UR0CO~0+%Svbm58M|I3F-5z*J_^2~iEcPp^9U7H`1f20%5O#|;sW<#SXQ9NSlo zJclxM8h*@wLSBx=aXGz{3Olg?E!;@PA`?1jKJ7|DXye^)@MQYzwMT(*_> z9oe%*A|4oQyaxxi2I4yx2R4?nV-!^hdy!dYUX}+hxRzpFzKC6=dvdtrTEaFY6|>4) zNFrz#wzvExt@6~=L5F72aD%r0_!>YO<_wn(f#9w|NJGwLHGw-qVl7X(f;Y&k$#50J z^b4i02+GmG1osUPTrzys$1uUQj-*boh6ES=TyU+X%%r|he=P#bIydD*bZDi$oFT!5 zNHR}RK$4vcE#*^?Lun=Ax^(Vw^;cXeejxlQ zxP_o-^;dxRuMb6mjbg~-nt|uJjkO(q<_mdXSqJ+2b6w~Er>SA++c&;ot3C#r%MWbs zKYshU?Ed}RJ5|)pQpIpx_Vc5}CTMz%YJzg;Vuw_<$vKg^;N*&oQt={(qcqT%;Dg4W zPS%r*T8z#m=je9C-JOg+hUA6Mn~%kQF|?>1880k z$ESeiCE+rW4Q1Dg8xm(s)VG~NSouqr0+3})5h8~&gO{+AG{0a}%Cg#11c?jt=CP97 zH5yS64qNDrP#AaGYnV~md}%U5O|>#%&;QJh;3`xb-Ns0GFRmkV3Xo+!sC}y+k$lAC zR!eansm{r4-sYo#E2Lj;kg3E8BwRvtIY{m8lgaPIB)-IRgd#z5|ON`c27Uo@E!t3TIWr(;jrT-~x8^8M@*43DMlK zsUnFvlG7igcuBG2W(yHce3n&q4ee$Ax73#{xY@f<3n5`PKCXcp7DR}%H;6|iNAJFm zHZXo`m`zw{5=LlPc9kT@^zlhxhpca>;|1iqFRvd%nNSpfbIDk$SZOf5%OO~S&x3~+BYiQuSP=JC!6ZM^mXx;rQ*wX-AY*6 z>76so@AP9vWAr0mG*rb=?8)Z`_U_r%>--EEsx z4=(egHMC9MCdzz$B@|Q5;#TPwC*ZvNLInUDh^dEQ1m*Z^-WoRM!-J1-zDcrW)dY=F{75azE7Og z^sZFJU+oreAHtB>GQEW;KL-C~PfPu!%-U0Ny#`wxJ@#m6m>rHl8hyKsEQuM5edN60 zDI6Mz#&Xn58Pdj?GrByJ-7Kye71ZqrFkjEjv*gMfN--%cdF(4CZA)$ON^b$hg3#$u#m5unaDEPAc6aO>zS^Bu z|EjHRPGQn%u-%6?P+u`65C~U-YqXA=E zKaj6$;W&IhiwjFcvAB;OldH&(zRXAEb7Y8%6Zy50S;ai3u?18i3f0T_uT%}3yjUOJ z+o}EXKtbCjA@`Kgm9PS(d><&F>qqS&o zvQ7|)NVBx)@rv=tUNx^_yP}A&$Jvb8@IqVZwMfV80);3eA?@cy`;`Do6aC2TxY;i0 z5!&~0`V0zXeYkE>}CB z+~VZUDDkCu90mcq9b%Z}xC*o=4BzOaJ*5{~b*KQa`*_R6UWD&ibK09bYigX*4`${Smv$r0hKkUMF5X2UMD5dBAI5wYkbu7I1DRc zK>0I;GBYYs`-x@X!6Ht>nf1y!Joe_wD&-ksqOe!yA0xg5IbtvUJ(wYQto0!@;u~%O zXG!_hJK5^-UQbz~yPqnp&ZB1dE4Xrjbi7koZ3_;sdG9~K(CU#q_SC?%&`CJx?lEy= zqQrPdp)S&3o2-`+t{Bk%%(~M0p=s%aJ_|=4!`Gdno^a-*9eEs@tv&bq!sBss?>S=( z+pJN)ilyYqPV2U1P}Z*LqK!&~GV5Ite^BsVN$!j2J-ppkk)AZ3#?hwzCsJLm`}c7@ z^(6SQD~BUV9`%#55W1n0F*y@nnP9owGaKu$jIQs`AZw%1`7Ye7Zy9h5%6MmYGgwhm zZs7SGBtc1gym_M4MN5JU zZ_E649r;MnHp(Z<3MjwDb?boTx4F4#+18}Pz0!9K6Zb$%V*k7)Q5^-fB>Xe+4{qsg z2$(uq5cHU0^_=ADsOw9><wFl8XINPVLCz39gK z1B_Z~mwCfQ+w|-oLa!aYdMS*92&C zATYhZ{qEoC@z2iM#i;s!g6V$QhEgZ=dH3S4@|Br+$?)d~>1}v-1zw z;Xe82oMG+xuW|-tRSx5em|>d$iWwSJ9?%%q_!#WffKwXF&r{kuI))LRFF2)T@WX;# z`SX~e?iMtt?t4C{UJM&l|DZxG=iKy)POYE%gY)1dZus*|TYi?i35xx2k}HN_)0a^L zZ2IQDMVPQ+b)fvkDQ(fFQnJM%Hk4FsaU?B%pBv!}#q-Wv65@MtxAf1;6AVy!0$AL_ zFa^ls+Wb7FsliTZ8>!RGGQDnnZw5H|Ct>9Yj;EKE)<)4;xRAWVloZwRD-KeiO<#1W zhYk*K=|h{P=qsx80_aZ!p_suP#0=jG)dN7x5G=Oz@;fL`m_X$T1Kl`Kp0G0L`6Fgn zIFA`BpqL@9g>`h#4~iMczq$N6W{A7Jw^pN*tR(NEGp2j>$&Kk)bWom{#uqro)kbV0 zLlUH_$a_bSPY+^-*5AeqD!+>vQ2V#HZoCY_{0v_0Th+Plw#=gxf1uQ;rVifG2>K*| zgo%DG) zQ(EMH&;7UWNp&%xQ<@=kN{f}K9uo$qv^(66;FQMp=PAvoIB>nhYwS!vez9Iz#2LGK z*q3Cmhmq9!693P_+J|wzpD{zuA2GwH>TW|&ScAn3eUWV{=P`q?YKWWwMq2p$AR4n( zd+!~Chp(8DTc-HK?rivhIlV}f$<*V6r`G$Ru!ac=Yek^2W_wz-{OIQ?&GY<}c2Igz zSle&=OJU9bys*}30u|O2Kw-@rDy$VactswZCjBg|!9j&Je^6LEt@&A4quxw|3Tvj9 zkh#*m^AerQ=#|4BxA)O`((>I4if6*gFy~Lf&}_X)hVa^p9VJ+bo_I=}TYcqd!!M`ZmTA5oK z{##A()z~nk2q3s@zy$x(r~g)SArE{unfR>RlI2y7H+OCd7~ZUNGr>kfTBZJ?p`<<3 zFsc=?Wgd6D!&PBnJo)LBb?D~$>d8Xkoev*+j*B!M4Mgkw*#7XqBnuDE3SC1Qe&K;d zAP-D&EEk9WfAhf4up1RH`=XSPoXt6ul!h57h@0zKu5NL}=-^F+=c2!C44Knz8&X4r zljNLhYwgm`p2@1qYSR*?PZXi}-s^DmIJ8alJu=5t#o=i;J){h@Rg)kJzrnh!>&QC6 zv52_22H`^qv$=QLKIxRlEfU*l_6fXdH_X6JXOx9&vCe*bv@Xr*Kx4(VwU*RyX`C8W z6zhZM{g2Zd)=Y$AZ^K^mFcRSlXKmXS*0MJ8qt(W&0+d&a(_<*zk4NEwytpcO$3mWz z2ts*7_v?khI~J6IafX9Ms+Xa6Ed04X=;BC;_kIKKSX5+hAANB|@7XcqN>QVr@kmiU z>cE{}yYE{fpd=)U^Myc3r+$s6XtD8H)_40?(p?`YA(S_?)A7X4#!zVJ#L1J7rTw@f zW4%mco1F@EEbi!SpnB~9u8Gnbc*mmV+6rh$v@Zk+56`aX_x1u&q*Jg3*SdjADJen9$ zUdw6NWap0TcRfO$?qcTSso|+pW$@1rD5Rm{%YJPvoTGM~GvaWbaI>4%?`$*|r^rz5 z=v2IJ20U*0@)~9W0<>e=g4nN@MYu`-?bFAsoE|D^a8Uc!AEncRJbMc*zP`xw>l&I! z2M<9xAt{J=jYNho1wY{I<{iU=;$68B(p3*X!tDlEAANXTEQiPFGolj4H+b}=?lzV% zi498A&PS}6>^%gfHCYx^+2PAlXYAUPX7RM_1D%pxhN;mRGEY-SBnCdw6H5;(QI|vo zXcI{mr3Xx1LWy|mpIt_ml_C(06r)6IKf1Gy+Ipx*Ch~?E{@a_4&V<#Hw|m^Zmy8dz zmKB>S5-pROxvct#I&hU^zLmv1qMJru3|;r2CUYr)^&Uz}dLwtp?3e4NP7zf%m zIc2|pQne{Q(XO+&~Oi1nw=?K4u#&OHp0tp82gqN8S-?ZCSTda2dXN+?fe!u!G}i^ zyGV(s`?D&82|%9WV=2#YMe0rO+&w8grz`IdmNHNvqrc ztcIpn=gLEdiVZz5u8ycXQXO-e(;P|0efAF##V-`@;`z~k}q;>YXV0`esmV z6PW6E-kDE<05fWr6Yeg9sW5z~+NQG?|Ep>n=08{4`bA})RNun~tb^#=HNrXzz7tEW zO@SEq3W5CU?72;1fNL{}$)c>yX0Ve^S?3eHVLc!i zMHut4#meeBqUqB1gIroybIqbFdA=K+gs|INFw`in62x>7vsb>suBi~UGm_J8@~LXS zS_*03Y?}4b*Bf$H3NQ8KYzVY-nTyb~_0@)=7C^!)NJ8}^@pEE!>_Xb)S=VDn%_@j? zpoNX-P(8hhO;1p7M<2#&{bL2H2{>VA<%OJ+qy~;V;Xh4_c z40Va7XGaMgO5b32cp;c9UEe3wMH;j0zm5ILS47xOOT8_EvbI!LbDcu+^IK$Nq1w+@ ztY0v%Dzmf8_M~&xj%L^;h);As8Jc&eE7B8z2c|ffj zq@AVbyrsdD_<*`JdlKTyR8QX5(Zb4Y{paO2)$196FS~iOJ++s}=_!maLq*~oGq*$_ zHE$kUd^qi7O?KwHF6+%_{K~IU-BvRRl!*5IFm($EpR^>MHg%a~^x%Hm$)r4XPJCarlzwQ_EK0 z2_}lby3{_@O%=l33?@l$I+U!%g?BK%%(+{$fcEA~Ew!yEw{Vm}Fih2i>eg{AS}cfm zcr@8i{rd#s7j<#$}asMK0cUBg$~O`MSUT`u)mR zlU#rm%Me6B_!ggttC@Xk}&do{2A15dd%7% zuo6FYFHQ1@E&2qPj~~jXd){pm&U>;-9KjI85Rik$8NOvmyh$4Wp*d9P*0q=iinrgA zTzl-J)dn;dZ0#@y7`>s}EOC$k)x7MryAwRAPk0O49l9(QZ?1)P z{f#5Qu)oeG(!wOsoP+B4B8Sc3T1+N^>eRwOKG58Z41-jo;{yU;+u2L<%|)fNGJ6MQ ziaXX|cp_z$aOMG?*tpbF%3o!|xc`_5!wSWjw|Mm5?Nx4rZkrWq@U?;<^Cpqax2#`v zy=ZMfw@vwvZrkCNP1kZ8Shwv=!gKCdnXn}+6K;WJ!tB$~!)`Zxy0nJ{SHQz=`tcXt zHjb24S8=-7MfCIK9A6v6a`KrbzTHHqP%J{KQm>1JHR|otN|%Wr*|_9r49kRr2_E6S za8xw_Tj9t3UawA$xRaAjk@tb?M_K?UhAzOUaa1PU)Z5@8FfXYb{JEX!aIy>=A&4aZ8yX(~7 zxatrJXFwJ1owI*lG_b|5ww$RTTYLl9;_g3evCN;g*pnNpt|v99v##@mp7*;3r#^S|ohmG@m}pUi+h|E7Cv zeevbL)#txGy?LGz%l+rB@Ti>mscWZhY&iv(80r-%=Yz|4U%0$ zs)%r)4%gK9Lm_vjq_(BcUYb7kChLkK?U~Fy{m=qb4sPL*SvRNx2PPl8Ho3+=;=NK# zw4n4?VQ)2_+#S3+Kb)=6EgiHtU@g?=sFo#iDD~*l){__M?#1*p-50Zxu)PN_TP3jf z@L3ANCQSpzxhbL*ZRC0R*tyxT#83(`;3lu_o z4~|rX93e;S2fZ5$zrxWXE^xF?bj>k(u=k+j8K$I}Ak1o8VG8f0VB&_5m*_B;l2z+` z1r=|Yx!F|(jOk8H?ICm)p0yARLX|zEgWv-vcVL9>f(M3*t76fu)qA}KU9F626 zC-%|2$caS(js`|{0FL%v>>?*V2Y?@)kL*AIa4=4cfzLy>Ydue(cQ@gGzPq_j?QH3G zr8hjo{Dix|BV9LeQCCwDR}ODvXPt1uiJb)}J@Xut?W%!a2tRzn0P>1{*WSw95N~)a@68|x0A4Zs3y;<}Dj6daKNQ6EtLm{F zA8b&P#T*Pux?Rh0i!ehE!P=tj!l`H{b8H+y15>`21H-V)ZFoONQeSl?a}>LdOMP1x zO!;1YB~AifdIPjX2`jVpht1_OCD~`p(y3^qJJ6IbxXN+760pA+`Escfr;m=0zH;ij zmx9@K8u}Ze0yb+eZN87=wwO$=`e8UtG5U zjrJ2o`&TJ0mH)$=#z1j@bCo;)?*E(K{(R~fM*n_Z5l1@RiQoMV{Y$-@YF;GxENBl4 zdAw!2zPZ&Ufgct^JiGnlTyHy1Yp9T+r;cfR?Pm0UK6Tu9DY+1O>KK9~U`vu;Z9~FZ zC&Cli#A!R041!^L+aeL;E{LuktEmAVzW@3Xl#hc`hEUo>(1$QPNlUbmW^U>k=X$!4 ze|t7Nv5};5UOrZY%Et&*!qAK)`!{Gt5=@%GW+Y<)c*eo?LNt^K0?%FucCOW+a{{%E zzEE3f`9k_<0=;0^VS3gzkX%jT!+f7^VSqdBR6_M2PB}Gkl+#;IIV4MO2=Ej&+^+>cE!e~F-`q3-QAKsxqOANv~ zjvS;(Gm|^m?dEIiI$t#NhZfCLFBZ-4z@k}1GB31f=Cbr$#%qk4sP;BrmecdmcA*9X zkUxx`=MUrGG4ZyGD$nzWz6q^IA|ug@(>T_Ixi(K43pJN6~11c54v?8ML}%5rZSw(9*iwN5^4 z|9zALL?P@b=lS=eTvgams}+}FqNeP~==Zl=`dje`u56Xx3ySdM1yJ|}J-LcW(rkpp z!M4r~gchV7?QJBM&EtEl9I1R3ucm01uauO<4>5+iSMS49VSqieqIlo+Q0lNCuBppl zH+?MpdYQ|$6WQz-YPE#MyL{8gmaEpU3NQw#0Gjq>OS?cqGIb+s$D|IYz1#e_J-jKh)5kpd4!{}_V>?k|Gnt`ty&Cgx&5_TtlqqLh*bw#Zcw#&SBMAskN4$=^$r{= z!N5)fGP-B)wADuaO?NOTv#z>X;NzI?8+AXTa-tDwGIS5$2)oH`ssDs5|M_@2BWyf<#RD2oU%c6DWyAx<(=VnZOTm<6jnnU4u4Jike~~-TU5iK} zV$aF?bKPy;raupU{dsQnLF4J)bYbJ^7=N4Zt>XG~zV`(*-^;Sl4FSLHe*(YjbT&w< zI-cQ>%e`xRVk!(=uKR_{1;H;W$1rmXaJk~t)>SsZ380 zx!mhE-~Z9&4t|jT`+V2mjg%ZCsf$-83-|J$xx~n>SH+m4)ThW{I986nx-S=3m*Mn$?k#jJO z2Y_j?`QAuk{G#y+wC0QXUWPyBdmCLlp!wd{pmecV7uog|&=51p&47jo64*-%XOb7o zUv=}|(NcQFl(aOJ3up+pyLtiGkU9XeE?JM~^ zzM8BY^-Q*}gl2WGJQ)vKyD3>a>6`H8>Q!X4;jYVe_huBJAxRA|Bq@hFUU2{oNft(c z2P?Xrz^Vf@Bv~f%y#gANTmVCo3E`R>c6C`?sA1u+DHF?V&xa)WcREB5nC`VJhGt$# z)3w*b3oZURu=Dlo(aAp?+tN6F~T#NW*$0&uc z!!KQZRc7~=~A+3G&D z-TTtFbifsVm3EUKyjJn_7SHMAZLyi=;Ce5|Tgbg@N}^&dRXDU_V7vGBuC!{L26)d^ z{%Y?)t~E--Cu24LyyQ=7H+2iRaDB&mkq3E4W??Ka;2`7&@`sK#EYq@zl(+5%`9AfZ zL8WVED4}7c;F+6gsCSCr z@I8tVb9+uK^i-)9hxpLzO_<-(;)}U64p4*(GI+T|`Qm~pZ0S?vaFzPBBM>5)LVd-= zlvNAn2B#@D{Yc)3b$w(UW^x}${h`wst6qeho@!v@Sfw{H;BabGdBxzU_=Q3)rsBO` zCTCOst=HJTNfVFg00nV3{8{}X&->@z#{+g14L6^wUR|fO&uZ3Z{ZU@VPH4OdK;XBZ zoK+NyD-#?-0SMg79na;FO+QjH!sk-wPV&{)j`K|?32jmLAb(0e(H#R!y=qMHoZIWl zN6)ad$3^YgmPloGvca7V^}6Hd?^_RYz@1I*Yu)k=VRB66WLq4*?9LW;XWnAkrlI7d-PZuKoDx}Cq|wJpyPJ7_7&MM z7K})~DLCK*95B4sb2w;3a`9p+t3vg$9a&c$-e4q5%{hB&h$F2DVlqtZqz&dVy!(c-4Mly*2*G0!o z^FKOnxY6JH@Fz-5SQy|(7%#_EYa6!*&?W6sUkiPlqD^n}L}F9=Gi61)ia9bw0w1jQ zb~5tLyyiahM?0WOXHmo0&@&%w&A2Xo-`9<$_fm-u$p|C1=bT3KPaK$fIthye3Aq~h z;juf`ZwUboe0!3#?h5m&!K>TeD}>JGR<{m&qQ%o5+J`$)Oh|Zkd5IQcULmzvWzWeL z)bp%dc`Ut`cCc?u$S*>kUPq)!*t`gZ7O6irGD}`)_f3tnL2KK_^?ywx&HIW&CInn@fX;% z>}WK;R10&Muy@k@_?yM37)SYOc}1{ zM7vkfMZgPIef`RYxViXpl!>|URb%$Ti&U{c2-s}FRvyZsl?VQdm4|t-^3dK1z=vG| z+7tuXu#P)8@gutxbM|twh}1s^ChI?`5Q2e8UE%-7+*<|3*|yudXmE!B!GgQH zy9IX(?(S~E-6c4L;1b+|dvJGmcbA6UB;WVjnsd#y_dZ!1P)z|v7xlh(-~Eg+u7OJr zb6nI1vO-ENDrxr5%yG;R8}VD_n6vp9m^p?7W{y39T%CVpjwk+bb(H>Oj)%@u?*C+t z%Ym8W!>M)8ZmpDD(0t-zYmYYc)mnFe)eE$I9ldMI^2fjVX6+q>1-gIuW>i&M4mdLr zgPtE6eRks_azXA;Xc7$@-UEXf_>toevxM}AlWk_jArrqisDHr%%Y&-y$AHnc(X`er zgtyG`PoNq278hs+X8Uah#yd3W)E)Y_%rOfvbDU!Qml;@b>~Ax0Gi?{rZ!<71&KL5Se6t*pADjWNl_xEY;1Fmj(6mDbM%>m>Co7O*f$bIWi1@(viqL^(&xNsu;T^*zmX9WbQ zlL%T--QID^OfvW+>r1?-KPoO1IB{$9A>K2f z0x~ZLrQ0UfRA2e>L>%bI-lRTI_6pHFfSYwe{*%De{*$+fLt98hQGNw zbdo#=Z(JQMpw|q@)iKSsk@_ohd?Nchb4>X;YCluWVW7E_2_2~MvkvOi>&{p~h8`AzlZ zu6skNXQUxYXv)2zbq;{e2g`DnbDjUbGw2iDVxE`Pi?GaC+0kj7i6X!0!p@jrc6L$lPvVM8*Iv{u=0Gd3 z7lM49ZNuL~*XDdvHC0%h04D%Yf?};Lu5~&ycvf+HG`N@O- z?W$EcYi`DSRq?L-o4sZ%#^^!DIQOVLsq>;0&H>mG( z5-?31)s`r(eubPB^(4+Lg97z;VOy`qBhD6?)Z1C_50tik=>GEs(?4gukQ*x6V{W4Q z6V?%Q4Kt6cuT&qG+XLj@3fqQ6FY5S|fQ4=KeQbGY#x{nj+CNa9y!_|eTi6KGcLQ}_ zhr6zG{{?3D?k|{G(;Li;>tA7J&~Gra-z4=nnAtx_>Y!A+#sN4V-@InKE1f@pUb8VU z3Ol6VWSyiSB!vHcU(j4XjJEmTvYOhz$!dT@kTHuZ6P@t^#caZo$Wi{P5uFiWPSBD13)j|5r)p`ES)#33m z+@sD5*#dHPE`r}=HR0XBKeAc^P*yAcBdaB6s=di-X{(n1O7ty|wd$t_%4)xD!2j-g z@WOI?qo|(%iM}C!DC*EaiaN~d4ib=}9;|VU>en}b)%X){>8-f}iI*4-_U)t>^3=a) z>-S0TJCfy;_dnhLCs~c|O;!VjkpE9*HL?FeR>S=djHIoDle2^I|IH@f6_`V}x6Ysj z;F9}4Jp2EC^8UwZ@Badl)arKuKySQ(B-uz@F(k$`nA4a!eK+;3K2Ek~WX^xBMuumfOW zo6L%PjNv&qRz|Va#&5LmAEdg<8&ZAKDCW=bZT`pbwfuYdHZc6h@Pz>mU-rL;um1Vw ztV75+AB(!=&JHBHQU4WNqv;Hp*&9-QG@NT$tWrK{B_5c=aF-U^^9A4Mz{0zW=JUjfev4GS%Lu@2H332-BRFi5gB1A0F}T zS$+9{w`12C|L?lYe{juAK>u?3R@aGY1k3(*`hF>p4qfKJdsEt;%$6p8D{bX_f0Q;} zpwsuNdf<=Jwu{&Gd;0p5@3X%-eP@79Uy?VTy4pW@>h?Cjk-mRQEOyZCm*RfwY{R_3 zeb*As?sxd@;qAEB^V8qqw_srSE&iY3w=`Yu$}0zlwN03@kkZgc5}z7=ExKYnpMQkk zfXBTxE6@K3zghf!+&khsY7Q3X_O|b80{7i6;Jyna`M&MDK$36#8_74b^3T2tfuqC6 z2_6Hi%5*F~=lvP;D(tFD2nR*tKiyvYSNJWHjY?o+u<*4zsk8JqNAh?0jT`9mefk%l zZ_8idH|O7NZExW>z+3q3*gcT_>Hj?ZR`hS-w|>6A!f)39Z^Lh`{~mt(dhz>g0oYs) z{Ll+tru+TiuTQ`c1|nn&Wa`)$(Oa1t(EmAw00V&rX?9$o)6mkoHv#@)9UBM;+JF2c zu$7(8$k-$(?Z{?{2Q~N=bD#Gf_I+|$LY4ZL(c+QWhxn*Tqjp_C1Li2UYUBM_HrMv= zXq?P>c{u_oZS-02NMxMCwiRQi?03HOY1#J%PcacEw?|(qbm?9_T|HlseF2jV{I<7G zA=e)xde5&adN)&{yEM2We5=JEepP$9zSc5;Y9b3Z%7^~I20ipn(?vfBp?Ud)hzi;` z{t8V#&T^8Y3WJ7(jk()J*Hm zjoZWA)6n_kc-{0-H4C-X%#ri#V9l`%@Km2yR^6DKST-Rha27L zXnvH~mq&>f$7VRwNoGyM9WnG*=j14p?agWYRPwX-OUlP(WXPGY#Dwhk$prAnxCT2e za4>MtNdtL}G~q2+q9`F>dZT9ZCmB%q*iQ=WGD7jX@A5DfiGCDGpryqwiJf8Dm z1L0*!E~?HY^q1+p?ACC*FW+icJRvu(u_9E)CgF~Sb`3qr3X@E|LkF)Yg6&c$rLoF( zb~0%JFLV9 zTXO`SG274+9ft6zj%<+itI|0`>sG**o2{y(8Q*Qk_qor5dNy&72fOqPDjvZ^sJDXe z@+sn)2}cTPj)C@kMC5={4bMX#>^2X~WZy=6)SRkQjNX|y#Pv9a#4>a4Y$Vi4Py~-69{(+In^wn~F*vy|XblJq@CS=X8JCK!%svHn#)-RwJ3% zXcy!*ygJTryurPCt$3%2rie zlrMQ<&Et*A`yGkMVbFDufVxkO{4uHJccG($H;!d zsR0s2v7yqLEsLNLIP_v>I~gN1rc(j9u#57j%j>1r!qqPZ@iT;An0Iq5aqW}&Ommo9 z7X~4rznxzVhiwz4ocy zRo{w+=$eYcrXsb3BJl+^aPcpQyDUp$;|Q#{W7e#<_K7(9dS6qvt)D1}+x4A+)Z(z+ z(dRjBVhUwMz&emx$#nlXr4QxdVUyF)oo)xpEVG)5?f{3QpO?PYsi5 za(`@6U@!TR^JQiJ#HMn>HN%I;8k2mI?GbC z;9M|=XAdoIyYXqf_O{&l(m0wc@cY&j?53oqE+ z2$51G#|e~>^K01>jA80EliY5^4Q}W;xHPdgH2r)8;D2Q$#YZjo!TRyhhC@U^Kl$hh zpma6v;>?bZ?Gh?La4g*1`H7jc`w)-loC5)Uv{}EE)tz0~7Cg9_kT)pd^0@k;V3-1d zvj?{G(Ph+Pb+J$*Q@D(%PqQgw2ELc2)DhZtK;2JVV`+iUMuot;Yw?5k^60I7=_3}? z`?D>V`j`OWve`({r+c^`=+*NXvfpVozijbMbCBw9628V>OX+4v;0idgDoCbbkrOyP z1`FeXDDP#fBFo{QURI~g^T!I8-JIWy1YXN~@saNO1WNoOoCOWOf!*LG)1W0MRzj?b zW+=BNr_s_&%m;^K91JZnH!~rvD1||F2(26QYYlI@PMz=T9qX|v3VXKa$fEt;FNV!4 z#8DHu%Cf7W^BkLvCbA7;@FlF(2z99V#UjM+nRG8HkxhFyMk95tlSOqm#&qa;o-hM4 zOA$#{sM)aIVP0@7C-ZTXOHJ9*mG3@V%KrP2nyX>3?k@Rpx(O zW1UTX&ceM*#U(|BvhoGZr%H`IitKU(=U%gZd?YnzwgIy;1 z`SwrRXOJ@weMo-Idf@_f?yxG|Y*Iz0_buNniJdvMjugkM!KP!hvw;nv(oma-y1&mhJ*^ zmBMb1mxT}kCX!j$<#JiPF;jN8%j_DHreZjsAV3Q@o|}M8uD8krPGP203DCGESGGEx$TE(sT3i^JlNEoa{&e zjy$t)bVbo*=WTGNZ*GQO{{o@Et))hun>3Ej6N}=gz zUpY`7H1PsmagiS-a-7SOYFi*C`0_=mPb|*(s=pA&+>U+<*yT&%Rx35$s>JYfMtMi0 z6f9Ivyd*$K93aDqh>Y(L8K%M(Jiikd*dr-%+{I|GpJe#ixRC1LAT{gY%xUaU?Q<-x zy5!oNV?ncA_UY7~)7aP^qYJBHjmEX3g9l%FL+SWJb7{Fcu9H;stF$4jVfGNpwf8dt z0gcD%XN+Z+c>@}~b7pV4bR6CT_oOPnIOnJ}v`vu2$z6(h*0{<8(&LsQv(|l8E^pWN zt+Pt0(KS}hAY5X~9aii{?#lQnxcR2y(5z~l&r^-k5@eN$oJiw*i$;kJHK*?^o!tq` zhTtZg(^{_Pi7xa!S8l>{Klh)n%i+)p75K$FU|I}sy}QYKJlH=zr(!jw-Y0)2$j`Xj z_b8ct_HzLn4tCoeG=2}#MeF&QhmD->gT{NU*}#P@Av7#io?Y0k2f%kirL7EDYN7!F+R;Yj%*1p$R7`o{Gu!X6K4wv zF>!YxSnj^itc7Q`25?E$0d2hX6|;-?v9Y<#inCy!oO)3c9&)}rb`;M@jk@ab#ZnAI zp_ZlW1}N(gRt9*Sm=narXa;s;uVIM-`t)if+Z|rM26ZJBC?d7J zyW%I*e~EPmA?`I8*ri)idGF6@S^#3a?`=d z5P4<)Y27PhbMOOiYa*>GKF<6kzUxR$6m^h1Gc{?pDbb9mrw3}AIe^J`$z7W^54TSI{Ufv699e9ZeM>yF( z*gra6gaRO;U-L8QX4!k6E}kU@j3YT@1w8Qe>bJ>lWbWQHE#0($o`&#)9@U8Gdnd1p zO+E62WTNpNG|h}eB?+m9OK_S>=_QVaRC}+qq0y6)fAgk9JdxT!vC6)N>IMTR&Ia{m z=;|Pd%n5q*AtKpyUk-T?A=KkjINwWp5IKbs^2oDxgT4i4gnshF;>J3I%Hv1rI=DXt z_XXoTCyz}V2f&yUXx;nDj=zU!YfhKbvkmY@Mm-L&lS6rmy~V>gx}!Fe2Ll>FD&<+P4}O5P*A)q&T(@Aig1ojXr6{zs3y6X~&|DyN3*c z`@|05K3VI62b4PWOT1E@&`ZzH+&SOYzSS&#XzHzA~h<623A3-neXy(^Nz2435swsL+e44ya&>hC;441N zRFD+;koqW2R1n#E=2PtR7hIAE?npj+hVvY>L;uuq6!G)y^aX`|#?>Bi zoEWOa7so2=M{$b4mx~Ck=eB=|63Fl+J}!5AX^o|o3cp+tUO#o6q;h3h464Nrmsr3w zN}e}fjycbrkS!^^GA|*Jlm|$BhH)ysW#5lJDdiP9k;|EWfoL2w@(pi=Zx$__RKl;w zkUJsOFKQ*};hfZozo8{F#N4;F_ZCK-W8X$J>DhCyiaXgzxBYgd0WtMJBa}U}%Y0A~ zJn=-`p{w%!8F*pB-Kgca1{!^9Yi7`Z%b4`3#LVf?`QkocMz8pCgP{{@sQ~fL@*@F7 zEYk1*_MKz3*-wQ=m|I6Kq$kcyKGc)FZMRs+F39sQT2HW%P(od9AD2~(c(Aq`ma^_n zXdVbtN%^-wVZW4Umf=GrT}rK2Sg_oeekgq^{S;U3VuyW?_REjoFA<+{rcX|;X&<+- zm%|6b7?7JXvSJsfGj@@v4NlDb4uOZ|eG9Hnh-VIn^35*mF6#@JWC$QPJ_vKN>p z73>Qk4H{`vK!8HF#i=DI>1pnTZIV;CW7HP+X5#(baO@0gRVFd0pX7R(qQ;kl;`$t#V za_rfDh~OJW!8yyL?^eEz)HZ9Y?Us7mNZ$a!DImAOJ@Qal*&(sSKtKL{Ai_>Y2jWcF zUDEU6RPng%XH_d|-|eUAiA8EaU8Tga|1r3)3}J_^(m6fOZ3JQFJDvL6Ha}r+@SV|| zv%$cv22UG-Yg+xu7p$2ZTENwbOH%Vl#TQ?E{q<~ddF{I~;@lIu^D#r@=PN8v?%T0^ z-{uwGk1W^7_YJ6!ud4pkCYQDkPUP0DF0i}INq!H~q()=p06bZV&GI=RUvh?PSO51+ zCsHH;(Nwigd_~-2!XWbD+nF;Cm5s=mw&+V#+#S;MqJ_3c>MU~Dvfx`XhFW&PIirRK zop4<@+@r7S>g^CZ2@35V))f?$U`OQoW!WNMO-`Y@rr1mM`E#-+Ikmtnt8c*xQyXtR zJJ!HppK0~*Ss%3~`QC|jIT^UVj&<^pz}^yeno8di-k@MQ@b-gw=W*;42l<-KiYx0i zD>(=dz`#FBjE697$$)!NTAyjoafP2mDOlOUud+_LClrl8CgUJn&Ng6em)kbo4PR=q z!{cn%*)aUFT(Rp<-M+aLyEeb{kU2r<3}YVBTC1M=I5xhDoWWJoGKB zgO#WA-c^oVm_HwBqgTOIW{doNJ!h@A#RzcATOw)4=)R!LBweQ`gnB_$G(C7xTwJ9% zc_uNZ-!0iIS!ZRAS`+%<)Bh|)NUT$_Uh$#NRzj^MynQ6qiPfF)+d#wxTJU{)o+Z|+ zoL)){nv>|R`>ek-3eC*+!9yVWNX8nRef+vj2@-Gi$4=dp>$qqFR?EupNCG7>{W#h3 z6#M5;qt5K9N7%$!wJ+Ap4~3AV4|at2g+XOrL7!;y_R3++-P%9($1oD)tcQP(?ZF}X zdCIAE;xOT;6W|6;NVqD{C`_^%J8CM}e!?lZ?v*fXib{T!8hBFnAT15{0#N3Eba#fy za()L0t#oRXvB`au#45=SyeCMLqdG2^7Gb;Kw6gU#^hCP{bL1E92(8O+z{Z4fPO#M z(V~A{VeG{~m1fgw9g3v*eiP{2ubB*cnJQz=qL;NF_l2Dsc~q-j|32UDvFpXxdB#+R zDLi9=PSgm$dj}Exz$;h>;>6?&EhSN*?S-_9B-HgR*jOCtC7%)I5TIIQ3nuK1R!hzN zlAvz0RxkdI9|P=Bsgs`dx-h33u#)cqsC^H4#o_Spu0r6qegGxR0lxD^NUoyMidssfb! z`u0j!tP7v;*t>5~?&I*vXfP)Po(=gFgB1u6j|6b6`jXsSJg8De5@mEfN?;ukE3i-L zMn{y{KGaL<`~=U2GCPn4-h(Yh@n26n_CUGVYFZe=&;98t=H^$C@wgINZfJGc2bk;F zMa0KQDxAA($lMEVgUxhJyqeLo22ald?_B}~y}11qp7jn8%o zvh5u?FI4){=KBlqmq+44?q64V@glW*eX>vVFqznfbw0XcVloR`oa;IQDKfhVh*#!P zSBlAdGJAQx9TL#TUyON50kBhdE4pAvo#Tj%rzE&ApkvB)->7_@P&gss@$zO`o0_OW8I9dG~Cy6X) z${)&!*zaI z=^L-L!8XK~u(Bnqn(L#q3QNpSF1r%Zrw>3CY?FGU;@ghe<(jX9H_p>g1D5CfN^f+V z*Y??K`2kZ~P;29b%&qRdeKhUjM5~6XN8roqXA>SvjtXxG!_cfPek&eUX0w9^<6s1K z9UB$`Mu5F+`%ggL28Vi$Xo9@0CP}otrw%`6V+YgPmX^U!|LOFpDX$6*w~S3W+N-)p z`hCvCnoAZ%l@UudQ{VXF*Yb^uq&tRsKWl?yvDw<&3iSsF99;ens2iH+<4Or@BR@9* zQIXfb{CT|i%}9w4NRrvJj`))7`PWfe7+A8HwJlp1pw@6VqoXJvo~n(x{F~+{E83Qm znOC)&wE3aExI#k6qcwJ=0KVVW_M4fGKpv^v^HuWjM?fO+_V9gO4cWC^BenSk=e_Bf z>iw%s2d(2gto|Qk>6X_FCC}C$?2|)ABId z57TlDVBS(0Nyf!rD$xjr@2YR%JOTvgdpj7zwp+4AOwcS2w)hMl#EOn7dTli{L_O>N zQx2W+-=smy@V#w<2A(?+z4h4ryKoAWL#_4AZRmh!PbZq*R_Og0*-w?;(bmTX3G=b_ z!NK9bb{W`65nZSwt<98)E4?ElIOb1JqP;zj`>O~{b(Kk|LS_$ksTw5A6>kD+@5@RQ zlRm|jlu$AGks$#4hVvDl#N#3vf2tDMgDZ2mtR0`?u@$i5zgWzmHLx?E0ajZoGTE7T zRUw6LpdVuIIBRfD4j0i*CWBQpwnT{+7sioK&JGvan3r)^F;3=!_62nmzk|mwPD;aM zfUQ)1=^I3O)S%%1(pMs=zQZT;)m^0witt7k`b^AFSHvvY+W)K}nJuSkjL^xkXvJn3 z9T9k&<-t~yqK43lItfos+u=s}39?sM<64zz4>%9TOAl5rpeZ-Ri&jZ9Rl~}CLJg}2 zN}Wv5I}4k|HTI-qlJRVlu*M#JXxG=msRkb^BHT3+PYA2sIujL*Fv#MGO3cfc^o68w z3P>_O_X-G3vx?u9XZdC844_G+i%f~;RuDxrh?uj6q{Ua4;Cib|eJDLg)}Fgod1euj z&MkNmzJ}0Xh9);N=-gV`9uAOZWFjesEEvhk3rS6uMJ3Mushl5@_u~p5WQZ&#-vbgZ zza9)D%87+7%rlorL~Ax4Hjw9oqi$~zat#UgW>quDwy_2p#kD)q&#Sm^pFo?Jx`PR@ zsVQM`wh9uvWrwoWr7V9aTuX4)rjo%(lIZ(j6-4vkp`>#P zBeni2)>(4V9?yAn-F;K)h?3+=Xu4Ig;M#g#!N9SZsNE3-n&u>glF3zF7P_+Vr)tPl zf6+|)3F^f6Y#}hKeF5f8qyfjwa2{Od)tu>v6L31Lv_Lzm%XKWu^20`k!VNlhQz)#=9z>bqAyCt2D}xy3 zXFn^D*l_AJ$B4RK4a%d4(qpIU_$H-vlVdZ7p9gF8rM{=lgl9BV5;5(AjrmqX#Y`5Q zI!SY@@*c4<5=HjI1qpq|@_^MvECu79>ITR!BPXA+9xJCK!*A)>NMM@rxdfJn+Ez+a znN*}a*ichRq$bhu|3M0E%Zlu{$1W2#P2>h$}9KvrQ?3|YRO|3o%* zNuueUKUOgSTUlmOE#yhu0P8A$v8-6jaMh@u6R!WUQA_%vpauNAW!Oz`3tq`IDh~08 z7AIK=iZqo`B*S7Lat-GVl{zP=!B`*o<-SIwZ=1f1pU3YEXC36)WW_Mv)< z+!!nO#Vf2Xk{no2pewK_dL)BEkGTA1^-vA05OYy&#+w#IdY5yONvHsLL}NY2;T_)f4SdRiE03SxNhfnK7ar4G znH+sza(kqEX)MTV&Ay|W98IG`799Fz3PK4Pa!;gs{t|yBQGACex^rC>%|~_cJ)F;C z-w@n;dIIW0h2Sr>&d&Fv<3^iBT<^g8<~r?Q0>1`79CdK229L|pcql=Xu7bB-U4eeV zt$LkZih;5!Z81LFId%8!FwCi;F_DLQJM`gU94A6=N_vithqe4o_f7B z#cbXaUqb*}YXGO0N!_@mo$YV3eob!sak)wGbU8VUy8{QRyPgS>D^z|aNNz-s0fpzk zR@J=Mgw`L8-wywC0Rx@Iqj=zyj^By^=BC%YeGY}yBY$usEPz=a_Y!eLNBi?<+*VYJ zR4yNPFE3m(fGtOcQr$dr-|9Mi%gS~!nr;623HtFM{DLpnlj+rh&)1eYswN5IgsX<- z+hBp2YBw!>JC;=`$Yb5oFA{r2=JAMX|fTmP#GxY?rhd z=Yhnc>bE!zQ*~#RyE+O!>2wQ$86)0b-Uc|R4ji9hzQ=Sdd}r4VMdM38AKcNPLP3x} zCC6FbZ69snVbSSm^@I22>r?%AA?A&jT~kiQRZ{}^oh|gsBJq=>+XLVES?#BL9xNH_ z7h1f2@Ko86Ab-hTo1rM>KA(XwHR}TAl{rt23Oep%blk z$^ulKvdnb5$&Zew{jy9f#>bAzb8V}}n_|9#P|SOyO2tDxDvg^=2V~-#%Obd)LrLeP z@_enA;VKxH)b_f;mZRkmmz&kD?lf7i5C#`@$&^;~k!=n46ZB^-Yv*#Fr&_MZcPFm& zE7xN(^J?N1kh^pl5;-pmS?=V>x7y@IUtbQ#hJHHVvi*AGj&)>3o;Cf<$HVY6CHJ`p zb*^1IXgr2b43jSafN6A`?F0T);EQpgd(Vm}ts8bp(lTLb*G!T8Ms5fqy*Fx`W zD%R7EOWnGMk*esQ$b6VQF)&BGzIZd&jO+Hu$JsVs)2=9yS+6lEVG!IKIxrKsUiY$H7+F z(|-5bx7Pu=n^_@8Gz*%MxwVl~UvzbygMD?{!LOVRcdui<{d@ni?G#jQ(%e(tzr=z8 z*Bqb$4EulGc680H^-Yc6_MP%%elv7nNJQ7F#cg0^hv1WlqR2D&2SSA~nf23cHgfhM zkFae9vY|As(e+GBIzm*Dc_BN-pdc3_bu;tA{HUPJpq!}8@+5PNp0C(7sj2La9~*b> zPVUkdR_<1hV|>1#3m}CanX*80wh!aBdzmsHTWzOXHuy8}A)V)jd;mCprGBxXHVZ_% zF<~xk!otMg2XE z{1p`=ONs8=%txMYT5eq}Mw{9fxV1LOS>v=k`qAlbNnpZ9WE(ImU1+66rG^h?KtKGw#B#jmea&Wq(qpv(8MP-#J}k$i3!*UO%@+W5eHxo zY<-k4cTbFTpFW#tIWoF#v0UXpL_%;En{`bk9ov7L59Orgw{?FlvQ6M&3x0V~VA@qE zJR^uWYRI}9eiCmbyyS*|*}K7CU%H+>o-DK{NQaBUF0Ov5m@&y;MaNxr6^N;wYk9W&pzc9w% zF%5=qpX0}Q+MxW>=b`eQY8F78V`TC%-KNrnYARF}cogNLa4kjJ#!A001iJ_S=hD6h zyo{MG;F^!$0k7YW|Mg{TZSDr7IK8dy8roLqD(HNcAEEQFV>WXKJ{(XqBMOV&Wq3>G=m1UBqDZti$oeVi|;n@nNBPGl+aI3X4n0 zL2o_Qbq*mh~h>D?r_W4xJ^H|K3dYM)OGtul~ej z5^}bQ{e)xqR`VGOL`SA4r*7cKNHL=&{}BDi;;q#uTs8G;RXMPd9mA))mK}SnNz-9+;CQ4tz`XgFm^{y%08y6Z z2U>leuP=1Z#fCiA3kUk?+9EH}j9qJ0UCM)NL7#eedUPi|Y>FWVif@;(jQO_KsO>%+4KMx50cYYIMW_;7K~!WVhSj6ib8tW8`tmgnmjw24(J_=5Kf`W5kuGV3d%av%oi zr7h&gXDva`l36%#t1btB0lU&Z0x%NaP(IBh{sCC+=k&ZxcuV1DSb=lu{Z5>V2o0xO zmy@XnQh_TeCxw}Na*T(EC93nhNAPf8u1`Ju+N4F$-OpVcd^S=%insy~r15AEq+r}P zkJa!hVn1`wpm>M45c2PYGb@fT?#KKY*97pH*FZiK?v);&f#B>x!bv&w8=sCnz7Qp@ z>gH90+|9+`3)I0qcwPqYG0JRJjIS-}{m7X=-KG{S?5+=J+{%AOFo<9&`ezK z0)$V4Wm=lGJ0;H3Ym;(Jhg?{W*SW8!_;0FxBnDor*J=^Ee&HM!KLf*O4j2^z{I;dC+qRuj)tVmV2# zkg+b&8kBhEXz;zbscX_mE8fgs^44N2t}rEmF{6PR{yv3SHluzELB|kYi=I$LZQjH= zxyGNmiryXWZ|zH#47R{4Tf1TWdUr#Vi_)-k+&2d0Wc7HSUG*iY((Xm}5vpcv zAJORjzH}p9efz}+EQC7pgTn`|{ni~?J#=>0XU{Gxa*px7*R=+0J>)b!|5toE@F9@* z5Ry>r4GAV>OR`Q^h@kfR)&7m!>ejXIvzaV+b{k9k8{a=50{U{GBIB)hMvO3dR_q}3 zOnsv}slIH1SnA`Sf7-X_=s^IJ#mb!SM)ss#C~^HU>c1M{1!FK+F9TB!=K+7scXTCy zAMTrfT0iUO{!SfN&7eY7{%Zo99r+IR#|m8hr?C%zQx4z!Q~=;hWC>bxcm+7{B@+3+ zJlE2-F?M=;fn512BcZH--v2s7M8WEe`$R$|n2R(}MbZV!Uqn(mP&^^ZvM`K5PQc81 z#X=Ff0D-imf~+7pEkvY=t*ktoOYi?)aXeR5Fnw{FNE3a!+1AT;wE2!FKbaSK<0bml zk^kjxd27xg2RF{lo|ku8AG@x)I=ECqqGyGU8z zWj>j8;|W$jkO!mt7uk1jCa14;69XNLY2P*b$GkLP>x%SQHrL8!WWnA~!V?CENKwMV z$sZ+9(6N#YbI!ge7X~Td?6T@nHEH%bGC#u{@H23GDgTKN+jJxU5?mIN;Tpma4qA8U z?it8!i*#$ZryXFSW~?O}x*5G%la>hqpNn0>;-MiU2vCNNAW#H|VC|9nx8DO;2=q%f zGG}vUHjUOPM-;jt8lo1C*`luuXA=Z*CC_MzTw?aJR3w?;XS{ zP%%!kT_W0)4X?CII~A0Ji%pthKIfK{=qPRT70#igf#h^&m9L%$2WQS7Xc!poqa0&Zh=<;P-`+b;x#rAR032 z+43I-TdVa=FkvGLLKC;yOrLsrt!$e}tJseDKQ!16Vm?vK*L%wdl;Y_RE@KopAI==j zIPcr;QtqGWfJ&Qx=zTp0{EKH2p=y)HU2_Ju<$rUJJ2{!W-Qy!_GG=Ik=sq_eKfO+_ z<=r5ObS5kMjuRvXr`tHqWqQ0`@ukxq*G!1l`X+c^oiMY1U@kYbWM-XV& zOH~F4NVJ~uK_1XDU5V@1}l>YG`|-bA1)RhaSs@;nNjDp zVup-#wTNf(fZW^nv3Y5{UUsMR<*A9~$G=oe|?7?&wHYXlh z6w`r_>O*>LOcfVtbKBU*&9P?jEv>4*nnak_-O8B(VKv;jgkk)QTj?9h zVN+6^boe%brna;)nEnnI=*dO%@q?$kDm#+hi(AyUI{|DPSn4IQVONVq2L_wl+yRk=oG5NxH_X_=`=(6s1#PzY zaeeC%+ims`z1~|KxLIOOl zsBUpdzGQh(zGP_IWiO{E6?E46vCr+{$wwi}Od9PDPcq8wGW*WI907fGuz)_u4*)=4 zCOzf16f97iHjyt3xMHxO06c(67wQk745u|{rs|nLuCCK?cYYX)h{jmsT zREW2k)6cv#_#b|U>A-j7V)Hio4Z<(a?f-n=O9H&%`QB@EcKvn3WBkYQjia@lvFY#kylN{_=nClkj~^eZd`{BP z-$UdQ>J#dt5WyIecw?bni!z;lc6M+vNlA5PCV5YlO5;`8fe$+!7?@R_^}YRDKSMme zM@h))lBcQ5X{P7tEf(a+)aaS(SWN3))wN}?a>~q z<1pcZw;(}>MUsEzHUPgMNu)_O0D6uQ0XfUy zo#uB519LR8iOZk*?Xb~I3Xr`?TF7?@1BL(%Ve;FbirESn*Vql^B(K$uEy3=Z*{Dr0E{hJJ^{7mEH zd(o%G{R*tPea3rxL?WqY?9Y8jh zuiybcoOZkiGX^N&dc%06hDJK(_mMCX=H<=9ju_xxRG*fwL!*g6s9D8h71B^1G(j$1 z$WmQneVaCv7BA~Rnwq%8H%~lF@GIiOew5Y7etyPPN^hpkBtV1T zU7gj)UnQ#cV=8MKGQ$H8A+E)VI3114c%_~~7WH~3UMWei{ z9e6HXS#RjE2E4_tqDt@>IjjPGl#y2C481gqkGHF7N1;Fu2hDT<4Ap(6`5J2 z&7DU|k<-zpbJtH3ovC$ZT6{ACb2bJ^J2g9)s9U2^7wALXN)RnLJ9jN;Z zP=Ik>i7F|OqwuB%$Z?SAuTD3T5|QS-lfQJoAF9p?TCk)YA2H`plp+{!wS|(G82&$< zoe4OUTOYtj$d)y6YZucg8e0^PYF|T=#LGda9q_`#;wl3 zu2^E?(B-hwZnF*-~Ha zl}T!aUhQR{cCdn#B?p07tc|cC<~?D9RR{}#b(ZVzLm(-WfL`ZTV#ES&wh;~jL3|;B zFzu~iq8r)EvvZq=&!W3RV|L8ryw^F&pRcc-n{!*M&FY|dP|>$X@e!#tDVIVmb??6xFS=0uxCbWG!V z>ssrAYQ-JIicdqf*9#nCtRHpdJuC5RZ*TU|*?risyQ;`QMCE1c$}y+W$RYETJku9? zdEaGS^nUc$rP!yAkMx+g_8C7jw8&T!-l4sNRFh>azR1s=b4Ra(heY<~8#~IG%I|f@ zJW;u^B$+MH$A9pmrAIQrq^Uk?Wuk`GvP`zN#YA>taxEAeM z+{+9jn(|olZtQ<8_B4(!O0ng}yck1?fhT%GLnf@<@#V?v8)96DOMAch$Vs}4bzII1 zG2VWoDqZrn%tz~Zg|JU;eEXJWu^bHBuf+ZSl3DQW)q!V^met8*;JuNvhXw;wB>f6*3nw27vGrWV(yGXJD7}?UHCrU0`l?ZIL8tc; z-6dkF1RZkp$dfOpMPijJdOf3<3f`HiMGAIulmHTCEc@Y*Em)AlC$T2 zU{AG;4{_3Dj&*tH6?3bgVQbRv_H>EWuM1aYTOCn3B7+cqk8)_&ETbJ_Nh>^*U3e8HTmfh;reB$u^rK!DI4|XVzKUj58J+IZV|EPgVCAZX> zEUwG(2G_O`8)^!YiCjB=@P6KXLeby>*Hx}FMt^VE9KihGSfOAflP<}*SAk9OUg>dD zZS9yLkMt@niJ+UJGDdTyO7A(pWZJh{jQeeR?LLovImJ2E9U=GZ^&H2lhXQ%p)gKdEJh zY&D;}RxXeJwj7lUJ{zBMU6pZv#gyAn82iZdN7Vv-&Rq&jYZm{bQ~&UAU;eV4B_3JL zC#wXMyPb|MGN|H{kbhMr%dsbR^Oe`uPjq?Aq?2!DCM6CZuXca__+`V|(@g=5GG%8Z zpWQG0)*i)PTECSwH(A&J`tGtrA50S0rRF*6Jv$z0@9ZVK-*%f=Lo?@qj-_gT^3&!8 z&xd$&(!){--w5x0=gU-vY=c|J=aEB4#*%D5YkbmD~@1eRH5T5i26vt~(% zd3TF@=OjYo2n&4-om> z?N#*te{HQb@Ae$Bwio{zn>^;;KHg7UHPH3zJ7?`XyB`&gs#`jT?KFcv?EPADz(KT3 z@)*yYp{4(%bDdlqFn5dh-0EvVpM}J81&(~%IV;e8gFrbr)<5`AT_c%yez26!9dX6$ zuCKTn*cAAh9C^E=j!NtB+!r$@Gplb6B5%0bCLMq2bEDq&;nREr{nn=cX6DwL{>nPQ zsd{4Trv3I>%9lhfL``ohIsRIBCTc4WtAbtF_{B}hMAeVJH5CQ9oHQn@BaAl#fu+djzf<-pXVvDP`l-MNtC96 z(ep#%O+3nbAGhpuRjK?W+_5ah!NbeSVV&Uir)6B#1;xL@TLXma+ro#Wh1U1Hd0faI zKd?XH+Gm;dJpRjK&$Rj7y8pPv&rO1C_V9thoo;V-Go$?H*FHCPDee>FZ@Vp~ul=LG zIuxXcOta=OQ}au*37lVY6Tq?C6JLCUUs{x3&<>Juc5zl&X=TYuU_QN@l5P@ya|FTP zVJ8^R`6SoSKA2+)e&-6l=l$j|fnOJfYl8nn94AkAlK1b6%>Xemg}9EMc)J)JRnzh6 z#V=L@Aq2b^3=^AhiQsfDKrBl6xt^YA$p$+vgdCT%(K))fkz71HNPDI<6=JcPyw{qD zrM3BD@<4Mw4*^V#sR5)ucqt<&)zrRh6k}@40-Mf#OK+)Xg@3d#~I7{&GVNqC5 zLEzafW*vMScq;HxuGF0FS&xsTTDl=DBRM|FdHhJ7qXs@t!VHjb3Ecr_3qh7(A(C>u zkhAZui4w9+z)IH5hM#)@B&i`xPxSHe4R#75QEv|c53YFx%M8wFBFcU{*=hqGJPi~O z%xqx5q(1qqa%}l*+4+Vjkq|9p1#01L@GS^=?iHc)q(1h}iN~HjHi9W`?!Y(1h^nq$ z%Bf6ywCQoei;+00U6nAlp2yqC%cc9Xs$KwQn?XHX81pF9pq-yfmc22{;0>^;y?-K@a?N;Q3iFjZlP z+d6Doxd8zs`TP6)zMBo0_8?5VfT^+^QH~N+Z26Nk89=F~FA=6j3{BtZAfUUPyu7Ar zDo-4?TN(tW@Y(J|ep%K%C>?LwFu-tS>B3J)8hpq`VpG&V*CGYbC$G-X{{WOssq z)___H_wh%K@rYE%PYA~lx@azjT9cMJg1FmfPXO87#beUc6%o)8U^+6OzibsSB?42J z+x7=8)%QEXH=NEF9zUFI5WY~-;E!+}1Fn7NE8fciR{`J(GshV)sh;Bq&m#;ygX|HW zo<7rJ8inv=$!sD9`Lb!rAUy>f@R?Lk_6qFSnM>y>0+oL>NFJfAfzt2$I(d@F|GXk|3loR+7XJOSR=g*xseHg~!r#F!*C^14vW7X)D5X4lpebm>sbR znC=0lFjCV47fH38kFdN)X9EQD-Hki^7gjo_>s|R97*C zt2sm0o*)Eu`nkcN;}=1=>I2t?!dEGZz;!VQDjb2RU`AA`Yc#_3A)PBcMzQTjQQf_0 z_lE-2F9_8wKsB|{U<116zsv|qH9dwftz~GsBm!kRb+i@cfbMw_F+&J{P7%)!-wkmYE34K{`vgJJC%* zSx&#o5SZ#BOdWx#z;}hqYQR(x(@S+S#!_u>A#9&9!?_e3Q_oa{?ezI#VkEZgNx<~4 zRT3HKn6e$iMN%zG5SHKRVhZOHf1N@hr@B&8L^wTwq)9=Xg(L_k3kWAn6grJZq&ik1 z9DmR`!Yw`uOsU}he%gf$)cKtyLemFmZgCtSp|jHE7a2gQrZouD6?AI^qR=>c<|;iD zdjvbEqiTqi0y3~&H<%($8A+8vP+{=;YkvS!jo(7X)U~E%r<#ahN;>()_uH8A5yf9x zB{!zPJN-!{XBQXhauXp7n?&RYf0BFLUgKH{-T`O=Q+T+Tn6j~`-z!dDP977}@P${g zRelceBc{8MqQQg5fYl2)gXAf|LZ_C9Xx!JCSXo}c%~@)wmk78ifD4aJT}4{-#5K8U?6u4^>`@rFznqOK8}31hze+l^EE&ui+*rrZljyGhH?;{Ny7n z7SKpeo?sf`M4kw3B_|VRd2l|E{X4r!!4|w|-6T%mP)|I@QYmXDG|vHqXP9{%v9l-t zfB|@X$}!f{JqyFvy+jfx);VZY&5d6%D=`wllc#w7%SdDusH?|Pr`9EC+}ViwDh0R? zq^oSB05=xc!fh&}8O{B@ia-O;L4aie_>;545wvhv8yZZV^3%8i2(CQf+UL(6MRTpX z(Ol{ToyHYLa909u=}5f*nk(}e&81GKXmO+7M6H6L) z1p=!Eu<^4Ny+>oCS(qk=FIpE%slOBRKpIvKfz<%mpR9ZjDAhLs1Y!vk2s=(RmNspp zkrfc+wSe5NWHcNB$Ps`HH)AC}G?_BRqEVF)R82q?e_d&aZf>l?I8^GChz3?efHwiK z(^qj_$`Ek`=)&#z?IJYz_xyzhUXK9l0Pxugmd)sPQLq#TJTcjzaW^8kdVu?{h=wAX zdsq^OJ25q&adi<~L%`+BQcgsdn}a->OG)HuRAU6y7*Nebjp`|58n&J(DB@6mC*Cx& zDS~VQ$Z0R#t{gztGY)k$nUW;asFnz-DWHBI{=1J7g)mSZ;9lp=dK~Ih<+VXTEdaDZ zcOfUG@?z7F3~dB-G7F{2+9SAI0T<+0(nkO{7051y8gZy0f(zx0G`1_mrlxjU_ufFM z9T$|^*_%$WJrt=~T~R7_<06k`R8A&*yQB{o($m4W5M+27rqFF6mTumNS-i{zyrPc1 zf3bll_UEVPS(rgqlRRnyTa4i46#s<$;Az&ytq^Z2H>7Q>WNyGJQjq(4Ogcir#!3t~ z{bG=vH7=5BiHDpXMPVq4E9@X7Ez|syqovm0{0D$zA#j9&t$09u!(8yty)~-L0icXQ zjif8*3@6BNa@&wPzq*bS#EV-b2S>nWmmc_-BV2D>ozXn%Hsnkq2u~~1U11(AtNv36 z^Ve$XQTET?fe^w(dlDXT<}nn2N?Cq4M4Y|>i3%X4Kx#eRyI-*p2!YCAO&WrAqF_`r z6pT`(#ZK|hw*n=b3BKX#GU`un25mm#6^Dy_#Dxy81R|G@A zsRaK|1)NlPsU;W`@BpZSaMutTf{UEFCA>+XwI73|+jPVWC6_+A%@=511e!4OUk1#X zd%}-?=K#hN-f+azv@e^_O}UVbdJQIMGvEufZ}4dn{|H>Bc5eZ-|HXES14ulehmN0@+O;J$#(FcaQWMfQe^XNZSPF=^;`~+Y+ z8#Eypx+I4I6hEf)rtrW!nva1_-}=NWc9ujsx+8f%&&^fHOCQ$20f4SRlOZ zi6_Z=Dw+KlkX#Ky2{Xlu@R|SBbM}1_sSUyjBULMKk^j|laTOK`ZFS;VUay{0-~%kNqhupKa^{wBWk31? zV>x}B6VGw^VRH#j;D~KK1}|}dGdF}gjqy4xkZy|;&$1+L0V}0iW?=fvqIw3}16MZV0B3Fp=P;b_vB0UVO+3N0yY2)^R~ZGu2=mHt zcr*8dn_*BV>^Hff^rtZgzN{VuaxzO-=)y(L+!Ef@>gk1%(DKxuOyLWjr<-2sV~EAt z3Q|tb17E0nS10~pVncK1z!VlNVt`v%nPv%sj|x-X%|zY9O8J*eV2`0NJdy5SQl{_V zR@UhN)QwrxA58&Bj>12h0ssor0jQ&orvT@;XHD)DP}~84b`bJ(2PBA+r_bv--m2WhoD~7pMn@m z!H~%p_bCY4iy7D#f2mcLvRVE_OG|DFF|p}Nc@3EMp>0|vL%je@v7lD6eN%{u*MUuq WSSbhU5l(^sgja){NeZC0VKUJ|aw6}J&(>J6w`Qu$pnP+n4{Oh}NoRBm3r$+$4bndyZseUM}rrVUl zlVG6~HS~m1rXv=LMbvMSd;XR5bI|1Id~fr;i;Gr#!g!E0$9)9Ca3C>klr$<9go=lq zOJmP>6O#NT2rfWJ)N%_Hwsn06Vg+WFk%)q4%Sg-ofS%V&FxYBg!D8)_Cn}G{;BiY& zc%CjUSb^^gyMHYlOs79j=l15o{J^xoa*seK`Zvi&O)Iq_=lF8p774Rd4=cV@2q!zJ2VJm$}-sX>$%X~%?{x>Uk zmZoOC%8oF!0lmvL*7`DqR&hpRISso2O;Ur5aTmB`x*`JLTWFHjK+>AKtIziaNBZ<5 zFMrwQT2|K=2PGQ+0|)l2(10tXc7M1V zk&3yhCJC2meUFhrpw@8yfCj#e568>xJ)v?*-#1kfP4@7D1G2Fun;gL`kxP*P^-=)d z_%fwF*Bh{7twRU!sbV&87uU;PMR@5dTJQ}wSc+f6n~xCMU-&#dVDFT=J$`O97|;hM z;snuXCSPl%2hRe4!@35f)8v`DuY}(ZePHTb^b3{#d4u*w?LX0u@i0({mZb50HB-CS; z@b+ndnGko!6n?Lmj{~H|w?+sdy)n*YcP+ONl6)nxzLvjw%$!k&i;N+Yu*=a4P}oQB z?|mVg9JeFo?y0BfDIMHfD@e^6li<0RiZHBR|5}*qJbxyTWj{2R0t;Fo zU)fo}e&a@yN&E3>BMf zK3>YvX~nv`0Zsa48>iH{EN-6bsF!3tzJvA`d+I=pLK0zo_?p}OsCZs6x*Jk*JC*z{P7gLVMTL zimhK|ON2@ktkbo05@T!aXHVza*gV^xgLr6#GZiN7Q)Q`=tgj@&*21;q+#s~T z?QJ~_yqv&TVEiu1=KU~{pAKbLO`TKTnbpU+Ik-!6;XpIYPn+m7>+#-iV}AA@w#i=6 z3wKq$1EM-JdHp(izps0Lx{|XjZh@RCxw){3TWF~MCfQj#f9fF$BHDD6ab=1vC4vEQ z@mL%I%|OUA7N)OaM5-B^Nx4UgjzO3#Y-rDspsb)sCtdjrT@RB`~o+_Ka!6lko2R{z);JU8iuH&^d6-2 zQ2Wx!hpLC7X`=KdWWFcgc*B%64+h={08lYGhk&7ztB>XCuvPPXHziwfJjOV6vhQ;! zD`YX{RZVX}ZLlI1962sy-zDNu$JFg|_jFt@F5r?0es!YN%CQQ@gD!-N7OLpI?vJq2 zZOy`d+3<16)U836BZ{<4!nb1Z(OYk?7f!W@Y$Dp!V-2YX6h7+ogPB}e; zV`W;!gO~NS9>{Ymjy)6*j>ojj3SP8itR&XV9?sOZXpUWe)$wrdiAfU8S!j>EJl{Yv zZGaJ@V5OFES-p-xDx4UKlB{%8uXkX>A*U)t@(yLiZZ;So)G)kzft6N}+;NhCV^97u zfclO(@0c<}5=B>hZm_dUqNPx{xCuh4;eb9)Vt5q3-rXuoGWp3+bDO6Lo@~utgZV6T z^Uta7eE%Z0=#!Z{LICUmUJSbf0QfEAgKGv>CbOsi#sNF>x z#H;+4ZXoKyi0I{%W4`hweL*^}qbMBp4{KJGiNQRFiXKF7WH)y|?~liKd2jR_Xs9dl z>R+H6b27=9y2i(9Vs0)|_P3?Au#arxKfz|~4RRQOX34Wh#| zk(v5e;0fZRFKG+Q8_Y-HHqjQP7Lh-6?fFZ~;e7L}Mz1yW^iEVB>`LyF0Oh%;N|;Fb z>YwKL^)OD zv2V&a^skT9i&PETp`^Y440Dvr(e+7%* zv(ZW4#?IR8kMS7v@*l>drS%Rg(vVIOe^*~`Gr9^&O-Ar9*h*Vy4W~vh9P;X$YC0f{ zdS)lp@LUP`s9*P;FR&uZu{iEKsqOcb6xB-w`CBr5Ti(NnaUHLEJ-yEM2(j12avUWK z)E5NTuKanXdDmijK3&5*akCFa3HY5K&t;?FRLDqhN=UL^)Q>WoWmR3ABkInh7+9$K z*Ap-It5CddsyTF}cdeb%yzXWFC}k4K%WR*GI7>{p!VXZ!QEMf03IydRHSyN|i{ z@9)ibSNY4=?fZcbTiYA0t3LJx9E@aMa6%tZwAMnoWSaCPRo9Z9F&$Xoj!va#(PpO6 z>LsIlxCdLPusxddBT0DCWDcnixi(VE)DjO+7p8seDesA0XNP2Rwz(^cn;|W#tW@(w zbA#MxqEI0IK1iT#77|sA)4W=DUSI;KAQ;ma0qSsBfbkZJ?^l!HRoLPpy$B^6+%9Uv ztMr88#k;ef+^8fz)IH1o4>j5uqZo)Yx)-EtQk7Nhq6Jn~%olEp%()ToKr`4R)3}CH zdHMqV*V?g^oXmtdAo}TpL&D6KhQ8Ch{M0#mQz=6ExBB`ztIIu-`P(#Sb(g3o$or%8{J!QOR?yKc*TB#4r1;kj13Kx@D#X#UvsjVS0fX;{RD_(}^kuZ3xM9X3? z*JI!_Vb0Sll~Un!VP0h3LmBE|yib2CzwIyD)_~qF#soRK6kCdXrH5SDF7P3)RL;7D zXOUTliDqlYhUHp+%Vs*>(5ZM{|7ig99m2~`t@bvvCo3VpG$G3C$!M-8+J}&Z-H(%IZ>*tS%kzS?ONE#DOyTTdJF}j!|_R1O2JiAPu$^4o46BkcH1+joKVS0d{ z$Xk8p31{c6ZIhXh2U~7Q5C$1@lN0N1*hKEksb?L6raQ4RuG)v~;vFSgY#sP*Zxdau z#_0IkDGh`{6y4)&-_p^s7?fd;9<{2I$(X0c6D(#tcN>8GZSJhjV2ttrI;eio%lJ11 zPG^W}@*_J#*9jy`NoY}-5ozG*DPWT-3-s?u^<#4&M=VA~21}Os>~%V+MT}?~+tujc zL07RgM<*jD3<0}jEVmVvm-N*yUP}{k0=6W<@it9+fW0I)=66*c&G+tH@dk~ve=?l( zp%+JB8r}%)u4H4;n01R{ThsZddWqnZohP#of-I`FqFBm2HjDhv;|r>zk2Z(ocSxw+F2?oM$bU$ z8X#j^iNy!==Y)YD`3Ea>C`3stzYHfQvcU;i^o2bvZP>#Okwt`Nz8Gi6=y*B>Tpx_2 zXuvFOd5xO_1hEYAY}sV7vPZpQ&TF|cbJ~iUagwxzDQtww(D35yfIsrYeV<7LrI0pZ zX23JFMECETK|FzUCV3eE2>0`eQXqLhF(_FHs*hL2G*vcTrLfXp>9@yb={Q)B^RG|8 z^BGYCi)SK_>kKqG(eGWFA#faxOj=EbV>G#1=SRQDFq|Trkxz;y%};|_8LXeoW}FuX zvlQYSzQJjc+NZ5;2dNLuFZ4lR)fmUp+xeQ4*_g0K9Z%hb#*l>O*l8qn8P4M1Ya<)_ z4N`yCMkgPt*P<@P&u>_85ftUF1@?$MO6Pfw4SVdkmti6%-KZMJo(Kq?MH|9^43|cc z*Er%U*iRjrq^{m_Mx>xM=PSschd?w7rLa?n&(Al9J@y1Y(BJZKfQ{~3sfPou`i-U; z6w*|fMOyD?#m{PBk91R_rq2q3x64ZN_njHWrK+1kK4yO2u zlyC(9p8l8+0(q5@jyPIS|2oF>Rp%)vPh69p>ZnD1RfID8A_4rIN&0wNmF$_Qwg$B;q5nJ9* ze#EA&kAl!%pC7Ze+ zpGE~pT;pB`5Nq#w*NfM`V1PAN1&XeJT&6%FO5ti}ey){u-Oqt32QJElX-urMnV186 zjU?0~I9Mb);^z@ux@n5e_#?_S17w}f>M$LxxyHLb>iP%#KgRrT3t>&7J+=k}0ALIG zuVY@>(9Yh}+KSdr|Bo^M+eg&?t3T*a(y`9vNAPC5;*vU&Ov4a3-kbRvkU*@})4bgv zj$8{~7Q6Xfx!pX@E9WJ#sVrnkc{SMWg?}k!!*QlxXF2$cPlZSdLSQqvuyF)tx z7U3wQ$16fiumD}R@Ur*Ta$(-drZT3CNT<*D3EhbEp-k(YDFI#O!1j_&nUMnNenU{5 z^!2?|NeSsITQE_8E49SReH+w9@t4+8&jwRD&cJZXv{>pgZ#o4c0rpzCU0n}YIyzaE zsEQbDLcaEOj8ggBtW0lxR_vwgUsHC7#psZ>HDA5zeF8dK37`x^lOzR zPfPW^m=YuhkyD~7FVd}YEil5t5_4807k;ytXZ=! z^b{qsXBjmztVVxqZ&BC?y1zz=V&2y5#rlezce}KvZ1cFn9S2(Bk^tfs7%zu)#A3S) z$(BIG*PCOAq9?^(^&yC-w6sayOU5vs6E5Bqh-Tu!opMcy5z6zP6k*;xGA~N}!c+Fg z(%M-#d}pjr-A5>%=1GP-|429Obw4i2Yq$x%h1#2$H7zFCLG5>>gfufH`}iaf00d> z{zlQL`926Zu>8iKtR#t!DOvUF7s!#)S^0D=()C}jh9&(PT4&Q_IC+e``R_H%bO591 z{OQgG=562kG~RpmyIeb-CTn(29B$fOn#e!?Fm`|Hq6={pCI?xL*!54>w(_}O;QyyC z`cy^Ee{2#$6>y<{ql(6(Wn}#M5e6%NR7DB!fnS~>^utzZ%%_E#C4 z^Gaio8BNF2nxnK_c^!!aD{nGCk(~|N9s(vtwChBS&R3+sVJm~y&TWXiB7WJ$K|JFakNRG3$J)e9x{b=Vx>K49@CH}^;O-5=GRM{pdK@hM$e7533`|fv~c`z zegBJu627gXYsn7F)z=epR#cwikq_L-fh*T_z<;!qR|*kk=GyS)TUWJAaLMCZ@3zXW>%SL9;wSkCM=VgsnJgpU7jTJj2qWif@fqc^)O9p?F3n2`B1E@tTjIft* z5nIPu4IA~qb9E0Gl1i|TIDc^Jytf63^rJ@{q95$+fkcKE6$JSa4Z##3Ff8hTdQd<0 zpr)tc-sL5)&z!)mI+t={ms@C=;FwlMWKLGN?KosG(rUxl^bpW)T~x)V=z5ycw_eHB zo)|c0=IUHBi*5UEdDJ+)-d26w>_Cs{v8lC_b?^Z0p~dF;uGit<9@;V&;1=t_s3qe9 z&9YERu=a;s(2A7Cx*-_=Q ze`{Cd_Q9`@lS|bxP$prcTC?~y=F17i&NZE5O|0ku?fk1j0LgI64&dMa2Y)JZsee-B z2>)}tSn8Qt{VBOW{1{;&Icp_jD+Z@Raz{@7RKe<_xPm5_m>Rh88C{eq=uDzg7llG zmLcb8_!~I4bTA^69SB9IaZLt&z+|~o8$eM4FD5L3@HQCfY#DB41*wJ;#B*vBdWa4p zWU%MRNxzlFI_tm==he#dO?g+X>(h+RKE z+B$|E^*veU`&jkZ&UpM2W4!keQXOa)K>ER{QEcKKG9>dDurWgt11Ow`%h8y$RkE}` zOI6B~F5h}x!-qiA5?r2O4w_RQELI*kSXP1E0f7WC{cLPqc{9m0?wV{0$@|Leeikw2 zZ)B-Ka(PxU<0<{C7xe(~58$eeLZD_1akRLp6QkFI&VMO!G+Gt6+`ECGGN(B%O}*~Z6#9u? znG8XprI<7K4oTVpM2Z@|exyPz!FXDxzSEu&Wm#YL92jbybhsv;Bg`~L+ML-6vkX|E zinHD4c{~V*=gTsSU|z<}`QjpU{g!BI%Q$B01{dhwc= zHPj;+@dxt+V3HBk65L1PEdS(TE2$4s*&_{^i$A0EY-=lc`^!9lq!eMM#qxK0{@lIN zr~m+X|C`BY$jxk_GbMrGAj7RM%3n;DdHoT zbm5#SHIySE4QW4!ZqWBmYOjtKo2;qysf4y+6%Xatkze6$=2qEScFmjNvd#K`Fx|Yl z14j>*9K#37i(5N{L}&ZXUqc!WDnDAy)t3&cl-*xF7wT#4pM{s%y&o6KO?cOrpR~Ka zlvbZD|E3KY{&O>xmKDCN9NlMV7$1fl=c2=$$r9Uue^L?rP z3#u|BKPsa#SL~ElJ+{$2#Q=7LUfDOyyQ3_Eaj)T^xnQ&mXrcvT@kEy#(5smfQMs@k zEKky{X=fidF`h+jK!s=aLG);-A`{VaG)rRFlj#l9YK|q$9wXk z47v5CaoYY^+W>%8urQ;0I23C-kd8x%6PJfbe_?i#_lr&x36}_5P+tp8HCCbWbvkIJ zgHy7SvbR9iQBlHeVxf{gCf*HzD1$(s-cGf5%tavk=2tWk1(Bd(v+dfBV&8# zRj>}wt7`H5!HojPOWDv-TCxvGKMV@s0_*jPWQ0PHcnBw@TYr@jDi~;__EoiKt>3JLKD-Cli zgn5WVD91DL+&C}1d$}<#Zu-(5mBu*2OA${%!oDH@wXip$f7;NHA= zEtsGG^LAFkp-J?%=8fm7YdewxgS>IL9}QgNYE}aujlhTFsBf*u?M4*cTNLa^nOqN) zoA9rqSzUs3Q)~tLNQ$rI2KOS~SbhPTVim?f$e)1tI+;V7NL{ z$b=H~JN;WgVDhhlPB7oj315MD_VtzQNi`;1vt#tSPciKgpKkyR@0y~!baXnn0v83Z z^%*#2WttE2oAI+L^C!PQ1~G0E`N(`WzO8m|csG2vH$)6Kcj4I+YD2vFpo;0)Zh*5G z@C3#+nof_-Ky?haH6sQ<6Iu26a|!2>j%f=e6^~FWwCo*r+o~$BW2{0ob4>cwYluTg zVHg*Nk;x9Wf%R%D#!jho;=IPPrft4IObm-u43~P>^;Ku@BDgvTDZqM>D}A>0LBlHe zvX|(D&B+Uih+aF&Nt5yZwy-HqPCsmc>Sz}LLqIwTq$Spgd?RyHq%#y(p_W5 zYjSc*TkY_mJE7xSsArr6PPQ$9gj!nVk{e?9viQ3o3AGRF1Uto(b0`25A!DhA!54_W z#|>I7V+;NxH5qb_)y_>raE3aAq}H9qDt){(`z*awq8Qdf?^u-TWp51Dh~sC20gQpk zCr>UOIxwweXTJ#nM%)XI@mGsuT&1khnA@mHmudlpI^>X%_{A@26;(gI|G0Jfvyr@J ziZEAxC(4os0RWgq0stWS|7|3H0jJU7eWBxj2TqpOtE>p`r$BG;zSZ#9D@)Spv`4xX z)udc3x?BS3NnQ}LvNOwDf-ykiEmzv_FHuN_8qzrCm_ZHvfZhl{+jg#6f{TXCyj?<; z*KzW5{n{o3I*v{O;YEa>#vH9EqWjSsylo!Or=BiPPE^j!OXYjXI3tVMleXC)?oL!# zUL0D)x*hG}crM1V!ILV(r^xS&W~Cy;BSe|R(R3)Bl_!c+fHxf9O`LeDW>4=Q(uOM5 z-{np`t-DU{QeW0z7TOY>Z9F_2>|T>>`z*}P>_u-ChgDOi%}l_Yh`9w%rj{15QoiQx z&UB*q-BJ2`%u&Ge^b|QHO5|RFIEBxwt?=@K9GyS-?YGaQ#pe3Rof~xchDgo}F;=db!iUwkd%;NPjG|m;8$MjWt%!bt8qPBZIhi>H2>e-hP~?XjY;r=sa8^3-%7@P3J5 zDqc1ODgFslh>)qiZTzPwuy-57;8)OodXRzu;dI2R2-?b<5BP7JnE1oS0d@^ zY`{KQ^+L3^6_RgAp@d|qVi{ywy$m_A1EeubQ#`yy@|PGfnzcDb&3dD;2PUR-)lKD< zYSqX$IX_`ay1)d^Xr>DvF#(hEiyd<*xQO(C@oJgXk&=NjTeZ8!y_t2^0%yi`*El`W z^zZJOqF(FLLLCK1j!^eBhqS*4DMq00Lw>~v#QdW2#G}s0_RK&b?xKPtMj28=WG9v| zILL;Q!(+Flu!)#FstDJ#rl`BQgis@if{|wTrTiCc%$fzDy>8`fspdP)uus}V!rsCp zp60=D`XNxfm?17Xj+-z?GVd#oD4+EPw2oc1WcS;6WYY;_z zd=1qNy{!`I^8c1e=>CAOoVo7oRndW+G$J?Xu2adVGlM4 z{t)lCLv`c23U(CrM+dzMX2|hC9gb)O8_l||%Vb2%4jL{}@psw@jh18oVEYG<{WD0R z|4YBJu(q~w)^jralg$1rl8XCq;=24KsoYPJBL2?>|5o|`n570l&ZQTND?yeB9NHn{ zBo#zz7w&Z%YdR8jfSw*Q8W`xdNO2b7E2w;zGBRBEmzS5x)10Rcq-l^Cz6lH&---k< zB%AKr0p_W`21-L&o)fbvyt{F>NW^JoeGLnR9(C{nZyDhkB-q>+PaWz0}Akz&K19AKn}> z-yWu$7HB~CUdo!XZegE{xNij-^)%v%ms9=%U03su)qn}4VqOq~L`b$!Z=_J{L=dWn zey@XS&4@J&W7GT@y`_VwxjBmW?tCFIIB0@MIekTR{cDI@@$PErDuDY;Fou;jA`Zk$ zUVur-d*-p$-G^g7rJyL3u%vof!HU3~gx#RfMEKTS;cWq$O=I_v6fZHNMB>d~%vq7w zdO!-}J>1P{c!l-Z<}o}CARSK>Ng zYI*(LH`ij>y;tu&q@d0thXuVG!jYU~BsM zJ3|*_IFBY#MUqnrF1cg;B&1@iHpTb)FfJM<3*8HPi$k}bj3|gX*~ebw?Da)~vsb|5 zYOqr2$Qj%@a|vFYL(!W`g@`Y;Cw=a5M)1393j&T3V_%v(J7JeU4;H%8@Nzr6j*0B8 z33Ip}mpC?#Z*Ee0<_tEPD@oAl+I;o0U;b+N_!Q&%-AqT;Q~or1UPr)D<*HzI>#lIQ zbdj0MHeV6_t;;v9DzRUgdUa6S`7(h(Y&+9wJDkO(mtD9^yKG7{zjwmx98ISpQUPl}PtRa_p%iZYyfA5tlSgDG}* z)#`2Z;4=;Prw)yqW{PYAEq&dwY2^NelURiG(#(E#^NeWPx=j78s@8i)sdZG{b6|ucD&ODrYfU1=}P1avL9JNw; zOW4wkb|U&I`UAvx<1kev&t}VfjWxVEqIPhbf91XD582P~mI;VRQ2UZ(BZ3s@%X7%pZ6Bcox2mrB65DQEm{HAfFs8;R#;WVmXILc7KBv&+A;DhL}Jdd zt5boRAn)rm*BJNc!+a4MF_roN+0!ockkY?2B?wK|p=2EJAqz;@GNRaPHj)A5CIdSx zj2G#^w6WAaxQ?uVvMQ|)ValM|&I;=M%FF=@7n1Np$-#;M!#8~z0U>ATiEjoMj@z3u zm4J^?C#m}J@08$EBP19#7c!Thuy`w&0fYvghWJr|F(l~jUkH} zD0Y6Kw)|{k7<2g@yFm8nre`wX4W;*z;@5S3em$?pLt6>nn!@}`EYu_gg zE;HLr;}98kGEWCciG0QY>*ZQ4$2RGKSKAtof|>YkqqdGw>{R9l&6Z7!t%l^pd|sI_ z6D*;jH+J@uH&&CZcDf7NvKx&jfN0W@LBPUbkhtc6FLlNbpcS$N6cm@tPr15!Oc>({ zK`t>6t1{=w!&Im|y+2^!fjOLR4d*NBJv_r;z&5WhXKlYWQ{=ZNM!rA zB8{351x;-A()tzFe0*Fk2>G+PaYAHu`c|qjPaG_-OA39zKG<0dn4ce*{7X_?UPOkd zUk<$)DAss5C@iqSwU-XqWJ?zI>=U6FhqroXdSy&+iimRak;T)&rpznrKPh-E zDUboBV_u)_<<7cn*P;9mz4gyDh4C-_>bIQIv#>GI`#->`D=}yCt52M&{KP5J|4qfe z*ZzM5R7={UbdY}lRWb-W?NP9DLd2gyb#>Zz4HvW)DnhhRdHCql8A1=nG_Fajixl29 zC7v_t8K9%v4>T8#5*Pn8?MG>lN^ks=JK#z`q~?BgXk&769ard-@Tmqx%fxui*?t#( z3e~n-{xQh5R|F!c_7*B&QhKEs(kmN)mhevP#eVDybRX^V?J2eS&KWE+Ct z_PHwlDF9r?X%bB)TJbbnIpBGECuLVTKz{-i)hAH(vHT6F`qflJi(%}UWe=(=>>^z# z8s5&GiGYIxe+VC5J|W9F3$q_+qa8T<41oqQsx|AWLpEl0lbSuHlHkz0ne*QPg~bQO z)=Uaf0d){}qkaNam3KsYe|i1*xuop9{x{)R8;wLu!e)QSG0L~|eN~T;;Y>}1+ZfW~ z?!a$4m22BQ=PlfDN>lH0*}0CZpFqW}JVT!nMgAvHdHCj@E`fgnRX{ zYGxL!G4Ll)xv{cv{RvbTK%YP*yGQp4RQjZp$$OBiUuJ#MKq~Z_fbWv_Jx&&URvE%M zI^vCKcW5GO=Vn}CM$kHrr{NVMfE_r*yBWGLKY@zaGD(|}OZu213%U5VL$==pm0ZoJ zShq`eY39z4tAkipXbW1#$88m);Q_pO2dtRWQNnx9g5t?0ANwp#o1t;IGTQoE>aQ4k z74UgV2ItM7XIcaNc=fYR7nj4wl<*OAr?mPqmw6noz#Av?EUu3pcVnaq}%E>S=}pQk*T=X7-2^~$L2 z%u`tS&?wSeZf!#XFxy>GG;f!tm-sl_cI*Yq&y93Isy`;JVh;%{XkNl?^TWMg&U^z} zL{U4{eIF9{OWR2^9hwTuGi-hLJomOf25w=(G@3&7B0nS{@kF4rZUEgzTfqiNbk3wLZ<_?R{A8WgHNKO_^ZqDv7oaq16@VL& z`=x8)0ih%~xil%{2`K5Tnm#)7w9AKU^uH`sqfsD$5V<;Y^FCbOs-D3|6Rv9b{DZ1G zAtZ> zn)!zJT)u9R8p;4UE#^NHAo9>pwKiD=UTNvc!NbLF7aiUDLOx_={&Bc_>(I5c-KAak za-&w~K6ioB>W#@ZR9Ksp%Qr@ zc<2NdX8{S(0+FX9e*jQlUV!IYX9u?GHpI9q!X^h^48#mgQFdOO){F&smJeW?Fsdl6zP?Cuq91a3CVcFxF9~)pxHZOr-^r-hP z7glp$FWeJ!NDjONWGFkaHl&utN!;p*c9yYn9(Xyy_k$4nUO%@nO<+vprFk-26mb}a zY2jn`W27j^1e!wO34w=4KZzb8VY`8#)GblvMCPFg(a3q8GV}d2VNVk~p=&r%L7@b0a^c5<<8aYdnuxWGyC0jO7DG)$1ZWg+ew%o;muX2to)IB@SL4~4=eM+j$ zO{n;g0{BVEKP6S$rY?0@fvNG|C6&^F zhO=*+>P`oJ96vkEROLzO+e>s*NGXO>E`%Xi#O9qBrR8dfk|NQ_(HfQS1W_`R+t+K64-h~^yCG~drjWsN~VE}!1D0R;q zbXbLk{!>zQyGVzilMD*%L0QVdV;??f@p)7{>seC0q1l2m{pfysl^j@cxtk{Plw$49 z)%O9_MDomXUKH<^r*vhr{j^dY9@)K5f3~fEpZEQ%ruq#(My3}3t)>D{*I+he5%#+HkDBW51^;&O zcdELS0seOnluGT3PHSWoa2$tG$9eZ6u6Qu zQTOD}!j&&-i6jc#nLXJXkNX}gJ|ieXd|(qqh>U^nNT5K7A|!>`e2n32M65v^Sjh^i z^UZ$D5hGp~TrmRt-(?}8A8#>Jz=<-i)yQtBx@Xe|I91w-S`knAfJKa+QunbDJ&b+k zfg2{(=}Hb`dUkw0iqjp0S8PXKZ3#7*FWi2WlpyI{gtRuVYq~r7lcJq^&xJ5&)<*6h11_BW2xgL3^ zsy{fHKH7pg>RJeza|_M{g-(=>Bo!jj7)EOQjfvU zhcFWq3_IPFDZ?unpiyO@$|U?aB(5Es-tQ#EAG>-`2Yw#4Oq>8Iy|cHgWmdwCDujA! zrr*1Ed`+#qmzWKwshW8#GN7b#*p-P=7t|>YdZ2Z61N01&%1E`Tl5(|9ESV*K7>$1j zlXCsAPRVU`Y(fPX3wTyFcdAg0eP3-j34k>bz+NggPE%>$CO}KvR(IY7a+)&qyoOd( zF<{hv+8~8JgR>s|GDHQJDB1V2_OagJ?xw>z)>HPPJS8sXL`TG}op-d{hH#a#xqhzl z0qF-UyP}v_nOt!`^4H7{8&;1wnqv)J;XhiczqJs$zg_(G0X#AbP~rcO`fal#ypKt| z;Fliqu9-CZclfVZ|c20RxDSBjPGC0Ykr-$lD17?;hZ{=^_|!;^*W=Y7u1x`?KE~a6 zWSaj;PXvinS=)&VtvG}yWiIwZo|aBAhEOrhX@g(*a`6RcV#YUz!rz%+ZkNAZ6%ua& zB1{QgsHPS*<4}N60OfFmf(N7UY!S}y%nx~_cOB?6^Gos6ukuf$_>w#KnfcM><$QW7 z@IO42hgDCOkLDBrLeAdt@62!AM*ok@58%(tFP=8)Zs5eRYSO-J8d&+ar$W&e@HDdW zm9jfEizA654N5j4azt{5914&?Qy@CXcJ~k{*hD01F%lZLA*Pc|)R)c^wH-fBeF7K2 zPo0~3L5jD-*M)L9b$g?InYOq>kZSU`J=xU)TWF(W zzoxY!Z$Y+`wq`$2efq^HHQ*wUX!D5qW5zCSBaYO*;Pbh4@P~oWcs~epqF_bSQ%@np zU1QpGD1Hz7jFGE_HmG)un4IrP6!ffnX1h*J!gh6_G(H^4WsHC`1i)5qDybTLo;KyP z9z1k9Un_iFf_ejX?qI9#tw59$pmNA!%82g;R};n$&}x`hEzF;8Qih>1&Rd z_9^x4F{cd{?|9)wxbwlP8{>zy7XEUBm(f+5>kjxjAxV$^qZ*bFK8ennp;~J&cA6OO zi6hwQiuHDJ^*JtK2BCs!8UEW4iB3ruqO@_dO2PU`&J(aA!&zx|sj2r-So3G-7bT}R zg;_DEb^46gFIAo!=Fo~FapCR!8TzT*-T-YuVd#p(iv_G5`-oAfc_u+_G)iH7L^BeS z&vcD4T+x_gFZe2x{`;J8GF&@^r+s@ zx1e|ryA5ST;0r#09#(PntS@q(Y~{l;1OVMk^4w`s5%e^}>_9WstT6^#;$hHEh zA6qow`Wpe0n<@S4w-^d%b0aXWJOi0!y~&hIIWdFTG=a97ojR0>zn;VT??jcco~7k~ zE2=I(AF<%)zrOnoRR392{aNvM7yRSu??^@bU!J1+_sQS?y{MYg7wAS|{FYp2fY|Kn9PjJBTXyp7`;{4k7Nm(rt;eTyhSrol~X`|}*tGlu96CWf20 z=-s`wPIB? zI(V-pHt44VH{h%-jcMEgG>YL6F9O^RIgQpXbjD9%`&X>W%U26_Y!g7|#k!K^>F-4t z3M*dd{7+AQRNf^%g}Bt>Jv1^)Rw-a>Bqp$JxW!$}2O3RaYf)-rM+MyWn8v2@1&I^- zvWaHmk81! z-SC|Ub;g-@X5M-K>vJsyT#J3qb90`XeeeCduC1*Ch^eXNWow4ikWmshF`a7{-YUC; z=Mo&gjQ3OtYU5{emZS*Cl9za_v!qqVa^@?Rr&TG~){V|@ z^OQka`aHbpLSK29qAIR{qUUpJW&Ib{oFXLX=T?yY%?$z~n*#m;(7!zUGRvpW>x0P8lZW!w1%H;<8nl-Fk!=7^t7QR3_=m=x6aS{l+UqO}gptb71$1%FI^y z%~P8_udAhY9v@0slasKSwa)8%EaCUY-w4@r_4U&n0Iu+_OjM5)

sp z#=Wjh8y1_oMKkl3yKwTeFE+8fq?^a7PPGYoOd_h`IL7e7SztVjQ{U@U1Pu1y6bL10 zL&|^Fsf4^XI*SFnxqhot;jx{D+}EjWT%UsKRD?jCieC94GN?|K*Kjfp)TxH2jxL=i ze%7hJA;e1J3n*a(TIQ4^tU^uTz!uTlS@!0x(sEynn^nc(&)I zk>XUf-aZ)uLl{}|d7nG{8VW{j{_5@JR~;D6?PqN6!ej!}AJx`^ZY}k^D^>7ctI{=f zY^LtepKy0>VsRCJ^48(-4xr0_@<8R$E;AvzI_u7R)&Zo)c@xvGGL{09Lrqj-6q1BD z7xv5Ka*tEJG$^#eA>VBhr$lS*q9afi+bS(@CnBueDblTqUIIQ(_b}DBcES%@-2v;~ z47VZ+EQ>`1RGME1PB9#%?*{n5&5~Y!;}&}JYIWST$|5msuMCTLM5vVN2|`=R7bBws z=!*)23r+AtXvFXXbt;xj%rDTP_9_j+yq~(TFFnUm^@_ZvlLuPGv^%gUzGa^)Rj}%M zR`(H)BbRUB>Z2ry3SccbV^qpWEy~XuWGLSCBQ}h)l&bpGcZDdlq8N*pAqNR`4O~5X zV?S+G;RE_42ts&exrdwlxP7h(Ml=I?2$2Y*>zH?#Ve%|B31#f@j10|gu`-viA* zlD`XgpHNx-AF`>^?@T)3I z=LT#0+k@@irD34y=f6#MQ2|9{o;UBvHjO%p9y5Y*9;7%Z1}30hq#Am3`^20aH!?r_ zc?+%V$jBSF*>tA@S0kc$E#gnl?JBOXH!)HTHtf?Vp|S;?HCl>vCC^+6=K3}<=H~T8 z=$%JKyl^*yKJIL>WE|lFOgaP-@ja6cVb)y&p$x7j{wT&~xroqW5E3WIe@*>H1fDJ; z<{ItTgyuCA3_VtP;C@v*_(kYgHkKm3sd@IWzUmS}i~`-2=e{TcC*nhtk84%bU#ws0 zzhB@OpaY9?L^96Tm#xCGdg3e6T=}Sf((Jg^hYmzhLF)iaI=DNpk2Juf>w3dF!au7X zaM?|`p)o@5osXSJMYJ(OVwY-eVZ=!Y@kwRVXq~o}r*N6}^J$q!^&-y|f5sRYff@JeS|7ILWSx!Z z8}5y-odQ?zYR>l4qZ>6RWDu95|1fEZ|9HOJ9Obd~+r88(&ooaPF@`V4OqmVgV-zx& z$}8wJ1jm(6nI%{b0VaJm>Oxjy^$UVURrQA*?!sITx$H4VNc5bPEUlEB0H8iqXu;#^ zE|d*o(!ow@Q7q3~6`np)cw`y3SgxyFxvVg*#kJsJ6{|zAfX~rHz8(ovq@!=sfn06f zM@*A2;CcJ4{Zt9o^`o?;bg21h-i0jJQzOsm-Te>gyFr>(aji%@%(2v4j>T$}{18E0 zt7kL>#cBN>2EPmjN7RKL3}e0Xi^kVkUf&X_JwE!UZM zhI~VLK}>e5N~sg6iW^szh}9S-<*YSiZSH+B(Xi9-gTV} z6zU(p`1Zx6-5?j9=QZhA-}@cggn&olTyeFFeNpMlFV0f#T5?XlW*R5UO^PCytJ zU0+zFTO3E$vz?KW;R(Q+u&(?|Pj~d8l@vRyx9bH&W8z`Rs$nc-ljq7WuWmSRp( zJx5`FT55eW`PiaiDa&Jr$T@1E>#an{*&TrW$BNZ4#z5ySLOtjBeZ?y7N5x9sXoNBq$rsX)()d9Z{Wr6R z>KtIA8(ud_9=+sK^gGdQKDaR1@zEjdUlPW8YHgyMle*?DJ%S&I?hvB)JX6R@VSgA$ z*fh%!Y7|Op3P9@JPwpXg=osly&(_yU-{4~AL6CY(66FWh0!4COW9Ol39MUrx!@g@+ zxKG1|)|Od^wjV+@xsb+*FgU+}OLsDQ(|*q1KH1)hGL4%MeB6vLJ6qC4aJ`i@3)xsoIdfua8&m z(Cpd*Dp&Q}>5)`7B;vdBBqS*fXppD}bTSqZ)``p-O{!*}mJ}XZf0M^R*yHM9bNkF1 zqc6u`0Bx&R>bMxEU$;n^3u}DjSotL1b;B0t#O!$<>FinsNk^$)polqHgzbTnf$$k;8G*jVGqITg|)318@wtnv2^C_C+s*e&TWH@-Mjh(8{lE zxmsReSIRi(j%b%M#IGiyZH3?v}Q0j!qUv&;N(SODCAv<_IWejRA=l{a@~lzXb(d=jRvyCJCFB z_$~|_Zb6lt=z?-rB_N^(gnB*ta3YZ%Wp1KC%sVQn7@Xs|tUVx0TV{dnN~ zpOSRVl91f-3A}WLtBzRhHLT8wft!-+5D=6OB7U_@5EK*5f2~WG^kDevOdly*0N3Bb z={?620p&G&&rifl$g-n0fqEtFJ%>jH(r;mX>A7FQ3;G{cdZ@N4?G33l)yk%Fn<>J` zVXj~ABxPD?oYcavG=%sN>%DLP?Ay=@6UAsJjwH>J$RZ2hJHYrXfhsg$U$9O6&eChz zPl^nvYB}Qdu>>t5K-VAht<7cg8+@@9vqDzp7&TLP>m2&lJZ}Nrl?{B@BLrgA@KkiC z;n=KGva=fh8~0PauSZkHb$$i%`j|~lvi7IA8AJ*bK4b}`)Vl~-TY}Wk^~SoNznsV) zsh9U)148*)0(+WV2^rO!H6^=neQ}B~E#qbW$4%oAqhi=OFgVJWl@q#Woa0{=tHZBH z3{8gS1)rW@=qLv*o3lW@Itr~Ul!i@JD|e+d+l%fwa?0T$oUGUCq|D4ZdB2cKy)$8D z{OCF9$ou%(afnf`mTdC+PuXg`O3C5csa1+~GWDT$W6vMuT#u#id5t|7j}G*cTTl7$ zFw~zS6PFCi+P`)8qG#*lG%C);8#wBdO_U%d$j}Qfj52z z3oLAVPBPh7V+oN^H?;`vSIncZ4@QwK6Xn`8KaLqJu@G?WTJe!KvDVj^yF49cgmlU@ z!v5?oj$R3=S?HAYq;uWIF!yv;l-6ylShjXo-xgg!(NUh>M2b1b8^EuMq7DK4DnGO^ zP{>tsNFcGz$EIw>vEXJKxmcs*Q$D&nM&^PqRMe|{HBas0Kb~iY7QBh)c4Ja zvZ+ye9YOOERb8YPyBNT)5Z*YA!_yY-J}!P>Dp3B=_0`(O8uwVwPza?xN){Y1(Yp_L zl;a^b%(Wzcl}OKL*)DD^ zVwt5b1LIW;Pl2k|*s6)4Xx^y0;M7u&42s5mV?e2W>iS0MCw5(<+o&dsCF8(>)m5vPk5H&bv{o=!3KnE7`|- zqm`%h%s)+W{GAETVCBNqr@KYAMoVwH!8htx!a%D~e9EYEDZ6kc4Q*5Ls)_m9?DNad z@wCiFoLX%Hzxoh?=qm}%#|)rOAvBP4G5rtw%D>6K{=~JnQl)V{qbCGm?G@X3Mlz1RxHta+75}X#9vjS zH6U^j{Md#=K5g=9Nw;ll{%5=JSy&X>##9;I#fBxizqJY3)8V-~Y?}qF{J9DD1qSVC zxIhk?8%2ir{Epn3N;|J7cGlbDn-)zUt*Ygt7Q{dBfav$$HtyZ`_Qf;BXY!3FF2!Dl zNs3+3bQ!GV?sUd)2CW`Fikm0M%$?vkOwcS+oKx7;hVQtH7ve0omLmem1SMV{;5NL9 zsCgui)b2xb-h8NzNBLN;TADIbt}oD9b>E@T%DeqhADplh$4=6$U2?}f%`u6f5;7?n zuK%Z3{g6ItwI^LsT*E%}vbZ8mwl?X6hB)~Y2AT^xz3h_08`9_t+yYa@jt_F-6H;2# zSW;20BCRK?0{0TQ-lU5k%PS0d6NEaZT()7M>Kf*uUou;O)>cyYxYB4k8^Mq$yGK~Iz6itr3##N?iVyZiU?#*%um9!Jk~-V z4y`#)XgjT@i7wPO9W%4ol8YR%YjY~iab-v^V)RFlJIc*jCgiJo?dsI<9kas=a#MM~ zfS00R^I^uT(sOQ;>*sSQ52qZ9?{qJA?gP+vSDnUhxXTgAYTd*=ZX7iRQx`1t8#j;5 zYrN_9m`ct@93V0g-b7%^V8T;{!fTm)T$a|%_01aB7l0S>wwTKLOeXr_&2*IDl&E?U z9EM!MMwyDQi{drtesp`h4jV!v5#fSrLa_r2J5p0a^aSIfXEZH$zT2NT z7Z287!UOrgOLm-u3Cc10bGD_X5Zk6#^>-vqA@SmOa;OGd)NBvEZ^B$p+RO>}Tscv$ zX8mzmuXv+r&$i6Mc$cmtO3ZYxksFd)&kAF}x$c6;rY|?!Yvo#Ry*}R(Y{RME=ru{$ z;bVA>_d!je+p2gcQ;W-TLvIsVzqq64c$oAJ>RKXs2PL}_>>#;l4v5eA0v*GOsJ=w? zI63Ryb$abPg1^tR@c(k_vNNzUadP^%5EiJu#b?fh27=o`^)1?ej0wuJe#HMbN!B0S z7kZ#Tl`eG%D>R_eB{_cYzM%hVw`Rv#_}0_R8i@+Llk#S?C>Fh`ihYESH`DVOzhG8V zg+#ZEUnuIvD>$QalP&vu!C+|s=NY<}A2{OZC-(Z=O;(D z>t-a81}@Rp$)c#Kv}Y|ySD1iekOjWY2&5PsNw8F1_PB;yLxbspe`e|`4D=06GCAI7 z^e^;5>?Q`E-~)X_uZ93|pl@gr3&!!bv`Bq|{wtsu4975goerDAExQf??#GOCHckx5 z3?RT=_`Yw53iJ)}(BHL-wsWk|CjfmznbdD~DE?k6X(xqH2~>b$aFPzABH$JuS{ogT z;aJe~3kQQ(d=MV~20M*q#zdQZ1)8sa!U#xZ%KLTm0>@&j1$Yoq6x}EJ4f;mQVmm}7^-CFQ!66UwJN%*+$ z4=PvZE8~ZPtUF}=>vc%hRFv45=?^Ghd@PggeTouYJX6*DehtlNuUHWWLY^_0r`yA8)Ba7?j%QYrroNB4B{N67%E(?QawJ=Rq z3rlKe20A*F_!VvCze@)1Q>?IWbx%!03;l)8B;O0DdxI~`b>jepdzwqJE_;4xaW}63 z1m(O{&BI!anMbFM{nKPOm0 zAmN}6+cSDA$$R18&kXAxavuRf?m&hmP59>wi+|X#mJ7P@?dMu&1zXLR?IP%k{1rfk zMSc)GD_~Ak^De5b)pNWdhmO+f&3H%{BCS`j0#M$f7gs-mvZBYCaa?SvvfIw*@YJ^D z9O}diRRj=sc!TUm&!iy>rhw*QD`94JQ!k)hzKxlCGAnSbx#zXt$2%i%z@PqNF=w5) zeppW&nY_rE3HPHBsga54hr$%B;cvLRi7{o5*dpGiO07%5O%@;>Y8ZKL!SUzEsbEAD z&}hFaDLHR|f)VY=`XL>3Df}TF)FDmSNB!Z$u&eYO#W5aL>IN3%!vIJ1@WkU7EIYya z=G#gHJIIG&bWfg34!i=<2#^l$mBxkMO9yS!vw&SnYBXSANSB_Q1QkfI9vuM*mcX0z z_s8rs>ug`uIbgD2V*4&?$S{%2WuD>L1Sv&6=cN10$|}g5$8eb6UNbZNl|bu3x{3w5 z*<;miZ-PspcZhZ0JN(!Xs1M~JB_bGLdgT3vm$3d;2}J`b!~pI)wofT#Gz~)=+ovm~Y9LT6m6>NOw8W?;`Q*^H*`R6$NS;7NN3SS5PPDVHZ&J$gk-`}$#M-b%_9!Z zPDeKfe-O7k%0%qfB5SZWjwM&PCi@HEO&=F<9t*Ir&*6 zDUy+>tWrdp_RRyKg*yC7u)_TUXY@JL@xO?PTM2kiL8%vlVaWAvlq%VS@~fhdQU-6TpFt$m^!1{f282kuPrmF+;HU5E;7$hSRoEs_7fj%Qh}V zz2{Zs74hC_^#QCP?ci5Kqt^3~7*uxHY4X>;wAyGl3X_wH-41N?5!!9T=H-VluK40L zVdzs)@L#1xOiwk9&e@xrwJ6Qb-{pA3XPw1|f@y_#xbbXqWL}sDZhxmpza#FFf3mdt z>q3^Dm4TC~t%LRVLe|B9^R+Std&Xg`gR~3Eu>QV~^;^*U6zj(oe#^0%T5kW!?e#w# zuD<73KOC;!SQJT^Tcer+Io5S-wD*z*fxqmFrZ*&-s%(a?E^8@fW@aRVu()>gSTV`H z*~^%XWbJ6-+!YNz_B6M`^g$@DK#oOvRG!m~+vEG;O9R}Kz;{Nbj4A#s?x(C)*OwP{ zA6}vM3N``04B`Zu@UFX9*O*Rl5k22{gV1sKueA%+D2IEavLp1lQ~gR$@;O?Xqt`4P z$1?cCofY;P^vXIWwziX=o5T2iV8q7sftXM|$#*ATn9H!ql>pVT@KZw_-4410xx!7= zgE#%23Pv#->VNCjw(;*xN#IyP5|nMmuxWX}Fi%^U5jb2{9K#ogaO3Gp@`Pa@5@ROt(3gFg@ULr3))~ zaS#^yS<_d1Mbv=J!D3i#d~}(qb0&K{XzRISF8glFfT!Xf$t;|1;;Lmzqu*vY{i!;fmk9H1t6d<#26MP!wT)I6?tQ}IsRpN=PWxClo2N+b4=Q=ddTK82hZV3oFmEJ2!q1Z)`wiTAXC zGS=bbeHqKT*08)TT<>kekY>UdBJN_$Qq@i_-}P>cg`uT^f{xPB$b_C?4Hw{XwS1EJ zv2+UG)L0UJWKR&BOJ^w5T5aIHm+g7PLy6PGvM*JSo*8cBYL%&)lPeu}os3poxQl9q zL6FWn2}@Zv4Z8=<$TRdUyoPS%iL|rlHIz*6qMnz7O>+!5#t1SQ?12 zn{&E1+ezslTL$>}MXuu`QM$W|7geHwEyG*Ft9rrRBljr2g`I?g3Xve=H;@x!aVO1>1p*VNmS z586Do)I)fTD7pPI{7Q?1=Oqr=6Xn?@qfG&SXE3?cLpIZ@p{t{%-&==<;LkY7s;OZ- zfgB43@CE(rGS*-3D!*h|No}`(ZFjWfBbHR{u`8TjRK4_#uP zK+(`_ez#|6u3xx4BRc7-B&452u=)@L;e}QR*j+V6^^R29JhKPJS8QAvcqM| z;Nct>=%o%MTHQSGqd=lXO76~Ntp62#xb&&q)aC4Bw;T&TE#sibzPC>hmXhB`)ZjEMq7M^<1RtI>lZ%a}>5uwf&LW3q(ayWDN?T zKIaZz5mQWjCU+r~Xh~g!G@qyevG2t8_w0KC0Wb8FFHdMPASPTE#vln&g5o-rtZG#u z4N{NEju^)AhU#hJ1~jbQDwu`2<$#TWN_jGR z1K5+#(sahGBlz}-N!U6B zJ@LUNhd?X3~N?${LhN%y}A%;sJ zfmkM1ws8JddZA8nLfHx>!GR;3)F?vBm6f!Vkk3i1Q4z=K`-*R4vSyKZWTiZoJ;~b% z(3wr`qt)_QtE09v3mE-F80AotHM0r*=&*S9ac=2zEM6O$y)PSNxHFCJ04?DgSov-3 zJ?`H-Qoa z@K!i)^s75yxJ*Rw5ItR6s(E#2k%cm4$Iz*|n+o{a2nI+uQ#@5I?E=Pm@)Zj&9-9MR z3^G>(^r>p?jgC^LG12hpH;X!~ulXVOse(jrRG- zhX{IopHDO7+)BkyVsrIRbeyj1#Ck8^`Z#mSwj6ZT$srzcmB~c} z-CEDv_@kuPN-k=rco_~V7y3yO(F-bY-MD(UDd(Bk*Vt6ZUdp~@Gryg2&%Wcq1|0H5<9R-3xgIL7b`89Ahi)*q z&Z4WTWELu%GNsLITRELqOHsABlR{>L;mCZWWkSGdT$?*;ve?7cyn;Jb%s`XXJMi^v? z)gNd4nyduwcu`{vhlrKNKuH>izH*ErPGd;691#|70I{Ifv|u&gX}BT3uvrgV3#-fw z*6RZK&7(Xc6q6f`ugUS*i`x$#oE{GPt8(dSrnxT;Y_nG4*?phm4-h}27jof|e&;*k zuHH~oVv?w7hsus&(--EKM6H5!nbGSIr0h7lk6pjCpBB-zY{xo!!D^?99GSdkEG->{ zu%#ax`X+^f?}j2zO7?LI73Kr=*DgH5L^A9eG2D}LO0jb9`|YedRau7&BAR3>?Ud70 zA`n@I=qS^r3irdm99gAfP_xnThs{bpVru6oX4I;r=+u-taO0FMynLY0Q1sqnBQCMG z=-NA&wHLMXWt-MW*U8k;y_@WJgastLvb&T1wg_am_Ben4Bl!QxcF0yv;#$e|u$DcG;> zDP5b~>~1wpxO)%tdoo0B*LkMYW~CMM#*uTn@{1J4`;0*(qe0Rv!$_DsR7e*U&7sI) zxTw@+8nmC&l=(zkymid_av-hF#d-FD2svqhxRm%qbWN~SILK!d4}E01#T88h6RL10 zF7k#4#`iUjW?Ln%ENK#0M4d$`L&#;pBI2Onc5iWMc>H5EeNU{Eu6FD;@@_50TJfbU zG8MpUpu6?Y<~~Y*`$j+o+1u2I5Z2SzxoAC_7Hyv$4PGqawPeMo* zjzfX+2>LkZ(y8!OufXHnQu*MaQKm55&JZy{^4DO2xR9l|5Ksi>Izi!rkJA=t>5m$R zc^hhFVNVny9LSO>kwi5`eemD;h9kkwchBQma*SDW))W|O5xS}tOxA8@w@NaGz6;`m z5J!Z6`w6Qr04BXhi%>_ugjkObIC(Q-)v@Io6=j+7zp>{{|`Ql86nz^>) zEWx;`*Yh@?jVEPAxoqx`ZSfEE+LHLnhJ0OJmaDI3E-Hj8(}W2>3_nL*$Xog z7rm2@)?0ZrYw2c&BiEFbK|)W_MB81l(_9<0I1@O&XSUvp&~Jla&%j$2QT*pHX1l+J zdD@#XGP&eE4?QmaJ_Co|d|vipq{+Io+`-Zk@L#8{y6>`Y7NEX7bJ1O=+u!N5IIB7` z3N+>lUX>G&H&M*>^L3O=RJq@PYf1q>!x`p9lVQgVzYWqKsBEv8VIEVk(!uS~zbiV%a z`ESQ-ihnJA`T^^L45aUm*Ska@1L>cfNF3O5te3fJf5^g2idiPn2tNY}VACz}-XYV+ z7j>f_jl4WI9ua;;;x{kK)SINLxmh zCwI_{*r5@;gLz)(3f?L8Mqi&9{B@)vgYiAD8+dd;jtk;-_3`g{-S{88E@rhBI*8Z3 zy!;B{b>V{nURTIj72tJgLA)-FJ=K6)w6DunX4VZ03uE!jBZEdX)=|tpC|o`kdAn~j z80(_t5X$f_@3|ChmK#|t7$88rF4vLrcV2f;l_nPo<~f$#oBb*u|4UH|g)kaqc8<|? zg;J-$Wb=d@a91|yU}&`9jgSk>7*}H!92GPr1k zc^uvIwgWKf(Y8L;C(&tzNmRbmecK$NwGoyLYGHuR*F3{AGoLIV0T1c3ysln>fQ&Qaz)Wf)f-N?n?fH{$}eFo}bm?xK{+3;t^EZ{C^-UGYf zjmr9a?a1LeeZ=MN<9>y)3+v~-9+e3pFf9hdK-1jgtY`-8DbZs*h>y$m( znO6LgLE?*HQ>%#va_PBhS?2P4*aNuqj7;f=D*EWQsO3b^G(=5`B)vKbsl^Iba-Rth zjeoi49(VwYjcs!P(E{<*y`HFogZ8s>M^#5Yz~}aU=W~}2S@S{SCj`%hV(%LzG?4ho zlkFW0?SWw)u1&E)DIc{l94jpMPl%vzXt#`7%OcH+L z&o5Re2b`}9O>NbR05X?;V&_3#>P=fhSn=e-1MpE18|Ck0Zrz6|cmjn~P7aB&0i2fW zhX9%D;ChYkGWh)Et)rE6evJQ27HvX1{({V`DY<|y_Sqi$-OCRf#S4Wjaizx~@e`hB zR;d1~eA9j5H)c}bdl)Ex+r#MG8s$^@#~#LCZ7RQ$yqA8XF=oR8fhGPqj9*s68ZG-`?7fmGj?Tp2}_q6$O;X$O+Ri<((5j z+?>i%l0>Wnh%VK4M0Zlw;PRbjSy~_>Mou(Lo*7n)Oh65Xo!5e^_4bGUP05jxI}e9x z=edlomB^PK(>&Iks6=P=o-Xe5SEJjX?$|7G74w|?Loz{_u9n;og=UZUlv zNfk{a(q~a@eWo=hh2-Y}a+s1FnPjdNwY6W?5pdCGo$^a!I z2~Z*hCtET-=E5eXWeYqV?1*gn#>{1(C$GR;F4b|CC&IwnNLjX1-5vA=J>hGP2^`o4+L zJw5h&6T^*4tug)KBnT4m0YM@~HFMqhNZ|9um~@wX<%(AesLZA;0|CPuJ&wkR3o3%TTlq9$jl`zA(A zKH6m3kmr39W9(-WgJn3k5P5dE;8yG`$?IrG#NO2c)WrCv0%q-@A1lFvCo|0!e7f`z z0r5H=nwJ*$60z#myp%)qRrs{$Z7qDM3OGf&+^A0Bmz~$=XDgFMB`wR$XXs4l{Z8^YF#|iBq-w^ku4qdxu=aNXE@-q7 zw+Xi$Sn?Etx5p1`x4b`c%-dSyyVSsxc^qXyD)04-9M}HZ#84*p1ezFm6(?gr6T|yw z6Qcms#K=8HUb}B%$TXD)wk)LumepuXKO1P3)$V`-37{M*SoJ)*`+^D~chEn!BQb?~ z(O7QN7~|pXiI=LIeA09C*Lswz`95S@EZ{JYl>KE1>vaU6D=%I}s>KH=5jPMe64;lR z6sKnW;psn9BL6v;1C#>&`?(w-Ld3r&tq*Z2Vqls>qnRG4Jr z=N#c6bjP(p5nLwW@ESdVI~TWuWh`CT{;0eSVfK~Qv=uME+7QUZ&V5{J?SOBNd725_ zBm#c?0UdS_L5mrq$A`kH)DiY(hb(M@4eJIiFzO%5^h$Hk#rR#HNr54#Bu%7kML5~k z@Xm%Ye`JLCZY3T3yOngN!khNbp%?RkK123Wt8^^r`s>=to7g1?v6Otr`lGfU?EKb3 zCh)N&eih-O>B8QD5Rq^Y*o_Yb?6GYC^cHYFEKpFZ7iNebFj$9;@$CYEA?L>_A-rVi z4$QBP@Y@Z8a%3Kqy4gU_jeN$a@Q@ut#%*EE)&v)m66v2>Cr$8KMEx8K9TQczB%(uB zI%iUMJz$U?BY|P_!EXr4mBp7fZ*c+lRaDIM2M%!(4L=0!nd9DsG~QYEsRAE_fh9!c z>gSkGgf)pMEN~-&$ytbcV>#Vk3o5$oJXvP(?jF-<1-KB7-m=da%*+56f^Fyeh#-xT z(IxDj3yCKwd%HG;U_N``fYp5HG!$gfuH&Z$;zC+^mg*-~Tm}v0%2on@w~`iGI{jfK zjdDYKZzT<&x2Gu?RL-#@ct5P9$LZOv4E9;?t)v&x-sXG@q`vQ2TtI#@Kvv1Pe8c;8 zD&B*8G-6Gs09VU+D)@|Qh`6tz#D6P3nb*$K6Q>eUD(~pi0T$qo#!cdKM2}1r!aW;}srQ|1{}IsP5lLd0%{~a%=RW>hS`h zI$$MT%}I3V9>ummsFIJPp__LgU#O(e*O!(4rrVPif3oS*CiF26owH4+Kb=X7M&57~ z-#evAdODMvHr0WIk|uhvZ1Garn)h>1xyRq zRd#!Y`QA!83_fj(I~%Z)UTU8z(^IW1n4yE1lah^02O1UHjl&{YD%;NNtfZv)77CY$ zUnk#R>{xEhPLiB-v|Br+MXZQ-?Gn|=rw!Ym9j_kOFA;OdEuC!1H7%Tfs5jtD7={M5 zHr@`Jvvc@c0b@CeEq3T@x^va+HU|UrAqO53O@xU&{l=ry4OsLD)ruJa7ClTa4!!^u zJqbt8o>l-j2w>4uS+Zqq7*~qY0D~ti2(su2EK#x|XgDJR1W$rHWPn9a3nU%cMir-|= zn}1~RvywZ2H;yE!AP|$qKIc?H z;;O8C!(+-(WK#F8D8&`+C zq1R2J^u4`RrRI5=BlzEzR0^YajAHpukYZOcM0z8giW04bde8QGc$$QouK5&@-? zYU8zJG$~gGeZO@y-?SR9)=1Hm>T|+OQkLZxZvN5=WQqKIjMrXMH~f_QzW&xUiTMc= zS|uV)27TyX&+-U@S(#R=bBb~tVr8x8o%xZeZ?b|*;?CT3;&fZmsJ=xf{Wh2bnFv*# zd7HUhr^oLjIf5Hrpi4RDx5*~=aloUe6mteuW@=Tps199jy53@+$yaL%H^Cv_c6z(L-{Mg5o^+~6d(`Rb+w_klJssUq z#_*IwTj#r2EwR%4T6={E-OJhimE!4Mjk1#!BR@HBErT8%U#p=3>&5$k9!{dn80?6# zlbKxnOoja>n{!QPz@z7KcNt^tq3_j2QYhfjLoRliY~@4Q3nmSCNi*#ikNf079J*{p z7KOV<>2_zN+B0Hy69xX}(UV517zo5!Z3g}djtfk(d*A%8aM z`D-<~>kk&>zfR@=mp6s-S+|LCnk{Q$e+NR1tu zoS(gdc}doZJILYK;G@WJD@+~ugRxamR+1SL%O3UUPUks73wniSvR<9!d0L;4&0foi~#?vvw6eb0VK8qKHhg(E5Kxjh5ek3$gq zAsRD6l!yVaA13$ght_VS+9+jhU|XcinvU-ED3?stM^=5d75GuiFf3d?)~qJ9avr%* zEodr;opejOh1aS)l>x!TNS6_|?+X~;G6(?!&JtrnlsC#0+R=sDzdQ4kgp?RW!fauw zos^)#=Q&KD2^oJbM~j6c;`gLljD#zg|L~<5qCDAvhCT3ks#eD-dwn;(UYr%A_&(xW zCBc|6g|QPii3izrkoCqwt1G*%EJ;2l#XFO_JmG8rU~8>WlJXgaiY2eRY0mI~72zuM z{RX+Tf-ikqt9CLJd=Pkk8GpAyKH|jg0cRefn*LfM!ohJf%jZpMd4SoW>uOyz$eHH};LI}w zIP>7&G+ZLS-Fpl;^RzB<0A`1PGf({b>#MqZXC8Nxsp)N$R&*%%xoeO!k0apBvt5H= zEsEgYj1M^TMErE-p$D9KN?6W90cRdIk$Yzz@t@8-Iv{7Bb-ki9)!g}n4QY1tXv_>hpn?1w`-z(G3RPgv}B^$o>d ztLd|SjDjZ{j-p%h0kC2N?o|>QByP{%yi*qiMsmCYjpR7H_Q!AFoWQrm3?K7ua>%Fv zr!|Aj_+)kEu1?t9sieIbsoNUKZ6)XFYaYhn!gBYV!r=Qzj-DJgojcYuZ;q49`8Xu@ zjiOdeC+yfoL|jxZbB9wVQTNqhV)Z-lbaKHl6>K1lvhDlT><}bjDj_sJ1r0ds2l(2* zmW}_ui~JvwsOiXzycuA;83q0K@n)XCjyIdV0eBC?r~f(LY^$X$YGx7Qz9uD9Wxabp z-fX_Mls2lHy2g9-qQR);Zug{k@qsF>fpUhpO1k6$Y{2D7vG{>gg-m-bFy8EJhyXFE zbYQf1$YoAOMj~7sKmHa=>-kdLha5Altf)(`E1mVx8Q06bj@z88S9MEgMBYmRTaSZp zBKHZehV|Yf$5|W?<9=iZpjz?m96YS6&+v^zMoZ=<#3f`4Y{n?>FDVBhN zE?qkAj0n%E+Sv=yJ423qfT@)SHo^gBb0l(n39_W5utC-wJOc!W6{IY}k2{56?^nU( zq%=65flZn6)Y)1)+bQRXrC)qvz4PQd456aFS1m=3Jc3e=M#P68b85SO+Pad%r8!6H z4bF-rL`#Zp)=i)L%G&c7X85b5!K2nL1TvS>5KIR1_Cca(3tt_hRI1Q!G-cU0a+twD z5@l#Fv`TpF!~7PDPn<&C${g1Q%cS3t!Ti$zvxah&KJ_Yj94^}(I7Gy_XxgmVwU+(s zk5R980s@fT`o_$A^blTbm>yBxee|%$k(la|tUKZi-r9Xi=vFW_-U*LaFcn@^^2HP{ z)3BLEp8FC^!n|R4|6^>!XcUWN=iDKmlu-CdG>}BOw8X%@!c1bKB=l{NnlLYZ0=-x~ zJvvH?5H4GT5xDROG~EnQzjmTT=bE7}I;}O~>zWyAt@E>YI6d3N50FMilkA!sKl0GT z44@HDc{XjkWTn=%_fW-4jrYwi?3FICtcDym&02Tisyk@1Pq6TO$bYogL=qI&QP#D0 zpr|qRPFbKIqn?>w-;aEWGP(HabZU6hD|HT>X$Hfd4RC)yKcOfd0_b8{|4k)}5Op`J z;5=KUvWY3U0`~brwULw2Ym}|z$8_(WZ!I;E6&g*;V|;qxB))xs-P8gLkNKgVDq%Qa zY;H-TMeXavbu$Y$EX=b}qOt7qSyB`_wWY5eb&RM~ce#8tA;-4Rozd(A9rAAG!yNVU zaLl*j*TI?whi}x9Ekl_n*@5Y1D~Dhy)^vvL@SWOJSuL@$1@lhcIn&dE^_lZD8JSpw z1g}OUB9T8Ng+-PNEyZ#{Gj~xN zt;%00$|u7q@UM<<3zeO8Q`4k_R7>Cx#E{>yTDm`BwQyj#VBi0sfwc>PK2x)BbT+UO z0UCbLV32M9IeziiXsVEpcz=BR{RgC9qTLAz{}K(DYX3cA1znxgpC(~{kNBNoXf&m# z7p!JRdv1S;7 z0R!u10|UeSC3d@S4{(W}uN`!^z~ApVAFvFWm)L(E-~H=N=K+B|6i*|PV8Ot$9{u^I zm*M_1@XucZKVW@a>~`Niv_HmHGjVXVu(e@wFuGrm|FYQo zKnm=nz!SR&EbA-~AN3ClattVPe_0S3;U zp!xCtur&WUL;Cl3^qr6=$?w+y9b`ZgrGbS3O_ctJn14QM{d^aKfuVuj3HAI(%%9Vs z?_+~bUVj<;_eKBXZ0X#Ixg z-!AjZ4*)cW_AjsW{n`BUV&VMZ*+ilJ^Ob(idHnv9_!q17$N7=Jzl?TYy}u9s^D4hR zs{dlW{y1Ci_Y2kfzGM8`SMl40{_iV>`-c_N2Dav(@8<81Ea=~#Q=)*M{J&VTKhB8y z{gt%)mi|NZ->&n&EZQH($NYY&THjmFzkeaWU+Vw9Y`;EeyFxXC>{paK13G@O7 zTm7KKF)U#eS@P24i8kJqSaHg8zh(FYiO+Z@B^D-?=;&E8@!6qp;ZA>#pw;qTO~aa)6i}|O+_L#PC7~0 zI4S12-+l77Ns?rtsRLR~tclVAv5B$*%sZ+G*uc(tRS^RwE@FRGg_$=v5Yxiyg~SZ) z4o(oZJ5++_rTG-xz~`kLJpMQuc$MP|=}+?FIn%=~8Yn}fG|k%TYhbYAgSawNjSZz*)EA-tf|r5Ar4n}Mszf9z2J zfB+x>6q2l&!wtuay#M*5Hv<5``+v3npAXWx8rfg#T-p_hBmH_OJn%g=z8W-Qk-sGj zL!Ktp59nHbCtgdN$`TX8;ATP2v`QJkaH6YJrf>2^+)m~gw2G;7SfTrsy zXeCG+CV*q_zd%g=NnJo6aTG>{g;b#Z%QOK`vtC|Xj&Uq6_SZf{5t1=?gj{++TrL@J zgi&?Cc_&u6@w=6V^fJ z?>QXe97~wJyXOHM{JO8vTg@2ph3-NW=+k-cXpzPH1x!O|0ac=T5CYV~l4HWGn5_Qi z^F6O0j1#Mj3gFXAx317&|m}nWOtrw49u; z#bXfQ=H7yRp*n=Gvmr4ePedgVv5faH{NA?{JCpfQ4$P(rlj-Sp1By>Hr_Bre&toFR z*kFGcA|Fe*MbV2iRAP8(L}&Dt-qJ#vDUHu_aX}O~b6@;y9!U=8?(}yIyEu}IF{ZjA zo-V&r#2NhL8Y53x{wd_jcFR*op;VF>y*StmcV<-`*< zm1St8o!jCzYR4LS19|WUO}iM46lMoqHiF0?nkRscDlO^^MNMn%))*BU?OJ`F=pA9# zie2BI089R!<%%g#xZ53_9Ht*@g| zOH9fIu{dfRDi1%qTmI_p3qn=pQAgNJX4@;fwZ6`1XK{aO@u@Vh1kzRn9Uf7nCZ-*t zgtAv5j|N%&P%47H#emLFnkg>fMP43(eYQfmqC{_)&oNJhifexn7c}&>r;S9{d;KY4 zK}odqf;LOP(K%=9{u)qOdN|ZdfJ(VaZKy~+S?S647w9( z=lH2)2~b+qLy2ST;iGepcGo2Ox^m}$c?L)fV`Jyh0uA5`qJaEWQDVH zeM51DQkBF;R3W7;VKtGZKCZyd1p0j)%K|m( z<3dSFm3Y8u_xgt$FZ|qc;B>175O5^T zpnY>;QY^{>Gh zP!d6VS@zsyF#;WpZk-AHcy#te4~NeM)7eJO1$kL@)EQX{#1xb1to^6jz)nf6cj&d) z>2QSK*U6 zzNEd}qzG0#ZNn_s+@na&S%ev82NLU4JX)2H99eEUGpSSPp*d2!x~CmV1ot~VCv;FH zmzkNd23^VSM|y3=rJ@WvgyR4YV3)bxEJq=CgWuQE7PH(i;7W_~n8Hh4{qchOnA_Ad zwPeNmHdyy0FJUQe|h$8#1LYD zgwO%d_fD?^n%F46;{H}wAMkMKif;e}mGA4K_V-!aTYn?JncC~_QJ2#vnO&y%?d3`&+|~Gv zC4Zt!WB=0rn!~IY?eW>G@fpbR{d*m~j(m+peLZ=79a+Eklix-)FYuaIY`rJ0<~#UW zW4xprW-;&8jCqZtUz5P`;8tKH)}YpQASk;6#QI*?1g((r)0qJH_mn*FKuS;CTHb(p zidKz-TwdI_IefWoPbYyxC^z{^iGx1GT9Hcu-pZWyCH8u!Z~f=|Sd9UB=`h_zV)u$x za;o=c@Vh-hVYi$(#^6)*xDUX+d?5LYlo7&c02mt^Wp@k(v2gIY9bN-YL_p1!2!z8GH z9bhmq`Z5qN=qC1%{6*zB+j%CO{a};bTx;x`(_<#@`RP%>*+mAx4OVU2?5gwT<9Q#u zpxxL7*S_=?>gRHNMkiS#Z=#$MmLQEU5kW9O6-c%|rc68=hl}~pZpahz9qkbZ2QcsXXYMOBY2{fq&g@*}+#*AcPq0oG`hHzrb z!u*MDX^r(BoBQAyM2mKpz&rbQdZ^QPo4Z4W!OZ1@W!xhEgJxj?-1%*NK|@E65T^lI z=zw&ol4&7hm8x2vPJ=`m{I`h6XNEsj|Ob7A7U9Q7o-#H8%raG~<`y zZQkABjlg{FYuw4NQ2#IBfAPHk=53!|R?MOLfD&1t007Cv004ylzr4-S&hlFG(r!Z> z;Wu0I8$Uh;UZ7?m-R#0Xr9mcgQYwDTCmeqs7)C8uHEP8N~hKH9WgPkloq8K3vQ;Sd3%Q#xn zbm7Pl+ZH>9NCAEb*)f9a=zJh6#yh1l8_l6=KGV($$I?@eNR$=^Cd?2l-B4diP zNd)^~zOUpU3!^Iwq%60jPdCG8wlmSi+6wKxU_U4*)b+6MSAkt&LQYaV zKrPH&v6IB<(%@Z1>HHJb*IiPsvyAVatuyTD=K=;i3!Zva5HX_s9C70wT9&1d1boG` zA58ErT1rZlHXAC6@pF&0h$|N|O2`ex3TIIK%<5t!1e-i2=|F#nr0ELuDd5Kz3zu2B zmdmM~`bu3rELChpJ010;LRVhqnu!(z3wa!$?`p1080o4_Y|W)Yu&es|1QxM0rM)Hc z(Xd)xiorWhTs`!b%SVGbjEvOOA88vbe^fe0GWnbMrB;*&3MMxsk3F{YB}}nG?j=J` zc6b6N5OTm~J_KXrUdSoZ1H7jm-VRb(t;*8B?p)8@3Y!iXUHAGuKQYln@U-DPgn&`( zWO`*bZD+O_c{vfvRfrr0!y~%NmCHSqM|TjKfbx;_??7O$6>d$hyr|P!cy?C^%Q&B! z6yOUq?eKyJy;1^DNo_5Ol_-;RgHjg>Zu56gChjpVj|vOc$r;1sxv=`^UC0R0X>6on zvrrh1@nM9hN!HjSuu9EF`)?FCIU|l>9HfntP;waX3kSoXc8JOeowY>Z+pn07GroMW zJNAFEee213nrJ{R+6d$>ZK~=E>S)*1hrd1O{_iw z1=rjYKTbW(qG#nf#-DK&1MB&4@MJQOUkwsq7es`Rg5lNRCzTEfMxu(x@oBS@+xi{w zlYe`i#NfU-?)o6UIBrhce{TnU&OB3a%AN9k0n7b(!Q{e)2s++%xWcyT2-Lpc-LCg{ z2e$AuC!#mtgLnI(rb-ZOHTkrBFNoIWQ0n?lngJLS?-*4 zz}ir5rZHYBC#Ac(V?X~p=g|$a>TLsgL#GqtxmOd`qN0E6eAn*jtzFlO(&4hjc)TH9 zF;SDcoPcfFv)OP_xqR-5$MqIyqEY5M%NolPnGs4{JEN`FloK-A03}yGQ(ks2l23c4 z{dq*cM|dxFNTP0`f2G~cysKr7(4I5PoLRav&js7Dsff}Mnv%M8!R*qZa_vlIDY7b4 z(m0ht@*&ZZ!)YCw-HgPRl=Q&#D+B!02k`%`;9>vIFT0Yk^#38=LyK&gv6Fo&h5iY5 z^HKx=l>giGpZR|zdykb9wpioo_lHApA8?wPUiLbBBV}M>$-+ZKy!hl0M`AUxKz+{u z1PBCk1uGyk80=jm_UCpR;9X$va!FTZT_0qej4Rux;`?0nboI2~_vWma8~dyGtzpBV zH@BN8v03wy)AzA{_tJBBL*Jvv&G#`3I@j%XL(`-6>5~2d&W$h6Pd)b6g9k%5mNw_V zEFzurzW>Yp_Urexzgx`qwG2szM-w=7n|kBk+>kC?#pY<~q1U!Imm%HWnt8sVd zGqCITEk^!Lug8-)>vgI$Ak`OND0DYwW&Zs(wD74151azW%n7PF`~L7ShX1oU zmQ<&=`{UWT^nLTeHNdB2*TA&affv2KFl%gotPN86rIdfdb!s)ETTPd>y%|?>D@*Uj z>*M{INB-O3QdM#bvdY0l-o|9tyY}wxmzGn&mH|^*l(YPMI(5FHXZ_vYyE!|D&P5&c zq;z|>bR#!`{&P<278-OO%jXn&Goo|1C}iikuS*9k)cl8yZ8zuqf^ligZR_Lku`5U6 zPVv&IN-YNl2)GS7dR_J|tqK_ameaLt;1oR7daMIi+SKUuwz96Lb919IQlvi1yKgS{ zw(GP?;Pa+KXl%CwLYMF>Ajo553L@`g1d|JRcYXW)^>L4{Xc_!cJ+H5V*X+>+EwAv6 zvLiSD4l(1VkJUYKRgNtZ>J_cm{e{b|*zLv`|28*M*sCL#AkDn>lW)d9(Jo#(rBV*j zSFF~ITUsvh7Gc)VQVzjaDE8Ct-B!|n(j?3?a)s_u=|%?!)#0e4Pa7j+%>0;=5`t*C zK+!8u83gn87eTZfB0uXA(hz9)#zT4OHZ@#_Vew10yBN-ecM>?`=13Tu;{A?3elV6do6o8K+~Z5SzWj zD<1s^C(etSU;Cu=)zwXCtlwQ|(EaJa!RJdv+cx}nSoJ99*SlTWt(&Xs?`I#l?AxxZ z8yx(y_rXk5-R;}W^=eX%UGLKG+mHF>3?6(P>DI2d&)e~8+E=UgbZXR31J~}lkGK3? z`u3ek*-{8o9y_sHy?rq{zR%AJAJ5MEH{V#@4qlJv{lnRM*Y|0T8F-y;pZm+lkqY_S z>O$11onH6au9xqFAFT9em%n&FN{J zUEGhu$NAAMwE(xbSPkF)_G%G7^XZR$%0ak^=GIIg+wSh=)z=j$d9M#d>`pbz;t*`(_w~Z*T-eb4aL#)}8l)`G z_TB63Md|mh9G}a}X8xAmPHE8nvk-wPX`AIBQR!TV-q#d# z{}o(a;aJWkzth)no34OyNx=?t8*>|JQCNXAJH!+(*=zfBpRd>I_rpth7vfi*-`Cqv zTAf(fqk%Me;1CyIoZE{n{EIGlDCzaH=(!%phVP@o*^HRhA#)`B=$QgY5iMeLt}w#} z(f|cb;QNr;-#1{Ov8$t@Rb<-JD?*vfbr!GMy-eIZy~-}r`zWicOdj+u(*ipc+$2Tq zCd)3pqUCzFL1?BQQczB#Z=6~6-FBvzzO8;j%o@8~7hBpbKBc>f+>?`*8bnSLc%gaS zH0!C|8Nw+l4`ad#wNcutE;Uumvg&l_49{BWcnYugi|70Mg{dI3x;Q=jI_~iPZ};~f zl|6y0+wTWUyI=F$cLg6L6G@H6Bb1C2{&*r{5z)x$P-s&ga#6`?Q^{&hj(XSP{)@E7 z$pg9dIs1yTHjs{*4-cintyD!rYK|(EVm1-gsA@C~+C#dOtr(&x6@IiTL0RRdCe;=x zrSmt10!vRWiHbc$D$I)Esa(||-Cp+}PrKjuCcWI-o?YqhI=#MKzt+qi-R^BJ-@exm z7u-dKg}UT8p%p?3Dnt{dt~Md)fCCcqsa3x%-YsGYc6(N7Vt7+H~W{1+db!EI9ai? zy(^aKfr;#`tp|M0xF4Z1y_~D6J5VVnd(OBev$67^AgiLQ4U#;(j?;-#I&dbnBZLtW z&32(+>c7lt79qHDi_bd-L6EdA$- zCnfMw*Rixh+^$juboH21mX$ZO(dy7-wN;zSge_7!cj2EK57oH{OK}fZm&}!0!FE>Yf%T0$#r(U;uxINxG9=_UP zSIP%vRI%bK1LZ=YmL>TAhzlNQSfE~*UsK-I`}NR$SsT7wZ!KOQHV3AYvGP~?5}$65 z^7A;>V+ZWChsLx7(6h?2G&`nafvZ~#z0+TMuDe$q+~4B_Xd`i%3O$U3W;2by9TAM z$_#heu(jMFZaGn3XFx}t;e#%#HgyA+2+))vW#%yQ(5K=wlFHCK)%a_qt(PfzQHw{U zBro;#WZA=Ik>1M=zVl0N&ey}mc2m$Q_-$T~kI&b^`qX#Zm>9h-9**8a(R=N|`G`Yu;Y(VC=oY{cf>yl|;U-N>f)rhhl*yH|d z(9H$8n+c?C_xo~FN0a(&*ayU#T06kyjp41|?T=G0a1-LFg(MnL zt;TZ6Kh&2~R$Q8_O4?awthI4&=*+ZWE;%O&3O_67%f7bByYeS!uNWI~x>P?c`J zbK3%*5Ni)@Z6yQs!R1RvZ_y+Jmn@j5_0IOPCKm^}ZWo8|?7CCKQ>lu52A9hNq8xfp zxO0x;(|Qni>FrA*T2*IwL*ZW3r;am;YI(T>P8C)0_f*H{RDvZJ$EO<-d-~WsT-@IW zx;r}ED?Tr;uY-}M!=UePy`3I*-wwaKTGkOQsuryYOu88Zf}xV@YM9ZRX$tl^zREvI=-ieiwwTatvg{stEJClLPpkY1}F+qkIs%ay= ziJv~Gr<^G_95oLrb9!hBw$EQBmNhDiDG4=Nxo#J|$PR;HR579}0p^3g!&&=pAJ>nQ z(^r{#)Ns4WmM<b5>H7>fg@#u;pYP zX@TncNR@!}DlIeB2HVtw7F)n&E1lzqmRbT-HNG)v`MwnuO8rZ+vV%zHX?@fnm1@ou z%gEYvT3tr19ZYW{(uWvI2voerKONnjEGL9ZE)%wT8uSsLhbf9Y+6N{D%l&G%yQ{qz zbRQ`X4&$64G892p@43d6o0rB^D%5UOf&!9ec{)&5^-}wsk7R2!VML6q-8Ijr7aj7f zN}2VO&)hQsiN=kEYRL!uDnk;MKPv`T{Nkx4v0jjh1|zktupgE=r2Lnc zevwgrj%MfOH?xXQ)W?VME)ZC^G$Vg%Q61tFcdEQoLBAzX$U+J;P^d^vz6j0TsGc=E z@nW70okk>`-k~-Ww$he=g@4Oo??vt7BZRl02*IDg+o{3I<)>xa~ zI8#!Xtc>m$(!O{!pCDf*kd-TtkA@+=WC&#C^JNec$*vMwDo$mgQV9MKcr3La#n^Bp z^;XCj`8ZJkHTPhA{>`f#&U4(D>mi%>rHc23qU6&$8e_Jho;`2_A){RCFP2V7B%@XG z!5Rl+(6DT$)%#s&xNZT7lXuWWqK}eZ{cL&F_)nnKLi65n$CrGz_`YXbzaDo=DLCl+ z*tK8izg?0R4KLZP9yj+xPXE$=6!MZdc_~Q1;gs?wBE*rNlbY!_D7Dgnfa-cas zGdK3E9?V|Mot@qc_+1dz$Ce8Bj=T4+A*DVywz_^9AB^c`sh|Np zxLGTVSxu10iLxF@)l@&E0Z4^aKBNRlsgwZ~@&qIvNxz@_h+pMfp+vv5A0>TJ^LwfP zugBMY!Q;?b*Dzy-CsAb1+dD$MVcB7Mqz+POdSYwvY}g$JA1;{Ll{ZL5!z1I`Xl=Lw z`+1}d|JZEUJT4!0py!t}#B0M6A!&FHtd;PUvpUZ~nNTMZ7p_Y78z>>|q!IWt_Y~ee z6xybH_ad<_pwbCLO0zj|ZGQ@f_IU^`+97HLHT9EGNN?r10%}Kofz!^@U=K>}6+GF^ zF~9eO`3(%&P(UAo9xEmckKTTw);&vZAAPUBP7z^`aXM@I(E4JIZZWLcv7f&CwT3WOA^;inkWmMK1}A@A zV|Qf9VFE2ogTfkxH41B`C#&QX*O;V1Nxh42P^5Ko*Er9rNT$2lj3X5 zMW^$L%U^Xd8zFQJrrN^D6~Q9dmXPYC6IwK(5_w8xs+=y|pU~1rw&e4i*05cJD7!af zPN*i^N<|0T`Q{o7un3M_QFP_D+}8I7KIx2|9XzPCTBOvh%8phPJqfCmC8UUCB1Gk4 zM<4+{Dnd9yNWw)5AuMxI5#t4g#E^k}2`p?C!bhF$H31|XlFuI^mOr8gp%1D1CQtPx zsEA?NoG=N=WJp$=isF{pwj-I%IFX8Xq|M-(2N8p@sMce{C{p1?C}UC8&LSp(smf#K z8p{aY^xk!%AG*WTXE2;b(Qd&NeIRBuId#Ae$@>v53vrW>Am8P|?7>%1;zckP%GNTO zrEQ&0)ecsH{jcE+SvgCJph^*}vk{RkMTI}XqgfClS6qq}e{?I)5W6b#jTFe)&F1R%jC z&Z&M@g!um|?yZ$srjujKmJxPSz5C3o9dTaM$?}|ffd7nA^eq6w0UCg|P#>*_2oOnB1HQm;0*4+b{U9tL|AQ*@#l(;y zV}nKpjb{c8#X;)H?z^|D{wGkl0Rt9_S#f`Wp~Z-8073$qtl3yfOpMgoL$xkA00|F1 zYZ*$97{fMFyN}jGQYVRH>t=I)@{n*N#H>)6p;Ch-ON*taLC|U}RoJRfmCYJc&M6{} z3QZ3Fk|nB=G-wi+rK(h9W8I%vmw7g48*XZYGJQxb@e>Ox4=y)ULe6lw!l2YMR|ESB z;vlIEI7S$HOe1$_=dq#75RK8p!=Wq7HrnhrZx3tFL6qr;LJt`RDQlxungIGC%b>Va z1s1uw$#g6;Xr9*A5&>H|i36yJZHO2iU}*>4Kgpx%*qD+{!(JG&kKB&Y6}XzrqsuT; zY8iTRT)7jWT{tq9rko4Wf7l9kPa?uGl%%>jVX9FxF+!IiE+Lh;mAoaCxO2%EXwX9) zU4a_K$-J&GWtwsh-uO?j^DvbTeY(qg8f^bIh9;VVAoqZENZrezZDv`Lfh6)bl8CF? zO#&vvf|P6}G;L1-X9qaJ?nnE8&BFpV7f%Hvtm-27k9V+cf!I?Sv_a>-tq~iv%kNwi zO?{pn^r@>RTR%38_*s>ah(AjPDc8Nxt5VT6|5yv@;bx)8!ItG|urBNE!*H;gN*&Pb zD{8WuE`ud=B)m#yjF(^|8-Qurf~6DsirPMM-xf1W&UQ}b@81JKdP_zH8rnk^^7MqlSafRVq5vKByfoRsC#OM<3 zaNa3dmiTb{kpc3UKan9z+H6*`YVT^BU6VT?_v}2G3QHQWKZ{n{|GHs#wj-Y<=^55` zsv8R4m*Mi@=v9{u^SyZ2A1A`rF1~?B+Jz-qQpJVja#A*SvS0XsOb2#SWeCdvb_@}M z!v^1j0?f9r;6}CUh21zNlBuJh6HO@bE`ysAGf&XaX|wha1-uq?o7+A% zs*XPj`p)P-v=jjpU?SvLgnFSytx8pY60x9RuRh2%kC1FmsWkT^Ti;Xa`%R*mp|XP> zP4~3L6-D`&zvpGn!&v8XR(GeSa?#&&;ln)A7#ElN?~CnPQSA1u?V=NsbD{|o>n#}h zv99Fs;aJGF{xVA9K7qmLNM23#n;37u%NJ%*J`$1I8q)E}pPWT}wPRR1I`rxjkm8WS z!~>Oq1(6*4$HO7U0E}V-{z?1LqCQodc|1Cz;m0TCd4Y+Slw&UI0)LNu$DS=9e|2Or~o*`rCPSnV*!YAGbG>ULJ%EV?@H z`2JdpSlk9zIGSZchD9U#8GVmx-z5QI^+((<1pS(}p&_5)f0%B@$E^&y$mh(+DpP;5 z7+s)5j zS%fyaX3f=d+GzH+_Ml0&&MUr%3N70oA-F^b`cy-e-!`xHwPJ7Q@G9R}BOf?$P9`_h z0Gqq^Og2-c|5xhlz+@iUuE%6N>L%?PYkT6)6t5Fd0;_u+0a$N!?qAy+ww7utl~}k7 z>DI_U1}Hnb6Y*(_$rJTy^AZ-O^A#&Bx;0f1`>j`R!7~(Hzww0hWft)c^hHZ?3iQ1^ z@OdD4#jIWq0Xp@Y>DxWy>#1vsqibpFAfZKS?x$!%y3SpwWTnMm6?82Zs#eQR^jxZ* zkA&1#aR=%e$UJB2l!#hTPXF%SrAgE|nov zrYCq6VXMW@l@d}A}mztNguaM}&R$D<^U9Y3)17A7%*Ch5d z?w%TtkI)b~=ZBHGF`+ElDvY6|WV_TIF>l$iWMJC1ev~)PxOu`6aPP8JfL4wG1M4?$ zhG=q79gyY5g=Kuj$A!V-RilvS7AV@!E6Qq8Y-XNYoSdSFuANBlru}mb>O|MU{SH7G8MAn}~PJyCslPEh& zR$$WXWSO~shUk2g;C${YPjzIx5u@s=R&`yju%D7Aq=^So%snSk<_9h3ULV#`e>Rf^ zFDh5$QLxuA#LVmHls=M=#~DUVLIF>wgkw->cGu&@q9SF{>~w$9uqf*ysDu<@585B> zaUBdxC0W0GYcD$MG8SqBoIop*X zDfqWb4p-vtwa%pYl$8+6nLGhrHXJ^ukSWp!N$JOw|s4irr0NfvIJHsvRVfkrI~zQzX6@1y!j9?cx4&}6U{xG<-dXA z_Gd6wU#y;Z4G~yo3hjcHC}OSrBm%i5QiCf z#=O!LqN3cK%+{32A%jk@Co^Wo)|*p%_8WkU19Dgp>x0%NXQc1Zj_jUCm+fv#(9(~h zo1$F?sW7kC>PQAdU4bru0TRY*YyUfb;riRJavuthn<66Grj?yJ->uqA{e#DXU zNofuo7(s(lLN`XSq+M3sqVl9sQAA^jpYO~L@q_W(zi(u3><0KdRX|S~>g}50P*V7r znHXqZIum)ULAnE}E~1}D1#lsdsvf@(_>7;+Ilrh3n2Z%No>c$Zjz~U4K>=wVVZNC>^%ijo_4fr>8KyUTMi^MO7?gvo_n59npl33^plLVyJj|q4<1+ z3WFsYOBA+9H6^~c-Ub3Ixnm-JiJ62riiPUW%TV3B{}Ht_LY~R{b~5&(0G_l?nnEW1G-rjn==R=HNemzP7Km>BU(@{d$;H36Fh8(fpkg~XbKGtO7r(8N6rr1nT+ zrFB#9cUL*taGA?eG%(EkjAyIch3C7oObRWIF!~3ZP;czo9uD+EkgjMUEB(Y30`L%i z(_H^_`m~dAOcJ>f>y>ru$aR4Po9}In)VK`-{in8q)(+6lD6uFpt#&b~>~Pfr6|fdb z(YMh_P2lbsXCkKIO%S^#sq!`Jb0qTr3Nw=Q$`QF(t0oW)Yf;8|SbWm;XnTv}vxN!e zhq=8`jNdFMv%s`GLx5%JK}DV!1y)39RtoFj)!cneUO1CmPOGoHM>n1x?PWr2FHd#Y zCfW@M0E?=|VVjbjnpI&-DC|t+0hv=_3^41dD z@zFsXxA&P0*^aZ%`C6Ak;dNN%78N+)8EDV4D19mV-3mtcnohnJ(^(|sA4#!VB0hDX zN@stS>`s7vLk)fa27p>Xe=bh|xzBc5s%CcdgcljI9HI~n=xuU&M6WRIlR)I8E2Jw_aui9w zRQS=)RJq{F>|wrE@cPvC=C#De2&0ZkQON&;Hnhkj++h-fLlq!*G zsy#Z8A^mndM5{Do!t+$DpfqX1`5H{;k*CadxOTW_fBR)l5q%vik)dcB4$9MzsZ}Ln zgP5eJt$Af7b)}f_094|Tgh6qG;!1pR^E3aQs_D(U=Y z|2|5x-AailL0YxXQimT|5f>u^c4O0CZZB9POJFc@GkLR_%GaKNsBUH&@qW!qy^`l$6# zHce28xUh;bf!3>kiDE=SJ~a~M|8yCVDlB73g~pWk#mu{6*CVJy&)x(Od*Ecg~~GX84Et z)(-tf+V*-Vbl(<);-70ERRN1t zO(LlOg0=9yG0T-nS$kTJ&Pldly2IK`Yz7h#&i8g~L(iJ7HGM1krq$ew<>;uoUN!v+ z`eoGfOv-g@2ZxKMEK^rW#UfM$FBGN6jLrkru~=#Xaa4Lj3`*!IL>zP_7Oq!N!mWzm z?*T-a1ELqUnQj5KrIy1Lkt$`oGpyZRt#Zj{M8Eoxa@dtCd0Qg4#whg z+;6MXAKYv2=hVl7rpFyzt}3Bh)e{EqyD|LUe+A~Lg^B&8q!rgo>!S~~*SY&T)>7+s z-_RAboy`}{Ij}vB7l_&JnDUGqus%&GzNj+v#yPSR@d*^dxvP`uZMt4?V!p*pv0$of z$7AB$L>jrH!~~}r`{m(`@LEWkvlr-$jb?Zgp>=uIq{$V5e?xK&go)IKFzq9+R7b1f zM1z(P+{^tm$jCdp^y55^shQx^TG4IPEH7TAnfU^iiZg!ZDU z76)_|*p_R_x-hBp^khrlu;%rCM0}iA|Lb$r>#El!R;wk#v32=l*$8dUw-!>BFR(Vl z+7tz6B3)>v${Y1E?xx=YS(PiWqrin&xgxS~#>N&Mil`_Q*_dN*s48Q!Z2V`sWrZTU zGwcslbwZYl(0>zxswx)QQ{X_UX;ZTN3!}gebVZR*g2n9I+1)KBY3N!93J)I%D||U4 zW_Xq^r-I2X3_h=uBh&Rhskp6HeCL3L<}a0SAJVR?i>u}|gmtLH72~gyYH2YIq{|!3 z)TdgYQL-AdzyygK2!jKI1CD-VK!i#j?P9#AO?wQcWm%}w^I=}Ze^G%3MOv`_QJ)HL ze5y^vNUh5ur;W|Be+2;Xm!|;-M}iFurm2^LRE0_5)Jo5@8LKR;r)jMv*Zj-W387XF z{kNA8EtRP;GMl%PEOIs5%B=H_?Y8HK(GF2d+`VUrncDMomqht;WQWW`y_F8i*6DYp zq3Y)$u)rk@+jKQd4@t~JW#LVEGrcyvNB9$$I$eAFaRZklt8(anaWcL79}_NqNKoqk z!SMzEbt8#S-Jr*^;=k z1Zu%B1OdJ3@+_!2tHSc5(Io=n=MSv73KvSzPo#lez45e#U}g2CNc ztL&Hos@^t)fizoIMsW$}`YZ;Wk=ihSrt=7^;bG3)=3Pu4tbspsPeOPzgWf$;P8_XVArem73J2 zdTI;kj;SXjM&b(h6j0C>--s=~FlSS5o``JNjgE9GQ{uQvF3z%u_g!j&O>4 z#03iE`Y-D4v{EGHm@P~|l_04f@oz1(st}AWl(WdQN?E8ylsQR>t>WVJN{im6Y&9t@ zX=n?)SX1AqYr0fY7gHJ{k1XYqFHbF-{gPppqb{V?45}E^(Ws+PX;vZ6fx=e|t{7a= zxTA1pvIMBDfPuaqs!B_KABB_^!PF5@QZ2*OP7;asyFp;f)Fw3INGYfy=T%q9I2oJu zz)AiR{Ups(B;jo70kn;=)(IwH?DZ0?WKzbS&?TE1`smTN1y5rIjWmWzZ}?$@Dj&fq z&z5vWW9Tze+k@a4$;8Niivx)S#Hff6?$NNui%>lBaZ?gR#bmI^*f3K>JXO@GDy@r2 zqD-8HP?Nsy&+I5~MB#%pF#{;>%!rd8f(;eqpfnKu>k7zAW1&SmI~x@Rlq!uoX{;c1F?7|5dl(GSo55-rB??1<TheTM!JStiPIb8@O++#3JFk^FvH0LYS^o!5G<<@oK2&U-J)Cn*Oe z)9NJ5q;eo|i$oFU(yah#pT*btN4gdYjspNwXu?E>DyvCKk`rQyLn@dkSbnEN zO>Xfw8)F4$dqtCF6E`+REQsig(Ovw}=^Ay`$l6oY;i z8ZiFDFj4<yeZMH67CQ*+HG#=m`x{Fq{RM#3FLyFfYW2cci9t~Ut z;Kz<{8^eggxR5*sJiL}R)jIT+Her#(`LQ%0tbf^)!PJ9erSV8E!2aFfmf`DovR$0_ z^vj}GoRb5Cw)@%C;l-oQuDF#xp|bRC(%45mraH3zN~|i&eA>ziW?{&Xd7RL|@ItDT zOW>~1}QbGbfYW*?t@wn+&hUXl9h2kUoeXqPHmL8K)oiL8`t4Yfp->A9LVL z+OMZD3*_;Q&d;LzR2Ot`=o-V>659#; zAyj*KQGZBi&vz|H&xNsbAyC$sM7fB4Ryi0COt1XF9u=h}Ud?bCUM))(euv`f=MaFFg9UA=4z`^DY5%9q8)nfO*y7 zW2&4pRJ(_;5I1m~c0#`mreCWaW1ZVbTuEV~<3zRkc+R-W?y z(&(1fWib|#0brbZ=8_-|#{ELlXvbigh57ZM9Q-E2GpR}kLFJ+4>c;DHM3=x3s6Ynx z%(OmWF@>NCy*y2@Hq*oN!qDJpq`93VC6=}C`0%Fs3O~V6Kv4w6Q3N}nApszR3I=Rp z(tL*CNTGpX(F-Y6sFg%|IG}6tbzSy&5jGcb+AZKstEoVbEB1xH~=-j63GuM zAuLlvQm)8Y3S!8Mn2;AyFR*Zl&O@uNK{^WGeKU16F^vq3gN;$+K@J47G0YzpS-ESM z2FzG>KIV(T-%h`qtj_XXOS8sDmotmIZg)15CDU7%>D7047!BvJ^HjJEKIhHCz_=Ck~;6 zlV7Nj-Y!LQJvH44?H6f8!G>R*JB2rmI5dWznpV$Nl zh7XgNLNYL()uAZafX1YscHOk0aHc6QvPphQ^ISDN$8C=2#hkSBY-g3F!!)Q zrF=%d>R{C4hA@m=KV$<^dko{kM}(55DN;{}b&%}b%L2gX4VFL05(^0Sw?mrIKJA6FDHk7x4hK~1^bM+fNVq;*i z+S_GO8+Y!+5ks2*I!Nv14Da>DjtO2#?+>=wr|1aHFb|PzN{aWge7W(sV;Kpyxn{JrE6UgorayG1{b^ z8NM1|%RtyhzYq^I&^U0lI-(v4`NZaX*L&A@9ZozaZXAzQx_ z-`zRs!z9aW!D@)hXpcw}p*x zXuS*jJZ9z-*U#t@&wu?Mitos%26mO{N($ZE8(J_0x1D~^jwH;k88P+C|L(5U;UXA8 zq+)Hc7WKo}KX6;g`|u_9PM%p4H{5*sH06pmBf#V-xr-42pS3@}=l*|~zCH1M_J#KQ z7lB}>;Fny_Gc;0iGl;R+cD>HjmgY$=x^L3Q>9Pn!UpZrgAIRu*v<5<5^He?Go`YwF z-#0&fu)imDe#epK&Ka8b{}EofnvH));%v|_U3D8g9Ddp8yE)8<>h{Q>;+?d@H>jK9 z`);EbKC9S^RtVKuDj+(uM()tiL4%BrGMZ5|lR79W&lU3^ASKyfm3IKuDK2nz47~y6 zZDA^AP`tNSj=%{GUJ>A>JYG$yCnqi7!2`2!dLl{t3;it^%{79XYw%HwD|HjRv|0ER ze&IgDoj|Aqr;UqP3s3*SzKF;LFi}$&U>Xe}ZV+mk9kgsMD1Z-`03IL7@DH_W3XNnu zAh=;+o1!jmR6Rd-E3a_(f57>T`MXvBgRz#fEvQO;iJ2lB1vU)c*$_NHYPfTx%Q88q z(dkAqIi!&r8J&?-Z#|v*F-#eHCMr)28Z}awiK?)_QSR0nW5sK3W}4WWSvhj7P)JFE z94jm+FI9<&TNFZBa6yiF;+lfBl{K|sm+?a!{CO1f+}5bm++H)GGpbBbqp^cM47CQl ziNQc}e3DNQUYZ%?XyG#={%1J`iR1I0+|lbE+EKJ%Qd)iNR{DV{UsPi((djZGeO@>- zT3!IoPPCu`=dW}1px!LzEdoP6zPiRFOUMxxg*tmb;G%`LXAy3Xd<|InKnNiIMTwYW zgUA8$D-6*HW@Mr^HFwD13b%aXP?5!rioD2)7{W9)hj7YEG!kLeyRVrgBwu$H)mm=5 zWTkAiie_lw;W~hzLowwL9Q#OS&_8%@dU)0!>cw zm7!lyk5*G@-zKQsB)8~S({DAgY~MJ4lj^lJX&c`ecw=-Q|8XkN8I-}je27oV&@XG}S z`uDg7p}t6(H_b+1L>{S>7|Q>65YS%s^Pb4TsdR;FhagITPz!nRd_d%s+ycV}#CMtP zq=t24VOXd29eyi+iYJv`Q@!d30Z3@-8F+-$-ODd2fKML*ak}F`Q;HKixd6~~VF?t! zU^)tARSB|R*u|W@&j1}%Zl$?%&v#bzNmNp~QUkagpsxp2Og$iKUpcoFa(Dmn3INx@ zkO(SS%V$U5(ult#h4j!Kev@1`2(_Vhj1cy!&ZP+^{8Agc5we?AH9Rq4L?`X6z~B$? zCwH;{`RbFmi3Fp;7jC{pp$1H4o>|!s_(Nrc-mt|#w~d8KcNhd)8fLc_Us&52eMkaR za7qa{u+KYuNevDF)E7;8GhmjI#7s|VMYaO@p`evg#HbbJMJE5nT!!Q|M#5ZSO~H|J z_p(Pwmk@xI0`<)sP6UL=H`cT)Hl|8Qy$DdoCsfW$il%xbp=pVH&XZ|}OSvbY*q}Z> z$q~<CX$AcLwAaj+5ap@0Si*MAC)5#jO~aa;Y(Dv9Q6SutL;+2{B=_tplU zfR_DYby`qNv}c7HoaC=j#o16~K~7LqpHCB9sL8p>awdBT4PtAD)eNcad(m3`g$MsB z?n|ic6Pq`VD`~ctB-_i~?B|>fOKrteXY$IryF5B?RnYhbtp=s+rv3|T_U>Hz9bgp0 zD1t!*Gyl8eiERZqi-TlAC>r}A@W1#990BtaQKDgnNBnK4eD*2)KMkHXs2jxBjw~Bm zGO)B>3k$CsN->aP#z%-(#fT5e4w4%r(2rsqoH}yp{m)S=P0~#Rp7p@g^Q^z-S+{ig z1HqZmVJVr4HJY5b(;mo7d#!a@Yp|E$wXl%RA)G~{lHY%OnNc^2OKKHq z@#2d@YOGyOt!tW4yLyIeIi)a2VHUwDs-P<__9p0!0*q4X+R_=^5Kg$MtDa(7WB*di zxl#y1*Bjw zMqmzBKvR8TGhSw}#B8d-Y=WDD`&$ol-afWL5dF^-y>Uv*@$p78-cFIt%X2Hmmlru) zzF&g32R}!2*&GL>RX=sz#anUsbPad{KSl#65@s)DP0Bep|0uOrSLL3ljSD98)=;wt zBKp-W6?f}XNUNi$FO6lM#gy=;^eJ7@vO6a8?vytd-F<)oajvL6;4LBX#y&7|-wcJs z!2_u|V*H8-qG^LTnY-yQ(`g_=iY9>YX#7M)Vev>6*ly%mGP|HgL|JPQlQNvO`EZ_s zg{`S+35W$&zL^!isN@6lEt6ypdM?z5a9ZOBCa#Z&#IdEzmU4Y}m0h4Ch%qMq_UrH4g4g5XFHiA}+ZEL1GpEob2u{;^8xa3MH?IKoV(2zx7 z!cv5E%pCc6_vDq%&^pvdA%hW3lM!&5>6~1BQ^1UJxSR!z5;bd*X6_RLTf^5c%aB01 zv(S)uX#tQZ?&DAbhtSzC>-kzLFn`AsJ$XiVqWe`6D-Eoc6R^NUcPwQ-EcH0K4 z{(qe0;$HUU4?bq~T8VAmtPB+5q$T3u!hTUoLIk@>l>72wT+>mbV)^->3;uYXLR@yc zVKo){M+Sc3T1fHwv#4u?GzqvwV4zx;aG2~O3{Qb#u@M*Y5g$o=*7tytM5GW86YT(n zJUQyq(9+ew<#RDTf6HQA;70ZF9# zxc?s~=!(-nPSE3D|Hlbx=Z*3|PEavrqp?s4>htjA%LAjPR+THGSIw30UFZ+CxoqTL z!s1J1zbx=Otrl_2GUXi@_pk1ANlNadZq3jbn9H`TXg-c>qa?)w1%um$q<<|nvzC>v z-@zMf-E057M!z!fd?06&tl-4?=xDMs7}VDZm7bCoW{IcnwM9&B3J(JS_u2l+Ijs)` z)h<8rjo_?mFphhy8^;gyOsgg*N0|KBG}ni(ai6a-Bk~M(+SY)($Ccj7&d{B$jwZ;b zV+s?a0R|$isVAL%Zmf1uDjk)$fn|DCZecMfMU>ng(m|cmUu#S45lzk6E}I?EG%|e( znUpQ&e%9ZwNeT*+8aRvR6R$vSPkk3AtVrt+kufy{H7)DJwXDe|AjH*!Ru|}9VE$yN zt^q_u26X^_11uye6=!~G>$i#Vx_!QpiOD#aF4BZ!XjdLNn|bU9Yacg@A9mzyFj0QV zmD_bBU)mEWl74btR0pc$Q)|E*jG+x;X!d*tPa&iW^kJ-CoBpI?g97kt-ra}L;mbh$ z%w=R5)x6`M)3wnyVQ58#AN-kKR88!`CiT7-$|%mt{x{0P)r|B9hdtz+QoB9R7vO~+ z!oj}}{6r>rlRCkK!Q+_6Y4+PbpVQg|Sx7!$a{qO%9%#1Iy%%v|#qZV(GnfGeLYL|| zs~CBV;QOZ~HuNoy@Tk)u8ZQ{3Jj^n#f2R560y)(-$^Iss=}o!zGyo;~5<3^g>7Dv<5~}isYJyWjFtO=|2q@ z`GF|vj#5{C4FQoSr6>!r`2$)aQJMhVjO4w&yl@-&DRc>0%@99$8(*@tJ{5=O zBr#n`a?-pgPy`Fq)2LK?qDkgbb%Jkw5Ic?O@DJ3Cr0FU;b(6ljVVBdyLCgnD!C6IZ zx>ZJOBD+nc;H2O*q~!s@`HU=7&UIWXOmodvL?=EnFu5O|H%%EJss^*dZsh47Y*Dn; zwUg;}8A;a*%LkR2_QIvi&|QHsR|-VVlhk~7fm-)Thi}o_0{YJHgQ9x3Kq^AtUYysR z!Wq8v)B&!gcjL)DzE+S~4bP%EXR*@`!C?AJ*f1j1`UR6HDc|h(gJ5{x*rttB^DooEbV5 z8`>dBBrm&7I59%4$X+UlM(`V%e^NbI!btqc-1dHGGQ_kcsI-c`MAYbaVJd^vW?eJ{ z;pX`yq%rw|@II_E;17u%33nLPFimqrB}9KVL=#v$jXCg7H9D3Izx=?Mc~#^^hd)h{ z2)0y2lHXOwCK+KJC83@#wG-LEd}a#y6@0|gGPifh)u-nmXw1F6!0@8jkR)}1%k!yD z!f;>H<$rlvC1=_L)>QSKApgwHpM!FvRKwjs}`S=LRIoMPOH!q3p zP&PUdY?DG^yj$hCqNed6+Pn{hU$QLL>SyMoB8&K^n`g~z8cU*2Sd|!|HSNRUXsq>W;#F{lxmU2- zV+Ne@X%X{vH{IjKmI32SrX8;`Wo|Uo@02)Dl?LTw1+-x@Xpe0HKf1?2N(RvX$auw{cw;SFl-6%<} z-@!ctcgL~Dfco*(%x^r;10DaFYO#r?D2e+h%xZLYTITr%PzIMba@*?92$Di9ud`5@ z$a3Am-ARSEOMviht3IM->LS7=wQo^Cf%zI)<4IPCezMe|7VYunQP-X2>SXS3G zwSJV!S>bjTNwoq-(MHI9UynHgx+3I)_)M9{L#MiQT_v2T!_9rmhEL4}-lnbRFnR56 z_RQ2O7xR5b0@9D?Ib{{s*S>yB`x!@1r;n7BslgeTTj^@Y}!<1-f8 zq;3mzsy+-QKTw$^4J1#)2cJbII0Zu>)rqf(}TtkgFII4GoD(}%t|4n z)8XayjryizLNgm-SY&mmM#qmXXHD%2=;~*}&_Pd~p94#BE8<~fT}6q#K|HjcLX>Ya zX7MhHysh~!Bcz9w9!}}Ied8f+&}0J{f!NZF#+^Y}_4@)*B3?OBZ@N=dj?ko#&{;9Z zv<$!Z%T`TeWctflu}rG4@o^r~uyII~oOEkzm)#1n2_X9SE2d11)u^bpO%GMclwFyu zM$cL1@ne)cm{4l^;$o_=rxIGhsKo1yG;^8v!GW>(3>q-NmK$JL%)R_46k=`$EjnG8+sZCWTr@gD4FPk2ei>rSVUd|0**kW`B5aegYG#Ug9O4 zDX`SKzu%-Vq^zClNG)Kj=F;+DOnpv1(RjR9XQ$Yl({VcA=wI1}{CtGG5c6vv_Nn-y z#Q|&LhRboE>~ci6zN37+o#^0l34fS>%>UauE_?4)XN)E(%iP9}g46+cA*U^=WKaq8 z6v7XS6TScv#U{3JxBKtjqV?aL~RGEt5ePD8mx88A!F=TfhiJ{3J`Y=!kMr8sue zlqe7)C%&NIc^C#$T-EZR`1#v1c7#VY&gdTE<0*eggtXF4DmX$r&iFb`yLxyjZKz0y z$SH>I6I6|_qX9vsfCFrWualKtrA@g}dp;`ouf!*(!{|YJ)(YDPfFdUn?6fJ%@Qfwm z&nRMyM4`MsfD(qk#-^G0EE^KEr1Fy~@}uVdO2NqHx?VzDIz=W$r?FyNL=3JN=!wQ5 zN(m;|Qse;hB9;>C2=It;sW?T90zo04MD8I4cwK1$Nt{Edb`Qu9wk|M>2h+D!y^XrX|C5n-pj1(!2 z2K&LNFf1AOo2p}Jw8Yjj5RFzS2_saPbHuh zlZ1jotOO5P_NNFv@N z5Uxi?2{#XWV{hb}y)5}6S%@xqC0EPDFLOv+^o&VN;$#{gSlWXhjf&X}eF6-B7{MXD zE+@~!QH(U7SQ^51HhYXVESP}{SNr$e9v<(=1OWb zyB-`&(a#O7)~)Wghc);#d07UEqf39Y#0w{@@{ys^CnuPqH=Fn}*BE11l(FD9_%=oO zmOm8vaSR=>3rt%T4;gB){xqxWYC1RoCzU{FHEJ@kaQJmy^E$hhVH8f!yo^hQ&wJs)qVGK`!9XvIVByCmF>LDI1F@GosN8`JVNjpXx!j~5yPYn zgH+%f6-x$^L6VVI@CR!FLO1LDrVDCG+&tg|7ZbZ)2ExE6qLBRM^Nmt?2_I0~f_r0N z_?+0~BnSYIh(I|;4G@~dg{I-+NJaXUJE(HbsMt?}JB&Lug=*r@b8cDWi@p_o`}y9; zSEe4rFb@Muy$T0gL{O9if-TkiHHBfz1h$MX@y6NUGkikoNvHVSxPGO3_qW-K(MZQkilJ#_r`gN^_QP3Nhg$M+lk1uaa6lTdJ zu}CBzO}>wG=|k|vM5tCu9%A*psB=7IJfv_uWEMA`pLCd-ez5Q>w5tkk*0M~GdapWn z`Udeh$zPazngT|8_jT<7?2l4WAo1uA>hmUv_!KZ^y`NKyO1_R|k{J=&{I+G{F$jk8 zKq<^AtUHc7H*iFa&P5x69nf_q9`;aB|BtQ?xb($P~If_;GKt7bv)uf!8{TX3>~Ja!?& zvF7`Jrbx^3A&6x|!Wqkx9x-;D?iKs5#8Ezm$Y@h_da0>-u$D`5ju5&)t3l4}k_Ft;}S;`X(U7U+@n`8uC$$A93 zjT)_dYg;($r1NuULzWIho5CUUwu0tK!Q&h|JPh_07$n(A7@9lqxj%byTH+2+zI=~d z>aUCBGZ0EXqudzOPjB)aNftabo@L^}%VfW;{N~b6u^YYPTGnzqmtVaGko8xa>*B#< zOF|8n)}(rBA&i9m&j^J35Cb-MlYr8MQ+kQpGVVb!jh-iF=6bXb4n;w=ozJl*A3ju) z&nc4VLW;akc9J58UOfUL0GHa46hp5-MP-$Xp7H2` zUWL|q>`o|ypMuo>uQ9+3iUf0wPd#ucC$2myHgA(ITZ!xPbFs>EyT3W#rKX49aCA%o~dKQMh1BGy?%n*i+em!&6+}~G$5hk_pOVu2$ViN&T zE-?{-IZ%~68|E9SfdNPTICIipy_+I+$zM1lDF`pQG1HEWu9M;EA(B24K+onZQ;iBT zUt(vJy&07>IUUy;2;XRRFLyTb0c(Uc3BMXeA57#7?`70vp5l^omgYe&5gOptFX7__ z79j7`1TOyim-#A138e_&J|I1xQ2-yzhGa#Xa;Z3snNm4=IC~qYJw7IBDZ_=i zmIjx`%5H9+ynV3Nn8}juS|gW>){)kj_mbU?Q-`aTXqS1D49z3!;&n)BpOjt^Kyd+} z*j7ao1S1%j+b1^yw{VzU$m<=jE_Ew$OOiZq6j1-rTi?a#FtllOe%;@V_h*#4F8M6zO@E1C{8R7tW@TBNYX|@Qf+Ukowqt5K-F0NhAKxZ^G9p87bm!xt zUzWqE_H9h-d8|M&c|_;QlSPbYCrcI?K^A?I?WBL9N1CG}PHguE+r%sJ89u&Ux4>B3 zacM>T7d^n4pQ(TwO{lTYWb(hRrT{TkY=G>cE_g{6&LpERf44yWis&0 z6>KWDEIfNp$#T82R0R21_l$$7{dUF#?|P1n$V_$585F59RP627KQvJEnFqXjOivKM z0yI_~fz;~GBi|yly3jlZ>16NTPV@qUg8RIr$M-2WrywX3txc5}-0>L=lIuZJfyWm( z$FC2Le;KhDu`sU zaB3|2qqzzWn@A7cv7gwQ({G>nsjt)Zqq^~j#^n1x%*sE3U5|6s;?Fz_;r?5+Lxftd z+%qK{bFrK$A}}S{+Rq;6vDyv+So3k#&hIpSj zQ4Yh8x&4TiCf8j$uRDpV)!!b?2)+g+MaoH$168u|)n@n9`&}m_P8R1el8R{Ei-2W9 zZ`g5}Qt`o9I>spaNiQ4Gsv1Q28T z$EKmV_uQz&dVY?KS^M1RltBarLJm@7;8KU&q<8irIx;9hU}155Uhu=r?IOP&JCn{{ zOyb*TP6v<`LhrXx+qfO0tl4iCXHxHPfbk@Lxn7oNvn$NonjBJSmm0CH|DQ`RGv~!F z^P~bT^Ke$+L$k&Ez`k6B7g875$hmn45H9%yNNO+dCD~t!zYStbArwK*`JdDpxEV^Z zQ|F>$gB8^G5QO^W`_k^%uI$NDe;+)CeW3sdg2U!*r@?68BuYs34-nnr396&$;aSDG zA8Jgt26ljqvywCzC<8X>u&xvA@?F-7Ib*G6^`a{q43(mf5EE zaX|ZKG+R2hU;WC1O`L5zMHU)d3~Q3%xNE*mimNS7eDfU1*e&rEG@=Dis4rmr0N4S& z>q=nL{xW#tx;Z!6b${7(1-PK-^ytWdCJ<+}ro;JN$-d>J_Y%5Z^)re?eUTydGzQu# zmaN(DAs8$Kk&H?!fACZif5Aw5+-={~n^bQrEQkDP` zkzl^`+l)r5umuQ}tIz`juvCD+#_V>ANj-t)3L#Z)(3!H6ht+Mi@T}PbSm}#+Gd zRBMCpi%9uwVXtt`YwY{zca7`sVLFg#R6fFH{&*;%A_%ztg$sv+wq}ln^lGQlh7pP8 z*-I3{qZ70WNqQTnVSXjPpWY#^v0=q@{2shzMr84|jhkBIP+)A5)L2<5O?FmQ*|C^( ze0#fhDrH&7b@0@c3MH5zc1`4@Xi^9EDEZvx!>5OG1 zokEiMYx&dDA5o#2d*Jl?TQ|9*S zs8qd+9*|J+xm2t+Me;`}saVmmf%f+!G|E^wf@|@sDy5yzF_CNlKN?To+kcOw4naj7 zQ_cGdD=lnSO1@hFDLw1Yl0ma^BD`ul7*Sx3s}AQB*Q1H-1S@!X5pQ4vxb1`+u!emzrLaU<8ADSjToQ<+ zZ()yu*b|Q*c|)jBt`UR+VkiqCl97ITbt7dpz8xc!(&jd;PPgdOa5xv`kG|hph3lfl z9(;O4hXKMr*4zhRSv~dl87_hQdyH0*gY?Gg1c$FU5)D@KSABdHfv|rTwQ2TTH9hi9 zT#X$$E)GOh^)4lXa%rlbzHU^b1fkHcw+lxZu1CNo}9=}ap$NK3_xN0b~%5ec0J-8PHDltt20iEV4-!ELxxSJwovUuosE zjb)H$2Ux0eyvol@y>A%NFii{U8`2AZeIu5gq#LNILXk z^!i79DC-8-uvQ~xI&~lqH&gpN->GKtEV*^3fDB9jJu8MgEB&re;MWhoPOPVs;nqxiXDEPHHO44e zkHW;FCUbLZlrpl_83iZ&uq~c@eZ*N@D|ZEQg!TKa)3hriw5Pe8lPV<`u|(6T)E$6u zg%OIBv$UopvY{kS1W>T4+nq|%>>Q4lX_Hx49p1IavB$AA>O@K?Tq#EtZ%%U2V|Y>X zl2w)y`Sqr`N9O`Lr-?!41Ua)w@^n|m(9#pOK*uo^al%7lL1EXej3_-m!Dl2J=s>GUBeg3?XFlUD8jcahPY50pq zDwqcQ5aZX8hID)tk%eS@4e$r}&vUC~KJvYD5CYgCFD!`umY^8JBD2s0i-))11Zzde zAOtJM&To4ayPq7MUx|jw5hjp(v+|BCSRI81dh6?Lk$vvDbKB6@RiQ{N;U=74 zpt}4-aj&!NzCXt*@|I*XufJS95Hqh70HPFsa9VUjOp)J|pF=Vp)k$bF6kspr*r3i4 z_HI>RSvX+85)q%1F%o8UipJgT2>Z%o$M2U|eByyg^>t8%eBT0!{hU+5sz~X98q}Uf zwn`y;^p+Cc$CQeo28mC=?n3-$Hd8nG&Q^+6{IQWvjMjMOz;(N0Dd|(#`66eK5SM1# z9IStOM3cUW^NkylsVU}X5V8-yUM4De0|ZPQ^R*IjKjf;&?`W8`u(Gf2IN>UM0&7e_ zArPQ>`Or{A!1Zu)B-XrhKD!+X%p=`>x+2SRC02Zqo7}C0{ok-hP!+9Lv?cx zhg~P+zdz|7G3acESy@L~C86Sj1}3pzQ_K579^`pWPgjK!#vAnn4}C%xSA?Y{gg!Gc zTBB7@z1C->uC9uiVv0|?U+E2|bOBS+*1yQdzsNAAG}Bcou)MUM4?k*-t#rA|(xRTO zuuFO_B#JO2cwYmev~Nn77D9@Kw5ndSOxkb^o0HPFeo0xGw-RNPdA z{&-#2)vidn?M4DxrMkEjo<17p>2EK>H{T+^e>W!N{h}yS-A^GZ7ofSlHx}=$k*XX! zMJIo|5huJwb9SbPJ`C&bYNkNE!Ad}g&rQGB{JcDcNto!`K_?Fb5}p%)6$MV1mIdh+nx+U_Q0GQ7*%dF5D| zblf@eIw;WGI8yJ45zPvisNv%iCKQOd!ZoN7!?qK~wg9rvnpOV(LV%+#`37vP7 zEV)F`rcp#@a%pwl@XV_189xMV7;cK5Si9&$PbTV$ zbAjP9@*f0>zXe>rd<{cIk`rzT#n-Qr{*iJ#D~Pj$CaDT-XT;7GxM0l_D` zIkD$rIh_o!>BJMKa$za;M?m!nYOqBkus_GHU-_+Z7^cv7_4u!7ZgBImtD$fD%qo!` zg8|_q)28o5YsdhBbsRgx%4q7JFze5}{zdug_}vHi5Y0@x_CXzS+eJYcnFTM*E$x`) zv0Qx??v^K;U5xZjN3WdLUiG(i>G?&QF7e1H}9Ln^~|nRonJPz8{w?p6SV%nInTT=2Jt$66>_HNaD)eM@l17gXXss@{RaK- z&T9aRJSN`kVPCN?KtQWez(D9g|7#=OKl}6iyXnrK{nj$AY}T5vf_P1OKK%78d%_As z)0@;enN7qji(zHrAnf8E1%U*MOw${Q&4~~CIgj3+1jFiR$Yl2VrA!*1YMR_U$CHDX zex~P@xOjgT)iV+cH00VW?OHBTreY%H(zUZGb{p9B(HS|SYtrs6`M9aZ_jYyZH9QTb zNrZ^VhWbcFe%M2>cv)N_&*fBh7ccxct5)_r)wldL;Z|w<1?M%kt7L(#LdM3!+iQBc z^rQIW*G2m3V)@`5Yh!ZbQT5~2V)oVLd(*qe>&50r`7dj$*M+n9->GXd?5cxNQXUM< zMRU!Mm&EtV$>CyYohMZ*n7JImzmP#0FX9NdXOF;#*`QyH)j8$6b&cC2Dk? zJ6h}8+>G8&)em-Nt7h`_h5@Jg?RebBoB95OJNFzLVWqTc0)_hm=v}n^ ztc`P}w(ox)~@YeKTP7dfln$ZR2Y)X0KtNPMOhx zn#B>2+&#c3v-q6;2~4vS0yqp>^LAG;@#|V>3@pwKQF_~;$n+zSOAQflqK_Wp#TVP( zM0kD?vQR8lAzdoz(5^SsZ#yEUJY@@TQETuE8Qv~y0r^$dY)}OeN8Jg zYf1&R4jc94aT{A&JbFHII~+M{MXzce!e+E?ui9|ucDR2SpSjbiIx9(n$$Um{Onyp= zkU9Jo4hb8K<8ad%SmW+`{qg*y+St67D4ptDU?{1GP_4k)5EGsEmeHx|keI>~H2ZMtfwLuJ)^Fl= z5x>Wc8&Xn}nz>{)k}y1xrEqx29Uj*g>XOblP#2>1;&slCy?uk<9kU08>YvruGrp7 zM3<$I$YIT41;Cyc_4IH7j$x0(y)|?!Y0Bu*YO7%-nrVCQF&VlPCcln%@$UBtWh3Mz z%3(>3f!~dzWtcoF7f6lG>t6}EOFoL2=0aQ{vpW>$paQ^9|4TqIZ8Vy23O__9Smr(M zSwXZX-Yl2WWKoVSXHjkCB@>Gnm00;g+KzJsg|*I)ur=1Ie1_0GapPaNKj`|a7$Gvj zGaF$z&IZ4=SFBPj$g6$UFy&=4L4^)7`#<6$7A1O zUU+BunIXoU$^gE4jfWl`Xsw5(2Hp~Mtvuqw5@=3g%@TOkhb0Hz6m*ruj|G#`7JD6{ zx!20JU1aL4jg>BYncrX90 zZI_kjOkB_|Uz=_0XNWFU?|Wih`53xF*f9go!K`E!k@X3ckUHkH{WvC*pex6lTzah3jRQXzLW3|u@S>9#g3-kQ7(xe^ce=HamoSwEuec76}L#R0O01YvU z1djL@6%LpfzUvaemVA_j~wctX&>2&zLYn-B^nP`bhY({JEClHs@F^zC7{;ax#DeOykqt)hMZ zH2J3!QBByO$;U=|%|Ulf6AYLBVfpl+`4rTc9W`)XZ(E-X3Akjux5@@duoJ~|Es>@GHMTLCaZ>4iD$~jpICUbqMZT`J zIs#KtTi2~1der(IiZg|OjTKAM{ht2FLrLDvG^&N09&2Q%V|>F1@~$L_bsg7_nF6YA z>}mPnS3+B3>8Okcn1%){wz5!<|Hs-p2TAsHd%tblwr$%srfs9zwr$&XPusRNZB5(L z*7WV)bIyIw^PYPy{p`OD z`a1s@~DzY9akt4Rs1uvS8AEPy;MJ*6&6h0F| zxhyyBysU(B6GkUYy0EZ1C#t&iRpn*x=l36|mp7C~ za#6T`)lb{?xVXv}GM@L?=Mu1fK?{92kl@L?q zQ?9;9%FoE>IZx8}UyDPY8zVx}Ez-(c9_0gYqd8Pl*)L`N@R7Vz>H4wGos*LCuldXR z!J+N``mvvaHa8Ig#WeqWc0CN>tbX6J`$G=2ur=mAccd+O7&v&nip?Tey_(k35~k69m%~_NR_vB2 zt8u3wV;;p-al*=aC2Nvh!Sdo;=L0j9Vu?Odlgt@rfO5?D}h`g)sH%;}HkTtj`^H#nwjorK{&r^sn5R^QnOo zB85RyG)S@tD=|7+cIgCd4Ca|}IT6`z*(=82n^?k_0Wx1fkLO1#8iJwsb(M$3?myg) zL;XLkWI&dfp=Sm|#2Rmq8Dm(p#L6VMFQ*E2ap{lgUmuaL{}?ZfT4I!6-TUEj$^;Q1 zP&rB}i&+}SN=XH$aK+_HAhg&C-e+-P+J!}WL`3PeR#WRVjpWdqgX^#_lN+pT{=&p` z@}_M~wxR0WN-dQSQmV|VJ@3}_o6L@~)hydA{q!ouX0Ii4i%5SZp@i2(3DcJ|7If4V zocLH6_m_R_Ou*eQldTNH3E$gyY-){OdU`E*iL~)7WaNQMYF|H#5Q}>ul>v~q;(DZ^ z`qK)uzmT6yg@5F+v+vL;a>BkpKC{GcjP{JrK$y}{35 z3)6rc5W;95wdtD5Nqfjr4+w$bTP-rqmXN`Juo;lp&&cKjdD#?|wFpuOiekzaLN@U{W)C)^A+-?4S ztYNHgbbH{cJS(2rSs3Z8F!41!#?P9opmsk!EJ`d;TW-IjEZ!Kf7`_-u5FlBn{q*kC46_;FbovP&5}!7g&HR=O|B}86dh*WfhmJ&Xn+U=9x_CX z6%UPO{=3UcL%_nk?0E7MDe#i2|LUO=$-noI62SEa@spQ)K3PT{`oUC14WvVlO6v_DsD5U6gvvBF?G3c(3)b-4|AxjXLGGG#uymDK46E%zgYDYkyJ zEOjqQ>W|0nn&ExyZ0@!|TuuprTPW=qCW3p|q#f&iOG*s*-B0WHHAe^C|zMNQEK6`|Qn?~+fw6@x} z(p+6s{saG60`JOT_OsBY#{Ka`g)pS|iL@O&{EfC#tbr3my=|#;w{1Lldsgq4ng@c ztC6j!_&-Qf-pI=S-%^i{wHULhzW)G$`lg^lNWegN|I_2&&FsFL{VN5zo(-T_3gfdo z@eiRj-+iGs8(FvQ;fy&suEWL#UpI4MmnOXy77a5#E?+}%hPKOx~K&cy==iOGy;myW8lDcI~6kliM>4S`bO zVOA@+H6_~x@B61a(RRQEF8H{Lq_ALo{KvM;{gcS+Myl{pvy~&=%dJ+*fLw(y7{B7Z z9KLQAsHAfqO+X$r-pmc1^UB$i2y7#BXvVEGJ4w`|z+Iu4HFNp7%V3n1oGx?A?sZtI ztyoK~r#HIxgth5V`#g)>gXi+RgQc!+<*kF5I#OIY=}dF(e9+zgF0y27Y;`4yc1(Pa zL!l;p#mQabuU;+#AtYj^?m84aIl{Pjzm6pDp5susl)^KRhp{I9fMiZq`$n)m*L8Xwe%=TG7z}A^mE)I7bJzRt~*eFyV} z1uwPFzxSR|75)gFkw;3KyUG}@Y{F1`l7ZuFRbLS09$ry@OXwe7a`$(Uab(%w0y6D4 zUZS1H2zFYolN_$w!}iNx(u@3!_b9c&&Pe?MQyL1LGQKepm3`f?hn+)4k;&7SAe=*x zkW+h~uf{^fBVX!A2ax*iL4TjqB@aXid1iG)TrDH7xEdFpz5yh11}v-3QG?->XTs6# z^bJ-BdlKI{$QAmRfGx(+kH2x(SMr!_lBDkzm^{V>(&Su$X~6W`Vk)VA9Oq|VyNst6 zP(r0mtzV0)Ey|krVbzdXlV<*zdWN4%UyD|tO0QR-D9ePjdmnfPo3pfp9(L^BEbY!l zUsd#V%h#Un4&ZP1P&J%HOdXkC$(3vAa*%3yiXjTBTAUX@2wXHkgXN`CXVopTG2RCKvbOh9Vmkq5$a-+H*@zXGPX%3GoRp`t4B+KOe^q5!Dy}VmW$@c;AwT)JH6>hub zFGJt@eQj^wdOl$H51V`+mJ3hyCY8j%T$hb>?^Ss2$#o~`j?|yQn+-;_GFSITE~j;? z!rFR+{xkpjkEh1J5?!>adk+wH2Cs4AV_hPj!6scG&leLkIhLZX~5U&ntEe0G5;kvccHRfCPC2kH>4|5`tf z93Sgn`81tcox#A{erRY!MK1PPPex5XWI0O6!oh~KPJuvtS#Gz}HMBM@s&uTaZD*#& zVgEZPMrQ=Za%c>_d*O?C}D3*AbBF3w?CC3ZiF*@#Gn8oPNZ0z5Hd-EuHVc98FZs23|n zDQM)dlZrfo9CV1?P`I4|0N-w~pvg7UCYY#cAKS)ppB39LTHdehUTDrp+M}InHBTqH zg5AjvXi4}zvimHa}~y@+O|W)M~M=IAP8)Acg(#tLh~DBGL% zIK%4Tv$`4_?DhU6B#iW)&V$=!bjK7TeR<|D^3q+X&5w=9TTIX{1l_C1tSp5D%uK4pEkM|=R~VIrbVlM z-6vRweMyyjjRsSjIhGzp@?U>|bd*X8Ek?U+|Liv8sB-iqz}s%$e9FY*!cYd4cScimW*ND!5o|JHpyfn~o@fAN`xj0($g|le_RKYkw!*>~2!7Li~IPR?`p%N)Yp^ zgKGLa@znD0%5iF9Thp@ZRP!EH*LEwoIXy*Ei}A8vg;wGZ8^R3+*pwTh`YmzoFgsdG z8@t{$BHUVbLD;y(4YSuI1=R3wI#~KBz^z@?dP0?2teuQ;%jmssH4=7bLYT2Q zsU6YNoJJO_U+uKWm5w2t9lZl)(77kpQ+`<23ZCyc?ccPsvA^Y4d@2YJWpSyR9M=xW z5%#{)s(_1ntqF;unYlpHc{eSLjLQtDrf6gfVhM24uHkb!$_Eo?{T-`TpUwQLEAlMI z@rzgz>m<&oiUj~#;j1?4zJAg9Bai%@NV7O}tVXJ_XJRT>mi>Zm7Z++%1^`Xjy;qsc zh-*@i{vD;k$K0xtL}AGstwax)=JBVU0DwR_x!Y4L*6&{Gjw&UxOsR%?D;GdO4HZh@ zg5gdW5;#yIp0~1X5`hv{&Ifv@yBPONYYYmVCYl~QF-$B{1s`58ltz}l)H*fEBdxZr zN+tG4Csdl};5XjTip3yP_e6>b6l9G|b_22%QeqF%{y>R|fIOY^B2#z{vD+k*$R&Dw zB?(Iy7xa)rq9$C~M)>GdTEk9&$W(CMWagcY@1}>_nLt@s_62P7mWN!_e$-zg8!6Go zqC^g)aGd-yuLAbFF2c->JQfXSi%<2ro-X_6V~us@@6*q4&)xBC#Dxzta%5&2bbs^Q zGZX7}t6rulkY-BMfjlheUijjo#uMQk+7FyE5Bfli6W1Y6F=`HxBWzCE4zgFYOS*iN zLg7vIG!yF?h>@0al99F}o|T%F%?N~cn(YJZwDQuyl2^1GzI>EAVN?j?FS>L1@gocg@;RqlO-yakZWMsv$hmdp}K58g5ez^vmTU6k?WW$#~=rad66xije5(qInaI z3*_d5(4uL<6uIKJ$w8jZ;<2HrV{(En71myv49RB*cYM89jp2 zyWO0oIBvmLT&XoDeyO%U#PhZxcu`DoQLyZ^Ov21vP&5*KcG_r>1>>r{zo~b95!qM? z&5RM4cY(S8H97&pa}YZ0$+^?qiyuo51WXZojm`4qY59=N1PBATv5^E5P@@GBHvi*O z3&^5ktnoS{Hfxjht)jWWOFq$ZIjjMO>vsyK8oWSFt|Wd>!oT&@ZApc%v~>;| z$JbKR-JAA3VYnaJeRS${!d=)iYivu@b@*OvIa68I!Ndkn=JIXcyIG!Si`1}ECSv#q z>9Y2P9(&idFvol_{2Bd@BrHp3h8pH8@|@Aj*$cn{M4zR~?xo72K(cG$smbjc-H49T z1swUm!w390hCWDoK~TH9>90MBaI9&(==}=@pT_N1n`*kE!Q=~=P957kSmlZ|3o0OQ z$Gh-5(e>E>wFFILqKJFWYC0j#t@nauhrmp?O$_c0uQvAgS81Ua4i z`~Fdf(IV-$J>g@S@9zD{Jzz}ot73Yt`&95#H4lz%;N22 z`Qer>H~$HYwLOnJEMx6*OqanJCmTX{$H;02|0hEY)FAYCkqvWL3`Gq<4M@k?EBT_h zrMP9l@8(>L1>63o9EotAbwIa5x5`G?#XW5O>z4R`-kQo(QI$TC2T}miw+=}Do86z? z-{o?Pppzv-r0`wzMIw>~a)5Gxx?O;F{XT-ft$*2+pPYf5f$q|(w!hDqgB*kI+yfjJ zqftXpL()}Ck_mG5viG{CUnqJwg*k=YsUKgD$6BHL|0%K%4vYS%9;hDas=2h^T?L{9 zVr1`^{*vF5-_zsq0QeH56=Z*xF1b?*e$D}o0XOVWPZ`@jo!@7zt^fhD#w#0>dtq6% zL5Bj4RrWPmHS3zQ*6i+KI%VWdGt_lRz>%W1$XNIAo2j+-a|R~1c37oWh(Y4j_$u5Q z0|cfb#x4;Lk#kpGpr3Km2a?emm0Ns*6P@H6*dk?uK;Q#(i6WI|e#0xVK@tcNHBb@= z)xri&QV-=nzbHz#X0J4@&gfe@%1KucBCEY``5o#a@qFZ$!r`qgS7r{pMRW81%k)o) z3K|lnR#pB?ea%BSKu~U4LR?lrDOT2#+Li`lvSg3oS zfWHRr0u{wyp;3aP^dNsAO#%Nj+4#C^kqS&U=^ekvssNp0xrZ~x(j;vzN?;WD9D5-u z+M0~HF#K};m%|dH@2uI1)!~%25{C`egl!1B8j86?GNqSnG%HT8^6!rZQMGd&YE4B6 z?b#s8bGlcHlunc4NR`bil{^z_P!S3HIjrO9vZXSA&5Cz%)e%!dbnlewWUu|eGW&i$ z8+ESwO+UYcyd?;7(;R6!LCgXwGiI}Lv>k_nHqcM}a5EpZ9PgKpZDlMPiBR-%wYwWz z%c4P(J)TZfM^6}xu}2pRL52oL^m=X&%*tYt93Actj=~;Hm7Co%z>otZBSY#@8XD_R ztFj{Vf(uai*z%+Ol^>U1HAXvdW>4TF)7BowZ?&Vf28 zngRWe7wp9h9e|+al;WjN4Kb7Prf&l*S7j$};FB^CM>-K4VuAT**IO@K$_WB)K2Y~^ z&>21%I0D=ic-zgp4HHm*=%VSujb68`nq{2cfVniupY)e3^`3x9TcorNqj^PEFB_6L zsh&F5W;+PCx|+>I-Rf~L+vSiXg{D0cVyfT-Cr@$(=8kvz(FBm$gT^!x7Z>$X=tX(d zZ)l9ufh4YLSY1nk$NB&`YQ zhy??8DrD>)Gelt|=cydU1?#oQ&nu@#hPVv!RfME#@|(Cs{rYCPIinAM7IkO!Vt%)hc--JDzz@AtLZD z*4We|HU<-v-K}U3Qy`WB$6g79IS=9*hxG{j+GUVP9*`3-DPrYuoHa2OpY`|Fn(KZ{C#T*jV1n+gGH(sk}laMhTNZL}HOOL836v z*})+(3k?GygNpr!k?0Q}kzv6Jk&R{hhlqpvCQ4pAX0Ku70|U){D~4sm(%PMhD4=6K zTG$|maTi$zLAmP@vml9QoRUnNQeK6z-N>>d&D+}sdhL&)HFUIhulOB+z^{Qq%zh7; zocJDiG@W5DX}sh7g7YOZ#Jd>8>prqcMyvFeiyMbhS-~VHYO(3MxR+mFUpq=$F^Hb@ zd*;Rp&muRSQrOEaCns z85WZEIiHYmNC#ERjS%T+sC<0GjG|JJKOJNWGtF7nPr7kt#=kb}BQQW%?d9pJLMw0^ z#8USK|9?*oQU84)cQJEzF|u{AH2ODosGMxehNgJ#ul`LQ$9#akLj?UBYW%MT|I7Lh zerV@hG>-AtM>X|pe(E}WVl`t=mW4tekP2g76FVAZu5T}o9y+f~(XFSCQmga6`wWDl zTmVdIK3pgxc`D%BIalbJw?xTy&wDN#RG7ID9O~d7B#s4jcc0R=jC}jyvPO_Sf0x!MkX~25zt$e8f&CNnG>O zdwB&ev~8Z!HY2I5C|b4ifa?8Tad@j};0miz4ggm^CaG}O?&{9}m&X+OQA?#7{o&d< zT>SoR1lsznlMcEYT!u<)?n1p2Z?nL44Uva%>N&uLJHtJ^x>3YYh5>9BbB?b33&(|o~$A`?oW%AA;h|E`IQ zB-DQx(V;_OU!^G0`;ksk&R`a8Gi8|?=RwE6@dmWY7Bv`8;!<}F4)!r!JE4FYrao%? z6{i))5}C`TrLYsFVvtO(M6~~kE!iy%iz}TJA}m&CK_%kiGKX$k!3nlT?(A}U zA_R^ihEzylhwE$rIzbr=$TP9!8QKeJ8aa9nkTb?Ucl{|#?<9wZq{W^-i9RZg_M;N3 zyw!n+W0^Dv#{y`K`L@PR1g@sjn){E@?nvqfdl12*!+_u1?n#xfbDf$uhMvh3SV)ev z7D@_uZ%Evbe){cYd3BnL*CSGdc)gNsKK18 z^bX?ocCu~safxtZub)DU%bjY9Ee(Z+%0W;h(ygrBCth$xe+_CIPSCUJ(yU!l=~t}L z%a+Y;9#MwU&g^@fmFvChSXAj(Y|vZ9mQL98 zs@KkQ-E35cGC0dTtmdm|E{U1|DBDSkq?XzrQEQQ^SIErPId~k_XQ-?l%Iq3PtuI2pF?zbL0zxjZEmnO zjCM{`RtMm)^<6Y(;*Rc_@gYcZ_(TZ8slUpjoW(71Cuu%mCD7KhU zPeUSEu|vqN#iGAt++h2H0CMAT1VsvpeFKsz z;OiL7siI47huLK$k^9vU=(IM$Q7Mu(z;rB?^LrrhG}nNFhjm~}g8?_Y&0>X?#hi>F z)PwNR!__x!1M5{-fLCyz5V+WAeBqORE-pW88gc$0)!uM_(Iq~w0%W~w0hB^0>M zF&v|fL5*YkV^q-zn|%7d?9gpsX~-C@*L7asv)=-?2EB>n5tBoH`tt0yhv{9I*+oh* zEQ!xf8vVSF`1TG{Fa}cN(wuoIYenFw2YA3V6TY0cF@qc|t^LusU~raS^?f6!VZ9d< zyw8$9do^*KAwa_R>BpeKu`RxIN-`<5Ig32LbcmTVo^(oN;&4_aHGfjE6iJY@L3SJH z&mKLZMgtQ$T*(hj5FAv!u)CIW)8!bl9{MkPCwm{N{cIF$mEU8X%L`!7pbKD{VyMFU z==cqv>cLTMYyu{>jftRJ@=1eNWb$Do61Sm}>k8R+D^+rpLq3-2){plxl_NR%=^5Ik ze+qqPb=9n|_(~`T-OBDpTJ6VWjY--YC>>mevj}}!QbI_tOD|QgR_;-Faf>k(Zo`^_ zr$g4*o6obfT;;VFP(9r2My_iX-xV(6j2_1*yJjUm;GCo2hLf;%twXcx?UE%p>FhDF$G1pPz!AX@Tfu83nwxW<6x zS8w$RCxC6)v-c-|<_J=97jpI&@7#3x^b~5-pV!07Uo}2X3IaT&Ul)!~h6d8!4XUet zv8Io-rWGgVtugNu@;9}};(4EY-(g!am;$FD(jb#l@py8=OniQGO~%&I#L>a-@TQe;5ppCzXbi(%dMoFT+)f2;QOW`_C zkwlgq)Gy!NM(mj9G}g#q7$_+u@>4HSOQ?I#AtW588ypEy)FTKY1Cug;fSdzBO`bT-CU5eQXF5v6*C2VwM z#&H}l+q*~7V~W{z6td)6(=vI@IGLaC+=z*NIV$z|Q zY^=G?f;m9Q}Ix2)v_QNzG(=>%UOl-kQpJ0Y^OfOv!zo?<(?@;1Bm=`=m z$z(EM2TRk~_1T~)XoOHgv}ZV=o0S^r<=R!=ScIa|U-IdZ%VO_p&cL2C)1b;j-a=pH zPB*g#hRHovlhEYa+ZFY>q>vKCE_wf|>tkyYsRT-alb}aDI3rOXh^vAVp$Dh|sQ^m} zq9;VXR0I@*#KCZFfO1WONzgKJ3*c-?M56{qM`(+gk_@0gCr1RNfW)eZD8t~%fQm#y zrGWSqiHC4mgzZO0$deh86sdrak?$cR$3#ep1rVb^Bmz+Z`$El&4&sxXA`yp%P?~=G z5Rgs$oTX_f=}!WYg`tz)In4o7@28#+`dn~ z4ve)6=} zaM~yao`n5S*Y&?0qIJq=h30qrgM5mKI}x8djl-%3m_EKAm9vtnYNMynzryEG6__J| z))sAu9Ti)^E#kAo5&`ekFd?agH?ig@TNFL)5(s5<`+|1A%z06i_OxL9Qa%^_FBl

)~Q#8c&Ufa+s-)DIKCK7}J_aJX7xV2~`H`kXQ=57Riz*F9YfT02(P!W~c^VC?^ zY88lM$NVOvol5KHMRq| z$?Pbws4il3B9qcE(mo2x3qPayp5)Ac`%V!NKznj_IuXyp`Wl| z9#g5Tl=oE>x`|v$e-7AiU=BoeZf~d88&?6QA#|pbPilh;>h)L4v>H5({)<=25~6R2 zQssors5m0&ok0 z_h{@@BwfAJufH^hl}ubjNE=tGw>59Z$54W}%JB5+b;U(aBR`2T+R75Ome;nZ{TmgFnUHNWG8$uOaL^~qI|2VhooD>z zl=kBEnD9b)wN{+-B^j?d%tRuSOqH5a3LQ6ZJnOfz}^@f^rm zCvdP(U1?Eg9@puWX@JJ(i~i}&e)q64ywt42`-9iG@FHHldS(gnXj!1k!FX-hxwc{V z3J=fkSJTc-N;Qky(GMCZLCYhESIh57@rpN}C%hJs%KH_#nL@1JXV_IbtRD)RpFHR> zpwlcK_BQw-D<<3tY+WemB(_c!N0F)!Z6$cC6xHEYeF419lg{RmITU*SEE{YIj#Kd6 zJq!+f&iY-hPB9>0iRbrHX=?bwZ}WwpKIXUE(m|v<>~E|X@>oPt6`F3XZ8p5k)u%_q z>Ssj)z0yUh#y->3s=NMa~3#XB4~R$O4HsgUx;X6^_Gy5DAsgC|)eEfuR=o5el&l#D)*Cfqq9cR)-zcf}0XtO2MK66m$pv zftbYoZ^kanQRUcrC$5Bh{VtqGLIFsuhU>)Y#;)F$mLS3va=~}H!A7zo!LMvaX#I)+brgbQWYVRykKxwei$BTd zTF6(QZ=g_u83W!<+!3%Ry+ED-SbSfqcRtk8yZB{*BqlpbOjHC$=$q_aG{5*=G!B1L z*@P9+_M2z$-s5n{CCu)AiwKnp`#d5Rscj*4-j$fQ)8{Ik`Gfdjd_0B)E$ftPSLRsqPDG z0iCZ#?#;_n(G=6>xwZ%{+2NxUrgNnEA6N^25Ye<0hEDtvJdt4-)=U1b@-W_VZNbjp zjC5XV`d0suwaH;HO(mDVS5ym4c{Wiu3YidWlKg=#Q7Es)qzZa`JB=GN)^2>(((~ij z4^}%tEaQ>&;rJ%KNn7TWrv&}={9n?Y}tNO%z}@>0s(av{ttxcKN|c)i2h~$2O+v}F49K% z>aLvpa$s;5l(UbGtT&b0vi*k;Reuwr zGn(oOtM7dl%%8>xBYGsa-+>Q)tpd3zDqbE7U+vr9){YS$SJ$LQoer%*gqx>Uv#Mpw zp=qJf84ebF)Tm5iia;(C@EAW^=@u*=fK0m|5`ir_};>c06*FkxhJ_qPgam0 zL?SDNo_B|ex9!aJ$MO`XX1Cy%Sm>=sd?S;{lKlxPW{G)K33FQ9D=aVSUCvXoGeLTPvMRz`t#g~PdpggdQ zX7OjXCb*d0erNI_%3893t$}ekCS}48N^}dRY$UNU1mhY(&VxP|8{pi82Hfj*Jcz_Y zqE5G#XP5E)q~}^SL(V>hCevC|Wg0Y%%6kH){lUZ>EC9D3Z%RwxYo7Ogh{3)=ZE`Y6 z5^>q}R)H-EgBM+UXb1J@jSq$WP|DM!F_)J&Xc(Bm5%xGyWz3Wx5+q5OW55`8^>;8< zct@~@sm++FT+_poZF++!5)W2>Yc`3>ceYgf0_8DMt$PyUuEJ-BT~T)N1p}{NmRtfU zBd9gfKTypaYG1*X4bVKj3-CFK!?bJw7exgRU^d+w%D6v08INf;mcCZ4Nrpc@K|Q`$ zA+~o^-i$S!!p(YCPv(mwUlp1gNj8es8`!xATbnUvK(tG5;oF=xF!%zP zI3OaR3#FYqRV>%pjF^+>cU7qgbl}k(kwD@x+`l@N>RK(^WaB{uF%LS6r|J0(iEWZC z;-RHQ*o1JN^%Z(`t$a4Cb%#d$e#M(>kk>HLT9dKQM{S8nE6kz&gX9KBM}7SiT1NXO zC5ib&?mG0_!c)iaWvl>pDM)vZLeTk1u+x75e3kC-akTfAC#Z&<0K!+6spc%C(Np-6 zOb#8EYxfr=_u7h98@R2%d2g=}Cw%1cHB{e)=AB>IKLP4mDn7x5CY9_t+=gp5W3VGPoo`0;j@ zzKx%eV?;Z@BUU3&eNj!xEgdeCGMARrZW+78r(NFk4?9y zCbkc*?ciA=w~ zy1yi{D`(1NNVnr4evZ}>zr}&G6~lrz^*H^-(UUT2mff$Ct`3s636iD_lJ`$lT>-`I3d;O2j)RxT$rtkyU~d<;Go4D>(KDmI`9GK9v4?M$=|A%L!$&jhfRZWYxHV^x?84r%s4VnTH^C zrlT>Xa%#$|{jBHZzL1|~pxhNN6VIgODY_vs;;Z3+uA=DX2jZ9JAUhTwNKLmOZ zXtvASD0%Kj6nKTZmOP7G z>Qy(8JJi=|uPd6vtInIQ2AbNmt6Op4TFupPwvcTS*FiVoF5sqri$h4S!hq5GjMFgT zGk9GSy+SA?J)*Ulmie~|A#7$Aa9bC>{NEg8$eLS^&l%|-6=kI9r5d=#yXR7HC<>%2 zK_^sVrb3x?DN2^J(XbhAIHKe+_--@{NxSvrLl+0sBkYvu&PKw?&XUH1Hs6Jxc96Xf zBcnb|m;BZ1xT<`3LL5+AC#~ixKD`!ykYZ`3!LI{2@5(9qwx7KCWk*K$R1y;5#7dl^3q&9cuNpp4zy-xp!YxdAD?N4}udF=+^0u zC^~s^WiXJiHgo4c4nJQD-v8$0LwFgfO`4_&C=dEwNkku$l;S1yGve+b#&;D0ufL=c zAq1(6YmzEN5<3JYFrOltB?$El4H6e}@dSz%%yA0T)JK+p0sz`hFrHM6*jJ;6qBS8U z^2@Qm!sMz4*1L=Ju2jxbktD(axJ|csc4d;BW6e--#rbH`j9Jr!keIE`F@)-zWvKoIFty# z?xTPwA3=VvfRvK{pcm4oMe0x~NZ~KYFCp4vVit0k$b-OX6WeSTk|6{yQBJMV_DAyA z8iC1T3k3~dcAu)~|BCziOo8h5v^)pf{|OsIhu$$|EMPF1dQZ-v$$+`8n@g+dLpMrM13SF$r-d{qqXPYb*2-dYP0K$5cGngb~NqFW*8i6%>Gx z^+%Y?E-E-!#MD8EiVQ5Nl!^-qXpEoY=FT|SbRt6?waHpULw>vpIvg6alTHk_dUwrv zyLdB~_=V9)h5_JpJpHG1k+HwnQ@>YZ>Vv z8Kq^>H0Sn{|;%80WIRng(uv8tJs0#`re+j(FkG~?lk5}NOng}dg66)zG zG+bBb9)F5?&}z_kXyxqEKHtY6fzaL0vgl8rk1PU4IQ@{4j=cB`i3IoFf(Ndimy-Kx z857@kEH+O}Mz6W}&vqb_y?=`8ce!rr_Bdq6^z!ggyXKJ7iEe5jQlCpzsaNX*YQ3P{AFxi+%7Z zx72L#o}d&%$ffvrT*z-(scW*0Vx%0Hf%*hJ*`MyjTv$o*#2wf{<-|PMx$oKZgGtky zraKh(9GPvACw4yhbQ6mObnuh^R3tva#LlRh+2dPc#}rihn*?r;-fdnQ{3ALBJDp=4 zKJ~U!EX{PR|Ee|(%v)d2E2a-k2`KNmGRM}F$L@M|%=;2I0}opF#{M9%82Nl^V8A$K z{p{79v~$w1c*U^s4Qqz|P0X;0qdAr=?aG&}K4z`Hx+S?kxGrFr?1Y{{cdqVetrmV> zLPK3#MU1h(R)t_zYaKIvF6CGCHzQ^bllSYDvemuYEb&@@Zr5dTxQqUtR3;^W1LRdcAeS1y8>ABDT}3=!|~FHiyej zvKo84>ONg9+krsVMmb`_B>Cp_6CcxFvcp(dJ{>@0K^#=P)EIuqjp;`wxmk$!dp4H4 zqtMaHHqAx8I#nMldBCiP4jxbaiAK+?g9iR3#`EVg*Q$&Tuj+-Kec5yWtd-eV`jYc3 zKV(X?vYET(AH!LU$bRM$)@NUf>p(_~T=Hl^LDbO&s>mU-){KB|XUARTyuKgrB=RY{ zg8q#re7VzV-okRBih5xtZ}Jds$E?$8_o?I<83C`BQxv8h~WusOk5;80iD)$dS@lT^kH#$(l(w=7Bb%$AI zz1l>|o^TiFbJ2Dz!xDhu@BMdyvAUI;@-y5xuc5Z568GLZ;T?uklm06rT%0KpLxa{b z?6_0EbP@Nf54KGCB{jQ*UcuL}hp&PsOWDRI$u1RjmGQ@X-B3744Lbn%Nb9MI$A zOHY2iS!aWLWQZdizpx%>DD>kiLZ;m@Cfp)L(}Ca$zp9`96kr!~vTYpc!*Ks+(~wWN z(#x7}1=WvFN{h#!V%WI9``kELKU#=Zg4DjiRdSW$MO>qk9R~{Y9V-5QDvl2M4|eWO zw#7@Uze7v8{=oC`9}WgQLjFE|tSd+5DF;y@Vr|%YcMGr}V3!1iO&ILC%-{18zW$X$+(w(;xZrjbaCzLlc5C_;~M)KhRdYcsp2f851_~pAqsnI8V zCdGJQphd-y0@tiVb$KMW9+84=u>FKs@ksGr|9s23F@fLt3;AD=aGSZ4Ap};al`=*wsaCIMlZ*&NQkEaXXVg9Sny`7GqsW0-M(9@ee&Z1dgOb`gR9%es|2c z(yDMP>R=4zB{Z9Vs*TG=(2L1NxSx??2(<$XSC4Pw?n__&E>X6zv3@VHseH`T(A>1^ zs^)kMTWZ1W+;;6mB>f1oxG?`r0R$0AaFIj`u?mXSwFw2CI*eG3f{K*t*mn`?OL|&u&ujRuQVR3jDBdl8Zc=+ zv9{-W`h@l1MQsjP9YyX|^?&UC7xejmbSV6X+_?X54u$`Sg3cBR;uXF{K}DWG|GPus z|M~cTUjI`N1UQgF`RnuTQ0Ue3Zq$T>a-Rej8J`T44YwhrM3lU~BsKmE|8^K~k{)vE z^7UC|mxE>71`o}e(U>CV;O^?GzV4TI&T{pN|A;ohVtcqF+|D`B6l3-v-l(T6PCBGy z$JP*Y^TSC=@;jAPVQxbLDwmc?04n}acENYG*!fl6y z2m*2S#6${#J#Q|pF$a=`VP1CxWL8YgNE_NWv`6omzL0og^}1ML1X3e=oU~vsSb8ZI zHu+^UF+X}u#8@cbho6PX-e|gRWARC|cw?|%cI{FquBO>PRIc*}946*(QY&pdiG>we zYmzG;FnL9TDd(ghhPnle>nH}zVu)OzB$C4V_0<=M!5n%>_%PX3M=&ok6xe#VM3py1A-Wa=?4$|= zF$;`q%ecBxU|-Gghdx(cC}w{jpbu_irQ$?vSf5S)(%S!{uk(OstNr45Xzf+wt=gk% z6C-xfqBUx7r8e=3)!G%cYEx>Lq9|(B-ULOBnk`bBs#U8-?D0=t?^~@;KL01uw_}vO1D{34!xJ0{3uTH~056y>4xg zUm)@Ib4lTy7tyTa^b;@YZ=0VQ7UAapl~9ymYp27GOb3Duk=Y{1fN`U$jo!NN6AsRb z2}r7jr2PUix-&;H zzzaRc*02hkMPz=ZrWw;!Y?le+yDQ`vOLtnVEeu=TDnBQEB~zTcx$DvBHFUZ01oZBHH5=#CBWsY0+^5GXK}-I(ja_tbKqh=}J!lgi zNO{3vjpaUqXvz^_8T6^ejcvDl&9rxg7F&Mc3#3Zg{piCzO5T8Ggh?-?llgf;Mu`I} zDK}WS?`HS1=T+%f)_pfK%fyiHhHjg84M&i6Y0#6lW^MG2F@2umj{M3)Q*KRqrt8~g z8D)aGMs?t#5;hg*tw$vy_7c}9RE2$O?$Lsg`EihuxzTqrGu?Q+uc!GO?NKhsnO)}D zQ`M=Mfg*|tKji#p2*UB#5(Wx&4m4BFhB$|Rn3hG`ld^^x8 zQFp~MaO!5(c)}MNI{SLEO~DC{d=i3(#~Pp3aWMoy*c3We`6hf$;MfS@jBE{i*#c&* zGlV>0+Iq7&h55le<6XWES`*cU{kY`2+Sb!zQaBV%R|pwQ_`gQ)jab525?FfnyThg= zopyM${pnl_-jUj+Qd{V?d&wS;BOD%`PKzIbzdys@-UjE+Kh6EZ>&;nCmtNV|FA+~B zhLfw3uu-zOC}wu*G8F|r5t1#zF%fwq-5I6+gXAcv<gSK)xf4N8_`Yq1iU&j0p zwKm|NY|Ci&w^!AH-Wqfs`sTHd4l?CrS5;hxyVBjoirR_Zh}rXz5wN!8x_$7TyhCtx z7okCjgt0?lRd+3TJtT#Sx%BUAyJ_``Z?9){cF-}ed3-t+s?15+&4D%!d5KVjuVcCGL9+g~Y0yY|$N+8yX5#`*7HT}}zZw^8mh&3JHm${O^al?pydR1ba zZb3No4BHjW#9oy-|4`AOQX4Ble6n+!-ac8&(8II`dlR!-8KiZDtxfKI(QQ~kTK3hF=tKxHt33eAj0KfX62MeLRd!%D9&YAuc zH^N?qoBDwh16_Yo(lbRN#*GK-3|o4kbQT&<;^dW=-L2Xc))Op04X{s6JrMnJ*pZo| z+^)?r`XQ4wv?`V}FEqvs9GjdQM&))(=VO*cSllw_q2#Ry{oo$M+#SONGmSb1j6HT@ z9}$4oU&~Ae-!P=r2nS>G$aV$iwF`pS$0;a<7)g|hXUF0S)Sc;+#k3Zf%as!LqYBh{ zX;!-UIA+V~sEA{aQmKqy#SMss1#y5k2GuAyFvB7OI$^DbbNJ01fLy?9Os6VLQGQ@7 z=g*wx6ii3_hEdijicu9mVXQF9?P6eCU9x?YB7DHT;5u#6g`I-&C+m zxIT~yx!w!fopvgwelH2Dcrh-W6-$c7JZt0 zTDA|iORMf-`3{wcpo)WVy0c)UmW$7qJ7r@uc3`MNu>v+*?RAksWmVnW*SBMWlHmX(cwrZ(@8f4@11N6IC+wNTKsUt zLYdQmnQ=Gs&XAz=cyqL*+gg7NbRs3`1$IJP= z<&Jl(>lawVc`c-^C3-S>E%)%VSCv(pHo?p}LTrmAHKr}IR2J)`yf6C0!gE=-aa?XZ zVICX~Z6|;)xGeh-$Td%DEr3;Jsh*eJ6~hkNR215C;L?#-9ECltu4I(1y8*O6AgjS4 zzD1UH%XIeXYt4D>9bD1)8Po2o>=iF{5Shn)nQ1(QU4qH>-g?EVmE~^1heKID0eoH=KKCVUw8F`y#3(I8 z@QFgW7&YAGL`w%3q&o9*G;qJYxhEgG5pS+elD7hKY)P~gO*1j7YbFe|G_F9-*7b26 zBVz92-}fc9gr*85nj-wBHE9Oy=eq7gB#Q2P36nsm215rQ9r8B~Wp>o9m*>>yk!PbC$^oZEWRe z99rzP&K6FeaEn)beBr&&HkF3w$@dns)QtOzSDZot9tJ&U`?$7(_S@dowrvQWvW0bC zLYW`4mf;Oy2DNxAI+_jcY+=$TiZ#U`z4gKc&K2Em^1uhsRZCTps|2+~B(d%XpXVV0 zLLH%+F*Tg6Swq}gtNE+m(cuU3TVf20R#J*zj$NOYL@#>wtV81#57_%-ql6z*;?|BS zD#dqm9;vIvmqMy-ggmn;ZP!LNyB0~Z)s99pae4Sj$r}2*Yo0x=O6760U4V}$ZVUcM z^JXl>z}P4LOobH}f|wnRsmDruXpr*QX<|P~ImrBKS14edezMKkj<+^WJM}FGo&9$I zJDwZ4u7wef2f{eRL7@^WItBF}kfp4#E_z9Lc^1*6U0TWLz;5fqvY3Zs6GICuwQB5{(w1^>8(k==-E@a9w*IWs z4fyFqv)SVop_R>jauaUQ3kWS-^z_gPIzs1!<01=wXgY}fh}~$GAyOXH4Dp2niZP6@ zG+=uW{XDzbOz;hhmx3Eu<5fKjc4)g2ra5d~RM=Es$8~bMdwNwGgZfx#AMz7EQ`}+_ z(1d*kCp?wDx+^pUc?VZN<9rq$Wx3>K2})^VOfi87oAfPYGek|jtcN$R42PrvddXnC z5T|E%o%-a8>gNkcLZ8#$!_mTPBG+GG81e~Z7;^Vv^YWXuEd7xpy(SUnm_S1xJ2xoLI}n8sy=v7P0WO7m>Uo1c$tb8x?PW2YcSXdL($H zcBFDLmA#KAAbA7O@l7=y=)3_veD?}@5Ru~ZLUqWmd@xQw*8^WTl#$P_l|G8dfrgln z(1EW*h#hvnMWmJaiJwCJ^C6rYCQk_-G0Srpz4I{6zN;dWTo{okbsSSVc+)ZG!$KC! zKSQ_l9yOiI(iI{Rt&=<-mj;Jkkz=<#@koO?w~|GUQ;=>`iMO;=mvOu&FeVge`S^Bp z#eU5+@8A8Us~uz8xb;q^5hapQw*wB>jRcLE1l!j;-fE^$xpfkKA|ULbGhdl*PXuxQ zpnF?w_Ix9Z3I>IkcVC-9|No>B{fj%7woLLH4q5){4^=@~4j`I1?|fOLBAc9RNUi7XTonbfYkqlxGDSWv zYe9GI0Tkn$5bBPe@JqpY=c212c>%!=`V)exDEWJLqN~z&Vf`)ak~Oks+yCo5RF$#w zh8h^A5r0~%oYx$?7#HZOj-kxY^+%yINA{xqzct8ymw|5f`2}e(8I2>qk$&~)`LE>i za7X30oi~)KFV93UIFL6MDce)a6lvE}8v;W?X>Qoj+)o^r6e& zLjljnd_&nK;D6bC7y8iU^P$Yo^{t@?pgj7O-S_*tLw92Eg0=-i>&_pvOZqOazduK1 zY1<{>dEoj&9lFrXpB^(mD z{~KRvvf{BKPV|Nl5&pKE&=2=2qkSB0+!nObLW7=q_@PiUzzRdD+|9!|ov5}#wdJW_ zD9e6w!63oXEqypoDDFRo3nK+@B-6=5>cX+e1J{PMRA3SlfXuLi=u>{l@?>Q^O>?#=SB$=N z(dtUpoE=015eGb~+;6tN%aCY`!;&T>1ZEfGoxjLqJ90+|!~UM+=N&(j{G~L3&1KN* z+E4sgKp7&7E&96$=l7}Bp@;wbFt(NjIsK~8YEb@aeF?^8ou|qRJIRZlr9N<>!uY4~ z<`y2mzyX0@`$=o&x4GEeAB`BSHgt&1k;Mj~RR6uR|A^DTeSY;GI|!6?2a75W-0G>! zf0tgc>V;W)p3xTiUIF{~0{&#;;P7)PGILbr8?st^Iw{?Qb(EB8wY1z#K!Fn^xlP2+ zp(uq}R0F5_JHtcyUjb`NgdLHJ6Xmo<)`VCbR?-)#gsQPg7Z6X{h+KNzgkwqfOv;vAI~MuD;Ev#a|ZHD4QMiwSw(`DQh8c z!Aw9$$zdi<{Z-00*7PW!<3ckojFI5plHn5m=oP^Mav`(`N58><{j2YFuGG+rb8 zqSCUOLY5dBV`8bgV}XjQS6DR@?i~Etb@EJ*1oVd%!Q$ z=I$v@_WMpAIyigr?#qROO+2C~^e#Ary502t3*fICoLA7S&Iph)KD1KJ5n>BIB_VYF zDsd;YGtN{b9WP$>flStDl|)MS=Y(<4&n(XXTUj%_D9?$2OF9{L44#ZMtzL3Y4|<~< zg0}W%_VYj`hOQ;9Vssq0H6GbY_7sMq_lv=Sr5|SM>bc(B2000M8codAck+m}c9Pq= zJh=$?z7no%7EfFKwo3-LysJ1>axQ?+vfNcsE%E)yGYi-amW=vxgYr(d-v;7ma$2%PmIc_!d@=l(cc=} zqYv|)jO}f?d;?py&$+TId%1ItrPDVBE6TN6;D^cK$fI)`THarwhj?)5KW|*GB!^G^ z?6yjZi*G+y2ln{kLj zcTzs-kX25$5!0l6D>{g?3Q_SN-#GNUY;oZ)Jb&J2WH(DiKy6vrb-KK*kv}mPPq8gW z`|GyL(u3lo@P9rAo3z)NHk~V;cG8rV9c|wL^xruCS-yw9SO;2_L779gxk=9&-!$sW zq%@(?f0=dUpf$pOb|3Cfw-iX7xO=i0{(p!((49vZ`^Vi&;w=D3tN{Up{|}MdySe=j zm6OpS<^OLgM?Hju8qCj&Czq_)e`C%p1d%|9g#VN(fP}Es;ICCwWH4z+(9#QPi0mqI zK0$O8H4Bq}p%6J8%gZ?(^vkyOJe+BbIxkE z@lOln-Z)7308-6W_&o_%9}6#Dl^Oq9q$&BinO8sNGxO#zk@Y-XKO(7kOk9T?@jA?! zha=yj;ci6Ml52EY=dfojVGMn7=rLu-Ez**0-hpa#U-8Ni_ik6+9bc@4{4NinGhxSl zLtz;B)JI&weC~v*i0P-e;x)PcUMp?U>^0G+{-)K7SQ5o!+SMGF#0ZHG%yo+mBeY|nOnxo=kmAShAxEa| z{OxHARb0l6?lKrO=Ln5?#)86f}um3=? zKafFSYbE43F(&CO>?4XT;FhG+bbJvQq;DG2-nYJP=!3odaP2&n_RJ;1B(@~wdT&ts zPvuEoT8Y^$q|If<@FZk|K;$KXnP?VbfNt*gG4kY#jO^P2Mr<))_-4@h+#wPnsz5~W ziUGT)^i~=KDehJxdKs60xyCMgz4Kc3`Y~AcT0WNkm9!C&R`Rpx?>cw3(c-eVkGC)e zMFj6uJh2k??D5zLwixa#Ghiue21fQ^>}?CwUF$_QD(a2Cz}Yg;g_4T2S~R9>F1TGy z)?Gi-?8S8BYjJ0b@`UwrC3Z#@FehXJ=jkKkK&;A^CZMFcrpvSsy)eQNBoE<-j;y#m^6TsP^D>A@7v_Rcx z(#puz!(deGZFvm)#DI}4Yt5DfBhj{-LcjEwKY>ZDf1-A5(WgSUYJSg7{ZO?7vXX(N zQ7Pa8^0HZ<+@fN69rO5|!3r++Cc6Udll}o&+@T-9Mw1m{)*wzim<{nrgdU^uOXo!1 znR3Vc_2rJa^=SwcgMTxz=O9Ra2PloCA6j-aTCZ@qt&EC}s&?43EsaTVgk1@qF(@_t zr?+b5(8+XgNz;QL&(`S+&fH3{_m)aG7$F^x$55LfYvA(#IVv8c*=w;#%;u@_0nhXE z_%_0&TNX)2u=r4(`sM3=2`{0BGCcn6!;Sd7_rgB)> zn)B$33ZBtiKE7mQzFC33hc%Yc(T_SMq0RK9%N;yAD(G7Z7#+fudgQNj+$v_r zK+9oJ+$#_>UrXZ{L)ym?-nl4gAdV(0R{JgLKdjLM*SKDMI8%;Zh%>jt(1=MlnEkIE z2Y%b);Y)DZh+fzuXO3VHe#kXj$l?_3vK>brLkEjbTUTMhmy1>VDlewIuO4`d9nq?h z8fREa9@ZJmvSHx;QW>NxW)Ke?qO|@ES<-w6@~^i(VUv9nsd%7}edK}vhTZT*2%?~u zSFBNK7(q<*X#zW9k@wob2Hu$qAi$U|u4wy9|O8A)ETwIt%t3jG3OTfJ~)(C-J_5$Edy?$`d5P7mNFw z!Q*?{7+l)$OUH@_$VRGYs0ec8bdt4}!((TxSoAl^-<%iT=)a-|JpJ-Gu&DB_Q;<+$ znPA}5U9VkskzM6;SaGd8dX|>}}!?UX$hKwvfLXcv%wOp6ahZ?PJO12dZp*>qT&ot<7&4pJu>0dPv zXDW;Mgd{>UoG5O{ql74ffSqS+TNDs`FP11>2rk9y=w>w}5)#IxgPnpVu);^QZ;(DH zQr-v*dMJPqU5v!bEMtw(`DNOGOpHG}0Ix@s>K6$Nb6f`@SG81js&)cPKQWj7yE2 z;?f2D%K32T+J5lY*x7d|SbtPN3U;_#uc+lw+R6&@n%+ zt`xbcPThHvLF+fkJj6+FWt)nCc-rIr(!u#fv|5Dj!zv`@IJ;8 zzO{U$6xpCODascpAVKK@9n45OV2%~J4LZ<5v;n=v^xD3eKZGe{)FY)Z2jg&BpAEKP z1U-jOk)Rj>8k{p~pa|zI6mTLzVFJvWyr5E-Ge!U>zZWJ`&Uyzx=1@>TPb7#1&L!Lp z8RXZr#J8?sl?GWSvr1!bf;Gdyg9@7Kz^0?l4+FU1ohUAa{vUdeK_Ir`3KBn#Zh~U?t&`5h+q8E zvYf+}1bXyMK8Pl-#wfCQ$dBJXG!^7<&Uws7+SKd;tP_QXP~5={yPfYf+n*<#fL5j3G!k^egJM+k&+;0Hl!xNtA((_+KdIE z!|O><=)f!~iX2#AK^~*SO6WV$kXnc|(Az@#0>DEPp$)txAi*4Lz_>97{*t12fl-_@ z3LuHZ9#r==1H%;5%qVLFk}9N^1Q{?Rc>zNlA4d2*j!$dB7zc-kVec#AJDI3Hbz*&B z^?f`e+{ykF47g_mmMm&teGi3!_g;fK^;_p?f>vGFVQ3XdL=gHKW3t+=I;?%{$A={nD>270UDM_$5V>ZhXu&ayL8X z8yxyPuJI@IFA&vru(e>#mB|A}5NX!M4uk|6B$!J0g;+WgHEoXOXpJNEfp5_?b1}Cx6}$uacCE0mb0 z1h3h8Fqe#w*0fB=HiSJSi|A3U7(oK4QNGgOu^L@T?i5-Q6mI&3XQVP2$647JS!HKz zf?t>D$5p{h+c;7qn_>`|tlMT+TdL%b(&*vG;_SVIG-SEjG}J+H2k4v0+0W3g=~%l7 z#x97~c_2S(F~Iz92RFUJScj;eHAR784s4DV{y~_4Y_>6)j-l;?Sk?VA{eG9~>0<{J ziBeA6mD*+hvetS@Yv$E{-kDNW;mG=DP9HiV;!Luo0FmSbXb?XSCvVI86Z+}I?M}THM@?FC%xZ%2m z^IKvih&&kR`IyqYgN=XzS^Wx3!A zm<_11@HywQ^2{y$-W4Zumk7(}dQgY#Rq}mCJiT|HMTG4{*;P#5W&d8R06k3L7i6K$ z=)JD;NkAh$Hhv_;T$9$B-l2;5CB{Mp8N1DXQp%yfU$9r*Hx4t)vAxS?i^v1pE?WM@ zRGX4VtK3us=>g@#41E3hj!k+bD&JK#>2U-p28ZcY0E5p+QqVoC(zj1~j-AgI-CN~4 zn*&70Yrb)hfI|iO?BDKaBeyy*E7Dxhr$%MOyc;zXzu2C+Zn^O9aJ-HbZp7 zs8_$W9Qx>5vV4c&M^fu5J?yZR-?KHRkfNLbjp#=#-+~_4y#m4*KEM)rkJj}NnLa>_ zS{S^{qCdtw5zg!#^U#b81rW!$XIOxSQWzWZ7$iR0!G)0ld!Xp8lKqT%h<8qe)E1J} zLOZdD?8Oblr8Kmnil=KHZP8GhK^_V!r8WJ+Qv@xQ`7q1=EyC6n9Z4 z=f*`I{tZ0i9hpb~Zuz^O8(l`OxVN0G0k{-dndONFh9 z_Ze^VMOvnG*6U!R?8Gu}AMPBJ!UOPTN@g|41gflex!^srqX;e?v6fkZ^^TW{Xocav zT`JUjhEm{G{~g9%#OFsc4u!Oe%b%H~^4X!7Ab+UORyFz= zU-^ANvucJEotys&uxY015y2^vD%-*QVcp@`k@X5Xi9m>2MrY)}TE;8F&3Jk`^v+yy zde~Kgb&nZB|86lxH*!^^&{2ihK;Vp{qtS0de&{k%zrXdpg_nfG5Li>#h!(eljp9BE zlvM@sp!+<*3)pR=`hlZ(rp`Oq`G3ga+gSy%GwK}#*3xVCXe3VZxzHI%sR``{t;2~X zqZuCD!yua9tkhXyB7yG~WjikVJm)^eVa39&C(b=jGzgY8VLu%~uPAMI!X9NMXfnC^ zUZWcZjsYI=qvSS8W>MY%8qOIvpgjodql4@O`8BL-^?hRVKMe+c2bvz(W3yQJkJF;~wt0{u z>J`yNRME2tTOuZDkjjwOCL=iNu=PKTtVj#ms6XWvmcZtf|B@swWtoK~M#r#!tsezh zEN3p6rb`^v%`ZYB9q^azNu)Wgxj1=%$GO8GN z*6E^S@DO>d``AEDV z$5CBu{iPoy>ZMFM2&W}~wiPsprTqya%H+N6Nnw=9vF^CP35&Vp%I&z`pJ6!JTM_hX z6_4CRvRtl3usqj!Kt20cLb=#@yu&%G=AR=8(1&(^x(SSr2F%SXkN!yIlArHDE2K%eaD{@$ZyPRj&?|p~XljwB$}e z&s7FvISWfucr+3^BRn|fJ2=Ml56SLZXp2+&<&&K5?zTeDj}s+aeIH7aRh9W?3C3pF zYz|u;^$J;Xx$HnfLKil z;%6=#;LeK$EYv@DLk?ueZiEF z8PPb3o}3~)=0vg<$x29+s5zCrC1T`8yF zYez4c>@ciS#q46NlYY*5bRC-6vFZc44U<}&K~JKZE$o!6bxGLbHqNWb%_$t9^qQts z66`A<*9)>gQ;WN&gnybdy zGax~2zkLC{OT@?$C}lT#%vO8zvkf30owx(Ild|1)r0J5gtJ5%Oaw1?%o>6FlYU!@P z9RDKb4nb)O-Zyuqg196XsdEW{wfT^ND(Jm^hLzwMp~hKb%G-!fY0SAo*Gcp=A+x*( z&_#{FULb2&po3+3hoBk1IrEUU zCloxH=AI^aon6#*zof+=<&=wWeW~p)35s&B!DKQB;=GteU+H8j+x<}+~ClhnXU=3bg~zULQi(HS-FGgDLP*$v16H<;cYr4wtF*adi4=F zWQ_pJ@?*C!D79kio$w(<_#8F9A1N%L7m5VYtj>ivEa2T0U+@* z6&Bz*+1{gt_%n_hz?Wkdy~j&~HycFcHfslv6}00H(iemRjN&8zWHfA?eu|Y29pRa2 z77%G!N;Gb!_!6{9t9S%c&G=~!yn%M($rvTS!qd$M1HQ{Eb|^BeLqMh?EnPY-ozH)o z8=diKq*Or3A9VIM#m!yxMz7gnX-6~ab-oKaS@=8o;>9$S#~%^l?q6Ww-Q@VgYoZ9G z0r(vZ=Uv<>@MCPk6tGNSIX2I$$Wwi3kDyY{(uQ}zR1@ig7pGL>GTodC?F)#sJHiE; z*@$4-G9LV`$}0xoHlmsxx{*y^CuvD76y1jzsUI%{80Y9thhT++oOB+;64L=eep}kO z5)Y>2Ses3)iedqQ0?c5BSt%#*%fyQ_69-KQh*9_DhpRT^OQw=o4 z=PoeYDQhDW1M|I_5_9`%evf{4JM-M$VFac|CXdKqO=FYJKu6oZdMtM@*BvL>S!B_Bmil{Ra&Mqr~K;E3z z&3TiF$S!e8i7Ngs$<$TaWTws+ZjytdnX;{!?fqoc?UzKTq)f)ZcbTg`MHLm1u`h7l zIwdO&=<|MO&4N}Bv!dl|Jk@ytX>T=CtTONago2`}G^bVFzj^6#-DPKT&Kwu%Q3PJM z>6^X5zVmfHlr^g+BiIs-$@0VQR95>7>YdPC{+0E6lW34*3Tqlw@%;MVrMC%Un;(+b zs*7qY%+fB*xFR|#%_2v?o>hhZm1Hy2U@1OZCf3et@Yd9F*i5LNOHHcgE*V7j22PxD zyneT*?-uzF4Hzg8V*(qYPD(5e06Xx=S@>GcYc23#i&aeyP)r3nXFCtUAl?kRA8CqNwI znYSLwdy%sLjj6Q8to4)c@D2KZP?&Gj%ZPrb)5lWhheh#E9_n%b?mM7=b8BbI|&Za=HI?V39^|BOSM6gP8`-OpmfLwNC^e)S+aOrqQ zzG9l_|M1QtW!qD5h5|%uZzS2rV4PdWb~QR!D>$!)={GzyRmb<}`+iIQ^D|>dGd`Y( zUtQIA4Q#;F{r19Py<=;SD;hqCbY)oRP-&9tfwuw)oig&#+WCxJh=7SQ$Ki9>$h$0V5>UmOfo-TYFS7OEASBZL$+|ONeCy1JI_3nYr^vQbgKY`7 z$o@_ufL+@=u60!P(S<@-;0ztimUqV86QQBxWhm91;-mx9W^UW!_?WcKaYiVxL#lDc zy>cnEJ4`w0fOFPNM)}3ofymUE`jd4x{Q@w)9eI#cnRowT)AOGJjUjm+&P(pV2|}Cx&pRHlJ7J9?@K?_o7u8^0 zS#$dO7kkKH2QdxEx?2e+2#V1Bw?ovRr)h_#}4r%7rN(m z%6e>k?!dzC;yloME)bqLqkK49SuYdw;d}emC?`2$U(nE{%AY^y_goT;jMVGKpf>vz zo!+=U++soSS~99L?=qPas`EXBUda-3ekopW zmHA(7ppENA9B>-HI=EQ^`9neNc!ComJ}GL-v_cQI6UG%aerLVmXwJ24a2l2{5(HOf z5+Zw*%=gTlAHqRrOFC7%!$q@o8nzP|yT2JeT@mJ+SRoj5DNhRz8~_K4!(TvN+M{$* z-0&$!e=)~hyBbkHe%icZj0hJHXUgzkP_w6EPWSMJMwvDc+($s+tYA9zIi659-BONL5E zeIku_E0rm3vR*lK<8oZ_#KaA*V_tx}_m5m8xbq1ve%<7cdjA$x!7Porw3&q?VZw^q z5oBmv>_~PWux&0*r*go(gsj*?Tk&<`QK~uq`>@_7CK^^px(yGhjvoT$(Q=huOABB zK1Vsx_YR1otVU-HC~tc>b5Nwo0s{NR$&~`*S#UnX5GYQE41o0wg>fuRWJl zvEm_NLFJ6-LuheD*W8&H^C$>6Df-T9Vj#O&ZEd`0MDJV8XNeUs=c|lDcf6%b{*@p6 zi{r>E7`4OnHwx}$6k8Gf2e;_nB_-P8S>~VbH!U*F#3I}0D@Lij_gjSN2Em#WXeUw# zw-Fj-#y%Z=G2C8gm(aR?C99;z!&bt*QQuQL@Nfa1hlC@9W< zHWb?FtWx_o!moEOm`9WZ=W|2jDT$UJZBp*9b$qGq%K6C%r{1i7w5xr!dgU@v*+(^! zij>anxvs1~m_^L8KA;m8l@FaiA5Cj7jaD()8ZmY9=y|}+oU#)ip;uFCd!1V(-E*O& z3OHS>(UNPGa|H}cq|CegF-~v{H>!vVY?hum2xuN4k!HIq{0!7i|+Nf_< zn4tDmC`WdYoT+gQGsq=Zv_s}=o4PAV_+JMIfOVi}gr^4PfDYdI<0Q+~Te!R-tiuWn zBqS79Tfg#(kexuAw#g+QK)-R%eNM0$CR{bmFV6cQOpfnlHumU{#(!AU5jS z$=!Ip&=J_dT0*E!&aYSqG^C>xD@P@|tC&td-c6%g5-6`p&sVvYY)wE0$GTT-=Bpmd zGk5~0Vu0WY#<4z}4S26MQ}iz+$sqBFI=fubs&bcChvOp)^_n8}+93K-}%tqEZ9f0s*-Ji*DTm&T~%G%LDG58`BBR(SZ(9q*Qb9Qmj`s7 z7mbz*lj=>U?Y(o)Q*&}%JgawD+yt=bNw!}HIUkCfS(@Ral|oH^Z`JwDDd`+bt1PW)}{l0(Z32)qSXM~`ehVm zYr8cjFG?K`bic+?DXmb=Z-gF*$!Wx;g{$JAO#eod(#ow}HMdcZZQTeVWHXV4<~OF< zna)r}-)a4)BGk{!hIh$*y;jKcBeXyB?7!3fKGl9G(sR66z#|Hv6NS zu*CvVOqcwDQXtM>f6ojV&k^kE@@Wa!46mhF|umnpIj4^baoYr3U48>ca z=QtM+JO1^O#Xc}NA94ki5h_tK*Ni18ME|k+E{69o#SJM`c@?*wtk$bI(iXmK1X0(P zlm125#PD)IU9xK}#tT{DXFAKWd7V+Gs$JaNNT3VNL6M;} zy}12JXnEU1^e)glOw?9>$Y-f@W7~;H>k-evSwT!6JqFr<-9~f%zkOqynw#$b35DXG zS5N}M_gcxximu5XXe*G(x~yJLbpO0vC&y@eaUVWNW;;(rm$9}lm$?MMxSk67GKZxP zybHnLr$%Q#ARc^vzJ;&fZjrd8wx{w5arSOj;LQu4=xGB_ZEYoz*00AD$AQcV_E7?` zZfLaX$G?z8iN@s91CHr!*T;Yx;?a0K_ge=O%d8Fa(~gRK$6d}BA?M88&ub!1O?(`| zS&z5N1`Q8{u4C3Cn1pv*Xw`~VR@ywRT$=b;E05{xBv6@`CndUWQXfFvqhspWQXz># z{WFnZo8nKb22w|a*zKD>pP&}HQXW5`W+#@-hERMON!J?kLiJzmEp4;+F@}o9DMfzS z;Vyi;B4gdvT#5T9} zQ(g=UZHBMvu=}|tr$~GjpSS;kdi1(aSo432jW#=} zw&vYP;BL6Jg|MDpe|9&4(`VXGT6sINqv|($anN1oi#+%wg5_0do^h=bg_^Z^Cy~8I zB%*J`-5;#dXJ$ule(@?=zXiQ0`48)i4G;H#obm z7?Ty!n2`{9_vW;aw&ZJ}7cbc-?)oM#ySYATj1HmnMO?UH|ZZr_IIL62mne&2fe@>|`%B>R)+`i_|H;GC}Q z?EZnqU_nJN-%6hLOChmGq1Jz@p2s>=DKBh->UQy2nz;DrokLr6u(;_Eol&~cF)?hh zm)o}G!spw9Z3SY+E%S3$fADj3u13AstZ#ed7;kkta6b9Zitg9J zQkoVsPB)(T)HBAEpCa-ZdC@mp|ic>7OI>3^N#JJl!qbZD3Q;h;=UotxSZ*mp5K zJ=c_9eE-taBo!~mQgZvZp)}Y>b`O(NRg|~ADne_!Co40c=Ej{wX4xc-u<59H$WzEs6VZ;AuwXt*HeXB9KcH}}*>@U%zOL~{A>y53FHTNI z{x!C;B3H>RQ-}MNdXkA<`g)hd{lp1JW98?h(B|w? z9%X7U(79ym$U*TrR_Q+`_f^-hfZA;4t&VWY&IfEUmnqDZkP2U6?>l#G52~%6B%`0i zXx{R@-OIT4!k9jRu`j!n>GNR7FAKpKa(-jyki$HXrml}c89xVlzTUg8(_IBN2G`3p zf*_^$4YxnN#H^OuuEj3cABQw;4!!h!2bpzhecx>l-!!CE?Mf9>X0Ln?HjJYCwqGBt z5a+w!K~S^HjjHs~WYnavlu!3XQ9%(JXK2#D3hwVSQWmBEs7`%WPQnkb3!;by$4=5a zwNwSaJpN{+@OEjV)J@65+(jljeRo|;F9h9S`rS>#MEqG-WyDJs>3%gkgf z6kz&MMc_RPN80nF;CKD?0XNTbp7&71S2n%&NSMh%y;fIiXA!ZjRUIuQ=wYaN-e)QH z^`TEcI|at2vD35BK>mAtA>rG`F5675PiofVmw7^t^@&aZ*fT0ZCY;+%TY z3&<(8?CLKK8QiQr{OK-rX<1D>Lu-x}d!}EGr)-r}mLva@kG#7EePKyw;0NbXXW2Kp zop4jP&8)Sn{SK-jc>@F@;Py!6x~Tt=D6U`Jg+unyM$kAQ8?N=E{=fNz*CkK`PsY}d zJ=X$?qJP22A4jc@tA_FaU5#8QuQnHp<9JUudLD@A(e)e!k)+6wN%JoKo(`Zg6+gKH zWAPzUeTVCJg~-|-ePpjsxBhl7x5^C32XkIthRX*x@Ae|zWB;|;jqoyK7AtSPP!h9^KjFj3o7=|V$ zw_ePVF>BfJ*-Lja8aat;ubpfR-bI|-+-SN|MWgp3j<;(N=Stc<3Iu#2VEDobIaLrR zj8w6~y7<95nfRDme70H`tQ5vk$Epd;%icwUzn*u4j3-VFk=4J`;+h9ioAV$$fP?< z^~`Qz{*qDne()L73NC%?q*}{&h-mRg8Qru!(>bVlsZ(WPS`J2E2<8RZl$*@q!5Y?m z+(%T>F~i5%7l8YR&;26?tfTCK=z zwsP#n`-Plmvb?X2+3HH7y`Feb1_b8h_d=8Z7r|sJ#uEI4xIn&h(UZ!Lca^5`V4lWM z$2^7kw8rpIcKen{NB7M~Lkn-inBPQc`zgOQ@y~acvD~y2Kk|L6j#`~8KWdbIJBAo{ zHu?H~hGUgCU|ii5?MM=%gMPm9*}dP1Orz)Wip|U|o9NJm`s}UlL9w(VN+0px z`k!cU83+m{|Hd)q2>xV<_ei_-Lt@5#YBq9U@Hw5yUccOT+BaD%JTFp9G5JV1dIlB- z4vNx+e?=rpH7&l~HEPUTNap1c2bpW;>Xw$uyD7Di_r@-#dndImBKsKMsn%b+9y2FL zFe5mKBAKPunQ&IZ#Br9^RJ&+bR>`iQqY=jp#LlmyUPIF+4L@wscZ^2z7~zfm=Z0H2 z8caHN^kRt8Qs()Ty2JaRZ@Xuw2LiWHd4$VYKZ~Vy^(j5`A{NfePG+ii`Sp&%d_@mY z$qe8J_TPf}4{u(49pf?bmpwX=-$DF-kKR*h%QTe#Wvtel=PhoN`_l-H+;lXqosbsK zjomVb-7B-)%lE;^^Y-KK>+_EnhGR!8&_i>nJC5&o?~#i=zW0RH>1mRkTYSp7??qqfk&YUo`y1eGc+rouXUC;M)n5ue;sxsv8 za&URQ_C9|-21gkF{OCXcE|EW>A$XEe>HfZ^nDg;RV9jqWq8)yWqVJov?oS)pYN`pK+oWgk+jvapA)?tIe3556Y}A3zjj9Ae5PgN7L2wb zJ_ZNazgLfiP@EbQEmQ^3aF!;{@G+K~bPlej@+LT894s0z@fNat)2sGAOr|}%jobMs z;PES*Wr@KKp?Xz=$Cl)+ffGYbVVF3R&hoWS(#U3qA;V$jFP)CHOTRPeFo{+E8sNSm zf$!s;x-v`3<9uAW)=W7mwh<~eD;tkr$zD8%+;TsDgx^SW6@D)HJW8ZunMJ}^= z@7C@K$y3saQVCu0xmAoYk@!!{{PM^et!eVby_n!%DV&W{-_r~~t_9b3&QZ-EI<4KK zj8H07ylY3bEa67t>q`bt-Tm+7bo=OBP(qA*j^buGN2e@uh8rpt0o-pz(_>Y$-xzk~ z#!mF)WPRQ%b<#fwRaVQ+dr|LvzKLDG=a|L%&4Y14L;VBh@=Xq9VLVewdGqJj4}p%b z?GOCp#9Fs|vt$oZpN>vD`|IcMv&18+Iu*{;J>jCF>7V7Z8K>%!b8EzkHJqu}k?5l7 zR4>6a? z_~p&#Ulx^^#_8P~i@o(9tSRzHKmWr29{Ey`E#)g!6Q(+HHQa3-`{}-}Flp?U#Wr8v zgeq-8?$MRe4g^;4`&7GWfvqHL_(`kCK*Y&{;EzcFqRnu)rRi2(G6wc~vdNYmD z!b7QUSor1BcwJr@a|PspdbuiAg<}{}JKt5;Aju#BbG(h}apl1@x8G>fi zfp?vnPZgs@HpQ@CU`cgNr0HuarJ_}37q+6W!pK`1^W2k`IwG@z8f_uUUM$M{b#207 z%4tI{%rLd^Wm%LR(8{XcZyX5kZvT>dW(tJ1jOA`6x%wW+Qd}d44HxW{E!qn--tUJWJ(+qZ1XV%wPRd`xSZ zd?D^@hf)y)^JXM_l=3o-I^7F;-nkUT4D^EoolV`Q2q17ZOU+v-{s^O<-s z?Y4v~mhp5@5pbDl71i~KO2iYMG}Bjxl%H$A7=TPpSKr@36^cU4ab75;6_ir%`5EXE zqcbptIH(a`%7u7wjmkftS8@+tiDLI$V>OozLLBJhK9RDhX5@mtCLLN$1-5#8#VoMP zm8XBHGp3rS1nF&TTcRVSeFo5r`iGX025DsPXiU(|aQql4%* zm-I#9F+G)a+D>0gCOgjg?JSy9On*@y{+~8NZ z6(v_F-wEO;Ij}PsG<;l+Gsj&AssTD}!O0g;>bs>Gs{RT~Gq*J}2*#m3gm`LiA%1CZ zA%0nJA%1ypA@1%i#E0}2;#c$*;#c+-;zN52@wDDT{HkcgAV6Fljc|>%bv7LKL%k(J>P)#h4{)!O77v6A`<3fEJAI^#)6bEgGl=Q=(%gBX-3g zEf~{{1>u8|bzHJmfjeKyrnr>^=*h9ddp-|_v|l{U8Vju-%1{}`SmFal;c3laACC=n zqC3k%U!9{w`oD=#hYLW1j4X3?ua#hTg5wp0)1b*=twjw2ArEh`M*xFYMKa9xX_4;H zieE0YwT!dcs)eX1W){)r9B49VC>6|45=dP2+8JP}jx7#BX!CW3LXcjY+SYL{qNqSz zP`r*?tZ2b6aSV;0)$b3JgiiRmhD*X#@S6y~dGK2SzhA?zhlUP=W>nEZn4|?x*|o=U zmLlYS@(J+YC|nXNU(%SR*yKxu#w=A9H9LDx@-1N3d7@B8#^rSCENn)E$E z-wyhIOW!W~o}sVc#;-zOmA+2;y6Bro-(>ox&^ML7Zu$!t5>`WDf54t?j-cL9A%=(~u%i|Om5?+W^^q;DC0SJU?i`aVV9XXv|uzR%Nl z8+~i(yOX|6^nIPa&GbD$-xm75Pv2Jh9;2^G-xKuhqVE~{3PUL0=sBAFKRX`3P0$MZIENp9fvx(1? z(&#y##>X%Uxt#jZhVXt_+=7MM8f$5vMPF;i0I}Ad3A67o(84zF1c#D}%W*e4e$Dr# z$l4Jf8fei6Baa?_LCTdp1%qSrhB0C4_4@JZZLBg>#Z=nI3qDs>o*39IRZbEEjna6* zZ{D#T{e-E~_T02l`1+r>{UCKgH7{&<&B>V*%KDwwHo#H1P5oJ#yMAcAHBLo*3hrz9 z6c~GIzy9aReK*0Fet|P&W~Acs91P@9W}pUg5cPufxM=sOzWaxxTXF!xD|sEav*byv zM>$Ean&@_U3qtSUafIC%ZaqpO%stQk>_%bZNJ$9PDuGi!Tltl7LwN{uSbGe&D^h0f zKtkFU*ju++hc!$ej=7zQOni=+X7DUc3m8dFv_%L8q#&RRpuC^p@;<*@p=``6c?;9_ z|G^22PycgPxAnms-G(K)<_hxKHVpIf`?gy{IM*5VH!Z(pGSc~&Zr1I+1RnMWflQNX zU98uDCt{j z9?sbfKj7Zc!+plgz=`R`O80!TZyNB<#we`d#uO9SIURRHO>}#`C87xZs+SHZP}Ggl zlc97ByU`ys=Zxm1gY~-J|>re}F{@8+fMeKq87eD?%zz7R?}(aYY^!#-^WS}}YkzT!wpQCfo5*plyC~3g zV0l4xNnGHQuE1H>Qrl~oNui`E{S+bnm}h^b+dXc$0NK85su6#Nx0{U)?(yGNHr@@x z`NsrWv;QWC$AP~DYxW3pc~O<~htJeK2C%Uod`_ zs1yH;b4yZc&}G%3@}t;(^nXJDPv`J10e||q(dc2hYTTr@`Dia5G3WrI7xFk3_W^ph z;uhPo@d!cEbV!Qc+$%Oem_KxkgU@+zE*SBPhA1>yfk#p@zFK~ZA&N~I9m{fhN3+A+ znu8;%GgL(AD`Vf%z6Pbxn2?y!vdp#~%^W4plqTaQ1+vr$d{v{5xHseL z8QX+ZXzFj~3PO<=7d5L_y4}X4F5`}G%Nx+CdX!!NsyOZ7(xJtk5Oijfho-#+HLSS& zn9z}NW?3AJ9HCc*n$`Z5eg@k8H_zhYT2VdpDTOl&@?$R6Kj~lS4b;hHN6vUYFV^2k zdtLu@U)wju&qB|G#p5j&cNJ?dx!uK|p;dcnp;A}tD%P9fdx?G4>^tT*bTeWf{~fnc z|B>5&Vx+f_(c*WR#qa+tQayRi_#s~ZW!m~grEOJ9ByB|Yf0$jlKgQAl>OoIKPw^;Z zG;0-AD04T+TJT?B=&T0=Y5)bRjbtM>%gwCBicj>>&KQ4nm|16_OF>Y4C zt?)dz8;l|q>N&V&oac6#QRFmkc7ogBK&>lK@9ItATQ&RkwAzL-|Mp)}c3SX#J?2Y) z|FV$aYpZK_)wQ_*Z%6#0F<%a-b&9iZZ&+QWW>sC4J*Lfnzq-d)yg~MVfeEO@_f|RrnJyv(A1WE_Asb@AAKER;4~LJP4rsskOG@;T zOk~mbJpBgOyY%K#f!w{&JWZ92-6vyucqs^+P^)2(R6w7o6~IfNXID#QW45zYGG>Q2 zNxSgmsv6aa7odWZg)3gA$)H0F#ks@j?m7A0lYUz89>`-D$4(ct;6hYRcl4v_;;ZZT zbyZDwk0?9Z3Ys$*+?NzPCb~yd`P{>bjhvXWTjkWD?fe- zsHSdBKUvpmE7pO`(O9gnbPubV;vNn}v1La@@D3LDBM_rub*&CZeX%~BI7q;71n@X= zNf+?AQGb(o0M4-+S&gV#@D@NtND@K*}T1DzR)>dzHZJi!fTm1_GF(SPaI8P}%dI_}k+0e;} zwZ*y&J^QfqV~|2UCkD-Rt@h$N(+O4;tzdS5ITp+#FdlVgELbJ9f;kS%id9%yRyjc_ zS^j8;N4T)MSreLz%?g_^RC*TMFhY$AHjGm|wG?+QQ|Z?3GPPUbQ;80k#yTMG6D>BN zPw!W3cp+H@F#uiJU{Jx382HQ!##k^a0HtChOYNDai2R8hrsv-wK)}G^uD(&_t3dx%Y5GC;)Ml3>9E# zbRg-`6<`t;LT7{MQyVAJ`i9Wip!jTMQy{R;29-@xXM>APiq$MtWVO;gD!jN2Ei(Cz z*$p7Sp=4ZC1m5nkVt8rsJPF<-|G=sIgj?+1M_htm3d~qV>#TJ4e473QE!;*ev^a3p zAAL6HN3BBv=C6dvR#|f4{3t(xQ~h+*by_vg`$vLtdP}blA5JmW(Aw7)93K?u){@sM zS~d!AcEs(nHRxWx6WPq>uxSS&&L0_^h_Ito9-tcQb^5!;7|(wFw0RcyMP+p6C5!%P z@OAl=vYQkMOsQm2z$B4L1(QN1*H#?18+oqk8H4o+YV`zH;{+U~3TE@og0Q<>!=%y1 zG$0n+pX*s4de@KM{qK4D092awWoZiSqFZ0V2Iu-pFw|(^-gfn%3)9ymaOtY111Q!l z29z#=-MP+3#)jVX@yP9ifxY5agGp=K9YOcjUutlC*7nzkJMR~vC3)U0VLVU!BaBV7 z>RqZ-^CF(NbRgBG(t%L6sZo_F>|WAG=~h8Xd{^T#K*_aIWUqQ;na>zJEI|pc6ygds z-CMDZ)(Azd0#6g5Qh&UJ ztYo)ZF;d@nJ_RSyz@6t9Bgu;Ir8B~`1)-!0jtK4*Pg==lgR>-1ujE*{(_XKC zqkjei=o4e2S4ESleq(OaP7}|5h#!VwHBbOf&XmXS1{SblL#$dwj#QFww_2N`bzVdb zHiP=hD|&(Pir~9Eytt}=6G|$(n$HAdJQnnbM>=N>ddmtl;HokO&zL}0>e57uXdLH( z_9)&V;Mqg_`gGo@4@?}{kiL-qfTpT zeA)w2fPn>SmFygA-CAcC-EujVx+E)HiKu9|=TiM+jNwR^(e4{-6exzQOCa-Ay&iYCWGmG<$=;I7T@p0M(X_oR zvQu4|iz?}$;9>vT_6+T%t`s^%LBHAM*;Bn5Cvzs~F1a7k1y?!EKPKWJ7HdJ^REU;&^k!Prks@^<`mf|O8N_^y7S=y#d^ZYo zmdS?CJp~jT?^c}u(OW(HO)vE7hKP46850!JQYYYIb+R$RNs8>P!nIGnzM8JwJnketcgNeL$Y_etTHPs}&H!v8kr z=S6K^Zv~akL!X!fFBgSp&f z8Xx2)QZjNCN=B|gY0JHgM|!D7ZYrDHf$v@ZOCd89y@SRLnG%fsw7`oHNTxu>nOH!X z$qBSU@hz0TtzJ-iFDiK=4JT%m1ckbNOlocloq5Pbn^VtCrcB9Aq)f?GD5G)(h%b+K zx^D9iFF%gP@^cuJ|B}sE$+v$3RdC1RA?IInfjL;L=eoJDb1wrp24HG9YnG>NRJUMf z@IPYZM0eh%7#Jr`sa)WmRD;}L96u3KJh|-}5Kft~5a7~LnGQ^1a4=wA7GI3nAwUEw z=eQ@ns=|1KG1$h-qqlpi*2u6$Q{aIX)H9E0X5q|1U4*- z3v@|-XUz)GB^zp1$h@;6iauD2BqES>5lL4R3A_8nA6ilTvGD*-CbtdJE=*s8i$-l{ z6MiUt-Fw+XU)=p!1oWz9$lcvQIiV5;&uz$0J8`b%M2s zAC=|igD{|2hvi@sgjk`$ysz61#oU1MQl*h{$urO_OS3%tOP(682wQQS2i4CN)wOES zzZch_D^w(?SS2e!$trn4#(i~BgI*kDUyhY7i#V0M1_UL0kvaSeC9NRMEJbfXp%l4j z30TKPv939Q-P9xFDM4{HAIM>cty!4fdLlL70{8S|l|$YGOO)s6{B9f6bH#ba%$ilm z+D)usJWICz<8cVtV9o=I9Zw7cf$$^i_%qFmR9+AN6ZrkltKoVVu#O7 z45-r)GcrP%Zhrr9C{&$&g}Ln$VloWqlw$2)*)e=44A2b4&lO@V_$Gc=MSQ!>tsi4D zIkxBJr&5xR>6`R1rY~^91Ln>s|R0!+LG293XxNd3$TRh--;1(VSH#70wS$ad_8+`uGfi^x+-S~SYypo zM?)d2FmaA^x?3p@AD=^;WF7>B4_fRGoJiCgJb0?W z#b@@8Scbh)&QjFJH;k;gP#(VyRExd)vJPx4!wc@}j(f{feiE%g$ z(*7Ks4yCAb`a(ES?ZgmbG0|vH%|S;oI}&Nxy;lige1~Ct|8|7qOVN!)*0Ud@I~}6? z^v6A-3zd7<5sq#`I7V3*qn*8CL>Wwx;`rcxcR!$syb8p$IEEG#}3X#ex6{kK}}aSD{i{H@dm zTOkQqScOvD=C6-Zeq>`+%IZ$8{+{^)_~bTwymyPO&USCc?$?~ozQ=f zO%%(2JeB`P+&+hG;iQHIi`#RUMcEMwqt2G)~=Nd0k|w_{MXRXDOuoEM#f2)|E1 zjPQ#I^ZTOJ;up;-0a#T*MRsRdYo0wA1~OAg++T?k=j&1utXWlc-Quew6RfLw3M7@* zY0*-Gjz)Y6)yAv7qf!6*RGN73zuGhXGmND1;E=5ozy_@aGSd^R-Oy-&%v5KTl%f)I zpda3MJd$Si`NG1DV3`-qaVCwu-|OBqSgpjCtq9HWOLsIBHwtrvJ9_Qk!nPVczq?TG zF=!_>GRjW-bE5vj`!jJXxM#l+pNKj11RYEXd>``lU5AMBor}fpYcnh8tcAD4+jGsi z0uRHRQzV+U#gi^x&*750C2YZo3DJ~3yS|19s`=<$@6~Ic!xPfCk(2Q}5e7f^Cj=M+ zL(J9ebrE^}xkUTotgVpItID`jsRRd~C67r8oyWoxOEaQLz7S~In@&fDd<7-A;$E@~ zIYy4}qTU)`@*zgB4^96lCAgkn5=;81VdX^+VmE4J$9SXU_GvP0dHi8@Y-=Z-&%!uV zDsIpd?$2j+DyirA8CXv@)=;VoBImUgeKb1jqcMliFRJzDVM?CDluY8twF%TeS6esF zlwMTLd9l4~tRztA&p!JsM}XFUu!D}ja7fjBmdRUkOvF8-$vp~O3-ZZ1>y*y4XqPqM z(r80|7{d9Csd7?Ppur&Ik0X#dhT2zb`OY~^h{5A&JumfD90$HXM;|?=XH+U)5csSE zdYu{V@Pt6u35P2$afup{tiWv+orpUaM}D@W<-gg@3LYa_ED(!Qg{o|FRMo*ta+6A$ z?NsM6ZjoD7YHTPd@Z?nS`c)u6u#1i_k+B>fIZfqQDx05NLe-&EED6D=50uhxzhbH7 zW~milG88@B${x()m!TwIKZbHUoQWh4Xnqvfydhe*Yll}NdrXZcy7QxV7bx93Z^J55 z^-8yME9#otJD@V*bkwuYnm6*~5N%j4b%r_9w#O&KJ600!=&=jbxkXiBS?}VM!8tyzvyb=v5%@>B!l%5}flasRaA9 z5*!m-n^;%6Q)lY&NT$c5V|WuQ0=Ip9;E2@hPGD#%7P@^ws_(FsWb2N z-Tl*_q~=_cbM@8Nj!ez>-#>i%y+2u)y7cEueG7jwBGvoTCBA!qdjHbYoS!cK`I39@ zDerH<(XKG+r2D;*ORLE?)}Y1o=e~Hd*A?XhZgh zZ2z-oj~_Rk8;kEAFzn30)YYonEQI>8(sbvgl9;&LlZYS7AgDCt;FcdD;^Ji%h+ z>l3w!-8!4F4B8F0|EF<{^PoLkjSl}ehYZlqe|^Y+q%of|IO^n62GbLi$QIm^zbkmk z;39UyJ9D*)f(xHAc>7C0<0*qf@6iFs;6E`pG7Qgz0;KvTUv(WiAX&jVOFEmdY6PNp@A-SL%%*xQr#sne+YHR0gY5xJzLgZA<3x5m@4P^v{t1i{))eV= zqXi*V@cwB{k*7%u;$$M}ob5KM9iVrgncKj`o?7i`oZ4N5EApP&EbVE%ncY3L?VXwj zE2b{$(-e!|n5r70G1YmssMn);f&!L76O^zoiz-*${5(|0lSek=3kWB_((8`h=@gIO zxpC9+oOS{K4Xr(%&8Fko#V}I5O{>7GWi|?7f@79*<<4W-kF^$`Y$?uY(jGkk`El${ z_c>to%JCcyGm`!VOYU8^aLH2P|EquhX}+ldCs(UeXfJMBL*2)+h#$SB?qkVF8V237 z*Z?}pjFK}rzxY$!3wJQB4#q4^Rw>f1r)3VW+0e#)4-w`Sgk|NIjIc3+EgRT^HzyH7 zkH>(_Uxm><;ztUT%8TSFtU}|8xMz>G6+&M{@+Ekf&mDnUjBEbEPM^Fx29@EVtPIP$ z?RdkxvO5>Y!20oS`BMHpiZbn&>%lj8$-`ax;+tmRO0s(P?7)7!Dlc^F_-nL4C78!w zr3G-4O+~HW#6ADZ(0!ShSJCNH%Q!abR`g_TWYE7h@z!);c5B%UWBu;3m4JgjIL+LK}K;f(G&m>Ds{M`4D;#_wiRfEapw92t{}*)*8Ql z8p3{n!>%e0-CA)>tN1z4mz^1_1=IL-6Dec2RXj ze^sA~{XSROsS)TpB1_+E;u7F)5`|GUFdqi1BmCmzDsO0V*{N%m##QY1_a~7#t6|y6 zvQuN1sLNqMdrt6u=Bb_4PG(LV6jT)aRkt7>32WJSec|96vdzh(Hm7N1t+hJy-vS>~|5xUw0< z4Q=L6zJVgm97>wcNN7>G^=b1Un<8vMssi2Iif-n0tlngXHHmPgGzW{MjksYblt@FN zVJ1}32m`$VlJ`B+G}NR3+T40M?xzK2cWurRXx_MWyRbkKyx%-)zV#({jzet!UFQgm z9Ydv{W>jOhWSWM^`>m$Y6Gk-fC^Bi5TW<$(KnY9({xdm(ra8;dVNJb|<1 zKcdcn4zXRvd|dwp<(2;F7MJb6TI6Uo*UqD+2+Ga_kk%a-e&+-1Mqi$erVqK4M)|*o>oPH%o6_F%vw6vs;8r^9cp+cLjOX4 z??=j}#mt-+*>kFJ6{uH)9_`gU^(8I`h`c$nhMLz!m-4#Zm5_ty&G`O*`;YgBs38AS zaMX%-AmM96#{KC=Ub48$m@&+lnqtgN73;)?w0&uB>nH{G$+_;dCcKLzH`%iX^pk!- zEX!Bt4TD<#hkxVv!Jj^EYO?Q2W4yasafn^T246vFEOIM#t&(Wcma73EHF#rVZTq(q zjKbtVgOagt$xH1G#;vL`BSmaVYYvly67_Z^+%IfMvcrVo4qo9~| z>4mX+VXqi`=o60Bk~#5b>P z4#>DI<19bVk{{peTe2<06VXgKggj(27nod!Oj;lV@<{pFa+Bp}KKn@~KbMi8SnvZm zlGpYHPNqUW_|rObKTP#8-+4rHG4h=XWc`tE6J%Xp+YTbXOYmO<EUjWLnXUj6 z<1Pc!O|+qBhB37h#!`>HifwD|tr;!aV_VP&4*t%J4(&0#kkBZ+Iip#7>@~}Qef*)@ z$Dexms3aeK(Z>rtd{lJ%sOaHiNp~0zM)_E_kf@gxhbfm8jmwQ)atBv7oDOUI#aZYz zo9HmF-qD74{pl@jQ$vKjgONXDB+f|b&24wHo1fg;tMr!k$MmN5-+}oVFt62{+t*y3 zTWmauEk@5hXB&@KA^r)gv@Qh?`#fIr?)SOh$;~&WW=}Kb=9?3y@mx_ZQ1~z6*r9Gu zubX(y%fPw)4XA{lR0qa|x3C!gVmQux094y}*g1j7Ge0 zqRB$*1uny%hr$roOAKi49cj(rhQ9N4Z=wM$VrnrGH(97;qc9)B(6dvJe|D+?jXWFV zW1gNp6sYy=VaD7WjNn+vkjCsW*mTocwqrxqv(t?rC44j{NY5U{LdD3P=Q#{9>4Mh! z`0Z%VH|F-ICTwJ><}Royl_}OdDMEbcSAtU3#n`gg~89|n(}GL8!}ni7 zKE8$+zf)xS8DYgZ+5Gx;^Z`Sd2~jb=%nIXKq@SD3#JLi1Xdv=zE!g)oM|`mh1|?2o zZi3zcYM`5vbHDLgC$_J`;r7!}y)5t9~7AxRsX7#)-Yjd`J4Mi5P;~E1)hdd?u(dVpk2cVLW&Q+wW+GAx=AmQ< zY;pORIN))8$hrZ^N=vssz_&H%p9D@gjfYYVyPkVy-4jqsfm+!Zj0X1^W4V&HQ$K?9 zHf9x!hREGWa*lvJEXR8QgZup#n|ObwzSjVKbOGu7PW?pqJ_H!<+!nb*R;ix)tyxfv z2M@+zDNLRoN?L%1j!@wl^XAt;rbc<}{T>r8e(VlpdPm_jcYu)w31tg_|7iy)W+FD-_Yv@Vm7I3>KKlL&0CXoRA~Z91SVs*xuHP$2^rkZW{Y ztNokOkTJ*IeXo4`zV7=q@Xir}z^1{BkpV1!nxuE+AL&h7G+I!oj9B#a%!wko&lX%qNY<(`35 zKivk#;#Ez>>s>&;=k|t18&cvQ7%`kFDJp{WrJFQ!VoVz9+0*_~#@=O;z7M*oj1K<> z{kFvR*3fM!_zcfXr!g5k0*CYcM&2hY#JJ;Yv(=N&bc!Mf@;+rp&s8gZ^bb1)(Kl1? zW8^q9>a+k|g*RDQwg6ZgW5xH30U2*;!B4Q9uM*q!f#Ys<`el8F6QVLB`DWu`r#>S& zZeF7HI8KLg+{cKg^giQq(9bPSWSOPv*{beULbs;0uQ76lX4EZt z(s(!p#yXz;)pv*|ztI~qx|UuE_OveXa7Nd%JMk_L!_`?2a;OAPtenC*!=vZK=3D%x zkq41pk_!=kbP6^g$Q>|F=r&%*#`X^^`xQ7xn3D=I$=IhojZ0*La$`0fZkbd)LD3&bHlN-c z5%6mG`Q}ssvd65v8wZ0X&S=fL!28*Hy`ff5h;w&kG%dMImjbop$4N^D7=yosL}auq zRrD73IbE{h?&)#T(inb%nY2$l&JYt?wlZW3&fZw|0YZM_9AJ5hT__|3ZW`!2S8={L(LLecn z+u}qE-9tLX?JECXfNX?TC(%UgUO8)sIxqajVr>K|4Z8PhckEVFxXUS60$Jj9QRi zRz}Zx8Sk!q!#aKE3MH-SN2|Ei`4F9&uBc3?IT>YHep7j7A|x0u1J$Z=>v`a`s6BQ+ zN)kvz`DwhUWXVOT>9qmz+UZCFILTe4sx-(jqjKul5 z>WTeA8M~HWVL06xZ~5lo16ZHq&^aXfZGrD&d}C|Aj}Gxv&k$W$0R9GRK1j`I^1te7 zinv1t;6_^gd(8f)uzYIIckAsEe*ZU->tP6=b55KanMRIBr1@Sw&31fZes~QY4k$k= zbc6&w39Fu7KLpF7t}B_(Q>;$`Bvnd1DKT6%mrkK->3=40YQf6C1Wpw{^at7mxpjU} z61JyTNWzY+DoNnb^ubtl^wAhkJrnDN`M5~>m=!JUaeT+6{1jdzuC2mRxj#OTiQ%f+ zsvGe5e58&%v~0WUao}F|m?XT`3_;N1m_C|9$fOX4uc0uxK6^q`iCxvCvU4Q{t=!2? zR!Of|L z#8=GdR37V*YfWk;<^jfMJqB#1+oF@rbu>7)2m7t)hr-y7ymug9v#FLs5SDJtH#AzcB*L*Huk)4=XX*VVwC3i?WRo9LVQX)5Q$hpRRn@Q(N|CYGsF)BjD@Gk&g7D1_aT|pfg0vhBc;P#qRIhJG{=tbN)?xMZs zNOl6;fLOpY7AX|TqHukW8=&lh(k$)qGCIln-s#jEAP%@Uhxu&cG?f zpYU=rO^?0opy{!fRhmMDXfKU};bB|);WpF@mwk$~hhHAhhE135drZY6m-@RfK>s%c znanv>iMiNno{+8d!7%O4F0KlBGTI}Fx;c!N5FJU$wPCb~Oe5(?vCy~`2scj^8wu%q zs`A9LPdeOMv7S&->$?teJ=wl==yrNzq3-SD`t^*NSawQXnp$>B^p9+mS#wLpV@B8u zwZGelZA554uq?jplw-N8QKsEm?>EXZgl?2^NYws1@^Dq`_kS79V%a|QW6?5->k|p< zRDHMpp8f{J_yb9ZZ1+p`mIMW%*4(p=r(F*F#{@flBlJ1$WOK-C)I%m0;AxZ@O!qUU z11_JEd`-n^0H983Z-x%^WOJRV4LK7M1xI6buIT8(E8nqT+F!y7-Tr)3d{liG#OFi( z-?a9?r`;%s8#su-S77;+uWqHIG`HjP>yK>>C-n@mOO7ikZxkfvn~#6XOEGcNEVRNKJeS$2d-NYS z9#m%<_bG)XAuNrq&77Vb81GEk67jk%+G})t^#=1V-{N^BQY&PRwJ$j;f|pVReRq&o zNX^M86`-X@R6a0ILFjspvpNU5&>X0!6s0GvC_SheIm*l-!Z*0XnOtsR7h+N>n`^$| z{s<$e=OmgRu$^-}#|8Q0)|`Bt*~+Lli9)qfh4=Mf1$nO=BPT7t&C_{7y;&8PT$L9% zXJ2`w+nJ8+Mo}ysT@K+W!jj>72S$;O3H>m&oiOe1SQ;+V)A=JOtK^{1?|<0+L(#d& zh-aPP&6V$mSx|@_mcc5o|GWIKJ*!bAoy=7c#?)BA3m(d(&Iy|H^2-fUILl8_si(7k zxU$th$kGiT>f8P{EB&u8>r2X%Km0Zn`i~M_q_PEG53 z5^jWOt3444!GOF6wz=)^Cn9HVA-~H{(9JTt^|!+}#6bM)pvaI2)OlM;)WpJ~@D|!? z>*0~`{8|-nWmU3Xnp3H`H;t{F?v_9i5rdunAqKMsshiQTOwwD-ej9LO2~Lq3YuKql z){p8PCNAKW??lE}i00u!?6BKE=WY5Y3;8kcu(Nf(M&D(Oo-<0pZFYEC+~KJWE2WJw zt6F|h+r7ofuD@j@1o!wp0A=+vy~#XNNRueGz;31ec(syIHYU^mP4y&EY?^z=1+Ghm z@i#>Ju+LUD7N7Ro55|kLZmIN!+P}-Hip{Q^9J#Qf2eo#*dY}jFDd#iQrV0` zmyzY72Y$A$ae%u0P@?{Bd1&3kr@vj9i1W4ee= zk1v9@Y3{HRv-K6=R6SFsYaZ*4N`va_x+J}>S~-hR5WDJHWw8r5w@PBOSXZ+EkkvEq z#;Y~x8KLp+w7Tlw;d3Io6HuG+KoG@3R@~Z-#HGemC-`fsUJ){KRbYag6kP99#OAQo z@C#|p;%>UK-j1p)ZBJNl#1a`NVhvKh*fy^(zfgy$8S$6%dJ-df}? z?k*2~1k4{w3S=S^LHk8LZUyYrR&6

  • %#Qc=hNaAZTBI8^^2t554-k8PI|3pggL) z&rU}?n@*n8->myW(ocH!Z^zt8YXn>;@&a z^LD)V^f${-)ouX!6dyeNu%mhlMx?qVv>9RAN4SmRcts;6_220Jv;)JX+YFQZKJYTgp5!&nP zIO!PGpy>X(M*UrLJyZko%asP$-3Xj%()E=2TPkw%lIgULWY;^W?}{QflCTcwU!}bb z)FnhsB&&Oezp7XGjy=9%V_X|#pQF;1Rkv5Y$^Xr?x;BZ9Mcf`ZBKs05T{nT_V(})Q zTR?{DNyJy2CK2>*BXDK)NzePX3u{ZhBbeHZ`ZqmJ~?sfW-$9Pk9FJKY@ldOAF zs>`RA;$}km zXz3 zGG>m&))}=%1`Ia-5QAJ|fX?eFBX-TU_T8C>Z^rcA%rmaIryG*|X&&8?f$ntUthx1A zC^Rm9K2*WwE^NW(kV(`MmrZCl=~_ec31ssYU`vKUzLa49%gcq0woMQqBDV~qB6HTH zr{npaT0o=8%)q$NirsC<v;y2w`_YI2n*IXW3&@~PrBxwZWTImSi+d=3=OUY z{lW0N^otFDqMl&*llA_+&QyeHoO*vCEQaxfKd~~QSa0b?2keZ8T*lNy_MkUKyVoSV z2m|S@xUaxssJ*hY2Z4qJ#$2^(s}=Zh<|EfsRUFI{YmBnOsD6ap}UwM1&u3PjYLer zen>%>T|t7~OFi`*&r zHi=Q722M%*n0er=O?&(i0pAOIVdGPHIUo#{XVjUhw?u^&YJNngXL;~TF^M8@Ai?%9 zLFjyfSS0up6Yzd`oYsms$D#AX?2IlY$?V=FE8WR6BP8)iGNu?*FBIHC9i2e1b$;hfTl!~y)(@?4z!K#Bdskq7%N)XJ8_|GiaUAQO!G8PZ1;XKs8lc= zLezadd>_6UwDDGdpR6}EfW1&+yT1c0bju4`K5mHImq1T?SGZdNY{tuUt5>>9s`*)P zV|dMPC1LwE_;~i?Ae3mIaKDeK{^nUT%@H|s-b^R6^i}lg9Y}Y6wzZ1+WVC3j{)Oss zOZg{|h7e_&rxUVD-$c&_I(8ZSUTmQC5+JdMLUpZi#uM%qa=Wj-#8^cU^n}DFeH(=j zQKm=GE65gTwS&Jd^rt#@!C3msQlaikbtYHV4w^Z3;eFs^4E8?BViO3dE4NzD!e;9X z1E*58Rd`4>#BZe1lTBMo1ip-LJLwTOG=xz;5G{+`3SR4>r?@?bq0w`&AR|B~m`gcu zkP?B@S^gt|ZIlv$AG?5jYT;BM5;GD{n9^z2m9%x+Ul{h_yBeZNNmkrOY(~>k7-#Co z!%w;QzCUmi^Ib!(d4Yx!oiRFNA|-?rRHsec>VO-gumN|Aot78XltT6ap#o_7vZlzWI zp!SsQtS#29>VJNn^mI~HMOVnsW1RF8T+?ZHO0B`gRmqLzzQz)R+Y1a%E5c=c?7SLV z#pLCm$dK2BJ?Hol zYp#BHE07ivPH!+jk0#m9BpId_yaL2h$r)-E-$rUjg-ePO%U0WnmcfTn2Cw-M8N4kl zgQ+5u4DN)gyy-v6U@ib{K$5>^jaL-0 ze-o~uEVayDHB@g6*H65G>7mywnTIoPAitr0s!&sV)le(`E57NDKUB{gGnW?=NT|D( z?CBQjt2jSexRSP7m9)&Nq#)MuIK}@d680$h+scjHwOMs0nHf~NR9yc|?*SFYM;w&ELclwe7^(BzR_P<(_ z|4!NmQ*1l{gbyY7kAP6m9r)ZMxUJ+JP_F4}-;X@C-~82Q8&Df)!3|lj_3(--5YF%} z#DYNPwj|t%EX~FnH=NUWWAL?f-HbZBp$@|$mTKiU+;Q#5JA8uzyImRQmVC9YmT3HU@J2X1vG$#3Pt~oCx+D1X z+rjk1p8YUzaq1maW3sY^(;0hLc2*qr*BLXEb;!Q_GYnU3UXOgtX^@`c^*g~B=4-e3 z(n4qV2U?xmn{$(yODA^|p%Z@0x)IX}yfD+Mp$dE*qAH4aeIz6)cq@(WjL}}Ol^@5QRpsaKsJRxv+do$Sdr#BCo;v;)p3bP2r!)TxPk*x>g8f#)x8X-B zbeC+t14k?CF@wxyv;{?3kD1@L0tD2w5+jnA8B?jPw*8Clo_0%^mAE*vbZGgxwmdAksXDGzCP1*E*D+Yam|Vl9?W(4So&Z?VFMAYNC6X z+)fM3i#9_B-$a^?7-Kup+)p$L#q=fOSWFljam3f(w||M$2hSoky)kmGWNC8X+=8Xv zz&VE&dG>vrh{lYi>9~GbOpwF z7n-g|6K*`-J{e6fqG>jo{)VOsH2n!pe?Zf3(6kFpI+_lm=@B%=V5#}hbP1a7BhF~L z6HN=yG!sp~Leo?v$8dzF^`r6P&tX|aS3#of1-I*A^s(}2)q^j zm@XQ0?>yz@k021AF|Z z&LE-|Z?S#{k1=Be%xN~>jEcf>2<}L&J1Wrvzpp=U2f3cM4ETy@ivaesziz<}M0pY; zp2ll?b**-5dCxoot&wL)emy<$N9b_MzbymllD_>he!oIGe5u(eqx4W53RnS}1KBX% zNNVC<`xYbqKoUKSIDv9bZ}#jrub3nVq)M)zJQ8=)PQmZs1Ki7vUx!G8k$86!Uq+8h zZbSkZbrA2Xho2XI6Y=tWoCh!jyiE8?hrs1N(OqPY{Uu#=I>xi#v&U0w3J|Pq?PDT3 zrU&+;o-JstKN}j2D%n#0qbQX+>%xh zd0OZ`pF3p%URi}#=HOxNQ2U!T>3+zg#e6bNp*UeQ%m?$J&{N!=JtA#(#@ko>?Bys= zcMpTinUzPo)>Vrl3n&u1DTV^Y7@%N=d&FIR_Uc`D?Ka?3*(dVu=(879FJq;9SlU6r zO~Gl~0q4?8+|rIubqx3nOcN=D$(Wmc-ov}9b#M{i0PTKapN?$2q!wQhpsl}nY99EE zDKP)1nl*V7-{=5TIs`PzEXbv>r|93Cjy&3iKVBF4dar4UKAOt54?duggr&P43pY}( z5NekGot4kPwJ6QZXx0KdaWIWp?e3Y?sSEga!rLc?GkXuW*YJLCdfkF5;0~OVf?Ajs z$ZRI9G<63>DJcsp7va`rQB=ZPg~NoVd3F^@C#$wNQA_u9LTvCjOLR2>5#Tv|pShr< z>;}-s{*eR2Er?V3Y3wOienuYD9vB5+K>;$i<9*xv{?N!(e!*) z*Q%WCT;DU1EZ^uofu?Sq&s>&e-Ir&6IRUTc3!irhyU&QYzXk62TAC6~VqO<<|Ci-1 z^>FW>#k$VqY(khZ5&B1%zD$UwcfTkJt!jP9GVGjI;Y?6ez@bklO75v_P znazI7+}j>D<9%(1&0pQf(}pILviahTxVxyh{J7AeHxsrIz`RES&jDc6{S#pw+_$+Iw$4(Hm_R0Y-1c2P7`qikl(LpYc5ygg!zAZWA8NJo=vm)JTz{gFgKrv#+h;R>E39_!&J;eyoa;=W6H$Swxub7(~9rL zt#}a7{Aq75%kl!JWBfDaL?M(p11#UPDGN+#Jrb2kQ=g;(<@8$rvH_5#Nk+@^`?jKBHa{ERJ9_^dPbbwOJLo~oJ-rFI3~+R0zR=rkD-My&-=6Qq4qmVx znGc-r=I|Y($eZ(eyFnrakXYA30>M8Hnar{01&O04^YZi1xWHvP&r4mOv82EzgZx`K zmW6Q6=}@Tbtul+?GA6iW+~C)tL-5;4&b9B?$!gN+hx${{a!}5-ZxzD*ZQz7r7XB6R z4cy)lTY8y!=SRF!aXExH8q8bJxe~e?rwh*`G}Pd|^d>%5wbkt5acGpsGarISbas|S zdAbrl#Ljb=5LGE|v!B2_RC{fSoHj#yS|QSY7fQ~<0MMNm1QmtFTdeA4h0ogbuM|N6)t7t#JWf8q+h@cyJ8 zUVfN=(*^mL)ZmoCbwYRvlu z4Mo=l8f%MrPO!{9;u{Vd;<_c{N8*Zqz1O30zBBU~@~&W`ENLDYxiVTQp=jW2s;TgV zt2w2UjxG*224m!m(MSP^N;uWpFi!2?rPE!#RxG2ldH0xJ44huGb&SQpb%FiMxch33+hw|;1?nGF2gU<5 zm&2zzXT155jSffUjPsV@6d=lnLzE3U<})$a8N{yqu2d-5iGGf1`C>6Hh<0pDwd zBy+&CENh>V18BX4ttIcEP4#q@85=^ZN%ApMS7z?U3C`X|UqG3Qba1Dl!VI;J*n=1kASeHPV> z174%>?B?mDm9^$TG5QWrEI+)7It+8*y>4PEwwEko zt7HRV;?Y>R@0GlcH1}J`N#m*~jW>UVb>(rYppRikjOY8$+n+QoKV0ReMFn8GnUnh? ztK@#p>JyUlNZ6<+vj^z5&p0QX7ZtA4QQFzz+P;b38l62U!(I5}+f>^Gl6gcKp7 zvZ??(UDZ!kXaY+S5z~#>jAIIOu5|wLUXLX>>wbz9z0sWTD?Gswj%|TtMHC;=Q5kom zWW|AA{9@eI5?hnQ9tTDfxj42l;n>o%QiS?OwBn0oPQvjx@sP;4#4tm=_^)@q1;z98 z?Pp@Ie8c^Lz4Hy<>h6(mpraG`pK(=8OUlU8v=#)pWdh1$UgfPPUvp6llTeutc12#3x&$ z-IKfB=}b7d1(OAu3QXn~_3)SnDv$sVwc|-mbeZnPH(*`++V>sY_u0M{$6+nl0i#2p z*$wea(d%%Z-^t_RUhPp_s~-pS+T)lk?NNNsXdGUFfihUQ)w5skxQ*}YKY8e6OW=?& zd)^&AGYvDW3Nz+~dd#Ks9o|0mcFTobv}Z5i#Y!^fH9JI?H|v8n{poSskCs59lF-r+ z?T$#L#=88~a=Dk8bL3 zJp|n&GFU&ckn`y|PSnE+LP=dTj=)>)tV@i0ROo^kSnBz-=`wr(J9$PZ>D!Ukt3_d7 zR>x?)!qLHllWymT{HD9dy2Pbv!CL>dSTXWR;q?OZM2O9a-h5{_EVtM2KsC@Mwf{SE zled-rqywmVng{+!?Xh9TE=iaJzq{a90>As==Y!t^@GFDgWAIxAKRyOz><9gPGkaZ+ zjA*8^qyFN%PzMrkdmHG<+6I1+i>@zg zsL7&l8GUh955DxoEWNE-gXi%Zdfo_DFvGf?oNxEfH&zjxW~?DtU~D2d!^{zAXcE}Q zmq+*=eAP4#DQcn2OD=VUANcux1nKCg!H@V2B{f1y`W)X!ZM|1iy~b??PZva2@Dexeyse9?D~|al2Qq6f;%m@SAiNrMHE)vn6qkt)sCy3UgOOy*#S!;3)Pi?I zPA=q2p=oYHF+!mo#QaBJR(uGR5(X~Cs@sn4Z=Dhc17Shhz76{oETFF>bFQMZOo5WP0M z?W`)sDZYk?%9u6}+OH@(c8(EOwBZ4_^Uf3Q*5AT5U3RDQjB&5iQ|tJkvRS{^X*NTS zk6)q%aS_i`+u0!bZ1lWcXG50HU-r7>*`H4W!8^nJF_#w@3W&{yDl?TuNri6J#?!)8vF!$*n=|_R& zA9xjS1Me78c)OLk9HUSVZKR*qQ$JJhsOp2)A(^%3=t-Yui;(YQ1C?(B1QtHFS-=MZ zC*l=1sn?LeO5EZGgCPOGo5oF6d>*~N{VTeK&VO-dwo~>w`6kXL^AcR+NScfn1~t)Q z61LO2_P32>eV~zq?AGH)ceNiRiDs$;!XEgRG^5r^Un8UsQ}@OhjB-@!jHNC-CO;m- zXfd%e(WUWjqsZwk{}^Z8O9j0MDuw=bm58Z^1b3OcDU;A+7J0Oo33MM`&*b{zFpY_H zANhA2H#(9GgBrGl6N~eivu^KwKio9E&ctd0!8VycMG?>(p~)AF!*rgrPJfSg_EGbl zAMfex-09MSKB`?VPMvYP5z)t%3Kd-$L`JvPSuwLRTA$2 zt}P9PqH5=ac-5!sO`)VSIJ1L%De-*pb32_JWi!O|$#j&N?d3vPJV6CBa$Ne?9GR-S zoyLRCvSV)rK25K@+j&!P&m+U3`G@>D8DINiI&++?*}wnH?G*>)YJ^(r!s;-x=in}XkInx^Tkx+XcQ22aoe%XBImxfn0@*!VI zKrGV2f6Sz3vHL|Q?tGd(KxiiMM5OUw;&kCFt{qog6Q@DUE38RZ3x!U!wu@vL+ zF;Co3et)>^v%(dQvaQKHJ%W0>*Mo=s9|b!fI?NLLtt3!b-U9YZCxJsdvichG*O;d0 zC)1iC4SS*1O{Su;EIn9ap zU5ez_ia6i!y;turey*77&k^&@M38pM%whKab?2udx;$p^YkY}r{S7)I7Ow74kwvZI z8=%nsbtrgPtDq-{Ca8fGs=yXcXH_9Cp(~yBSy}~-TXnp(tx$m;aXKo`bj#>oTI1el z`1u@b?=h?0x*JZZ9(9p1myVGb4=Li?Y0ct39CxR^rvnz>G{r#ks8R|5;f)BQjg{LESQW-8=L<eaSrdKk5{xH z_8x#e!Zqc0bg%>rms2z#WAK7Ku|BO%Y{1u+^(nMrL}{zT=Y^&^U2XWJ5kDI%zWrjz z^WM0J6yME;U%A!D6?DH+y;#)!LY0u(#C=#-y#Hb(8S^6~1N~PMYdc3RZv?NGcj29I z&jMn!h4>T^uU1N!9a*?pM9Da$RqO+-wXHw$-uwFNss5n7t#M3u`wpCNZ}AG&WC>L{ z+L4o}<2Vb-2w(Q50-fkig?8<9n+LD8&iZ&?3x(3^=?((iQG}0cxqDA2hadL?g%x)w zf_m)4qg_ApBCGXQpZ@NTkg(dzliX2nh+0FE$>B%r8m#a|4p{v0fTO0+d-4*6?hS8& z6KeNOE~E`bJwe9EU;6%>uAXNLW=dS-)uT>q$7CQvqW_ViBVf0aMIa$*xjA?o>LpNj~i zJcgsR&5DxP2svz7K05DE#)UJEpM!DX48Ra*?nm>z-E#m@VGjsjGZPv8AHZE7Z?wPB zy%fvx2Im_tP>sU`*dCI(J-Givdnio~Uo2EAMqg%(#gW*_FUU#0WH8~-So9@W`IF4; z1&@p*M>idoe;5I5iPrOcosA-&0_kj&eEuysSAgS>3S6P32f(ZW{*Oi!R|SO9@Q@vk zpr%^lDsuUIDnxo-XQRtM-@5sze5cbI<90TxKKm9_kJ~G@;G#wwK7WPSSehVi!$Y2= zMbmCl9H+%@z7(zV!MYh2lKu>;ajH2mn(8x{)I}<>dz((?`gmOs-E`0rA3!_p|QxFNYiBI zt;=~EC5`{|7JlvFD;Pa}(Yv`6nvzA^(nHFeH-Grx;GXk`RR51J+ErrDtRo5LQ*f%1jY zW6gIODd)|1wzXXu$JO2?m|7?e8COSM0N0nQp&aL2TBIQMb>>Td2KJ!h3&H)%62?tX z{Rzg;oVV&fbNVhrx&~^VHIp5{?lXK)%5t=kqmfpq|4a=hfl!eVZjErQBD7r>nYJN& zyB={5v}$#&iY*nXT$q+9J2wBCR7gS_KH_5eCwpEuKNnKId#k#I%Hh!G9$|kE;Cqt*M9bDs1@d5a9Eg3qG5(4oX7#QA+Dznh_dJgQU!fba6G!L&ZOZ z&w+TIHD%yo%WC*+T?@Xp3kUI1ZR9i`Ibqb+&p{7K^Xb0pHRx^hT6#-l3bFGNJ4{E7 z7kMp4FVo3O5qzy=P0OE2RelTB=ui?esIH>%Ky#qp#fXf({;xcH%}Wu>uZZALHLB@M zK$Y4uV*TCG(ISQIm}Q$=BX%o+@f6?qsQ6}5d^0J6nHa%4Xj$Gm3xd-s@(31WB&e?LxuwRTKqhXOlbF9gpGOV8bNsaLKHpa zEzxa35xE|#T$XvLKNztd%xbXYq4ju;FNf-gb&u3A^24=WeA|$5<_-m;&t}%lgbF+w zsU`&K)r_x}9i)0?t_3{Jr%*|8JQ{8IYy@$&Bx`r@l6Nc2L>Zc%FA zY3JSbzz^6pRKB~t6B)KJ!$Un8E{`zmv=}1vC64`>xYUN+8j&?_%WnV5KCkBjaU1Ub zjgn7oTYK66(bI0-|K~LptKC|z|Eh6=&%{GJj}3PEhUlZwJZ|u!A%IamAw3gKIBSGS zvR?SH-V|Anq2I$(WEKpk*%TQC<{^-hppt~F{RLG+ zjzAz~$GR$yRh7#WUR59sK_84%#_d-G>IMc6`?q>J_0c#1&$&$;UoEia{Qt@Q^dju1@iD&kKY41Y z|8JW(0LOl*LJe*JX^V*zI_+=316X(-OA?#6V_d~raW}<{9)-EgNH($*;@p`PpXHB% zuj=b(UfLE4P0(8)P9N$`6q}5WC0}NK0SuNN_3Ur|kos51zGkD3IdK@MT@zgA&yUjr zPGq{&$Wx8U&cOGgPs1mxk;+oMs)}*G*|^_XS?nY#HSkF~=s|Y9!(0wJYSpdro=|6< z;!CW2qwJGYm1gDr@lKIemMZh&Hw#B4Tzz|C7(=e-Awm&;>0dTMz+C2SA(fB2rv z9RfbbfStfH+ZLKUdGtFFI(1#i^zaKWFEr3Kw)_m0GOK}&jaf=OGK<&}de|Ic-_f4c zS<_`1cg!7-!zXpQm$FaWR{}?PGwAASx zx0v6JqczpT%eTVM#y*?O8<|_Yr`EH-O04RiW^ufdIhsV*L)`QFQfHm)znl(O;ANiB zZsTc3JznSu76(7~jSp>x`n*;9=iI_`pdJk3$$)DQPW%oo-(2tbUYk zjIAcAqgCJ$#2UQy)41Iw9u`~ZP?_g*BU#%qMjyskQ7m$+y3g%2Cb;TOyQ~Lj67^QV zr!*#|ow(Ef#PQcawxV0>+Hp4?DtZ8x1_Mf4)4$48%P#-qhg!l}=m_ObMU< z8a#av-AjGgujz|Zas4Ljv?X;Q^q@72@)aGahthoPF5i>EtIt;;8ya*aCOsHW_GEF<29!UiHjT|67=G4^qaR+R>dQA>-%H zwD-{MK5&ak`|P!Dx3joJ-#OLDai+Z!=(71Q!>qz=YJ4P?B1%`WW$e;^i7z$Mohg%} zb10+nA&c%drmLQWbT?t<+?Q%Rn1YWdq((Al&1uSVmwlhUWI)-N zjOB^Ri#&xmy;>P7U{G^1<6(Rk_0W^d-vpjAbKr zGyE)4Zu^?DQ^R~~fzbEIvQt<4ep_}beW{$={&?A`jAeRzC*b_M+UxYAp2NC{ciG^Q zlb+%>@lmQOm%gj))L8!|cS! z>P`C6RPzzuAW;We?>Gos&q?7Ot(|lz-^V9-%QCL<&81*vtjhS7Fbt0L990LY?xG{+ zihHu2<0>0F!hbc?VEw3h1xx8VV(KirVT8Z0ezZDIG~>_FD|LuYZp=x+YS3ZR_w3(Fw?`+ToZm7L zWTUx-{8pvHkS>LZDu?VEh@)RL2O`&q(*oNTbXi9%sH+%GH+6rE_ZBpni}8)wQEnri z-0Rc6s!G=1)Z>v&+38{a_$?@qv&?%bm#fBdU}d3U{wE-psDCl1;t6rWZzj%P>m776 zyOB8*oHx@A;9sXTT3GAycw@L59Mj&3P_IK?I(bQJ*2#5!>IIU7`ICD+)ew$y@jLLZKT1=z)XCCw@pw&pT za31F;=TOy))`!Z*3ckKo11pouPRIJN;IvUm>=zqkIR*mkoyYxys)((iu#g8 zI9&p}(!aciz3< z6U1QcvgGPSLHxSfnS4`vDDat7HDGeFJ}_9jyu;c%#5YiT_803P7YB}=SyQCfjm9@u zynk9#)fxPBhRV{%6JlGZuR>_S9-m<0|(mysyzyTRqwjjXL9EEr^mhV}_yy@mOfa zt*RD`B{tC5+ty%9A6;%y4hU1a!jv3fDg@}S9$oz($g+U!*6Pu}{|{tfZNIX5^t1ng z4Byofyq?-D?dc(chOc_6fmSWhrD;Jr4fAEZnO zQv&}VB#I9ch0DG-jijx@n~!LhruKC8=mn5Ih_fD}&y)3A?fQ&3EEL4Y&_vsU3I+eF#}tyT0VTQ2Q|)+%slo_CuTe2KOu^^6i$k}~b- zOcB9j7hClaFemHDr6Mj|MZ0}!9;!)3p-R5>x3z6ew`f6pk979j2F-(8jd)YPbu;`_ zry&|s)vHCl9?cUJundClT$kPtREeIA1l)jnnxZ{ZpIFzLc+&6OjHgOr(0oLDzPZN( ztVXVS@+Z!d54jk*Ci1Fl13flw5AN~HCqHiR=AS&G*A<=oSftP12K`{!ksCYfQvEU7 z3(aqT27OeZE!DICZL^olDR3!kONH+B?XGC2XY1c?ZP4q%$y59G(FVb>f5pX)Ju70& z$&eonCl8)H95^VLG-T{slH%{1(Xc!rtwnE0+mp7R3JFbzfAjd>hQb*$(>nE&`gh{t zK6{q*%LV%Hmg6%$Uv~BB>=T;0;<9}Q_Z?1a8L;=eC0~eyaqer|cUWxcvv=v2?F97( zeIE>lPTeuD*LC%SjfSi=Wj|H#4}S=Ns5W^?6@ zIE!pPnT2aW?Ix&DE#^>UY>~itWS`-xo+awZm9e2LSMT{4d@pEo^LLV9W`j`Lt;7gD zr+gxp>8PYbf26+=z2#5RDsWjz``0PdOYmi!$dyW#{4Ic{>MM(wt=+`BjR{Xgw}3s_Xw)#y1h0}MDgs9=auJSL+7 zjfU}&h>vyv2M`5EKt+Q_lo`Pw5I9HC7&B&=WcC~<_3xMdO`ATnroCyJ+uAlw)ub(t z1i{o6wK1q|f+jaPI5E+fARsz-t-a5{3~GA+$M@au-v2+}w`b1TkF{TG@4eREYpva@ z`Vd9=Axuz|@kc@fr6UIS`fzW!8*k~ASH#Pb4*9s0FVgzAYDhm;0eb1lJBd76(Ilw% z$ygqR9Ic%5uW=+#=Xo+#w(6j{#26|?*nsy9K?!6ib~lRUdDq68+k0Ack`3h^frFE4 z4C>yjxshD-YL)dcw?hA9_B5x8=@5z37~Ji~h7L?D#X3Lk_gwWzbhlOUtc_L72>G`V z==s3;Nx!ETN?_nAFYU3$`oE8jXTc4Xw4>6G{0CM1arLI})Vq4uJf(Ft3N37(H4Ohy zDLh{0Y@4|uMIwdW3W)~{%)SJg+9Kzn65}xv8>I0{95-n4VQ|FZX#u-=`h9ZDn|K(d z@txNNDcW1lTbuzwyoQR1JuQNl#Ua6b2UV@B^CDcS_)0=h=sb703`LMmU!OZF%Bn=-A{EP;*_HKFj{D8SY0owNn2F?VU|Xw$2QRQ8|Z=1?mn!q z(IsKCryI0V89U6mn8q%OGd5tzpRhOIpa!o|rz8*fBC_2;@^$R&=y5%nLti3;dKT)& zZN5(4Zjd8)f1(96qZM+v{;Ku=&eb%IWn3#Cnn&SV&`6h>rx@YO5&U~u|2**tPB%GY zhR*g7C-Ly?{PMzrP-!(i6OvoqLXS<9L`X>DO+nA_^^WS(vc%>dcDfixI-zPOr=Wfm z%||)?G2I_Q?>C0LgXv)bYzh&uk2PPS>Js%s%Y``8S!(#aCp}h>l7Xgzij5-8s@4R` zzN0(}3Sy7&u7=(h$lKWe;WGK|OHv|u^;qI~(THgZl9}+fhP*vARVym%-j5 zgJ*l}%Np@DdAnYIRPR0~z9K&kiyUy!`vKk$$yJz~0o47I)n!K-8&UxNy_C~ZXSc}q z2(BE$8D8o6Uod%=8k~O?{(x=kDP_@qO=a)Z_E-V5_0dLX9`;^2laj@^`M2HD0|%l^oHy`o>Ao&RjzrO#`D) zt$!PnA{z8yr@t5FT3tS=)wz3i8f1;d-0sZ@5RL!4KwltfN1FV5;B^#xeQDTv4xW%r z;pl-;w5n+X8RY8Zaf>rau8xfJW-_zs=uhQI5F1#xmjE{Oyd{W6)VYYEOqX(Y3KOIM z_&TaFJkHb@bNB4Z1q5PuE4C>kp)vh0 z%De|vASiQs0gy~5PNKMlwg}^tBUmk<;A!I6U}AZ7y#E8q084*d(965spkkZzuYza0 zA?P1AUf6k^@}2vTY~L04vJ+tZ*-5pDCQYUrVr@$KKp+sLvgqjfSYK`;$PW7O6qTo97s3>EF#{sz!k7d*+kq)N$tYTHe3)~3->*&P-=fsJJUWNc0&;ZH{Cb~;QK3z+X{3+gjap=`x@b<7^F8pERX)7B~v95*d zQF2C#9hB5q!^r*>0K-?z`*imxn`fz_WhSNC#HPIIfMj*EVYNmsU)gwGUAHL^x>VRg zy&&?+$*N@I;Q1mRjp01J0I!#e_1Spb=ZtX9TPT_FZL)I*&l#U@G`_Cv$BRvo1c3sV zxi5+LFl+HcvL&B;bNP&hcB$F_HdB5&G?N}aLIUw02Qam(QBTTyN%_EmVw4{PQpTtI zpV%6F2fd#sZa@0B>XK2LW*^(HtQ!xt z2%cu>mA)&%>Pg1n#lOMxS%XPVKyZ8$@k6^mhf_iJWAeWMU%(6PZ}H0 z3ZM6W(%0~jm}qYFYLwS8T?@SO$}iwGt%Y3>djk5$=%zR1B+!aoOL?y;pg|SjO7t8{ zt^gt%(E=+kuhs$S3$y4I)=aSGWs=Lz1yP(B1qe19+De{If&3-qGgj!Pn;Ozat}30T zV5!rtJvq{+Gg`cH*&bUU?b^<-n1}_CVA(u-$?&e`(;Lni-I)P;Nl7LowuYmhCxI^F`iPUm-a8H4w`}y>~ z1A4i^h~0h9b6lhG>2wsQ@B2Q!KRX8n%6C@=0^dX9%) zhiCdrFdHcrm2Z3)d6tFf1$^{W9&ZxNqSv24b8ayz<5ooVWe2$ysp@ zIq?Xd)H`-xKhrNo9r0kmi}-Z~zMjJ`AAa>pF-N|IIJ*U&a)gx$wg=&=bWJPO$`#?nPzJ|N%sPWx>3E%Kyn(hzbZTEaF z$2W?zD1%951=VX#XUECf`B^2>2v?s@y4UqYJTHz%IYC#SVb|Z;eG{33XAe66pIm)W zQY1vvNoQPrk@Qt7{lyoLgGzQxr45!fv}3|*~esFU1y zBP$Kx3$tfrcxiEJ@$D-1{pL+PyK2_|^rx==a;ZzjPfO8JZm1ymY0;$uf<(cDp~_Ff zVx)!^7XgVn*)^XN1=3~P96W2lnI;lNEw*(B&qQ=8U%Z#yWU`VEZb}s#nY2g4DL=*O zie9?C<`(%J)w%)Q0e%^w^%{)d`Z0&HmbgrJL}@wKO${^`hTQ~4^m`!<*;&GgtC6)e z9Kj^!M#VcRq;@EsIYIrh6|r-U!(9mREggwvmw;p7ZUBV+FU4X-`CvuWltrDzs(fqbT^~q5QRyQu1M=?2 zAM-gBfuEnFGrITTI#CR)kkS1!B+ojPvmKPTYoVIRNXIVLFk+uvRz^Mmcz-oOWv)@} zn{=*Ya$m|z9dxb5R39tZQ>jqLL|9k;J`GZwVq%Z4A$_&vG>T5KGf5pClX5JTgpcRF z1qG^fcoC1v^zCXqSZAsAQru1JMlo8~Jk-U<35xCsV3kPR0sM15Q3yegAO($^Af$y# zp$wOwUBMbeDcLgEPAJCnEZ#cAB$UzieGApws0q~$_^g}l+Db-Nqcd2e?e7AVS>$v1 zIaCw4J!zpTe2{6a)&hP%RV=U;a>PAAhtm2`R+VKXYnA=M%-TaTGeBnkL-GWyEZ+M* zKT{`Fq4-xw6Dw$C>InlUtqm>v%-fay4-i$Z)Bm%=Qzn%>rte;ejeZa0_pINm7Bo|@ zTvKiXdINyQBr!uBP;@WSJ7}wbbpR7lh+}y7ZACR5G17caZIVva+QGH^nd$@qHl-VtGWh{kPAsCl#vsQ4ELy;)lTnCTc>@2Ax!a`+bp9`31NwBtz5jwx=cNv)`!_gW7|I&A^RQ02G?~I7=}3p zZNCled1%y|z*N2y>CmM>OuvCAfv&z7X_hy`@CFyjaW7k>`<=P5ak8eBiNro=%vNQq`x-L;1nZ}}d^zyuHd9#kpgSZCVF=>$^=5LOd9)zgHG^%I{-xX2i zJLw*b0JsaRtKk3pU>tL!r)@a#%HerQy*pZxVO%E+dk!%GxAKQLk49Av4f zEHwb+6Dcv_N3nMvdESJyT0=mbB{$Gl`BnPoO}093OcoyiUK1f)B+NVTo*E5!GwC?+ z9L2le!W`E|;obHnrW`ra_q+*_kTkGAMR^Ui-tn$F{I-%vuQi}T^DHv0ZD#=<9Fijae^G_YSfWP*@hSS784B>Uy^6I z-qw*B@`|A6a=O_ZC)yC)I62AHq9;kuWe&)N6r2O#bx&6}q{qr5aXWsbyqu`-3l^{Y{hJJ2!Yzft+a$0EI+7$820iiKB;Ov| zJA;kaz#5PKbtw-=s*Q)=&ox7x@nXahQzdYxH9Xpi6M<7LG1c>J;IotZEaf{=n!H7{ zkC*l|>!pd#ou+kyl<3-NTFUJjbwuE(>_|@Fy#U1UD+rUE2W~czb+>m^0I%aH&rK)r z>puCE0x2soWol^3O1}aDo zJ8voQPQQZX)EgTfx&iAFwubS!Y4AF{MLweR)yh@mG&$RvIaW~c+7(qP(>ZslIMEyD z>`$$o>g-S3Huf9%HF0dTU)Kd|{xih3fRei%- z&Rd)}rix|;Yykp$_^~DWFkpKBdGen3v7~DsIFIYe6FSdhN&er2g4YB13BU#Wa(HKd ze%(FJ{>63co&8zH2E-VYWmL2FpEW*%=Qhs%%DQ+b@Btrs>yn&*i6d>Ex+ILZZLG7N zuapwJg%h2}cvqvwQ#cX*o&DRS-$N0c#{~;yPos{9s1Hf|o%Nd8(u>|D6P@jlKSEdIaXsoEItj-;NWI_ZR`kDlg$|Le}{sZyk8%~*^77fk*= zlG?gzHaDU@r01H*=_%f%j0T`pENQ*cm8cLIcWRF(68Vq!VU#tQ&$(^}q^XW6vf1J8 z5dqCemxFxaYSJj*NnplsKIB{cA5eQxQFzJW6jvH2PDs1@)ZH}h6nPXzE>|OWLFB)u zUETFpYS#!8PUedc{yy*=}d3>%MO5kph)It%@V>v*m$CJ-|hGhQYV(*$jZjNU) zpZ0}x)fb=aZrmA_)2d0$^?#*(z@***w05`v|K4DJO|U$~qs;ssWVcDYGC9ox2@9d(@ia?bhgd+#0Z`|UCI8f*Pg&!|~7YtH%1RjX!_3RC}4e|ps`yi1{O zv7(2;svA?3BSt#=4d|T7)d0XU&6|DlP<4tLZcys0d-vApp4De-&SVitD~o=b&4a*! z$#)#oo@E>NO}V5f?I+cbp`}Ss+!p6K5UB?V^2JnOm39LggW9am+|wOInQ@KBcNfF3 zWaybW{-jzZX7?h?t39AIn_A}~_h<>C`j*SRdGyicHr7Usz@FbejlGo#IW7P}JEjw}t!RcEcPRIZO_W3Z- zh!%e9as8~kFBJn0UtTC?j?QbaJ{O-Vxq>H7*BUuscxiq0H*+6s;SZBVCKOOVf6&Wbz1!aWP5M z0}8N>J!+zG*MQ9qR%v~{={bB0TcM|^jibcP^GneV$v2EaNOqa!iyj{6V2U904a*+@ z9Yv_BA721{01~W~Bf%z*!kp}mjbqU@mt@{H_n$8o)Hk(oC9F=amM0}{SHeKaKxQ|R z6J%6!SHZXkWPuJff^MN{i&%_(dJ>wbt9$!wsm)8P&?qcRD`pGV_?cNsp-5KMl$m^t zarZ(W0CWRQm1{58*x4O99Z%Km2=#3GtZ=;?^z!kf#7NxOXiA`vq2|XzAJ7duw>x+9 zWI5_k)KcwgmU(|Bv4T9#u!aUHJsR;bc(HR#sRGkLr!n^-e={Ekw+*%3fS2w`QY@)Q|nj6Vv`OCarM9S^!nk7J19 z>lsUR@jV8_`Xl3#;=6w_ArnU5xL*aSl#WfaeU32{(@`}z9uUwa!#_S&c`nt^IU8<< z^=njr19!mdHc5%N5abF;%}IUo+zpT&KE#Q*{ljs-2SEug_OiaOS$n)e8N{xJ9&GxC z@f^&fx3vUp^-I;#qb}Ym^Lh&Y=H2&et4@NMM|jD)y3J#M`v6i>CV_D!LixzyJ$dJ1 zX-Ov2R`6GC%Ophq$K68522FBL(c0A$m71tHLmE9I}Xg7_ug z8T7j$+d?u#y)NH9>{W`qUfRsdW6<%{aoB-BL<23A7?%@}?nO@g3*+QWej|wlU4DA@ z0%I+ohk;D=2}4z2*FJm`T-8^792n?Ey8JZvw@9G#?j>G~3k;k#}0WP$BSSUVDo z8l$!pHYofe9Eg*YVNG+$+8wCr9DU%mSQ}>dASX~-@Dic0WXTJ=Q;v@xfs1p#wsj`Q zRscC}%6b!VI~Y42;hx9PP%Op?`%*N$%?QnhT5z>%zk2Q5W9069lpuli-~?3$Rn znSom6p%$8V$hkW8>&c| zcrb^vK*p^OS-b_xuVC<-6;fc+OM{tQOc4A*um=y155*-nIp!ur8~gdmL= zUxhBLc4IG@5@d$w=b~rX+?Z>&Pq$W}3jDzDdg9eITl7yWS7t z=t-d|y{vDP);Oo7L#oH}jq2RHu6hmj{AdJ;Nk)`Xd8tuKH1amRt4NdCOEe~6d{UZo z@`W>eZxyx#qWG#Upe)oRn`?a2y+EA>p8$s^U=B15naV4k2#}05MQ@Dm+n4&{BkLol zvbJ|Aq)rMOzRdKXS*)0WV>xB z9VEkeqB&F!PAh0<5t8I&dv`D zDg9~B!z7xk(j@!2a9n-m&1|HvB(;@ub%s#Pqd?z)=fyj?!Us0V`3A>-;@VmhT%(q8iV^Tq|9zP@e@~%%*c!uM((; z9~&pz%WkbMP7j|3=h{IKen3u~MymS^JYm5_E`8_ZRV*Y4BxosDd?PZy(>?BPboW5v@Rq?d!sej4gap zo;NZpJ6 z9s$jwqx}lE!wu+Wo zL~7&&6_CEghYhnLDCokl5UPwgdB76P355AF8l@ZU8dd9zW z+2v<08^bLY$cSX;G1V^%@sLz1J(+4uJS!9gh!aXPf*sYBYnm?e-W3u}M-fx;pg*~}Vj0Y?(u+X=F#?e^8Ov8%wo&wG z0k7k6E`yLrX^>N^<`eCqB9kOWNsk0YfHWcR?RGRhAD_G7KrWzy4rla|<-AFo$P z+%0gL_NVLduUoCnyIx~O^}KxLXVjIP{ifgt5_&2s-6fNNjZZ#Q^_n*E#<0Yz!!gH} z+;wVU`3=1m&6>b8kNw>~&6z6`DO0LJV{V!nmxx-=@j=}#>?4YCqww0G@Ro={KwmUh zG%g8AW$H<+wAZt;m$XxOV_o2z9K(Xw@A6l;d2@JVr|9}lCgYT0mMPxt;9@kTvb~kf zN}+D5Om$c$Q;)7D*NbTdVk!wCOZ7*0lS1-M>riQB36V(OAuU>NZaH$`; zEljDy$&)hsTCx55O9Z&sQzq}R7kGoWpnhid=kH$qwNGD$GjQ+-hep6S1k5`yF~5#1 zL2EQjew5Lcc+nn|%N-zQR@-F3T}tRU`4j|}l*AN#=yAkiiw?l043R`kEUb998_VbY z`YE>wYYsQ6I-A{+Uv`iAj`+xy64;KFwvT=FKn-?J;$Z)f6}Uo$$??$z!I#G^6A}NX zA3>H#j(>A(h7#HaiRC*Y%pe-#=o#}<1!dZ>zi(*jmkdJ3S~JMyE`ib{Ry=k2gP~Se zcaVn1no?}!nnDfx{aJmbMuT1vC+ux6w65Dj{U5Wz6zLI*QejJEgF54%Z;{%r^0M#{ zXB4!BrdS54f4b(WDt5HZxD3u^&Z3Km7Sn2@h9{r?{Kz>qQ zoE0%C{Z1kW*;4z(Ki+D&9*xhdDC_)?NgI&tn6e|- z%Nmk4Ni1;Lh6WUAh#&35 z&j)zu&V_qpBbV{dFyB+DydsY5*lW5EdKvWJ9l8q%iU|~EmQ6<}Z_bqQBmPnkcN2ZZ z#CsEh6(2J(x`!<1CY2gJ@WX&Ebq3HI~E{*{1X2`jvP`^pW-C&dqyMuoxdBR%E>rC(@l!W3hXiQ^L7 z>?|ULhVIN~Wls(x>I7v{PO5miGy@$YB5qH$8#toyn|$)P8)>FPQYJ(_bK<(=ZI zwDvt%7UF&G{P!>HU!I=Yfis-J@Ld_0V&n7;V*7~@*-jO;(r9SQJum~e;hg^+)A;QM zS;kPI!C$&E7j(?Z))PS)6oEiU54fGo%FhCHYC*jB_nOU|m8b-}t;)5}7AoPOIQ$Xd z;)z{B|5`i>-&~063CDBjvPZ!OMkPh7)(ZHl0(Bt>z1tHp!7DWfv0%Zp8@Qf)d7 z>BYHe@)m4Vm)LMNe-*zi0E=h3od!c(!B{_mC{+zyHM$-kFBJgpI|lN zwnq|Fp=^U&OM{T$0<>ZNc7`bBPIR_@Qd6GoGvA(Ke^v<@f0?97bru)Us5SXnMS^RX zZV^PrE=m<4ntI7U(2#2{UuY)LxW5O*dljcJu96@SV!iTCQu+Es%$W!J3B}xeh99#D zgDMR##oz-p7DxIC#A;|Xz*YUJE9X1Q^tcBu+^uKSnp!K5Lxih9TQnL%rI>rbfg(>m z$Vx0Hg#&oXNDIQ4;ep`9HhgwoyzMXA*msCxX0HGYSkrkyh#NjIk+p+II`rX8md5P? zu4BfAz-Cm>k7TcsEkg^*05sPhy80cWPwxoF+y1s)zG9vS7*Xk((0gZe?oX9;7;nWw zy%KB0r%DvPx03kffr4xK-s7GwC?UpPvL?q}zm@b?v@6g-HCMEY>GMCHM(H0*BJNSe zE33M5ccHbuyuODYRLmE1h^a?3^7C@TU@|^rWnfVaf+FFVSXp8f9#Y6?ltu87=f*$I&M!wj5JnzE!MUFN#}wouI3+J$tZ zdwo3IKxVc8rO+EQeb0{1yDJe3b)48ag$k)jCM*d}{zolXXx`D~c1hVHkM#AaO zmRJ!BSoiYE8M=DmP++iOrZH1j%%0OW;HME9EbYk{9i$Yf_XwSLq=Y`o5Vur8sPRD3 zS*al!UA(dq{lc#G%#$D(?6}AnhF#sTNuayrSWC47U;v)I2tRTUZ`f8qw9Pe`w(WZ2 z-F^kPrvnFpH-S5^9i3o&b^>yHOEF2o@ag`>@_@UFQz#u;8u-B|lSJE72>EB4tUd*e z{@q@tj;)`LSg)wfR?xno7~F~YE`Rqs(Y897sSo|Z`K5mry$xBM*v%dG)0FZ&xg%U0 z@xd*%TQn!?%L%sjx4?J-;DJuVw2}LMc%Ap!EBp|?hNI;P3GKa@us>Mi(&}2bG~UL&mt+(1>#wo>okzFNs|HO_ljn~8CBk|U z>5S3d^P|mMwg?*=3-Fc9Mq9TFDM~{-EVl)Bcx|5i=*x75CR{K~Ez^<@lWQO85x^BN znlrxEi??A?yQG*j)pM9yqXR#5Jv2j%Aj1qgrWUJL$J3NeXsxf518%J-+(zfDoIWp# zFd6g0hYZC2zGHXgWqpSRLAriab|UMU?IUh2tS%kJTh5l^IL-}I)D26v5DluF{0rQB zD^^ZTUsKh9FkS;@k;L9rx9Fhk;#ML85%&%SGJil9aPbs{Y5QQ& z7o>OgD=1OnfX&zHx<#i8H=YBamSu6lS&&*dxnJk}UJ_W;B=TA9GI8%cHx2Iqg7Wn; zbdnnpf8Dcp;HArhBMY4>f8G?-y&CJNV@5sNf`Rn6XAe=pWbLz{F=*a!J;zzt%y0eo zv&+GGQL58fwpWWVz34XHWFqmW8BesQA)@S7T|)jKb=>a5_IB4ozRi6er%}bp)=516 zEAE$q7RG^WB8|DR8Y*mLcFpVSUPPum{TyjNYQ>DRdrKMh>@-J)2bg1K}=T= zS5xX&NS~+o_&=$k!NQF?WF#!68nEr;guQl_p}aiMo^Z6#eF%+#b9q|9@e9bj4c~r; zQA`Z9Lba<1i$f`H+9XX{o~uk*d|-#0C95D7;n~Cte@Lj-)@n`1o4>|GQZGZ;fv0NF^06n0O4*3b+M9RO?#m zv*7S0zc&Um%O{~XoY~7uOzWmhoma~pW?^vhwu~&Nj+T=KpySL#SYoUXu@fBQbjiOl z=Qh+K#C=ji1ZN+Bu606mak5Wj+mN61dS1CSAglheB>jF2;trK(2D4oj2nw#8QSHMD ztCwdcN*iu;2?B6%Ze5}fDKnHQo@lKl;M(z*LNKllAvM}tQQyt{%CL{b?LLqm;TaIc zAnc2hH_O3_n?zaK3_=tv$uPZ}B09+V;U3Hgn0c9>MEZ>)rGa^vA7_!tHCX8J$7z?^ zf$_?E5s-9dJs%K$=fv`bNn*_OGc!ZF`s1s|QO;vfx;}K`6ibr1VH^&TU{;l4UPFNK z4ox;T2CYcQ(ZQjM<<*YvwCY7O^z2A;Th1vW_-uv^lf_SVFe|sz2_nnfkgQPe0)8w$ z$N`hSkyeGqDp4OD>>YHaEW4;)Ax78SwG2%9L)X1C^DDM|AFv1RmfNf}=<7Y=FN6n# zIiVr4Qb`}N@E;hRqQtraVmYD@${E8xRs?SGkF21zRYm2NTnHwB7JjOCq*CiQ<%{Axa$XLxb=l7fsM}5?ff4EV5;&{adgYwooy_4 zzFGQ?ogAPZU+1P#2OAs5bgqy@F{Q+>%6tDHc@$iH2FxSFAgre;}_izaNXsC#l*>FXeWM)td< zxLPQ**JA3T{Sl|S1`jQ#(@u9#VIycmWMF-=eQ6_{ag&mkp7x;7kChg6+eSFECJdd6 zrX=p_>dMM>eJzt+SS*J61BRSB%ad7>9(q_9koi<~p~wN}j%@%_erIEO<*YuHs=93% zGF7Ols-8&=DnK>Pt!#pv7~SWhmM?Vw#r)^%+V|-osV4W;APlw4cdfhczq0N?ZE`qj z`cr>&xoSx~&*A_YB6<0qZ@_ks|?>LY-uqrL>qg!o}M zfz<3MW%3nba)+qF9CMlI$GMxalz--Vfun4zVGU~jm`yodc^(m=nIlotoS0_FT`b-O zI-O{~W;nzap_G>R#*&B@J0Bmu+;!)7v(V{fx`sKdVyxmRK*D$WS|?DGiYx_-jh{JS->NLE2F_1`PB?t*Qt$a1YBHPJ+m&a7)9n`VT=uQ zj~6)#zO!BHu~7(cWzLZ0TBwx<2sm)T!QZ~O$b;!#gyok(<~cTHflC=641gUH`~pmm`~pprIy&4%tYH2iWuUBfrpBd4pf zfc+)zUB^C&BAR(WH>X8PY72Gq=eUEy8$*ulA^bxt#h~b%#pWr-rhcF2oIRe?svT@> z{_iNNRE;nSU`9_hutRuoo2r(NW-<6KrF2)*<8Jm&nYw?%8lVqTO^@ zB@LX2HEiBGV}?x)n5*_+V8P+O4Hw)zW>}dHdmbIAwY55L;l9VN6#EAlR9HohNYD+K z2O18U{hM%bRl!Vb*Rd6Ank1`SsZ*tuoBeisG9^yw2kvQ$%SEh;%Thg;xw;-b+ogl| zSeWB7S?I7AwT!76zqKbQ<9M}mTCq+okTP}D0>rKl@CjL)?CR~B>>BeM zi9MWnW$lh)(gxF&-Yg$@(nUdLsBMPDa7&P^>iR5339$JxZqH_H%xsG@OH?5vt|@jr z&orLF<0l$QJukzY+OixtXmo3(#evL65*?~U8&!-q<}|oPsuqR8krF(CgiH&ovgj6%%rM!iB}X3%8+!=Mn{9pYDcEa8q8Ohq zABI}U{h0|HeG9k>wN|a%jz;EZH@nLJ86Eqlws z42!D~Ykoh2Vr)7~K`|ogmNW3h0j%&egr8FqG)O{%&jMUyw;3(0xv6^3hZh}RdaIy* zz+MuET!3j5{!$!pp#Es-F5Kxxy0qB#hqy#=wA(Ur3L!;Uf~d_(FrdXy>BqYhH-5&-c+26|gyuJ(Q% z4)I4b&GxjVJzJ|m@NXZl>+V)QM`}kbFhmIUwch-|p>Gi3tZSArM6oF#9lsbret;l4 zoc*pycQl~XuNqp4g~~ens1RH}I@m^Z|CIqX2{Q?*Ahg2msCU)p4Lu1t30i%qrwR1| zc}B-g#l1!o;R3q2oRmQLZnw?LYq$Yn0rmsd>Q8ow1S}8+MLBWiAr3~GnJ|yI66Vz}422igSVn}MD4W@Av{V@ejS7*~ z&1BwyK_VXDQIo0&EjG;uVz_S#3)~Fgq(zR1TSW8$UA44hM<*i*Aj+Q#VL_uLul*JB z1h$-z3ez0@CwCiXlvjLag;Mwya=O!9!xjUrR09l8Hg~N5AvB^hR1v3pJX)Oz~=#N?Co}g_GSf<35&o`4dlm zOVF*KW5_nwA4dQ9qgIJmNwWS&B9?Q!kEaCJ{15E+0^AQM;K%$iuzj$?DY!8-^(B4| zyY$}At30)RJDAx9)4FUgWS(m0i#gLfte)PT2k0|VOqhZEkRbECu}JPc(ss=)-?QVf zU>zBZ?`Kss={=^ck^?y{6*IGqLG6w%nbI|N5_|fRO!2kjKyybhXy=bDC0Q_VbN~PV z4e+#MV86jtg6#+S`w@TyzyL^mm9sKt`uoagYh|pa3IhN`CmI$N3A7PY^8^P#fSLj> zlE)N&389A}LF)%ni-Xq~vez5#iC|uqLW%~#KqeNKxe}wv+N`3csQrjl+#x%~(>xS9 zF>7}#Y{)Zxf9lD}8S^a$K?OLaG0?$f#wtV$@N=qJt4Qagf&L-swV=mD{ccMJ39JJi z5l4R>26T@s6VscRfRf8r3A%qhjle=wD%YqZPsw1NW|+$?5fYO{;Xogw5kkPu?kWP> z`xP=~HZcu|R>e=<4x)>;w=%D3&Pm zi%D2M=DbAgturfWNW|i!Df|$1^j5tU$@%L_dAesb`a>TN5o7k)kkt3uhl0E^bgu^w z?aj~rp=+x!&u8P-zr}#J|NPj`i4PljL)u4hnn@T(8ZX~}1=48o5YlH7PQ{!#C#*;{ zfql=6IFv9kqhObPgAweBGcn;1rIK%d9m#TztAL%|kDMpVWN;^Hcns*db)po(@JHt) zkk^k;>h=u|fD&@jBW-z;oqjaIDuz(=c^)dum?Lg&zYT3k)=pTdSV|A*|2yGgFZ4vQYX3p$G^SYBr`wB-RU z!d-D2fEC%i%0gg11ALck84|9EPFux?jztKPWT)aV*%>`A$9Q@3q{YaUG#1 z4MJu)9q!lLefE!lgLB$~luOTJb`$j!v=AeN z-o8%OPt)c9R#bI6`cwW3999k>r;&?;y0Fl!{Om_g;R%b`y~ur_IeJ)O9X5m-O|3E)M=&gVo@1LkB}KrA&`TESm~$`@;s=wzBsy zA0Aq6y=l{xqQT2U&FW7WsGhB!{>Az3ukhE1X3~R685|EP6=gNE{&-uB($*kh#-vkM zn9xJoQ{B8UIM(GK@(}_0wW}GlAaQG7l#dThZUZPzr-zqBF2GGE^nNNB@7!7wk(#{e zTQK2q)~fzFYfg$n*o73Nk`+^>crb+u)N^K0O=QC5yOM0b;2y7`Or@lEOU1~g$hlxw z%gXYy>X=xhwd+eQzus*lkt1)<0X`K76PS1RXoyjlYe343x_AX-|zZsS1n`Up0cEUDbiW z<^y-}pX&*%*?PG)Xax+|zHBQ^@a|-qGG51z>0{niw{t+CB2L4E?nV+va)zZlquI zt8JtkNvd$6f)^ezKj2a2TU-Qx|t5o#$%*+AuPW0?Wp27F+MM?kOnuc== zD1blsh4i^!Bz1csd{qk?G)4N_|Gr2t!M{<3^qTxe1ggj%*7ZM7W2XW zta~c3?8&iXvT1nWU_(7>50v@Qbw>%{@kGBL@)7;jxph3Ev)RN&@wIC~roh7~bZsb7uoEzQKU z9NqE;%*LC92rPHBwJZa9W8kky>!n5n|Lq)HB=Xt2Q--ekKO+R^&oBY*(>b`9xw;!U zyD*yAnf~n`q8Qc1{xdwVOZbBHix@rB!#{LPj{sMXT)v2}2qm8e8!J@+(_~&4?W0>L zwy6wm-~VCV1<95t#oQ=FD79lClG_^5tLM7raAl(g#@ZOIog*FuJG0G?{6X?hXXPRc zY{e+4!LwtoPO_4C*0>Q6+#tFASI+{BC@Wwq#{qj6w--5_IQB$oAT+Liunf{jjFS-9y_J5C@=4ZQ>nww=_Pym1o z5&%H>SG)i6t(Kqd9seV=s#4W+m}5rwo2qG5fzzh@UROZUSY}*{X{92Ws0|(=J?vzU z%M_PAaJhPY*5>q`(dOyIRA|C|S$u zWyZzg+xiN3K{>j_{tl6gGRPRX@Xn&hB&<%{_%S>eOhc_mC`6LOI=!bB)dav5elGVb zb+~De$&bBj&H9u;mODk=7yB;&!SUm!y(eSv_s^|mjJ;fRz@`C)uiFmI+l9bRVzF|} zE)_7yGNOS4-d|21`zf4cnTVI)W$VxO`pl5C7CE10(UsC~3Yh+I3gLwag+CxWPMN6u zf*4>r=rhe>hWc^Vv~*n4FJi=&%C#*pSSVrv^{P%khB(lj)1aMJ=kbt+eqaT7!0*c9^rT ziEV>i&0&zka@RAg7_x|=8lE#>Cda!>7N&i=^W({t>yhtK!1wt5)PZ!>_wk~1^01za z>y}{_Yx&X>PJSw_nS5@d`c z@&W6Lh-4F(DnJ{V94Er)zu})VWnb-4r5lOuNO$aDe>^KeO;?em+^oeid}^AoX#=U1 z9Rn&qL0pkUa?)a)aPS7EBntwH1@?dIEaa#5{qsWxj0pdA_fMFwrV0T7`$v5NfPVn~ zVFq37imY3CR@afAF<}qdU&{Lrz+XfmAdu&O0RG_#mVe_&z@Un#dHy%fUkn3!@kIb- z7XXMV1^Hwc|LVwJIG~@);-8NEgJWuI`!~{GeB=K@`fslCpGa!Q|BduFbNQ6*|3doT z@$P@hrgIATkLdRk;-AR(zs36BR`EX}Jb{4!wvnGGf7!@?i}Zib62$)u&R?_SeGT}R uo%#Qnr2lPU{<9bL|7!nld-I9&m%aI?9}u5||5vaN4PgAVQ1o|yJ^eqAUU{Ve diff --git a/l4/pkg/libsdl/contrib/Watcom-Win32.zip b/l4/pkg/libsdl/contrib/Watcom-Win32.zip deleted file mode 100644 index c60af6df43d2ab91ec59bc16d372ee056fcca958..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 3709 zcmZ{nc{CJk8^(vRugN;1vV>$8VHjH&L)Ni0%DxQ-5lv-ZlFHU(Hc~opQ_iDeiO>9QT~E;Y`?s$_SJF0O4Q3vYt_;ZZQ#&xn!r>(nyz=_ zQ?N@f(%5o$dfYAL!}P^Z)TYV?Wa@7{XVt6IkS?>l_ibQE@?^7RV_z9upw1&K_oz>B zJAf()og~i*OG5(l16ilhHPe}yxBTi&zFInefIB2MyK&A;HN!ICUzMoUBE1Ceqlyc4 z(}>2o3%(0U5#BV6NzL&2_;f>g&@3O4j;smhDNPmwX_HsNJ`?vaT`W=wo7 zq(z-ywZ-Gq_cJ9r-^nZ@6UztfTo;`g?h8M?7_odCV-mj6BlwttF^Of^P#}$g^?p5w z@YOFq{yi6BAqiLKnOe-#l0cz-CFhb#GM7W7SGGcAqR?Ul)w*q8UUG^_EsU2ie3d=@ z$L%xw9&5n|k#~y1+2B;7Ny2$QblSOl!s%tx?5%;;h2q(m2_cWQB1oK4)J{qG-7>jQ z0p-O@ByfyMxgbodj@byTZWn*OWxvm8{efmjqEykOIY9?&F}b~zpa^Ea+jD610ly}Y zJM}bwd1lO_b>&WJpvB_AJ(_JvglBz9o^dg*_H`k8sRKKJj)E_ryA6J+KGy2*2^G&T z8@FklHHxCF!Ds{5S8geJ?6PqAdnq3WVOJFSl`LrZzya6sc#KW5s>S*@Lq#RApTE91 zhUBJLyxn7Lcaw%2q3qq8-$(NEZ3_n%Z{Sp()atkpRa4)Yc;PqHf^yq-LPKH> zY=Ao);-5*2yo&z9!*4zvu&kPC9-kX_>$EvA+X!h2!YIfFI~)ik_c#W#b-sj>-2751 zh9{{E&3<)1CD~8ex6+_=2&>MLmVsD0O!Vvs+$9O>B@e%u0Tt$c(k*2^dBs5Tt!;@c zx2bc$qFhi0$;>*xj6u?iMnP-6(HD4gAj;9)d&Wuhm#{* zs^!ewNY`hl<(C=i&p+X8AY>3IXI8hQ!4f!9MotwexMd?ECo)wvba@cXei>ps zv@G}P0vJ(J*)O2kxuJ13E6?41lYVP2Xb|_cJn9?fwMcl~)cqrJ(_C!FRW89M$%QI4 zo_IZ6N|aJJ)1yRh!D*?QBAkw?=^AQKog`e_6xZr$Io&QEFg<3f;Xq=)KnW$G?Xu_W zlEtSoCmOq@oE#~8GwUSX4VM@qoj+F7yUfC-ZfZ=?d+3!MaNtquA*(+pt|G<=x<+yG z`8Z00gJ)ejY=BE!rPIYX`({HtH)o?$ zF{#C3$!AyRai{_Jh_mhESfJkd6S>l3Y3y#D5%-*b{c1^?)9MgBkLv;duU;d3N$X)a zR~G3t$jx-WG?88Ey&}By*cgAlFm;8R-4*%e@@<95wRQ%fO+7ULDh$t;hgJlNjHO@JKUr~Txa;1+N!M?dz|et8sOIN0xU+XD zu;fmEjf5HamQLw8n|9@j0?(7V*hJX_l?Wvv%ImSWzr5iTQb5nFv&B_06yDLxJd9Zo zjp?bwJL-KI`22%Y^;K7UFEhA~EX(awSbnsSEv0&FwQe?GP?wQu)l$PnvYThTfW)-U zmWGtP@iyQ9ubCcg#}OFAZMs)%0^$6)YC{0X~V0YCBx$@!Z~~ zAnbWJ!*uo%Z)9%t8l3?DZDqtY`jm93000s{0KoR!%J?{XIJ>w?A-$dcHZ$!1utUk| zH+|S;&xGZ~zBqYj#`cmG&H<;FT-An(a}0}Eu+HY0;l=}OhS1m6k|OOAc5&Fd@t8=!I*@+*?8^v=fcQ#FTQ4@X!la*X6=~BuiJZ+13 zzHmeYeZUhzF7cA(ZIhHAti-InQuJwVmv&ra9KsFdN2 zL_&)j6!9uSlTI=dB`=WyyK`1MCbwV(Kj7DsP*6)~qv3L+9Jl_J^#m}Ekm5w^;Lyx@ zrcyL*5kCB3Qh;CKy&T)gCsFh~=9bnR7drNcv8ay#`05K%P!mN9)*o^6%)l8 zY(f_1wPUuXb`Q5!lB-!%7^}D@tx)S) z?P1;0M6nOZw-vPt8Nz)HyIIcN^;?z;t&1Zx9HZo0!@Hvy&cx3uQKj077Cj zz8dkCzAbPO(t4yzGKRe_ZG+HH`D#ZZ#*c zu`rWuHf$6Z`lgO+J-9n;aRL%vmu&Ow^t+|z?dC043_i;8W!yFND<|u_U;6|m&w3a< z+29ytvho#o_Y5MyR^uSFlPu?z>0f>pwegTox?UTX;-q=4;OB+m+@g;SYz5!r*<$ax zl~FZ%!X)L5M!St5-jm%ust-ern;ISaoOA5rF;-^#w%ORwttwO&ZKgkG{o{}gbrS;$ zN^ao)3uMgyjb>*6>zaR*f5$WGzv7t%8UXl<@c)9@Uj&L%?W=H=--O>W?UeLKO#5G? hf6v8#lBntb?&Y6T@?R`!nm;-Qp6;>JJK<0He*m(v#{B>Q diff --git a/l4/pkg/libsdl/contrib/src/joystick/darwin/10.3.9-FIX/IOHIDLib.h b/l4/pkg/libsdl/contrib/src/joystick/darwin/10.3.9-FIX/IOHIDLib.h deleted file mode 100644 index 836a71ec3..000000000 --- a/l4/pkg/libsdl/contrib/src/joystick/darwin/10.3.9-FIX/IOHIDLib.h +++ /dev/null @@ -1,874 +0,0 @@ -/* *INDENT-OFF* */ -/* - * - * @APPLE_LICENSE_HEADER_START@ - * - * Copyright (c) 1999-2003 Apple Computer, Inc. All Rights Reserved. - * - * This file contains Original Code and/or Modifications of Original Code - * as defined in and that are subject to the Apple Public Source License - * Version 2.0 (the 'License'). You may not use this file except in - * compliance with the License. Please obtain a copy of the License at - * http://www.opensource.apple.com/apsl/ and read it before using this - * file. - * - * The Original Code and all software distributed under the License are - * distributed on an 'AS IS' basis, WITHOUT WARRANTY OF ANY KIND, EITHER - * EXPRESS OR IMPLIED, AND APPLE HEREBY DISCLAIMS ALL SUCH WARRANTIES, - * INCLUDING WITHOUT LIMITATION, ANY WARRANTIES OF MERCHANTABILITY, - * FITNESS FOR A PARTICULAR PURPOSE, QUIET ENJOYMENT OR NON-INFRINGEMENT. - * Please see the License for the specific language governing rights and - * limitations under the License. - * - * @APPLE_LICENSE_HEADER_END@ - */ - -#ifndef _IOKIT_HID_IOHIDLIB_H_ -#define _IOKIT_HID_IOHIDLIB_H_ - -#include - -__BEGIN_DECLS -#include -#if COREFOUNDATION_CFPLUGINCOM_SEPARATE -#include -#endif - -#include -#include - -#include - -struct IOHIDEventStruct -{ - IOHIDElementType type; - IOHIDElementCookie elementCookie; - SInt32 value; - AbsoluteTime timestamp; - UInt32 longValueSize; - void * longValue; -}; -typedef struct IOHIDEventStruct IOHIDEventStruct; - -/* FA12FA38-6F1A-11D4-BA0C-0005028F18D5 */ -#define kIOHIDDeviceUserClientTypeID CFUUIDGetConstantUUIDWithBytes(NULL, \ - 0xFA, 0x12, 0xFA, 0x38, 0x6F, 0x1A, 0x11, 0xD4, \ - 0xBA, 0x0C, 0x00, 0x05, 0x02, 0x8F, 0x18, 0xD5) - -/* 13AA9C44-6F1B-11D4-907C-0005028F18D5 */ -#define kIOHIDDeviceFactoryID CFUUIDGetConstantUUIDWithBytes(NULL, \ - 0x13, 0xAA, 0x9C, 0x44, 0x6F, 0x1B, 0x11, 0xD4, \ - 0x90, 0x7C, 0x00, 0x05, 0x02, 0x8F, 0x18, 0xD5) - -/* 78BD420C-6F14-11D4-9474-0005028F18D5 */ -/*! @defined kIOHIDDeviceInterfaceID - @discussion Interface ID for the IOHIDDeviceInterface. Corresponds to an - available HID device. */ -#define kIOHIDDeviceInterfaceID CFUUIDGetConstantUUIDWithBytes(NULL, \ - 0x78, 0xBD, 0x42, 0x0C, 0x6F, 0x14, 0x11, 0xD4, \ - 0x94, 0x74, 0x00, 0x05, 0x02, 0x8F, 0x18, 0xD5) - -/* 7D0B510E-16D5-11D7-9E9B-000393992E38 */ -/*! @defined kIOHIDDeviceInterfaceID121 - @discussion Interface ID for the IOHIDDeviceInterface121. Corresponds to - an available HID device that includes methods from - IOHIDDeviceInterface. This interface is available on - IOHIDLib 1.2.1 and Mac OS X 10.2.3 or later.*/ -#define kIOHIDDeviceInterfaceID121 CFUUIDGetConstantUUIDWithBytes(NULL, \ - 0x7d, 0xb, 0x51, 0xe, 0x16, 0xd5, 0x11, 0xd7, \ - 0x9e, 0x9b, 0x0, 0x3, 0x93, 0x99, 0x2e, 0x38) - -/* B70ABF31-16D5-11D7-AB35-000393992E38 */ -/*! @defined kIOHIDDeviceInterfaceID122 - @discussion Interface ID for the IOHIDDeviceInterface122. Corresponds to - an available HID device that includes methods from - IOHIDDeviceInterface and IOHIDDeviceInterface121. This - interface is available on IOHIDLib 1.2.2 and Mac OS X 10.3 - or later.*/ -#define kIOHIDDeviceInterfaceID122 CFUUIDGetConstantUUIDWithBytes(NULL, \ - 0xb7, 0xa, 0xbf, 0x31, 0x16, 0xd5, 0x11, 0xd7, \ - 0xab, 0x35, 0x0, 0x3, 0x93, 0x99, 0x2e, 0x38) - -/* 8138629E-6F14-11D4-970E-0005028F18D5 */ -/*! @defined kIOHIDQueueInterfaceID - @discussion Interface ID for the kIOHIDQueueInterfaceID. Corresponds to a - queue for a specific HID device. */ -#define kIOHIDQueueInterfaceID CFUUIDGetConstantUUIDWithBytes(NULL, \ - 0x81, 0x38, 0x62, 0x9E, 0x6F, 0x14, 0x11, 0xD4, \ - 0x97, 0x0E, 0x00, 0x05, 0x02, 0x8F, 0x18, 0xD5) - -/* 80CDCC00-755D-11D4-8E0F-0005028F18D5 */ -/*! @defined kIOHIDOutputTransactionInterfaceID - @discussion Interface ID for the kIOHIDOutputTransactionInterfaceID. - Corresponds to an output transaction for one or more report IDs - on a specific device. */ -#define kIOHIDOutputTransactionInterfaceID CFUUIDGetConstantUUIDWithBytes(NULL,\ - 0x80, 0xCD, 0xCC, 0x00, 0x75, 0x5D, 0x11, 0xD4, \ - 0x80, 0xEF, 0x00, 0x05, 0x02, 0x8F, 0x18, 0xD5) - -/*! @typedef IOHIDCallbackFunction - @discussion Type and arguments of callout C function that is used when a - completion routine is called, see - IOHIDLib.h:setRemovalCallback(). - @param target void * pointer to your data, often a pointer to an object. - @param result Completion result of desired operation. - @param refcon void * pointer to more data. - @param sender Interface instance sending the completion routine. -*/ -typedef void (*IOHIDCallbackFunction) - (void * target, IOReturn result, void * refcon, void * sender); - -/*! @typedef IOHIDElementCallbackFunction - @discussion Type and arguments of callout C function that is used when a - completion routine is called, see IOHIDLib.h:setElementValue(). - @param target void * pointer to your data, often a pointer to an object. - @param result Completion result of desired operation. - @param refcon void * pointer to more data. - @param sender Interface instance sending the completion routine. - @param elementCookie Element within interface instance sending completion. -*/ -typedef void (*IOHIDElementCallbackFunction) - (void * target, - IOReturn result, - void * refcon, - void * sender, - IOHIDElementCookie elementCookie); - -/*! @typedef IOHIDReportCallbackFunction - @discussion Type and arguments of callout C function that is used when a - completion routine is called, see IOHIDLib.h:setReport(). - @param target void * pointer to your data, often a pointer to an object. - @param result Completion result of desired operation. - @param refcon void * pointer to more data. - @param sender Interface instance sending the completion routine. - @param bufferSize Size of the buffer received upon completion. -*/ -typedef void (*IOHIDReportCallbackFunction) - (void * target, - IOReturn result, - void * refcon, - void * sender, - UInt32 bufferSize); - - -/* Forward declarations of the queue and output transaction interfaces */ -struct IOHIDQueueInterface; -struct IOHIDOutputTransactionInterface; -typedef struct IOHIDQueueInterface IOHIDQueueInterface; -typedef struct IOHIDOutputTransactionInterface IOHIDOutputTransactionInterface; - -// -// IOHIDDeviceInterface Functions available in version 1.0 (10.0) and higher of Mac OS X -// -#define IOHIDDEVICEINTERFACE_FUNCS_100 \ - IOReturn (*createAsyncEventSource)(void * self, CFRunLoopSourceRef * source); \ - CFRunLoopSourceRef (*getAsyncEventSource)(void * self); \ - IOReturn (*createAsyncPort)(void * self, mach_port_t * port); \ - mach_port_t (*getAsyncPort)(void * self); \ - IOReturn (*open)(void * self, UInt32 flags); \ - IOReturn (*close)(void * self); \ - IOReturn (*setRemovalCallback)(void * self, IOHIDCallbackFunction removalCallback, \ - void * removalTarget, void * removalRefcon); \ - IOReturn (*getElementValue)(void * self, IOHIDElementCookie elementCookie, \ - IOHIDEventStruct * valueEvent); \ - IOReturn (*setElementValue)(void * self, IOHIDElementCookie elementCookie, \ - IOHIDEventStruct * valueEvent, UInt32 timeoutMS, \ - IOHIDElementCallbackFunction callback, \ - void * callbackTarget, void * callbackRefcon); \ - IOReturn (*queryElementValue)(void * self, IOHIDElementCookie elementCookie, \ - IOHIDEventStruct * valueEvent, UInt32 timeoutMS, \ - IOHIDElementCallbackFunction callback, \ - void * callbackTarget, void * callbackRefcon); \ - IOReturn (*startAllQueues)(void * self); \ - IOReturn (*stopAllQueues)(void * self); \ - IOHIDQueueInterface ** (*allocQueue) (void *self); \ - IOHIDOutputTransactionInterface ** (*allocOutputTransaction) (void *self) - -// -// IOHIDDeviceInterface Functions available in version 1.2.1 (10.2.3) and higher of Mac OS X -// -#define IOHIDDEVICEINTERFACE_FUNCS_121 \ - IOReturn (*setReport)(void * self, IOHIDReportType reportType, UInt32 reportID, \ - void * reportBuffer, UInt32 reportBufferSize, \ - UInt32 timeoutMS, IOHIDReportCallbackFunction callback, \ - void * callbackTarget, void * callbackRefcon); \ - IOReturn (*getReport)(void * self, IOHIDReportType reportType, \ - UInt32 reportID, void * reportBuffer, \ - UInt32 * reportBufferSize, UInt32 timeoutMS, \ - IOHIDReportCallbackFunction callback, \ - void * callbackTarget, void * callbackRefcon) - -// -// IOHIDDeviceInterface Functions available in version 1.2.2 (10.3) and higher of Mac OS X -// -#define IOHIDDEVICEINTERFACE_FUNCS_122 \ - IOReturn (*copyMatchingElements)(void * self, CFDictionaryRef matchingDict, \ - CFArrayRef * elements); \ - IOReturn (*setInterruptReportHandlerCallback)(void * self, void * reportBuffer, \ - UInt32 reportBufferSize, \ - IOHIDReportCallbackFunction callback, \ - void * callbackTarget, void * callbackRefcon) - -typedef struct IOHIDDeviceInterface -{ - IUNKNOWN_C_GUTS; - IOHIDDEVICEINTERFACE_FUNCS_100; - IOHIDDEVICEINTERFACE_FUNCS_121; -} IOHIDDeviceInterface; - -typedef struct IOHIDDeviceInterface121 -{ - IUNKNOWN_C_GUTS; - IOHIDDEVICEINTERFACE_FUNCS_100; - IOHIDDEVICEINTERFACE_FUNCS_121; -} IOHIDDeviceInterface121; - -typedef struct IOHIDDeviceInterface122 -{ - IUNKNOWN_C_GUTS; - IOHIDDEVICEINTERFACE_FUNCS_100; - IOHIDDEVICEINTERFACE_FUNCS_121; - IOHIDDEVICEINTERFACE_FUNCS_122; -} IOHIDDeviceInterface122; - - -// -// IOHIDQueueInterface Functions available in version 1.0 (10.0) and higher of Mac OS X -// -#define IOHIDQUEUEINTERFACE_FUNCS_100 \ - IOReturn (*createAsyncEventSource)(void * self, CFRunLoopSourceRef * source); \ - CFRunLoopSourceRef (*getAsyncEventSource)(void * self); \ - IOReturn (*createAsyncPort)(void * self, mach_port_t * port); \ - mach_port_t (*getAsyncPort)(void * self); \ - IOReturn (*create)(void * self, UInt32 flags, UInt32 depth); \ - IOReturn (*dispose)(void * self); \ - IOReturn (*addElement)(void * self, IOHIDElementCookie elementCookie, UInt32 flags);\ - IOReturn (*removeElement)(void * self, IOHIDElementCookie elementCookie); \ - Boolean (*hasElement)(void * self, IOHIDElementCookie elementCookie); \ - IOReturn (*start)(void * self); \ - IOReturn (*stop)(void * self); \ - IOReturn (*getNextEvent)(void * self, IOHIDEventStruct * event, \ - AbsoluteTime maxTime, UInt32 timeoutMS); \ - IOReturn (*setEventCallout)(void * self, IOHIDCallbackFunction callback, \ - void * callbackTarget, void * callbackRefcon); \ - IOReturn (*getEventCallout)(void * self, IOHIDCallbackFunction * outCallback, \ - void ** outCallbackTarget, void ** outCallbackRefcon) - -struct IOHIDQueueInterface -{ - IUNKNOWN_C_GUTS; - IOHIDQUEUEINTERFACE_FUNCS_100; -}; - -// -// IOHIDOutputTransactionInterface Functions available in version 1.2 (10.2) and higher of Mac OS X -// -#define IOHIDOUTPUTTRANSACTIONINTERFACE_FUNCS_120 \ - IOReturn (*createAsyncEventSource)(void * self, CFRunLoopSourceRef * source); \ - CFRunLoopSourceRef (*getAsyncEventSource)(void * self); \ - IOReturn (*createAsyncPort)(void * self, mach_port_t * port); \ - mach_port_t (*getAsyncPort)(void * self); \ - IOReturn (*create)(void * self); \ - IOReturn (*dispose)(void * self); \ - IOReturn (*addElement)(void * self, IOHIDElementCookie elementCookie); \ - IOReturn (*removeElement)(void * self, IOHIDElementCookie elementCookie); \ - Boolean (*hasElement)(void * self, IOHIDElementCookie elementCookie); \ - IOReturn (*setElementDefault)(void *self, IOHIDElementCookie elementCookie, \ - IOHIDEventStruct * valueEvent); \ - IOReturn (*getElementDefault)(void * self, IOHIDElementCookie elementCookie, \ - IOHIDEventStruct * outValueEvent); \ - IOReturn (*setElementValue)(void * self, IOHIDElementCookie elementCookie, \ - IOHIDEventStruct * valueEvent); \ - IOReturn (*getElementValue)(void * self, IOHIDElementCookie elementCookie, \ - IOHIDEventStruct * outValueEvent); \ - IOReturn (*commit)(void * self, UInt32 timeoutMS, IOHIDCallbackFunction callback, \ - void * callbackTarget, void * callbackRefcon); \ - IOReturn (*clear)(void * self) - -struct IOHIDOutputTransactionInterface -{ - IUNKNOWN_C_GUTS; - IOHIDOUTPUTTRANSACTIONINTERFACE_FUNCS_120; -}; - - -// -// BEGIN READABLE STRUCTURE DEFINITIONS -// -// This portion of uncompiled code provides a more reader friendly representation of -// the CFPlugin methods defined above. - -#if 0 -/*! @class IOHIDDeviceInterface - @discussion CFPlugin object subclass which provides the primary interface to - HID devices. -*/ -typedef struct IOHIDDeviceInterface -{ - - IUNKNOWN_C_GUTS; - -/*! @function createAsyncEventSource - @abstract Creates async eventsource. - @discussion This method will create an async mach port, if one - has not already been created. - @param source Reference to CFRunLoopSourceRef that is created. - @result Returns an IOReturn code. -*/ - IOReturn (*createAsyncEventSource)(void * self, - CFRunLoopSourceRef * source); - -/*! @function getAsyncEventSource - @abstract Gets the created async event source. - @result Returns a CFRunLoopSourceRef. -*/ - CFRunLoopSourceRef (*getAsyncEventSource)(void * self); - -/*! @function createAsyncPort - @abstract Creates an async port. - @discussion The port must be created before any callbacks can be used. - @param port Reference to mach port that is created. - @result Returns an IOReturn code. -*/ - IOReturn (*createAsyncPort)(void * self, mach_port_t * port); - -/*! @function getAsyncPort - @abstract Gets the current async port. - @result Returns a mach_port_t. -*/ - mach_port_t (*getAsyncPort)(void * self); - -/*! @function open - @abstract Opens the device. - @param flags Flags to be passed down to the user client. - @result Returns an IOReturn code. -*/ - IOReturn (*open)(void * self, UInt32 flags); - -/*! @function close - @abstract Closes the device. - @result Returns an IOReturn code. -*/ - IOReturn (*close)(void * self); - -/*! @function setRemovalCallback - @abstract Sets callback to be used when device is removed. - @param removalCallback Called when the device is removed. - @param removeTarget Passed to the callback. - @param removalRefcon Passed to the callback. - @result Returns an IOReturn code. -*/ - IOReturn (*setRemovalCallback)(void * self, - IOHIDCallbackFunction removalCallback, - void * removalTarget, - void * removalRefcon); - -/*! @function getElementValue - @abstract Obtains the most recent value of an element. - @discussion This call is most useful for interrupt driven elements, - such as input type elements. Since feature type element values - need to be polled from the device, it is recommended to use the - queryElementValue method to obtain the current value. The - timestamp field in the event details the last time the element - value was altered. - @param elementCookie The element of interest. - @param valueEvent The event that will be filled. If a long value is - present, it is up to the caller to deallocate it. - @result Returns an IOReturn code. -*/ - IOReturn (*getElementValue)(void * self, - IOHIDElementCookie elementCookie, - IOHIDEventStruct * valueEvent); - -/*! @function setElementValue - @abstract Sets an element value on the device. - @discussion This call is most useful for feature type elements. It is - recommended to use IOOutputTransaction for output type elements. - @param elementCookie The element of interest. - @param valueEvent The event that will be filled. If a long value is - present, it will be copied. - @param timeoutMS UNSUPPORTED. - @param callback UNSUPPORTED. - @param callbackTarget UNSUPPORTED. - @param callbackRefcon UNSUPPORTED. - @result Returns an IOReturn code. -*/ - IOReturn (*setElementValue)(void * self, - IOHIDElementCookie elementCookie, - IOHIDEventStruct * valueEvent, - UInt32 timeoutMS, - IOHIDElementCallbackFunction callback, - void * callbackTarget, - void * callbackRefcon); - -/*! @function queryElementValue - @abstract Obtains the current value of an element. - @discussion This call is most useful for feature type elements. This - method will poll the device for the current element value. - @param elementCookie The element of interest. - @param valueEvent The event that will be filled. If a long value is - present, it is up to the caller to deallocate it. - @param timeoutMS UNSUPPORTED. - @param callback UNSUPPORTED. - @param callbackTarget UNSUPPORTED. - @param callbackRefcon UNSUPPORTED. - @result Returns an IOReturn code. -*/ - IOReturn (*queryElementValue)(void * self, - IOHIDElementCookie elementCookie, - IOHIDEventStruct * valueEvent, - UInt32 timeoutMS, - IOHIDElementCallbackFunction callback, - void * callbackTarget, - void * callbackRefcon); - -/*! @function startAllQueues - @abstract Starts data delivery on all queues for this device. - @result Returns an IOReturn code. -*/ - IOReturn (*startAllQueues)(void * self); - -/*! @function stopAllQueues - @abstract Stops data delivery on all queues for this device. - @result Returns an IOReturn code. -*/ - IOReturn (*stopAllQueues)(void * self); - -/*! @function allocQueue - @abstract Wrapper to return instances of the IOHIDQueueInterface. - @result Returns the created IOHIDQueueInterface. -*/ - IOHIDQueueInterface ** (*allocQueue) (void *self); - -/*! @function allocOutputTransaction - @abstract Wrapper to return instances of the IOHIDOutputTransactionInterface. - @result Returns the created IOHIDOutputTransactionInterface. -*/ - IOHIDOutputTransactionInterface ** (*allocOutputTransaction) (void *self); - -} IOHIDDeviceInterface; - -/*! @class IOHIDDeviceInterface121 - @discussion CFPlugin object subclass which provides the primary interface to - HID devices. This class is a subclass of IOHIDDeviceInterface. -*/ -typedef struct IOHIDDeviceInterface121 -{ - - IUNKNOWN_C_GUTS; - IOHIDDEVICEINTERFACE_FUNCS_100; - -/*! @function setReport - @abstract Sends a report to the device. - @param reportType The report type. - @param reportID The report id. - @param reportBuffer Pointer to a preallocated buffer. - @param reportBufferSize Size of the reportBuffer in bytes. - @param timeoutMS - @param callback If null, this method will behave synchronously. - @param callbackTarget The callback target passed to the callback. - @param callbackRefcon The callback refcon passed to the callback. - @result Returns an IOReturn code. -*/ - IOReturn (*setReport) (void * self, - IOHIDReportType reportType, - UInt32 reportID, - void * reportBuffer, - UInt32 reportBufferSize, - UInt32 timeoutMS, - IOHIDReportCallbackFunction callback, - void * callbackTarget, - void * callbackRefcon); - -/*! @function getReport - @abstract Obtains a report from the device. - @param reportType The report type. - @param reportID The report ID. - @param reportBuffer Pointer to a preallocated buffer. - @param reportBufferSize Size of the reportBuffer in bytes. - When finished, will contain the actual size of the report. - @param timeoutMS - @param callback If null, this method will behave synchronously. - @param callbackTarget The callback target passed to the callback. - @param callbackRefcon The callback refcon passed to the callback. - @result Returns an IOReturn code. -*/ - IOReturn (*getReport) (void * self, - IOHIDReportType reportType, - UInt32 reportID, - void * reportBuffer, - UInt32 * reportBufferSize, - UInt32 timeoutMS, - IOHIDReportCallbackFunction callback, - void * callbackTarget, - void * callbackRefcon); - -}IOHIDDeviceInterface121; - -/*! @class IOHIDDeviceInterface122 - @discussion CFPlugin object subclass which provides the primary interface to - HID devices. This class is a subclass of IOHIDDeviceInterface121. -*/ -typedef struct IOHIDDeviceInterface122 -{ - - IUNKNOWN_C_GUTS; - IOHIDDEVICEINTERFACE_FUNCS_100; - IOHIDDEVICEINTERFACE_FUNCS_121; - -/*! @function copyMatchingElements - @abstract Obtains specific elements defined by the device. - @discussion Using keys defined in IOHIDKeys.h for elements, create a - matching dictonary containing items that you wish to search for. - A null array indicates that no elements matching that criteria - were found. Each item in the array is a reference to the same - dictionary item that represents each element in the I/O Registry. - It is up to the caller to release the returned array of elements. - @param matchingDict Dictionary containg key/value pairs to match on. Pass - a null value to match on all elements. - @param elements Pointer to a CFArrayRef that will be returned by this - method. It is up to the caller to release it when finished. - @result Returns an IOReturn code. -*/ - IOReturn (*copyMatchingElements)(void * self, - CFDictionaryRef matchingDict, - CFArrayRef * elements); - -/*! @function setInterruptReportHandlerCallback - @abstract Sets the report handler callout to be called when the data - is received from the Interrupt-In pipe. - @discussion In order for this to work correctly, you must call - createAsyncPort and createAsyncEventSource. - @param reportBuffer Pointer to a preallocated buffer. - @param reportBufferSize Size of the reportBuffer in bytes. - @param callback If non-NULL, is a callback to be called when data - is received from the device. - @param callbackTarget The callback target passed to the callback - @param callbackRefcon The callback refcon passed to the callback. - @result Returns an IOReturn code. -*/ - IOReturn (*setInterruptReportHandlerCallback)( - void * self, - void * reportBuffer, - UInt32 reportBufferSize, - IOHIDReportCallbackFunction callback, - void * callbackTarget, - void * callbackRefcon); - -}IOHIDDeviceInterface122; - -/*! @class IOHIDQueueInterface - @discussion CFPlugin object subclass which provides an interface for input - queues from HID devices. Created by an IOHIDDeviceInterface - object. -*/ -typedef struct IOHIDQueueInterface -{ - - IUNKNOWN_C_GUTS; - -/*! @function createAsyncEventSource - @abstract Creates an async event source. - @discussion This will be used with setEventCallout. - @param source The newly created event source. - @result Returns an IOReturn code. -*/ - IOReturn (*createAsyncEventSource)(void * self, - CFRunLoopSourceRef * source); - -/*! @function getAsyncEventSource - @abstract Obtains the current event source. - @result Returns a CFRunLoopSourceRef. -*/ - CFRunLoopSourceRef (*getAsyncEventSource)(void * self); - -/*! @function createAsyncPort - @abstract Creates an async port. - @discussion This will be used with createAsyncEventSource. - @param port The newly created async port. - @result Returns an IOReturn code. -*/ - IOReturn (*createAsyncPort)(void * self, mach_port_t * port); - -/*! @function getAsyncPort - @abstract Obtains the current async port. - @result Returns a mach_port_t. -*/ - mach_port_t (*getAsyncPort)(void * self); - -/*! @function create - @abstract Creates the current queue. - @param flags - @param depth The maximum number of elements in the queue - before the oldest elements in the queue begin to be lost. - @result Returns an IOReturn code. -*/ - IOReturn (*create)(void * self, - UInt32 flags, - UInt32 depth); - -/*! @function create - @abstract Disposes of the current queue. - @result Returns an IOReturn code. -*/ - IOReturn (*dispose)(void * self); - -/*! @function addElement - @abstract Adds an element to the queue. - @discussion If the element has already been added to queue, - an error will be returned. - @param elementCookie The element of interest. - @param flags - @result Returns an IOReturn code. -*/ - IOReturn (*addElement)(void * self, - IOHIDElementCookie elementCookie, - UInt32 flags); - -/*! @function removeElement - @abstract Removes an element from the queue. - @discussion If the element has not been added to queue, - an error will be returned. - @param elementCookie The element of interest. - @result Returns an IOReturn code. -*/ - IOReturn (*removeElement)(void * self, IOHIDElementCookie elementCookie); - -/*! @function hasElement - @abstract Checks whether an element has been added to - the queue. - @discussion Will return true if present, otherwise will return false. - @param elementCookie The element of interest. - @result Returns a Boolean value. -*/ - Boolean (*hasElement)(void * self, IOHIDElementCookie elementCookie); - -/*! @function start - @abstract Starts event delivery to the queue. - @result Returns an IOReturn code. -*/ - IOReturn (*start)(void * self); - -/*! @function stop - @abstract Stops event delivery to the queue. - @result Returns an IOReturn code. -*/ - IOReturn (*stop)(void * self); - -/*! @function getNextEvent - @abstract Reads next event from the queue. - @param event The event that will be filled. If a long value is - present, it is up to the caller to deallocate it. - @param maxtime UNSUPPORTED. If non-zero, limits read events to - those that occured on or before maxTime. - @param timoutMS UNSUPPORTED. The timeout in milliseconds, a zero - timeout will cause this call to be non-blocking (returning - queue empty) if there is a NULL callback, and blocking forever - until the queue is non-empty if there is a valid callback. - @result Returns an IOReturn code. -*/ - IOReturn (*getNextEvent)(void * self, - IOHIDEventStruct * event, - AbsoluteTime maxTime, - UInt32 timeoutMS); - -/*! @function setEventCallout - @abstract Sets the event callout to be called when the queue - transitions to non-empty. - @discussion In order for this to work correctly, you must call - createAsyncPort and createAsyncEventSource. - @param callback if non-NULL is a callback to be called when data - is inserted to the queue - @param callbackTarget The callback target passed to the callback - @param callbackRefcon The callback refcon passed to the callback. - @result Returns an IOReturn code. -*/ - IOReturn (*setEventCallout)(void * self, - IOHIDCallbackFunction callback, - void * callbackTarget, - void * callbackRefcon); - -/*! @function getEventCallout - @abstract Gets the event callout. - @discussion This callback will be called the queue transitions - to non-empty. - @param callback if non-NULL is a callback to be called when data - is inserted to the queue - @param callbackTarget The callback target passed to the callback - @param callbackRefcon The callback refcon passed to the callback - @result Returns an IOReturn code. -*/ - IOReturn (*getEventCallout)(void * self, - IOHIDCallbackFunction * outCallback, - void ** outCallbackTarget, - void ** outCallbackRefcon); -} IOHIDQueueInterface; - -/*! @class IOHIDOutputTransactionInterface - @discussion CFPlugin object subclass which privides interface for output - transactions to HID devices. Created by a IOHIDDeviceInterface - object. */ - -typedef struct IOHIDOutputTransactionInterface -{ - IUNKNOWN_C_GUTS; - -/*! @function createAsyncEventSource - @abstract Creates an async event source. - @discussion This will be used with setEventCallout. - @param source The newly created event source - @result Returns an IOReturn code. -*/ - IOReturn (*createAsyncEventSource)(void * self, - CFRunLoopSourceRef * source); - -/*! @function getAsyncEventSource - @abstract Obtains the current event source. - @result Returns a CFRunLoopSourceRef. -*/ - CFRunLoopSourceRef (*getAsyncEventSource)(void * self); - -/*! @function createAsyncPort - @abstract Creates an async port. - @discussion This will be used with createAsyncEventSource. - @param port The newly created async port. - @result Returns an IOReturn code. -*/ - IOReturn (*createAsyncPort)(void * self, mach_port_t * port); - -/*! @function getAsyncPort - @abstract Obtains the current async port. - @result Returns a mach_port_t. -*/ - mach_port_t (*getAsyncPort)(void * self); - -/*! @function create - @abstract Creates the current transaction. - @discussion This method will free any memory that has been - allocated for this transaction. - @result Returns an IOReturn code. -*/ - IOReturn (*create)(void * self); - -/*! @function dispose - @abstract Disposes of the current transaction. - @discussion The transaction will have to be recreated, in order - to perform any operations on the transaction. - @result Returns an IOReturn code. -*/ - IOReturn (*dispose)(void * self); - -/*! @function addElement - @abstract Adds an element to the transaction. - @discussion If the element has already been added to transaction, - an error will be returned. - @param elementCookie The element of interest. - @result Returns an IOReturn code. -*/ - IOReturn (*addElement) (void * self, IOHIDElementCookie elementCookie); - -/*! @function removeElement - @abstract Removes an element from the transaction. - @discussion If the element has not been added to transaction, - an error will be returned. - @param elementCookie The element of interest. - @result Returns an IOReturn code. -*/ - IOReturn (*removeElement) (void * self, IOHIDElementCookie elementCookie); - -/*! @function hasElement - @abstract Checks whether an element has been added to - the transaction. - @discussion Will return true if present, otherwise will return false. - @param elementCookie The element of interest. - @result Returns a Boolean value. -*/ - Boolean (*hasElement) (void * self, IOHIDElementCookie elementCookie); - -/*! @function setElementDefault - @abstract Sets the default value of an element in a - transaction. - @discussion An error will be returned if the element has not been - added to the transaction. - @param elementCookie The element of interest. - @param valueEvent The event that will be filled. If a long value is - present, it will be copied. - @result Returns an IOReturn code. -*/ - IOReturn (*setElementDefault)(void * self, - IOHIDElementCookie elementCookie, - IOHIDEventStruct * valueEvent); - -/*! @function getElementDefault - @abstract Obtains the default value of an element in a - transaction. - @discussion An error will be returned if the element has not been - added to the transaction. - @param elementCookie The element of interest. - @param outValueEvent The event that will be filled. If a long value is - present, it is up to the caller to deallocate it. - @result Returns an IOReturn code. -*/ - IOReturn (*getElementDefault)(void * self, - IOHIDElementCookie elementCookie, - IOHIDEventStruct * outValueEvent); - -/*! @function setElementValue - @abstract Sets the value of an element in a transaction. - @discussion An error will be returned if the element has not been - added to the transaction. - @param elementCookie The element of interest. - @param valueEvent The event that will be filled. If a long value is - present, it will be copied. - @result Returns an IOReturn code. -*/ - IOReturn (*setElementValue)(void * self, - IOHIDElementCookie elementCookie, - IOHIDEventStruct * valueEvent); - -/*! @function getElementValue - @abstract Obtains the value of an element in a transaction. - @discussion An error will be returned if the element has not been - added to the transaction. - @param elementCookie The element of interest. - @param outValueEvent The event that will be filled. If a long value is - present, it is up to the caller to deallocate it. - @result Returns an IOReturn code. -*/ - IOReturn (*getElementValue)(void * self, - IOHIDElementCookie elementCookie, - IOHIDEventStruct * outValueEvent); - -/*! @function commit - @abstract Commits the transaction. - @discussion Transaction element values, if set, will be sent to the - device. Otherwise, the default element value will be used. If - neither are set, that element will be omitted from the commit. - After a transaction is committed, transaction element values - will be cleared. Default values will be preserved. - @param timeoutMS UNSUPPORTED - @param callback UNSUPPORTED - @param callbackTarget UNSUPPORTED - @param callbackRefcon UNSUPPORTED - @result Returns an IOReturn code. -*/ - IOReturn (*commit)(void * self, - UInt32 timeoutMS, - IOHIDCallbackFunction callback, - void * callbackTarget, - void * callbackRefcon); - -/*! @function clear - @abstract Clears the transaction. - @discussion Transaction element values will cleared. Default - values will be preserved. - @result Returns an IOReturn code. -*/ - IOReturn (*clear)(void * self); -} IOHIDOutputTransactionInterface; - -#endif - -__END_DECLS - -#endif /* !_IOKIT_HID_IOHIDLIB_H_ */ diff --git a/l4/pkg/libsdl/contrib/src/joystick/os2/SDL_sysjoystick.c b/l4/pkg/libsdl/contrib/src/joystick/os2/SDL_sysjoystick.c deleted file mode 100644 index 8f80655d9..000000000 --- a/l4/pkg/libsdl/contrib/src/joystick/os2/SDL_sysjoystick.c +++ /dev/null @@ -1,668 +0,0 @@ -/* - SDL - Simple DirectMedia Layer - Copyright (C) 1997-2009 Sam Lantinga - - This library is free software; you can redistribute it and/or - modify it under the terms of the GNU Lesser General Public - License as published by the Free Software Foundation; either - version 2.1 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 Lesser General Public - License along with this library; if not, write to the Free Software - Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA - - Sam Lantinga - slouken@libsdl.org -*/ -#include "SDL_config.h" - -#ifdef SDL_JOYSTICK_OS2 - -/* OS/2 Joystick driver, contributed by Daniel Caetano */ - -#include - -#define INCL_DOSDEVICES -#define INCL_DOSDEVIOCTL -#define INCL_DOSMEMMGR -#include -#include "joyos2.h" - -#include "SDL_joystick.h" -#include "SDL_events.h" -#include "../SDL_sysjoystick.h" -#include "../SDL_joystick_c.h" - -HFILE hJoyPort = NULL; /* Joystick GAME$ Port Address */ -#define MAX_JOYSTICKS 2 /* Maximum of two joysticks */ -#define MAX_AXES 4 /* each joystick can have up to 4 axes */ -#define MAX_BUTTONS 8 /* 8 buttons */ -#define MAX_HATS 0 /* 0 hats - OS/2 doesn't support it */ -#define MAX_BALLS 0 /* and 0 balls - OS/2 doesn't support it */ -#define AXIS_MIN -32768 /* minimum value for axes coordinate */ -#define AXIS_MAX 32767 /* maximum value for axes coordinate */ -#define MAX_JOYNAME 128 /* Joystick name may have 128 characters */ -/* limit axes to 256 possible positions to filter out noise */ -#define JOY_AXIS_THRESHOLD (((AXIS_MAX)-(AXIS_MIN))/256) -/* Calc Button Flag for buttons A to D */ -#define JOY_BUTTON_FLAG(n) (1< MAX_JOYSTICKS ) maxdevs = MAX_JOYSTICKS; - -/* Defines min/max axes values (callibration) */ -ulDataLen = sizeof(stGameCalib); -rc = DosDevIOCtl(hJoyPort, IOCTL_CAT_USER, GAME_GET_CALIB, - NULL, 0, NULL, &stGameCalib, ulDataLen, &ulDataLen); -if (rc != 0) - { - joyPortClose(&hJoyPort); - SDL_SetError("Could not read callibration data."); - return -1; - } - -/* Determine how many joysticks are active */ -numdevs = 0; /* Points no device */ -ucNewJoystickMask = 0x0F; /* read all 4 joystick axis */ -ulDataLen = sizeof(ucNewJoystickMask); -rc = DosDevIOCtl(hJoyPort, IOCTL_CAT_USER, GAME_PORT_RESET, - &ucNewJoystickMask, ulDataLen, &ulDataLen, NULL, 0, NULL); -if (rc == 0) - { - ulDataLen = sizeof(stJoyStatus); - rc = DosDevIOCtl(hJoyPort, IOCTL_CAT_USER, GAME_PORT_GET, - NULL, 0, NULL, &stJoyStatus, ulDataLen, &ulDataLen); - if (rc != 0) - { - joyPortClose(&hJoyPort); - SDL_SetError("Could not call joystick port."); - return -1; - } - ulLastTick = stJoyStatus.ulJs_Ticks; - while (stJoyStatus.ulJs_Ticks == ulLastTick) - { - rc = DosDevIOCtl(hJoyPort, IOCTL_CAT_USER, GAME_PORT_GET, - NULL, 0, NULL, &stJoyStatus, ulDataLen, &ulDataLen); - } - if ((stJoyStatus.ucJs_JoyStickMask & 0x03) > 0) numdevs++; - if (((stJoyStatus.ucJs_JoyStickMask >> 2) & 0x03) > 0) numdevs++; - } - -if (numdevs>maxdevs) numdevs=maxdevs; - -/* If *any* joystick was detected... Let's configure SDL for them */ -if (numdevs > 0) - { - /* Verify if it is a "user defined" joystick */ - if (joyGetEnv(&joycfg)) - { - GAME_3POS_STRUCT * axis[4]; - axis[0] = &stGameCalib.Ax; - axis[1] = &stGameCalib.Ay; - axis[2] = &stGameCalib.Bx; - axis[3] = &stGameCalib.By; - /* Say it has one device only (user defined is always one device only) */ - numdevs = 1; - /* Define Device 0 as... */ - SYS_JoyData[0].id=0; - /* Define Number of Axes... up to 4 */ - if (joycfg.axes>MAX_AXES) joycfg.axes = MAX_AXES; - SYS_JoyData[0].axes = joycfg.axes; - /* Define number of buttons... 8 if 2 axes, 6 if 3 axes and 4 if 4 axes */ - maxbut = MAX_BUTTONS; - if (joycfg.axes>2) maxbut-=((joycfg.axes-2)<<1); /* MAX_BUTTONS - 2*(axes-2) */ - if (joycfg.buttons > maxbut) joycfg.buttons = maxbut; - SYS_JoyData[0].buttons = joycfg.buttons; - /* Define number of hats */ - if (joycfg.hats > MAX_HATS) joycfg.hats = MAX_HATS; - SYS_JoyData[0].hats = joycfg.hats; - /* Define number of balls */ - if (joycfg.balls > MAX_BALLS) joycfg.balls = MAX_BALLS; - SYS_JoyData[0].balls = joycfg.balls; - /* Initialize Axes Callibration Values */ - for (i=0; ilower; - SYS_JoyData[0].axes_med[i] = axis[i]->centre; - SYS_JoyData[0].axes_max[i] = axis[i]->upper; - } - /* Initialize Buttons 5 to 8 structures */ - if (joycfg.buttons>=5) SYS_JoyData[0].buttoncalc[0]=((axis[2]->lower+axis[3]->centre)>>1); - if (joycfg.buttons>=6) SYS_JoyData[0].buttoncalc[1]=((axis[3]->lower+axis[3]->centre)>>1); - if (joycfg.buttons>=7) SYS_JoyData[0].buttoncalc[2]=((axis[2]->upper+axis[3]->centre)>>1); - if (joycfg.buttons>=8) SYS_JoyData[0].buttoncalc[3]=((axis[3]->upper+axis[3]->centre)>>1); - /* Intialize Joystick Name */ - SDL_strlcpy (SYS_JoyData[0].szDeviceName,joycfg.name, SDL_arraysize(SYS_JoyData[0].szDeviceName)); - } - /* Default Init ... autoconfig */ - else - { - /* if two devices were detected... configure as Joy1 4 axis and Joy2 2 axis */ - if (numdevs==2) - { - /* Define Device 0 as 4 axes, 4 buttons */ - SYS_JoyData[0].id=0; - SYS_JoyData[0].axes = 4; - SYS_JoyData[0].buttons = 4; - SYS_JoyData[0].hats = 0; - SYS_JoyData[0].balls = 0; - SYS_JoyData[0].axes_min[0] = stGameCalib.Ax.lower; - SYS_JoyData[0].axes_med[0] = stGameCalib.Ax.centre; - SYS_JoyData[0].axes_max[0] = stGameCalib.Ax.upper; - SYS_JoyData[0].axes_min[1] = stGameCalib.Ay.lower; - SYS_JoyData[0].axes_med[1] = stGameCalib.Ay.centre; - SYS_JoyData[0].axes_max[1] = stGameCalib.Ay.upper; - SYS_JoyData[0].axes_min[2] = stGameCalib.Bx.lower; - SYS_JoyData[0].axes_med[2] = stGameCalib.Bx.centre; - SYS_JoyData[0].axes_max[2] = stGameCalib.Bx.upper; - SYS_JoyData[0].axes_min[3] = stGameCalib.By.lower; - SYS_JoyData[0].axes_med[3] = stGameCalib.By.centre; - SYS_JoyData[0].axes_max[3] = stGameCalib.By.upper; - /* Define Device 1 as 2 axes, 2 buttons */ - SYS_JoyData[1].id=1; - SYS_JoyData[1].axes = 2; - SYS_JoyData[1].buttons = 2; - SYS_JoyData[1].hats = 0; - SYS_JoyData[1].balls = 0; - SYS_JoyData[1].axes_min[0] = stGameCalib.Bx.lower; - SYS_JoyData[1].axes_med[0] = stGameCalib.Bx.centre; - SYS_JoyData[1].axes_max[0] = stGameCalib.Bx.upper; - SYS_JoyData[1].axes_min[1] = stGameCalib.By.lower; - SYS_JoyData[1].axes_med[1] = stGameCalib.By.centre; - SYS_JoyData[1].axes_max[1] = stGameCalib.By.upper; - } - /* One joystick only? */ - else - { - /* If it is joystick A... */ - if ((stJoyStatus.ucJs_JoyStickMask & 0x03) > 0) - { - /* Define Device 0 as 2 axes, 4 buttons */ - SYS_JoyData[0].id=0; - SYS_JoyData[0].axes = 2; - SYS_JoyData[0].buttons = 4; - SYS_JoyData[0].hats = 0; - SYS_JoyData[0].balls = 0; - SYS_JoyData[0].axes_min[0] = stGameCalib.Ax.lower; - SYS_JoyData[0].axes_med[0] = stGameCalib.Ax.centre; - SYS_JoyData[0].axes_max[0] = stGameCalib.Ax.upper; - SYS_JoyData[0].axes_min[1] = stGameCalib.Ay.lower; - SYS_JoyData[0].axes_med[1] = stGameCalib.Ay.centre; - SYS_JoyData[0].axes_max[1] = stGameCalib.Ay.upper; - } - /* If not, it is joystick B */ - else - { - /* Define Device 1 as 2 axes, 2 buttons */ - SYS_JoyData[0].id=1; - SYS_JoyData[0].axes = 2; - SYS_JoyData[0].buttons = 2; - SYS_JoyData[0].hats = 0; - SYS_JoyData[0].balls = 0; - SYS_JoyData[0].axes_min[0] = stGameCalib.Bx.lower; - SYS_JoyData[0].axes_med[0] = stGameCalib.Bx.centre; - SYS_JoyData[0].axes_max[0] = stGameCalib.Bx.upper; - SYS_JoyData[0].axes_min[1] = stGameCalib.By.lower; - SYS_JoyData[0].axes_med[1] = stGameCalib.By.centre; - SYS_JoyData[0].axes_max[1] = stGameCalib.By.upper; - } - } - /* Hack to define Joystick Port Names */ - if ( numdevs > maxdevs ) numdevs = maxdevs; - for (i=0; ihwdata = (struct joystick_hwdata *) SDL_malloc(sizeof(*joystick->hwdata)); -if (joystick->hwdata == NULL) - { - SDL_OutOfMemory(); - return(-1); - } -/* Reset Hardware Data */ -SDL_memset(joystick->hwdata, 0, sizeof(*joystick->hwdata)); - -/* ShortCut Pointer */ -index = joystick->index; -/* Define offsets and scales for all axes */ -joystick->hwdata->id = SYS_JoyData[index].id; -for ( i = 0; i < MAX_AXES; ++i ) - { - if ( (i<2) || i < SYS_JoyData[index].axes ) - { - joystick->hwdata->transaxes[i].offset = ((AXIS_MAX + AXIS_MIN)>>1) - SYS_JoyData[index].axes_med[i]; - //joystick->hwdata->transaxes[i].scale = (float)((AXIS_MAX - AXIS_MIN)/(SYS_JoyData[index].axes_max[i]-SYS_JoyData[index].axes_min[i])); - joystick->hwdata->transaxes[i].scale1 = (float)abs((AXIS_MIN/SYS_JoyData[index].axes_min[i])); - joystick->hwdata->transaxes[i].scale2 = (float)abs((AXIS_MAX/SYS_JoyData[index].axes_max[i])); - } - else - { - joystick->hwdata->transaxes[i].offset = 0; - //joystick->hwdata->transaxes[i].scale = 1.0; /* Just in case */ - joystick->hwdata->transaxes[i].scale1 = 1.0; /* Just in case */ - joystick->hwdata->transaxes[i].scale2 = 1.0; /* Just in case */ - } - } - -/* fill nbuttons, naxes, and nhats fields */ -joystick->nbuttons = SYS_JoyData[index].buttons; -joystick->naxes = SYS_JoyData[index].axes; -/* joystick->nhats = SYS_JoyData[index].hats; */ -joystick->nhats = 0; /* No support for hats at this time */ -/* joystick->nballs = SYS_JoyData[index].balls; */ -joystick->nballs = 0; /* No support for balls at this time */ -return 0; -} - - - -/***************************************************************************/ -/* Function to update the state of a joystick - called as a device poll. */ -/* This function shouldn't update the joystick structure directly, */ -/* but instead should call SDL_PrivateJoystick*() to deliver events */ -/* and update joystick device state. */ -/***************************************************************************/ -void SDL_SYS_JoystickUpdate(SDL_Joystick *joystick) -{ -APIRET rc; /* Generic OS/2 return code */ -int index; /* index shortcurt to joystick index */ -int i; /* Generic counter */ -int normbut; /* Number of buttons reported by joystick */ -int corr; /* Correction for button names */ -Sint16 value, change; /* Values used to update axis values */ -struct _transaxes *transaxes; /* Shortcut for Correction structure */ -Uint32 pos[MAX_AXES]; /* Vector to inform the Axis status */ -ULONG ulDataLen; /* Size of data */ -GAME_STATUS_STRUCT stGameStatus; /* Joystick Status Structure */ - -ulDataLen = sizeof(stGameStatus); -rc = DosDevIOCtl(hJoyPort, IOCTL_CAT_USER, GAME_GET_STATUS, - NULL, 0, NULL, &stGameStatus, ulDataLen, &ulDataLen); -if (rc != 0) - { - SDL_SetError("Could not read joystick status."); - return; /* Could not read data */ - } - -/* Shortcut pointer */ -index = joystick->index; -/* joystick motion events */ - -if (SYS_JoyData[index].id == 0) - { - pos[0] = stGameStatus.curdata.A.x; - pos[1] = stGameStatus.curdata.A.y; - if (SYS_JoyData[index].axes >= 3) pos[2] = stGameStatus.curdata.B.x; - else pos[2]=0; - if (SYS_JoyData[index].axes >= 4) pos[3] = stGameStatus.curdata.B.y; - else pos[3]=0; - pos[4]=0; /* OS/2 basic drivers do not support more than 4 axes joysticks */ - pos[5]=0; - } -else if (SYS_JoyData[index].id == 1) - { - pos[0] = stGameStatus.curdata.B.x; - pos[1] = stGameStatus.curdata.B.y; - pos[2]=0; - pos[3]=0; - pos[4]=0; - pos[5]=0; - } - -/* Corrects the movements using the callibration */ -transaxes = joystick->hwdata->transaxes; -for (i = 0; i < joystick->naxes; i++) - { - value = pos[i] + transaxes[i].offset; - if (value<0) - { - value*=transaxes[i].scale1; - if (value>0) value = AXIS_MIN; - } - else - { - value*=transaxes[i].scale2; - if (value<0) value = AXIS_MAX; - } - change = (value - joystick->axes[i]); - if ( (change < -JOY_AXIS_THRESHOLD) || (change > JOY_AXIS_THRESHOLD) ) - { - SDL_PrivateJoystickAxis(joystick, (Uint8)i, (Sint16)value); - } - } - -/* joystick button A to D events */ -if (SYS_JoyData[index].id == 1) corr = 2; -else corr = 0; -normbut=4; /* Number of normal buttons */ -if (joystick->nbuttonsnbuttons; -for ( i = corr; (i-corr) < normbut; ++i ) - { - /* - Button A: 1110 0000 - Button B: 1101 0000 - Button C: 1011 0000 - Button D: 0111 0000 - */ - if ( (~stGameStatus.curdata.butMask)>>4 & JOY_BUTTON_FLAG(i) ) - { - if ( ! joystick->buttons[i-corr] ) - { - SDL_PrivateJoystickButton(joystick, (Uint8)(i-corr), SDL_PRESSED); - } - } - else - { - if ( joystick->buttons[i-corr] ) - { - SDL_PrivateJoystickButton(joystick, (Uint8)(i-corr), SDL_RELEASED); - } - } - } - -/* Joystick button E to H buttons */ - /* - Button E: Axis 2 X Left - Button F: Axis 2 Y Up - Button G: Axis 2 X Right - Button H: Axis 2 Y Down - */ -if (joystick->nbuttons>=5) - { - if (stGameStatus.curdata.B.x < SYS_JoyData[index].buttoncalc[0]) SDL_PrivateJoystickButton(joystick, (Uint8)4, SDL_PRESSED); - else SDL_PrivateJoystickButton(joystick, (Uint8)4, SDL_RELEASED); - } -if (joystick->nbuttons>=6) - { - if (stGameStatus.curdata.B.y < SYS_JoyData[index].buttoncalc[1]) SDL_PrivateJoystickButton(joystick, (Uint8)5, SDL_PRESSED); - else SDL_PrivateJoystickButton(joystick, (Uint8)5, SDL_RELEASED); - } -if (joystick->nbuttons>=7) - { - if (stGameStatus.curdata.B.x > SYS_JoyData[index].buttoncalc[2]) SDL_PrivateJoystickButton(joystick, (Uint8)6, SDL_PRESSED); - else SDL_PrivateJoystickButton(joystick, (Uint8)6, SDL_RELEASED); - } -if (joystick->nbuttons>=8) - { - if (stGameStatus.curdata.B.y > SYS_JoyData[index].buttoncalc[3]) SDL_PrivateJoystickButton(joystick, (Uint8)7, SDL_PRESSED); - else SDL_PrivateJoystickButton(joystick, (Uint8)7, SDL_RELEASED); - } - -/* joystick hat events */ -/* Not Supported under OS/2 */ -/* joystick ball events */ -/* Not Supported under OS/2 */ -} - - - -/******************************************/ -/* Function to close a joystick after use */ -/******************************************/ -void SDL_SYS_JoystickClose(SDL_Joystick *joystick) -{ -if (joystick->hwdata != NULL) - { - /* free system specific hardware data */ - SDL_free(joystick->hwdata); - } -} - - - -/********************************************************************/ -/* Function to perform any system-specific joystick related cleanup */ -/********************************************************************/ -void SDL_SYS_JoystickQuit(void) -{ -joyPortClose(&hJoyPort); -} - - - -/************************/ -/************************/ -/* OS/2 Implementations */ -/************************/ -/************************/ - - -/*****************************************/ -/* Open Joystick Port, if not opened yet */ -/*****************************************/ -APIRET joyPortOpen(HFILE * hGame) -{ -APIRET rc; /* Generic Return Code */ -ULONG ulAction; /* ? */ -ULONG ulVersion; /* Version of joystick driver */ -ULONG ulDataLen; /* Size of version data */ - -/* Verifies if joyport is not already open... */ -if (*hGame != NULL) return 0; -/* Open GAME$ for read */ -rc = DosOpen((PSZ)GAMEPDDNAME, hGame, &ulAction, 0, FILE_READONLY, - FILE_OPEN, OPEN_ACCESS_READONLY | OPEN_SHARE_DENYNONE, NULL); -if (rc != 0) - { - SDL_SetError("Could not open Joystick Port."); - return -1; - } - -/* Get Joystick Driver Version... must be 2.0 or higher */ -ulVersion = 0; -ulDataLen = sizeof(ulVersion); -rc = DosDevIOCtl( *hGame, IOCTL_CAT_USER, GAME_GET_VERSION, - NULL, 0, NULL, &ulVersion, ulDataLen, &ulDataLen); -if (rc != 0) - { - joyPortClose(hGame); - SDL_SetError("Could not get Joystick Driver version."); - return -1; - } -if (ulVersion < GAME_VERSION) - { - joyPortClose(hGame); - SDL_SetError("Driver too old. At least IBM driver version 2.0 required."); - return -1; - } -return 0; -} - - - -/****************************/ -/* Close JoyPort, if opened */ -/****************************/ -void joyPortClose(HFILE * hGame) -{ -if (*hGame != NULL) DosClose(*hGame); -*hGame = NULL; -} - - - -/***************************/ -/* Get SDL Joystick EnvVar */ -/***************************/ -int joyGetEnv(struct _joycfg * joydata) -{ -char *joyenv; /* Pointer to tested character */ -char tempnumber[5]; /* Temporary place to put numeric texts */ - -joyenv = SDL_getenv("SDL_OS2_JOYSTICK"); -if (joyenv == NULL) return 0; -/* Joystick Environment is defined! */ -while (*joyenv==' ' && *joyenv!=0) joyenv++; /* jump spaces... */ -/* If the string name starts with '... get if fully */ -if (*joyenv=='\'') joyenv+=joyGetData(++joyenv,joydata->name,'\'',sizeof(joydata->name)); -/* If not, get it until the next space */ -else if (*joyenv=='\"') joyenv+=joyGetData(++joyenv,joydata->name,'\"',sizeof(joydata->name)); -else joyenv+=joyGetData(joyenv,joydata->name,' ',sizeof(joydata->name)); -/* Now get the number of axes */ -while (*joyenv==' ' && *joyenv!=0) joyenv++; /* jump spaces... */ -joyenv+=joyGetData(joyenv,tempnumber,' ',sizeof(tempnumber)); -joydata->axes = atoi(tempnumber); -/* Now get the number of buttons */ -while (*joyenv==' ' && *joyenv!=0) joyenv++; /* jump spaces... */ -joyenv+=joyGetData(joyenv,tempnumber,' ',sizeof(tempnumber)); -joydata->buttons = atoi(tempnumber); -/* Now get the number of hats */ -while (*joyenv==' ' && *joyenv!=0) joyenv++; /* jump spaces... */ -joyenv+=joyGetData(joyenv,tempnumber,' ',sizeof(tempnumber)); -joydata->hats = atoi(tempnumber); -/* Now get the number of balls */ -while (*joyenv==' ' && *joyenv!=0) joyenv++; /* jump spaces... */ -joyenv+=joyGetData(joyenv,tempnumber,' ',sizeof(tempnumber)); -joydata->balls = atoi(tempnumber); -return 1; -} - - - -/************************************************************************/ -/* Get a text from in the string starting in joyenv until it finds */ -/* the stopchar or maxchars is reached. The result is placed in name. */ -/************************************************************************/ -int joyGetData(char *joyenv, char *name, char stopchar, size_t maxchars) -{ -char *nameptr; /* Pointer to the selected character */ -int chcnt=0; /* Count how many characters where copied */ - -nameptr=name; -while (*joyenv!=stopchar && *joyenv!=0) - { - if (nameptr<(name+(maxchars-1))) - { - *nameptr = *joyenv; /* Only copy if smaller than maximum */ - nameptr++; - } - chcnt++; - joyenv++; - } -if (*joyenv==stopchar) - { - joyenv++; /* Jump stopchar */ - chcnt++; - } -*nameptr = 0; /* Mark last byte */ -return chcnt; -} - -#endif /* SDL_JOYSTICK_OS2 */ diff --git a/l4/pkg/libsdl/contrib/src/joystick/os2/joyos2.h b/l4/pkg/libsdl/contrib/src/joystick/os2/joyos2.h deleted file mode 100644 index 29800106e..000000000 --- a/l4/pkg/libsdl/contrib/src/joystick/os2/joyos2.h +++ /dev/null @@ -1,177 +0,0 @@ -/*****************************************************************************/ -/* */ -/* COPYRIGHT Copyright (C) 1995 IBM Corporation */ -/* */ -/* The following IBM OS/2 source code is provided to you solely for */ -/* the purpose of assisting you in your development of OS/2 device */ -/* drivers. You may use this code in accordance with the IBM License */ -/* Agreement provided in the IBM Device Driver Source Kit for OS/2. This */ -/* Copyright statement may not be removed. */ -/* */ -/*****************************************************************************/ -#ifndef JOYOS2_H -#define JOYOS2_H - -/****** GAMEPORT.SYS joystick definitions, start *****************************/ -#define GAME_VERSION 0x20 /* 2.0 First IBM version */ -#define GAMEPDDNAME "GAME$ " -#define IOCTL_CAT_USER 0x80 -#define GAME_PORT_GET 0x20 /* read GAMEPORT.SYS values */ -#define GAME_PORT_RESET 0x60 /* reset joystick mask with given value */ - -#pragma pack(1) /* pack structure size is 1 byte */ -typedef struct { /* GAMEPORT.SYS structure */ - USHORT usJs_AxCnt; /* Joystick_A X position */ - USHORT usJs_AyCnt; /* Joystick_A Y position */ - USHORT usJs_BxCnt; /* Joystick_B X position */ - USHORT usJs_ByCnt; /* Joystick_B Y position */ - USHORT usJs_ButtonA1Cnt; /* button A1 press count */ - USHORT usJs_ButtonA2Cnt; /* button A2 press count */ - USHORT usJs_ButtonB1Cnt; /* button B1 press count */ - USHORT usJs_ButtonB2Cnt; /* button B2 press count */ - UCHAR ucJs_JoyStickMask; /* mask of connected joystick pots */ - UCHAR ucJs_ButtonStatus; /* bits of switches down */ - ULONG ulJs_Ticks; /* joystick clock ticks */ -} GAME_PORT_STRUCT; -#pragma pack() /*reset to normal pack size */ -/****** GAMEPORT.SYS joystick definitions, end *******************************/ - - -/****************************************************************************/ -#define GAME_GET_VERSION 0x01 -#define GAME_GET_PARMS 0x02 -#define GAME_SET_PARMS 0x03 -#define GAME_GET_CALIB 0x04 -#define GAME_SET_CALIB 0x05 -#define GAME_GET_DIGSET 0x06 -#define GAME_SET_DIGSET 0x07 -#define GAME_GET_STATUS 0x10 -#define GAME_GET_STATUS_BUTWAIT 0x11 -#define GAME_GET_STATUS_SAMPWAIT 0x12 -/****************************************************************************/ - -/****************************************************************************/ -// bit masks for each axis -#define JOY_AX_BIT 0x01 -#define JOY_AY_BIT 0x02 -#define JOY_A_BITS (JOY_AX_BIT|JOY_AY_BIT) -#define JOY_BX_BIT 0x04 -#define JOY_BY_BIT 0x08 -#define JOY_B_BITS (JOY_BX_BIT|JOY_BY_BIT) -#define JOY_ALLPOS_BITS (JOY_A_BITS|JOY_B_BITS) - -// bit masks for each button -#define JOY_BUT1_BIT 0x10 -#define JOY_BUT2_BIT 0x20 -#define JOY_BUT3_BIT 0x40 -#define JOY_BUT4_BIT 0x80 -#define JOY_ALL_BUTS (JOY_BUT1_BIT|JOY_BUT2_BIT|JOY_BUT3_BIT|JOY_BUT4_BIT) -/****************************************************************************/ - -/****************************************************************************/ -// 1-D position struct used for each axis -typedef SHORT GAME_POS; /* some data formats require signed values */ - -// simple 2-D position for each joystick -typedef struct -{ - GAME_POS x; - GAME_POS y; -} -GAME_2DPOS_STRUCT; - -// struct defining the instantaneous state of both sticks and all buttons -typedef struct -{ - GAME_2DPOS_STRUCT A; - GAME_2DPOS_STRUCT B; - USHORT butMask; -} -GAME_DATA_STRUCT; - -// struct to be used for calibration and digital response on each axis -typedef struct -{ - GAME_POS lower; - GAME_POS centre; - GAME_POS upper; -} -GAME_3POS_STRUCT; -/****************************************************************************/ - -/****************************************************************************/ -// status struct returned to OS/2 applications: -// current data for all sticks as well as button counts since last read -typedef struct -{ - GAME_DATA_STRUCT curdata; - USHORT b1cnt; - USHORT b2cnt; - USHORT b3cnt; - USHORT b4cnt; -} -GAME_STATUS_STRUCT; -/****************************************************************************/ - -/****************************************************************************/ -/* in use bitmasks originating in 0.2b */ -#define GAME_USE_BOTH_OLDMASK 0x01 /* for backward compat with bool */ -#define GAME_USE_X_NEWMASK 0x02 -#define GAME_USE_Y_NEWMASK 0x04 -#define GAME_USE_X_EITHERMASK (GAME_USE_X_NEWMASK|GAME_USE_BOTH_OLDMASK) -#define GAME_USE_Y_EITHERMASK (GAME_USE_Y_NEWMASK|GAME_USE_BOTH_OLDMASK) -#define GAME_USE_BOTH_NEWMASK (GAME_USE_X_NEWMASK|GAME_USE_Y_NEWMASK) - -/* only timed sampling implemented in version 1.0 */ -#define GAME_MODE_TIMED 1 /* timed sampling */ -#define GAME_MODE_REQUEST 2 /* request driven sampling */ - -/* only raw implemented in version 1.0 */ -#define GAME_DATA_FORMAT_RAW 1 /* [l,c,r] */ -#define GAME_DATA_FORMAT_SIGNED 2 /* [-l,0,+r] */ -#define GAME_DATA_FORMAT_BINARY 3 /* {-1,0,+1} */ -#define GAME_DATA_FORMAT_SCALED 4 /* [-10,+10] */ - -// parameters defining the operation of the driver -typedef struct -{ - USHORT useA; /* new bitmasks: see above */ - USHORT useB; - USHORT mode; /* see consts above */ - USHORT format; /* see consts above */ - USHORT sampDiv; /* samp freq = 32 / n */ - USHORT scale; /* scaling factor */ - USHORT res1; /* must be 0 */ - USHORT res2; /* must be 0 */ -} -GAME_PARM_STRUCT; -/****************************************************************************/ - -/****************************************************************************/ -// calibration values for each axis: -// - upper limit on value to be considered in lower range -// - centre value -// - lower limit on value to be considered in upper range -typedef struct -{ - GAME_3POS_STRUCT Ax; - GAME_3POS_STRUCT Ay; - GAME_3POS_STRUCT Bx; - GAME_3POS_STRUCT By; -} -GAME_CALIB_STRUCT; -/****************************************************************************/ - -/****************************************************************************/ -// struct defining the digital response values for all axes -typedef struct -{ - GAME_3POS_STRUCT Ax; - GAME_3POS_STRUCT Ay; - GAME_3POS_STRUCT Bx; - GAME_3POS_STRUCT By; -} -GAME_DIGSET_STRUCT; -/****************************************************************************/ - -#endif diff --git a/l4/pkg/libsdl/contrib/symbian.zip b/l4/pkg/libsdl/contrib/symbian.zip deleted file mode 100644 index b3686e926b04b810dffe7887fa76f93977c8dfc7..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 378899 zcmbrm1#l(1k|uo2)MlnOGcz;WZMNIY%*@Qp%*@Poo2kvr%*;$}dwt)V*?0H-J3ABc zpNK4#q9m0vQ%ZfxR2?}f5Kt5V000SCs}yD}9`8(X{>o*25#kpKsz}Hv(m5Df8o3%N z(+Z1-Iz&NU!$U(I9_%*4%h23NkB>V*I^Wn$P&wE_I^WwmLc;)swIv;raIw3BvIoBa z8wn78NDT4=g^+_mfC+)|`S6M9sDN1njdvh{g*sDFmD*vAaD)vGLfaak#NXY8OQFm= z@`pR2;Ma>6Q=0l2F}t<7wgKe+cP9zdG+2Y=UNIaY0f74N007+IJNb_u7O6=&tg$2U zUMWrZOq-2KObARz=szOJ!w*%fHWQA?Wn<`DcHyeVY#ajxWas)3xs-2{(s`-;zf zM-ks0Z$~GUwC&-gzefKww*QlFUsiCP;;5keSkwN#x}}{}Vo!%%#Kb43s2xozp&Rjz zjDcBtQs-fFJFINKon?frXyj?j`O!`7cfuZlPUm%DYS~C_B#cehR@zLOW|W3U-@E*# z`rK3>`|w?MTFLi@Cs|Ar!~q7{KjqOkD{EKIvi=Z5V|$jtKo+E|zE&?jlG*6qh$u#I zLU-@_BX@)I$b_yL6STDZ^{U<4DbY5W>3hb484qdn#(qAjVO61>F~%K;KV^Z$FUkMJ z%CcEFIW|}8Ahe!yU16~I~SyAPC&3OAkm+q zYxgvYxbH_r%~gK;5-GPj9 zxBO8-^WppnWdA{!2Ji2y7r>r-ycber+AjxWYI% zYZ_*L=44Y^8|l$}A?MyV7hXCvGX;K8d%MthgID*3Z$}p`<|uHGA6akQQw7X%c<9#* zD4AqZA4oy#`-_bp0?zoIthjl+5KgJ?kpr_OSecvaN17eBGpa0wGg!Pzq1q{Lo4+FS zv}GNvuMAMdgyj_df$_TFoG>o1daz=E6?eejUHTW0CtVe?nFVpvdT_;lT>SBMGFCc^ zWMTa^UZ*rW|NYyql(Nc-_2AyC&70N;nI5Qd#*#UHhWUsKpg2Tp*HaV z1B`tPw_(fmnC}VrqPDsLA^g>@?B~I;gN=!3L}S3Al;uHDTzcIo@B*Qla8Nohrrcmd z?2w#Ux)k;jBeAz6J5FlXc%ce?#J}DdYXV}(tp@fr3(1%Z&Lx;~a{SLJP-hW~kgcmSZ6RTq1BQ>v*uh%6 ziJr(>(M@E5FrwbFM5`chkdaivtmied?J&)`kLz1IyENCSRYH-`CPpxjPYWFd!ThJ# zNdIJs*>xP`MT!k`#T0xCfigRiYp6)XmbH@m8C7Qi;*>A_%Ibdo7)pFM{` zaUCuw{8Z#QFj70FPc(~gn&rzH$VxPJ2tC@b>_`Vp&>zY5tz@!e9k4hTt4Y#u?J(`CiTVaY>Igyh)5ojz0H~0D4H&BFDDeC4j}_ zLT=JkPhm385-3m&VnuoQaaV5E^@fB!%iqej566Mrpu;yIcP&C_C0_TTCy`E@zlP;_ zp41{MnWM%wgO=O{a+w)un?PT&F=$tbU&yk(`DC^RQA*hAx3m0nBo}j2+p3rt9PR^< z#_;^1WZ%O{`f4EVqA_cpREt@Q4gA|d=VvlHj#QVF>npTT0p$_x&MBp2_RG!N_jp`X zJdAH;0?`=*H)dLb$lv>4-0!r0BDz=x$dNI#=jlFMzE++st4hamHO>5tv(qxa9v$RP zR;uIOF~>EeG*QiQBFGMe6gxW(QKLFTcDLp)UBKTlK~8L%)bkRY4!--5-JzKum?w=j zbSi=+AUIRZ%~B#mkCsL7sKNJFBYdA|be<*x}n&Z+bs?NW?YUkWexlA`Fr6 zRuD%@ZKv!OoEUB)Sbm3w05u}qCQ#eRthgQ_K^^cqXxPX79{{&J0 z!Z3dUEwATqwZdP|#J>pPi$nwjCI0U?D>CMm3FaRVi|IcR7wm2GHz0;}$-8(akZ-VF zez*8tJ_>fl{sI1Z{yE(_1vON3=yd3RLro}_o2+ca5A^;J000Fx008^9H~s@O1*KZq ztg)g5@!9lz2>HGPDK2Kz>80+a(28f4#v8P}A(1mCK*o_o#b+LFUEPMq7fF$Vsn0(+ zh=+&FALOZQ`M29*zdxSQ&DhJ+dRkO+B{7+v{gE7M<DM%qq$v+ri6^tSz_xCa09t3k!o4&9mE>v=**@Q>r^ByG>(R&D^^u*~kwvqAkna zQS|5jGdHb>`?_9=)$u||;W+*@VZ$KozjkS8 z=`u>lXl)%;kk^mWPB-V&++u48Dv?-8H%C@dj9R)Lf0Wceif;}d!ac++!Kj)xLExO? zPFq*uo?_Ot(;UgQ07kSR+ADr54(1i#yh?d;|JL(N^cc^JzQNiAb*g5crwQB$#63l? zVH?aV`K6YTU*D{imQTtwOA$_g@(Rg;IBQ{}huf3p|?3wcH2y0Y8cl7<{lypMp zWk(MpgNMeRLRU#{L}b^#`Fov2S8z(kHc&+<+XBHn6qprs!qR2t15Q>J?5$>2ba>>E zd@nY73a0u2Vg;++iZ!N>p^ZP0?$R%~iMaOTyS4tz_rtR>VFqiByGtOo$BAxxqcj#ytb(byi< zBpIrlH;jwme0~fSl$gI6sy7d6n1R3*52%gvmpraJ>AdrChTIxKQxIMR@|EIqU@Foe z*=9GIrJ$!DC^8C$<;uY9^v@2L7bnJrW7kAiEcacUKk9TT}8}#EnDK#x853FOq8e%CG`1*l5R~U;?RCuMIx?5_Uet955=a`j#--d`v41+ zA)h!;ly$_>QDjX9bp+Dzc2(puxdp!qCw=;Q9ls-@-^_AXj7XRr6hT4lX=aIl7u{@n zh2*5ExC(+4T>*!d0CiWSsAC|TR?B<^TDf(ZGL6y(Qb6?WE+&2&W@yKCtscJ5^V6a> zz!-U%@cIh4d6`lKm8mS>uRKW&91~<^!(b51@=3X;64rC&9S>U?HmcaRZ2Lt|X9u{Z z&%&pI*8q8Ko_JsRlRsA^&j4Zd)=wDPYtY`O+PVPZ&>CWESj8e}LQCil^E(i}v;*y` z%eFD9yWSgvVS=rWi0xEBwBRB2HeYK%%AdsMK~q4DG25!4zeURnLQpQuUNmkO#lPw4J{)SI*X-Ih;SZQC{=+ zzIvpC3;0W2yz-%op64x0@-Ah|9Z2&kXT9d}JUZyHHJW%;D+|f;DX8tKc|1-9y-!ab zsk1b`m6_9@!K?h9HF@9JRqa=cNjXqY3aTcg4hN@%x`g)8S9l$3ROt5C8g-35oT{*G zPVGLFi@db6cq=Gc)$Y9<%D->gu?oMSlScQ^{PS`2cv`cSgcQO*IA6JZ;+sxB(GFWa=)tue7DkyFW6?!_DR z75jlGE#CupPop1}DK_Y_}MAUj+|+yJWV^`kK?t#0@GE8l+& zA;A7~vHll=AT-}(O|zbT96F4rUhO*VvF52#d=OIkC9ItS9vFgKlXfs-k3+|)kEujXNlHy zgJ#kLdkKuA{Vf3n290AK_|o})$AXC%dcs-0na8|FpLTh4Zi?cyhkaGoHJ@d~d3q?w z=oOA7&#;mNy$zzrXy!T_^rMS)HHlsx57f@8c6mc|A<1n-M|!dwCqK!DD^?wyRX?Q3 z7F@^V&KU^Urn=hpmgD0hC!~EMlvsQob97;($BH^{Zz!Vbc)I&r9>D%3ph2@u)-Q(t z_wO$>^Pk*{NC_~|{ntft|GlW9@DCj$TN?v=Cu>JDE2IBMRigi{s-U!hg7iNc_@_Tj zrTLD2w0mYu^{b-q7qR`%8u+V6B66}q3d%A{64E07=5=$FrGb*6m6V>i8{Wn_jD7!Jn7pkybC1zO{-1&4}|zn-1_e_{qMQ`hiC9#L-H?fA(TfJ-M+ZY{U34rj|TqV+%~%Won05( zzwzqyK3H7HP0h?5OTsS*!Nipd9t$Vv)H zkI3;eOpJo`Q$+1$^zG_^%TJ)q(>pXfH2?pI!^Gak$@Xu`$B&I-Trw}_-Tx8=$JY#{ z`bz(gG5YTV@1G3_2>uYJ6%~E;71X8^8d7j8YdmlO)oZsF~fG6h5n6Lz(t_y z6&7EnNV@x^vR9l~{r$?Nk-(gBeX0&3RLS6nHSE_E(s~s5X30pAN2v~IBvx2?6Al_Qw>k5h4RVLJ!rZv zx>B_swW!M=%UI`#=OfIg$l?}7Bu>O^8DNv;%C=OLwDLCeQ5uKR9PBwh4+Y)*QmNpd z<8ty8&nn-pzu}%(RAE&fHg|HbT9Cu8bXS>_W>{oMNgSNvEnR&4ZF^#1c}HIkU_V>%7MTrE|=&|lH%=&a5Yud;g z>2|B|9}0)Qy<@4kW)Uun!7%@tSmrKw^v^#6^V7bBGWtb-nZEzQNc!^G|J|_BT3Ok` z*nP8iftBChr>lR*@8lKugDX<1rwKswqv*8a)SIr8Z)^lWSz#4G|P z&h9A;>OmyX2?Hyz#6eESxQM-daWYy7+R4}Kq#!pWKJ>--f6P0A|BhKR zYlFYdI0rh(e<{b|XI$wx2%SHw?O$a6f z+v1_g@x+K{n6{|R8GiTk(y0%Wf#CW;%6sb|KK1~b24zscA=_qa>(;S}Tswj=8tEbI zrn`VWJ#yFdejms1?3=qKh#Q<-Gvql~Bp-9p^yChUxHM2Cm5^MYYjV6Q@V$|g`ydmj z%|Yot#w`|$E@auT`U3T6=3M7Hl!rF0A4WYhh?ERabq|}+qMUwDyDw^Jh%a0eKNQV{ z1yIcfj)h@SK;k6gl|b0Yw49)&rpgY;rgVVP-s?@wQVW?)YKgV(jH{w07aFH7PH#zd z@fru?Q@LYd#e{nXy2G@(Ah^3MYDcbNvB-X6Rrk2h!_dS9Sm2$rJIh>R&B}?{@GIWd zf4#Q;x4Lq$|GTc7!!Q_Jy}Y@Dzw~qt3;;0yce?tk`oCFCS_50#Ao(@Petrb6=4qeQ zX8bbo4nIM6KXU_`W=d)5SCqxeLbY|vQENi9o2@M3RZ%c4@l+lUU*JJFoq%yZDyT2(ekLAd^#ca~2(m(GWZuTq5U zt@GCORBuk1h{c7Noqm>ViZlA!Lp7L=^ z^7UA!Xb@)`ljL`{`3rUPi4$;!!Qmv5{UHgWWH>gf9BgJj;?CTdfCa!&ieR^a(`x6VNQ!t>@8GjVvlgB6oiL z*q}4K4f{+X02{+Aeb8<{x5^Nzu*};fq|VcC=*A&7Em~nTMo?sE7Ops{+9T^l$y}+K zaMl*W`V-*%DneCs+64cvVR8R&=kx`yUZ_yJO725{t7t$r)B%A zq@jZzt?3|!#g}L5x&e5f4}nH*SYWznlGRW~r6>8K$oJ0o0KX@=SC^QSfHa|8d}So~ zyyfbdnTE=Ok2*VU_jgdAkH|bt~e-|Fgb}#&j`2+0oh#B6M}340wu{DePET#7(3KoX6tu zwv2dmo1}yz9Nrj;F6TGP81X?RvPmXX8H-y8JvaQ!c{-!pIuE~VaD@jUd|cklH8P;2 zqnZ&oP!j(;w*=vO3{W${OTKBvzRCX-sk(6{uH?2ce zqr3BH$sq8`WyPj+<~$lrHm*l>2SZ zGHG!EcXBvg#-m0DMK@Ul6Sl78L0+RzVW2Fg#|6Lqmo>Yav*b1f;02py#X-4tJrxHoUFI6gb(;_-=#2C ztdmvQh(@BRIOKxPNkw3dsFWWA?b zy$l%xv6$GUZ|J{+Xx5QTMPM`q?}^<4$6rbAgin{Do90(h8LU@;doE-|+D)a#bnJ`qwz)A7)ZJsq!F`+wp(&j-WbeK4= zsBys@l{a$0v5x$Z<nLiuIv6~*+#-a5Px**gxrr-;(~^76bh-LpX-z+G&? z@CcVzj2=%E@n_Qtd0=;=894&#@Hr-!MB2ZF7|p(xL}3GE801_^e;!v*$m~A&lIxLZ^+4bb}=t?KT=g&AqT7SMeD< zGl;8mPYRQ#9|e_E(?Wy0)4%23(s;BQ|NQJT;8uM4+~Rfgfe&j8LpLK;b~oAi{{guSu5 z)6D)>*>{s*$$Rm&i5zpaeZwx}Jit7Rd#MHC>kz}(UAxK$Inl>I!XE$J>!K$0vQ7ma ziu!;80I^^DakPIk<$rClb-sWWt!dFu4Vztd6z^=wcX+gdDqz7Prn~x8YZd=k>ls^( zcxybO1e_joBonKUzRCOUnhWAsP^QR6CG*U^D^FhDrF+gL74Z-JBA{J8N9;l~TDzy4 z_-)V$%>h3v2>?zNxzMGpr&p2?X=LcaRqT8s{J98hW|SmMf?@9 zUpcuLsX$`THJ9fLHDXH!U%CRVAPvv(B0(9h$cL0v(Ohr9@8VGFfxBx4TDqG$vGbwd-M z2{EFW8@if?WS;su^Jl!jI! z@>5HyFmfo3G!PdMwE#_f5?No%pS;O(4J1qYv)pi=)y%%*HzxIu+md_Y+ksa7Gp$V| zLO687>x3?r)*m-y1Zv6&=9@XumKIB*4wcaq^psxb<>xxs{|H!$$UP!v?3r#? zKjI+?r9T>W9;TAcG^_|9exxX^&ZDS|J_?S*1(Kq z(wM=43SDb*=MFOmu}Yg1d9FYK5_Fi$WM*GfKFq zB3i7$Wv@P>Sj6UIt0!KM;pGqwJ$d^)$Gh0b9x9+WZF{In}aTR0;y zldzrht(82y3ebGkBWbjeyT^GY%qYu;(kk>!Qm&e`Q6A_@`+`0VBO&-&oNQE8)pweubrZ2yeAL`FJZc3$3d9%(nq{3}*z2I8kyNerU)U7wiw2I$FQ z@1lUBM$2>b>S}tJnCEbv^#!FjiRf!177-N1dm&9y^z4+i{N3YTJbY-V9iYri?uqlm@gi>M!e@i9>}O2rtWxxkiT>;ZSf7hyaAhz85JfC~pi4EcMa9bXq56T5fSfjct2+&ER?3KT>8BEc_+xGqw4GQTK(mn~CvAsMKZJ znab%>LkUVLo7mXZayEa$!yq`|_#w!V(&%Y|GUtcrnOC4^7*j?yvUPbTUy?WefS5`? zMaE3E20VDn+fOdE1Y#kXz<$|$*us3TTFoI?syL`$fb2nIG`2nWSnNBMspnH)a>Z6w zR_jxcJa5|{EppflCCG*4a(?y=o%qmKnW>d9oyYF1MbyM$KYm!BLy($3l&zIU7`RY4 z9N1t{s2mE6>x?f0n{H-qYkBF&wB)N-Dijmnl7kn*kH4vdH?kN1CbB*ZAI>2*{(s$qurO9BMfm%mm(tsAF>oP zTEvw(GahGURpf2$4Od&VK;zV~Jwl65l__Mu&HJctWy|9ua%ZZrja<1;YDIcnEt7bc&}__MdsTB$smoLf?{&(D5g zluD)5(cNfR2=sBv_ys*LcLrqT1B#4WkKV!uGGoE1v~AhRNTAtGj>3zd#Sq4?e z4xSWt<+2~>;f$oBR050FwE5%WjamPI-`|ISK*US1?)zNMSIV*h{ zMH*`>j@7h{(O8V^Puqj-iki9WC9M7mUXu@-iZcmFzev!}xN2e}p7KgGJ0~v|&$af8 zEbUCMOP%}R{>Nh^OP&7g4U#+~7SY4+Zz+o}2NMq$#|}9Q?G`PwTfqllg4xYi*I{qk zymnhN$WQOj170=hZ%E1*XVYt;OLnXh*oj(S1tZ9*C1Gg%LSRhTOAwe?tjMai1d@b=T1_LveG|-If<4?9(+sBJaldljnD_}J8Arb zhO42YfMn*t!zwt%N=X@R9&Xu)tOts$6b>6tQxqJO4PdN?h)FaZ%*th1vNqWsirP!6@5D^uz&pzCMa{&} znMT&GWk}!9%4-zI{^6;CFZ+-MB*U~9I_`TqUx3;ojA~4N&SywDUnB{3^Ua);dn$!P zr5Gh>?+EJ}RJ6F3aB731LQ?6+PyFd9p=((dR4S83B38F<lQYiR`Zmw!uk zbKuj78SSKyV!->gL!zjpG7rmvfBOKn?kEz+h#=WX zJ3%fCvx6{DO|1y;lSK5nyH$UmEcqjYZ&D`5?j}Yoi8ZHiSx}Zoh^Ne@g!pCcC5eX@a<@$Sy$nq}W6I!gRvM<(w8~UVR(sx#LXE&W zMk_2NLJr4M|Kl7jI>uo2BD*%}ZX&sRXcxIyIn__ipCoBfNlHmojpI_3ys`Inn~_gj z7MV=Rtc+1uG|&-WcvvlygfkIG<%(|D#`j0(jM0?RMCpYUii{AFd+N0Jw^q}T2!g}! zpVMZVpk^4ivRMo5_{o0)8oU`yYeT~LAqvywb7%5SQRG;eJ(iS&YFCSXl9VrdHdS{! zZ6Mk?KbdT`IghNal{6X61~2eRmXd5mul&_qZ1WeH+p@ zCd<4ZPG#1tT+=iDR>PGy=t@0r2ffjRYyy`_#8_$0ut=N=*8TPISg+$XRg#mwp1T4$<<^6yX_Gf8&?&wdHQCCN|Q?ar$a z1|cS8`70NH953}=yinV+ND_$LpOH)UJub&qqrbs%e`YaJz?&yY_>i3otV&F?rOTgH zh@=(t6i5G(?=rD@rSEMfLc*t_7Y~(j;#jpz|8Pbq@Z-kP^8}l&h9~rw>CGKr_60x@ zHf1o8Xce!Ew^ngeQ`&koZ8CXdzUL>k^D$#@r-zp&!fdp{6@btB6qxe0zJM^(Tdv_6 zU|5?yIKh%oYp?5X)Bm_zADk4>|1qYtc(Q1rr6ynidY*Q?=~U*({(R6Fq)RF+nWXP! z+EeDZG;wBUopkSIh2!9@rq${7QMtJu6O(7b4Z6o`9M_W@THtukzESscB zsg-10Xhc7)60*6Fv}y5MoKuhmuGw#u9)dzs}@DF5sLLcPt>WXkmKqcL1kkJn4S(#K?YO&9|# zr=m!7`nw^t54zTu&#?@uCKFq`eweg@YDv-a>7(i&A_tR=bX3-OV~y#oL%&(QJcc~> z4$-?fXtf5=+?p5s9*#JMOLE{eeqU+(UO1x+;aY6!+%+(fv$o{Yo^oCS6KXBEn$fFu zCRF$LiM*Uq4*YV@_QJRla4YK zK#NOzfVBTKl$v*#Z>Eor1A6nxM;r7bBKlF%Cn%v4YO6qF?EIx+>u=k=Rj+PVE06b| zhF`v0lP}*b>i-uzS?QTs)0#Rd%$WDlqj*{8ecB3OaE{s<&}FRUR-gtobFRIp>tk!- zlNOmd3H@=gQ5YmxlS;^RxNK`9yQobfKZdTS#te>Q3u~}T=5U5!AU$R|U*;f_^t(zL zppu%jS74$5Pd}lLyDQG6E8lKRw9 zSnKy6rlt=dG~Qdg-;eB%r1FSMU_@PXheMJz8|Oso zW*hUCV(F0c6$x2n$*>I>vlP1XnG1V^2-6)!+LAN*!*pvy&Gpd*qxuBzsJUh1?u^az zSi+aEPuK{E^!^n4m+ST4gSdYkEc};4)xlBE((-S?5*w>c*3Ez^DEF^D`^lFJ7XANH z`mZg!fswtDQVUXnD#G|n_?WT=B%MF(cTv|E+q7$7Vs7~7*SSk8t$IZk2?(A!MV|M) zp%!*|g>fI(nTMqIJ`kNhU?2S7L=Ybmj(QJD0ZQz0UK#*S6(fTU)?_doKLeN%6{Rr?sPIAS#;2;BY0yEUBIz(m+kn#3_&-4N!K9M7(J(KiUeuJE89J5a>* zE-FFtr8F~0OyTk0zQOR-zsq8GY-;_D3*uA`-MUh-*Z+862i8Ol zfm|j3SmhEK_$7R5F0vl-T(G!OvH=EU`f2r2H1J~vy~}DI;Y0qJa zN*cr|a=(GY;DR<^)9wr|LEmk6FXDcNi z=Zf~`K5i~-mnSsc|A zEx&>e$E9HXY!3(#8z&REr`@hfl8lQ%{1`(ZJ>G?QblBiT}_@fw&)7az$a_B*5|I{8Z%f5w}j&0^orvT->m&Z$X0p(C*~KL{7$-J&(t^mbz4g7<^&U`;?;-uQmG z8UNfp%wnW&O#%9G(XfB&Sv^ClgO`h8VZPOj*KC8Bepf@gctXaC5eid zWQCxZwLbS*L(R4Bw{1RzNM^T^HX;CjeQD7}f|{>VyB^ySKbRM9n)+=YZV3@Po~3Qz zCDn7D>NKV5Kv7dTX`ZE)Ci`TC5M!`)d@kD{Z8ZMbo)$(RoXeZE0NLIyq;aYIVzOIM zi5}ql>+YfZaTD6PM)~00WOkKG)169C;bcfYU=S?SoSN+svq7x_gnQ-X z1^EScJ)hza?%^l!zvAEz`@;^2XEK6^3@=1KuPMUop*F&w-B;?<@K`fkRq-yGK_< zH{Ua!w#mh?qZ{0=>jQ1f!TnRnUKZEX&2pB}G9QYBFN7;JXn!4`00?x$5~Ts$jb=MB zCTrA@-R?SE+GD{iZ&O>~hJ$|K_wNH?$G1u$>r@s)cn0$!>)`dm>2jnkR|3cqcTLG~ zgGv=lQW6Fo8U>8*JDy@`X|8CE9_!>(8gx09ZcqKINTaO&?|G%gVtj?ONyNIm#CItN zxgHFvjox3!Nn;mzlTQyJ>*zg+?Bs(Hn_28aE)hdq`!WLdjfL!<4h^8*)y3u|FGTwM zfOlmd&{8&Gty^hTx#c-(Y2W_1t^z?{ss2=L`r{4^Sm|tO)zp}AbddmUIBuBq=QZLZ z3NAqs>zP05Q8AiMIvQp}6!S6=_!B=1OHT*O;AZa;}(Me&u$UbE@#sd(|1$0ndVP2z+p; zqPp$)B0pNxEwqp*1`EGf|LpWeL@-ALK!QW2!51mh_)yF7+H;XoJyW#(cmnOBNfP9Mpm?HWL+M zePo%1Mwp>}376&`J+m(qFM(d90Pp^MEm%P;ZhvE;6iQeY32VGLQgY@8H?To!Qk`l* z9?)l*;Y>nm04~joKhqa6HNW=f?0v98gjmxqiA07%O$a2)AAIo1FK4L5a2bD8;BMv? zW!M^4Cb$@>Bm|8O6-Fq6>F9~EC`;>FoaP!Rt#uwFGR#U)Bvr0kZx=UuFSfrR`ZaKg&Fg7zQfb<~aiC}&)AV}xYq z7@ZpcN#v%42!)oH=tQuz^1)cH{z&l>T9Nh?2C9kY;Eqd|Zl^;yNM+3jA`5P9W_}ho zVm)wygbQ(}Rzl`sLDpP%G^faZ%?9zcst%d#EV0sj_6ZChb#1l}aU(N{PdTW?qd+u(uW;u}T=zoKx742`ooOF% zF75mV$PP0pCAa^zqKg~;VEXbeqa9~D`l?=qx*XS5hAArZW<|J$)djc`=< zT9)eaM#Ck>2Wr^0f2Dn7M!7-(S!wB43T0L{k+MB0Ao&+GbTD&p1*rKJ`?zD_{{=PyW;}S;qG`~ee+B*T!+-#UU+I^M z06p9Qz+XoS|GH;50|35kIDqr(+n6sE0t&xA<^AjDnz?7BtDD;2+tUM4SOUaAhR^`8 zE3WzjA&Nf%KG6G(_8TvMI#ejCF9tC!IJyd8_eU^sFk!GTesy3uvS0b0U&Wk}tEu7j@V9reoenZ zZOBm>zj}k%Kk2FzbUn~4Fo(Q`fY}ld78R)T9Hm@YCO<=l0L%a&AwX;jJabzjL0Vp5 zFY>VlIJh43lm9sQ3vnaRxjRVZQCTeX?rSByrc(5KrtPJpKEW}|6{XYG%-v~~v zI>K~d`q;H^oB$Gqwo;z6)!n?=1xK5bll1}v!^!BNM;qh`J{XPGK z1){AOCB2g3PPHEXDo;o|yTnu7 z`N*^UP(Bk|$}7(%Fi{2gB@wg$kzqTK!(`AWWR&Dp`Z0(0 zlTagNrfI|`ly7IG$ETHUC!{GQsw$Zc8}xw18>1P+Io~kEA|J8Pv(YoL(lgUDu-1nH z+tYj-kEG7i3?H}FZ~l7cY!F8h;;_7~xxS&HYvnxs?7z@ zUoC?Bp4Wuk89Ss7bd8Jk-WEEI7Y*j)yI}RkHYJdQd>>EQCJ#U7)ZX8W-L1S^Zp)SI zSe7tPrd2P%wp=AGyoJ#c`7~RsCpep8#>G5bu&6h@58s(e&Yq})OmNbQ?|wZjeRMBc zxYMQlG2i2rLv?7b;3PXvSTYZ`pX%>B$oUlC(A{(?6qC9%miX+@5c@Q$Io8}mcV;#+ zo0ZQ_-0BR=sBgq@p{MuC?CHFd9|Cu4Cd>u%_{Vz-nYqhdVCjKbjALOng;X(YLqL?S8`w8rkB zimU_8#$@`r3 zqH*ZW-ep#OK6RUd6i>CJs^<9+lTK8y#5yS2`AWMafX#IgYs0(r9Ai^o{!5E%r@k^f zOHnnge!4BPeGrdtg6D!@&;5Qxexy66{F$?&)7&1+r_8|F zGSjYW$$4j`A$6&?F}sN?$<=7I4Npu4+V!H08SY3OkDZF_ms^VKOMBl?N5aNgz4{h!BR$FKQi~QnoP5{Tj(&n&lDA-#EEW2rSCmxZ(YOdQ45RjiTB=H zIi4TLeK{XgP%rEE)qJ#;dBPV>=;u%0Rf)&9o;%g*=gb_=jzILw6L^%03-;}dLBuiZ z?Y$ndgp;zzGBVg$$!HbnrKXqEhKchBS=|&`5Xdx$me9*k2ivDE3=!gurhOO4_`g;W zPn{kB;OpNX0I>l;|5#H(zf!!fyzhVHUB6QNue_@{&_C81>#y{$wI;>muj^lH&G|1E zImL}7*2vOa!rV~DP)XzyEzarRz0%39@WpD<6_q%I$t?PfF32WU5*lU&M3Xk zxv7Z>+JyWeKrZ97_eia@yc`YAd4mH}0t0_rq$CFVCGMAljreTOpz;#FOx>K|$r0yu z^i?S-#HUr<@ja$}s$Ry$bMxSnv^j}N5;|URh7GdBi+K<)Nqn39~t3d@I>dFjy#jZjD9VVKj3cw$~QrUhz0Q%h3K_>Qo8;Y{TT0 z6%}4(Pz$TGggsYIktCW1MWmN-dt*`ey(`BV?)h#AF{OH!6REwNtLe#1^%gV5k@+hn=qN#^ zE3A0JE?iTALuwT*s7M9wL%2#1ngC??F4r4^n<&ckz1Y`mNCtIpk+#vr&%Mlsy5mpC zs6MjtpIAkXnl*$*f=+oZt*4Tk7fwY}Y^8_|vctA>}Ep8o|eK+wOQ zCg?HRJWMED-8II*a5@AWcd{0s>w^Ds((^=1AUUdlimev`wBY_osUGm0&Nid7dom=e zZ`GgJ`0mAy+3EIuxXc_;fwK8%6*lP!=~#ocrJF24g)6AX;xd(#^S+CH&|RD`sl7OHR4B} z6tJY^EZCc85@7`lvSl;&s1840J0JIQZ#Y%gK+0~Ic?CW{*&CLY<&BGbgb0x5DrtUp z(${}I^C^bVBz)hVt?&_>e4Gm>|4I+;CMl+@dlRvO^zj0%I_N=sKCa@WSDE^Z8fdPnWiXd zMNs$#Pa}}5Pixnw2x@~~^+dnctf&}qsH$HUot9vXnf7clXygf9;o~b6Jy9}+FG28p zCm(v@KE^Y|0snIxGus*L(72C)FZ65~b_n2G43ogoU_)lqkdgOzPM?sC$2?+vAPUQ% z<@Lv?Hgw`68{7-IGsBvhci$MtNoI1gt>iSWN^;7ig~TyfIyzsskIfYMRI7C9SvdG4 zA9q1fl_WYvN?%dusS)Rdy#cVe=Vx3}t+V?^rZK6FeJ+PVRwk#|jL3H=)#vijQ8GqG zLirP7yhMCpf}3;02`SfeE$5BAgpLB$+lkMtESjEuy)fp=7Pz;yG%M^!l6Jpz#bQj{cgRnOOL=C-QDf zMY6{x3j#3+^X}#qocIcg^E_U@Z8ehU(5u)e_te!+_UxLVmW0pCoCk``EFN0;s_AqM z`RpXe38%YmgEjra13&}6WN%@LApvF{&Zp$ajS#^5j%Ft7 z@EuucBYN3dnyp75^5SPBg$cTWL1bQ$6q2ik6%YT;XOmdlE^M@+we9*IELXf%XN(nV zfs@)bGvJz}knnpRXJ-Q>5ZD)-@a8=eQD@jmBuAOZNs2=iy77Y$Jl zYB;hD-@p#EzUEw`S6`ZW(m<1;HZ{DdT4Wgcr*vd#ggI({%uhno^)F^R_dy@E*{Ehb zvM#ql+?yTbu%Wk!kgDD92FaJzdIIDB8sFl*(?Zg&WMvdDTe2R5hTk7>INMd;aZ_iz z|4xU&?2$O`#YBnDxDyLb$ffgBg+b!s>5BQhV(?iIpo@ZsINBs^B>R4SDpow9jC#s> zE|FE~s|~LdCSG9TDYqbNz3K2FMg=CTzN`CVIXh#aXJBB`694C>H@jKfnnDO#T-Lv6 zxew<6rv;u`v6s?OC+vWLFZIfA$_i!ma#=iekTze5LNZ=VA>0Dc)#)2A^ylrLP$3I0 zBSS&~7k4cCeE&AW2k-tCEEB3Od+D_(x@g9_#~LVhI=_8w=P%n8;I?i8GLXV;L4(8g z%Mnr&68WUs-(*NUc1(ZOh4aVT{>|heKZf_J}^c}J(Uas%w0!y zaA~p?)Wjf@0=fd5-eyhHDs-8A$tS~uaipzsFKg~X7LB!4cb?1(0}p#!%j?rEUUeKl zX*ea1WPL+h7kISik?Tj!UuWay72mIPprPcZC!5tY?Dj5`smj0NH`1<;jmZvE-|?7C zJAN%Ne8uo3J`H`$1UdpaaML5}hEL7r+)? z&6TWCF)|G)JlRGelg{Us+U|&pTtrIIq1n;FFxWO?_-L6BBwDRY9CQuq;!5e$-$0u5 zZ%IpSR16b-LQMKr(Rva!ll7Z>e<&}AmHvps7jUseaYNg%0J`C=WwpwXXr|NmX!*}N zagTa3RpviWl>TUxQk62LGM|0mZX`W@RGG~A7WL{t$AF!;6qPha^hT$I&=I@7(tgqE z<&vdoqUpVt+ma9IE%?;bqd#`f>#(~iTO!#PQOKhN3&_AMO2Y}-3cB#E;kf)OY*Ncn@%n*C zB6H_Bo4j%+LzMKN@^=|?YLc`CwJPTjAQwNuQoI*UE<*UGcvim%#7xAV=GG@MZ{f#i z7f|;kFRlkx{GNw-JM}4l^5A&b2eQCcnV{cDaY*++OEM-myq)%ib@r`n^tBCS6O|BR z*WhW0E3oG#Tv)Eht=7ZotB9T5JQpi9rTxdH<<8$raVB~!eX^_rMRW0du#*RK>r!wA z;0`zLsOt~|_(6V2dxFNTYImMGR3DyWW(LS%Z@Il?s`P3tZ;3+LTP10{gEy!E<~WwN zfax`xvuhn|>P5xemp7!;F26W!!fm|Kiozpt3nIG%h5GSd*1q@*ADv<|eqz&ffQty` z$cmK>oixDYBwHm{?ro_rCr1VlO82^-^>PHXsX;I7(i1SE=DK;h4twEEEHR51w&Xn% zEnNI6u=ZTOQ#I!a%I`h2ad`_^K{?ojcQDsS77ub-?n}s`+*OSfmj z6fe2H4{L8rZ)EFldiZ*~S*}WZUYvSA9oDL|d+Xr<^*7_Nr`UOJ2`~2~KW0`$-4F~S zIJ|LN3PZC4*$IBUmOJiKNtZ;bb<~M*b*icME}I$25EA7aSh<_= z8Q?dvYJv0+<(NYJ%b{gfxZLcQzLA(N^DQrm(La?jNj3V-ndm9;+|ghuYp=_V_z6Xz zV0;(vB;h`^fW>t%NKuIqE~Wj73N6@_zovmze&jD%?l4%gB^Nwo=EbdwKi?69^R%CW zS2+Y^1BgL=tt_Dsk&MJgcrL#`+{_g}6$0Yn$h=+r5e9`t@IhK5T7Gy^h&X)gk)JS| z6V&du&_mpf!=7Hc0aGpF*^?o7dIg|V#4g2B#VXozf|{mz@fyPeee1m4YKEF7vw2_sZ1C4T_RWzy%DJm%5*mR} z8=rW<`eugQm))&b?AX09mvdu<4*^pk{qT1yQk|7|S-nX;tK##4| ztlat0*`WfOo*w702bTfH)qmV4UiS}ZQ~r?bR|^!V(?q7q#0tEyK*X*!cQy7+JvfN3 z+G4INEmsZYK}h#O7Q6^9oEm&7$8<|Gf@fi0mx|gv`T{KKcrcnT^lpGfan3Xj%WOYH ziY+f9mkH;B%PA)O6E#vga+nOuRY9kc4-nF!ij#=}LfJXg4`O+`=}|)5eCWi7HCjR!Rcu$Zse5vCtO(J$@!z{jQ8$!HIlGq64dQ^3CabYQIRrsd%s7S=N{G z0P8~YzWE+nOB!Y`>p(v`^V|O0xC1{s_D0bkgQq-X*41VgAbSqlbd% z`c*7T`WaeXnfvdF0y6Ci29b(iTfM{&p_IEvZpIf= z87lo;eId=Fj+Q?1DvAg5Lt5+Gt%8lXoqnqA`(NO2{Oqf}?NQIk11j6ugFLgijWB>Q z8Fyf>pY96jY| ze(AVL2r`DgnDN-+Kqc2rjEbi-c|1e4crLg~xuB1Rm?Mpq`l^Yu!!Y?XxB||*FzZwd!qcwEdc6N|WD9;*p*mtI!!N`2rZ^hVdv`|2bW^BFtXWG_(m zfP8Os*co5J#t~xhbybfdZ>h?5WYuJw{2>N`wzW}f|4C}w= zO|yh1j=Uufp`%Sz=75_i$!w@N;8CMzwh(}~cTn1Hps~@--Y$qy74TOnn#E6fu2uo9 zkpecJN!B1JknwyXlpQUVl z@E%*p7vu4H8ETFQN7tTJ%}HK_;!}vZd?&M+6qcfL zd~2?guQu{)cCkr%?@3k)DU5DrQ)cW-3jCWL;)<$^bE(y+l*G8#loJtz`fLM_uZI()M zez0?8&!7^rE$-a1N7iMN8-HXc>9{Q2pRzq3Cq9=P6sdh=Wc%n`)JUKK-%&ALk9hr^ z@A?+9iV_`OI%~|No=ZD2! z;NG9MZ^RSX*zwLan>%(+Ubs0Ta%L<|=8j0yB`LRVf&;p+ae<7!#w%Odm&~%fJ#{_@ z$6=0qJC7-~|76{;uX*PWi9JEt49dyPN6kYB72KhhW5mHcAz}7=6fe0X@Lm}eO{A-7 zZ^zz>vfr%cTWR!If${ru(H-y^H${^!dAzgSp2qvorxI_q@BW0yP+UO&TDeyY3Q9t( zpwjsEOXvxM#e`}9@5;g98+ueLU+3p`w1ESRjH9BxV>%PvjRsVo&B6+9_g@|724OSEYxX)JE2rL5;$7rD{ zBYT>lL3a+8U_VS_2l`n{I4!xco-;4bdx`-)79}IHRpv*31%c+BO-r*8q@{l^rq@Pf zpn`JnqfE4xVMX}H)`2^n^JW(9cdQ5pcMA>s+&4iCH43|=;MsE8;fqG~EpG>dqQv_d z{?^CEOO{D6lslv6Z`TCxy48!Q;^{5f)b`m9bfF%2{~Z>&Z8Nz`a%$+h7c%+6ipLKj z*ZJ{Mr)8O{MO5k!H9jDAX7hpT#L5k&#m<4XS9&dECxw!+_cfFJq0#5!U7rmR#bmRt zo8P_!ew^!#09ZePkgONr%JFr1I`FMj)Ed{YZ`yCo_gbI0$%ln2&b!7#6(p5?{3b@e zu6#UDLSM8QJlV?RFPQMdeak#$C31|vMNzPIajaj@09cFB?sdKe2_X;oIyl< zLlV}UyagZwW~DH~kT}_(2ksF!VI_T02PR+XUBBaVWYB;ORF%ZA@0=WJG7!&hTNJ;| z(GgoJuNSJt{a|p|)KGD*H1VakoNL=HPz$a zH5>GNG<1ne=D3sx_{Rre`H0-L+fHemCQjy$V_wEB_tn%so6|kzkeoQ+`U)Ky;oen@ z&hS#lfddv?2Xd}o*#D9Aa%OkX&K3zD$Y_)FQMl*=Y=4@2ja=h;f3Mp&&1MDlXhkux zyL?Z(+~>*mA~y&1pV~qVN53OARcwh^Z=JUNN1cMoGi_}Ko{$-Jz@0@yGg*2G%Rh{# zW|~WNjYVyC^xlE`(ZQA8!FkleBT3pP}WnN@-^R6-90Jr zo3WIrq2GDYTyH0_)i$zNDCuj-{AaDXzw74fRu9dISPm;F2iFlrJM+ixdBxrF_=JoX z>@S;1e^qpkyYf0xT!#ttjLcK~!7kgwqaB-WO_vbq($~nTm*?j?>=?es$<*JexM8>Q zwVn}1q^=jFG^<8*bU@`W`7SQwtLJ(jQVy`5a7N}MZ_$P`3}W+~)sISJu(NEGE3z$- zd+bD|edbwD^=AajI;<9j&4F{Q*O24`#(^9jVoM;HUr{2 zfl;@MAEQecF!*&X>pMXo4eUk*B7OlazSk^p4KeT*^9l#4NS$-}^(|bmmg2#|W4`Yp!^@I^n)&BZT#ioNTT&KPaO;CV+bEAQ$yr#($^S&-_T`!jAd$mfisK0ivl)lHMNp1gJ}- zbbsYk83UYnC=>F^xUWs);RD&x;%;#mvhMwv?wu4~(%XGFktbTqATS{z>dT?K=1tytZY0xly zdLA(C(LNxaHO!MaJj0W-XR9{6T3YH!CP{6b@T+#6nek-MO~jnOP5_E&in^7Vv1YUW zkt8RKO&y(~D`6QWLf`tUsk)LPan+YYH-vLoMF+^pU*K2(;pncg{UTBW`D7K2pNz?O z?umRgc30xSg_m~1n*bs`ey7B9_A+SS2dQx8RPmOFwdwEeneub(JH#DJ1x=@bH$)A| z)8^U10Jj|pgA|Z0Y*N|njrH3AIjE~+T}?a^sYaU;#ne=3zHL7+T-r19au-oK!|a_pF;H#srsV;hH-+%$8-EApD)6_N9~gYP zAIPCigEu~M{p;?|>>lV;U@5Ed_UOjr3#rP>uY-QQO1PWj318C>)Rg9jl@3bNR7NkP zdche>k9Q-fqt@@nuDnVmlp_Ar88t92}oKr#?6G%Q*jFOdB zJqCb3oIKXVpQ(>hIr)EZ2qqslP?9|TYRF@x$i%#tvd^6^t#=NMS2|#m0@-0xAfG+i zSTGeb9g8Ckl~(&9)KSa!%SptJ2ZB|-t_isl2Mkb)#=W%@27c)cWm?mOgbV?VK@WY1 zW>u?YR_3b39>;|rSgccFOvmS-V0$fcz2OdYC+l?Y+qxq9lzaU0?U+6iSJH;m3js;uN zT4sl~d`rrMfTGg2rm{-ANM6l<6JBewLq|3?-cO0TSXrF?p?>n|)U5p*)=lLraQk+> znMG1XuGrX-^|DM}x=Mm)=q2r@1#v}!fVxFdzp_e)O@TePe1ycf29!RQIMf_7c;M{I zY%B>!%g(LcFxnR!YDs#sf8A1Fxq&%NFODg8u3XPj0}E2K)^S9sqtqs|ga`DM$2RhI z<1V?rx*>~=rX5rG!EIX2E!=<1x11tE+3?RpVERa3*LrczdC5#a-2jP;rDt9)1rH$m zLM*=oN@1>q9qf@s`|LV>7#DI~9m7V#TX3f8+g!h_)}#^E-`uFIeGo$07?DSM@v`DV zf0t@Q8G~`7v%1{WsSm1Hazbc51E!>cHrg%j)<=|*H!zA)n-(!RU1$nx6nkNNAf-1q zy}mP`IdlLxzOL7E;iXBy_Ak;9lR-s8tG$Nr^GiXyTx)x_Cz|JPXekaah>X71weN1r z@QbW$x>Xc&oaE`;^rXCuTh(Y`?V`?hSK_^~N#7tZFk>(MJz`>~r@UtD0{+7O*|IrX z&Vke4h_hJ;{yO#DO!Luu?kph+ zN#`B~+wbfO>oO>PrcXjeGkHw~sx1(2e>}J>d&IrM%LuJsf=D=FiA1 zzXl~MS^QG$q7oZ^?VQ{YB>A{pN#{G;zRul?lD(1b-46MW1CS^2m6UPc+Ion=5{n*f zFyle8dCSx5z)Cn}%Rn+^3nG=WF6i`>u7my*5cn>Ts3?Cius8Q>GA zUR$kBydfEK>&K|Jjwjp$9*tT3y!)m!DtsK9I=7A+QKW(-sr6EVT z9f~cNNYH=>un%+gL(i~%a>ll+0`LUyxpS%&_yg$N$$)Uh{?W_mz($!;wLoIS?!Zb< zA?%lp|3XS@<|Fk_8K1OMxmxc(g#|Cvrxf_)oF(cmc zqQp{>u2}&s+;UGBv>R6Xz~}a6;9ga*vpmk(JpZlHH+o2Sx4;Y(&nlWKdx^e-Z$AZX ze(MWse zsWM6leWyTtCsgl`VtLY1Zft2Ja@@FfbofdYRlsMda%aO7G*%$!-w~Ez99lr!J@?Fp z4uHW2f$q+QEqwPncI)9*ExP63f4Twutl-iBWJlILV%%@z_+-M>Wl{ed3l|t-u;z^! zQoqZ(&kE)vFsv=ADLNNJjFe0`ITb(Gg)IuAf%kf3XfE{20t_$FxBh5;7MOT7f8bI~ zaoF#Cz+04yqD34W9fEA(n_k-;EmL)%jYue-Ox&f4QBjSiQ}U9eok;SY_(@1eNx4b- z#XzbB>OcT@%dzo;bsn5(2NQfOL2NOUOWF0&4zNH-t3j$S<@O!Y0zNAmtOt0Rk*?K z;hC2yi&0&QBg(9sRMdYJW`24Y3voD%fW{ZO=4_if5F8y==57~VZL@Do1gp)Fo7Pe) zxNxCsmsJDv&1tMZdFlVyF3z&dK@$Vva@RbGm7fkUJGbH8{n`P{mr0U@BpejNIh^5& z{8<m2^h#*B4r(qb(AP)c=tg?!X>Gn zY+m@iuez-~HWUa51Uupk3fRV-dmA?=udFTvE{-S7e_p+n#IN3r+Vo&gruxrhV)V%r zLP_QdVSJ6W-ZocLbW5{_z~t_a-3oK%*(^>mQS%}Pv9bT|0Cq_%CzoA!{}Lz@ zVt&T-kz{WFmNWd^a_Ut6Xw z8X(cdDX|ByR*%F+1P>>O>prV%$t&j)pv2A&9sVcPw}%3ae^wh_}Sb~d;ga*bIlVw~SdN4#|?z#hT6v1en!#$(@7 zhPjA-nA(=?yuU*oV~B*H1t(3fIk4^DGE;bMe_7U%R)&&FpI;O;^}X+f90I;uasHS& z1T^j&0wVdQk3+;^arQ9%Md--$oK{BuE;Bp$e0>T;&t5o001xo|(BqzViwOL{Bp>>w zLRqYx|I(yyZ`k)JWkpwuQQ;)uT(5Ren=$u%cDrW#mfa<&sP>;Fea>Pp96ewv2jp`( ztGHBhD1!@}Rp7cu2ssLPUWdp5W;qAq~ zWyA<#zEN-EAe3<~QJv?#7gKb02;pk}Y!kSpO>>m52YYSyNB$t20PjR7a`%Yo z#^G@CQsS2YA?M4{xo0xpm@vI=SZO_T87nn0z2QfBX=XVz$YaIX_TCoDuTOzX^{R4v zYAY;%0L2Mz(%WP6_=pM1p0S~7CSvG2$&;#d@u_$>Z<~3*-rqZNA+FadhQ8VD{iZ&X zmb@Q`30EU+g$|48E>N7EcF@SJ$9f8NN1TVB-x9TZ*Aw1-rs%&(p*(+=V=hQxcp6x#s!fh3zmtPPo$k!M2w9+Kvctsp8+5rId zk@F5A9?{vnc(!&#IEnonxDq3dlR{8bNM)P?`0S6Vz+SKwV8~tcvOKaFXQ=R=iRfTn z)0|65y>;Pl`uCM-Y}xL*U=jXLbMJEOuH+yy%7J*lxfd>Yo7vsh-Z|$%kt@GjV68jvEfG$YFuT~?B zDM~3>vI!~#^xeg)oPL1|o~_d3q5nnOb=4>16)o_JHX35NX=b^f^Ix=4SG3$hK<}I@ z+J{#+Su7X-i+0|U59n>y*8G$B9<{e41OfXsPoYzeSu8gyhPK9bzM#kB|K1fmD6Pe8 zkEjz==&^x&?Wm+Ei4BSr0I$S%$R!}GJb2chg1B{VJ3F&NSuw-xPI3FAYN#?7+qFuq zX0f&yk9pzP1P8XPxxbGs)tK-PNBM3DoYV3ze`#JJuRZ*@?UlaR3dxnJO5=?lD+oqw zAt3I+5FBSkjF^GSjg&Jj>(0w0YtU<9(E%MZ+UHw4vA*ux!`gf>+_lKLdIt51F9j!CyZ5eO z?y=_fOdH1sNHzCPtXZFf0P2zVur;}P@31*TP%mRiNwW;@k z{)$lm=&Nj10gwHAFxYOv3=%!dX!+yhW=>qwZIWN}Y(Zw=gZGLSi6?;F6-23C@fa9gn(TbDf65-JqC;AUc=hbvRgPt=udq6M7iY5VuX%P1m$p`A^ z3V&}D_Y@d(6r?ok%m2WZ{&F&2%k7E2WRX|-(e75VHCc#S{Wnzhjo2saB_Dl7fK-Hc z6sc2N)9Z#-M;RSW1}~fBo?UHtkw?FfY~k7%bjdaF{IfxYL|O0uWta?kUixy@;6`z>kw~qqXKB2W$nY>RR)s zvaz*?Jr!IxZf{5R`Q`sIWc8Ew+dI_JKF6~jW z%Qyc?y)tS%Cp_Y?oeE_S3)N6Thp$Zy_9rxJgmwpSO${~*e{T}^|RSSf)s^xu>K<0n;i z0!>9+=I)s(X3oZqnHz%vBLyFto=-2FdO=!R->^JHesJJKB-wws0*8L3ihj}2NbeK1 z6f=7}mCSwY^L?y{V;i>H9ovnH>WU`c451h>iRy|dVw&<=B9AN1l#N*PUBaL#xhPOH zGd&THWF?>5;UGFWZ?GNAdquES6ssbdJN!iSc#lR`A6M02@u#JTg^A$BlmzsyKSxox4u7gPx- zzZ%rZH9D&UScFLW!@cAI;cKRz1Y63#l?@JgG`ZPELfN;8sOTBS@`1SK5|umUZP_ zdjbl|+jlF*{7FZ8EN;Y)`Cl{58|96+G$18C_DO$>Qg4vEo81?veUlVV7*6xlXplL# zl!KNZZ{W9m5`6L%|9{6Iw!NK`8Q9_FIM^TiAKw~F^Rap1>o}M$k-MJ9uXfbE$jJ-_ zT|G+vW>wS&()^33RvHp9JLTLrW33WuMgd>zX`DmyV=41cmUY3*u3!bk8! zAk~S|@kJKtpn~DvnYRAbb3}yOuGIsGgLaPTf9-Gw=}7yP+M~i+N-!6!7Ow63K=*BZ z(YOAM+g13&C2w{lE2qbVlai!f-yir}JmNqs@dFur@qkqIxH`Jwt^iB0!>MX9h2`Sj zbt4JmRKQi(vysIdnMR*qbh#o4h_Vsv6oy$~VxOILPg$h){HWq!@z2Zz195LvH9d=*H(75^(hP*BEaQKI&OsbnuMJvg%SyO@0UwGzN-iKiR zr>vOm5}34}m|8_fo{=bz`NkVAF?#!QyP4RVn36P+hKRzqA5;q^?{k8Ryt%=?bkV{u zTwUt(cXbuZD%bn!WFP(yEyfW8766J85<;Cj)RbqF2H%Fc8B*qcSn7t=po~Y*%5aecTN~cWMHQw960ztVxt%gosmU-RLH5Cw;u%-cLGxs)R zv+Ct%(`u`4B&B*4*GTqfa12Xh?4`Fo29jz?RHl|g+9s%N)v&TLj99OeR+Q&$zp z!a(kihtAJFO^hYCXlJ`JIxo$%f(Pc*<8*1;~U&yPk95sGf1fO->^`zxe0_Q4JXv$_it9eKCpm zuZ*Ltp$A=u?zUMa{B!(9Zj2w`9s?HKi*{RaT|Sl6Ts4hh;!91z7ZJON$(NyUIr9&V zZ|9PoCF!D*&pk1kHCAQaSt*e-LmJ#>QX6}NjPsGP7g?HP+Vdv^!f(&3Hya|=B_G!q zN9af>98kLb7O#4h8MJ*VLT1tUuE$do;m1CqAQfdC-t+=2&-<#Q?|LDPbg5_h*`^BH ztId>28K2Pj%q|l$c^O&z`4r!chXXKwy0P#-(=km^Ovv}s1Bh}q$aC;H83C5iaD06I z#--=OmvEUla!ERgp14QN^GTbw#|0Q zq;K{AQL%BS6j<0cah>_l=riyZmuxbzlLjuA^C`{MP9!DWcEe~pGwirL&GNWZk7+jd z{XO z9zjlQ*D=mjdb#4A^AfPQ&C(a(fNY(EV?mE+;2!H z`AuSL+N^f>7=_~mOiJQN!nds|&5F(kdkP$fNd$_`F8|V%c7>XnRLMDvyfcG_XUuN< ziF)=+NlGKQRcYi5?rry$0eYI^O5#l7YJc;EJ9 zUHbD`8|~UXug~bfw6Q;AGRxDgPB%x~^-hkn91+2H@^8LNaxJ-e3{vJi{6Ga8O6n4h zCCi_Yut=TU_=nOW2s9?9nNBmv|7lF{R`;UD|0IQ;URpk>+5vkgVtt*za~vdUap}DO z@ZI|tx!LW_HsV@rAT*eFa6XV<$|QtF`HM#Ym|cFXE;?LbZAQgT4K0=4 zqBl5o5R`Nb&c8B{+a{FWx=9sQ@TtA8^W&dA?+EL;k>znsMaU zy*&h4P{_fM;48w#_FQhXOy~^GZ!gqxF!=D`c++&mVMJ&t0~7c*b%0&I{?V>t6OSmh z8I3erD8VnHeIo+36cH!d(;BmP9G1;6+*F0g%__1hG@EywI=+!T>C{?o1s_AM8?9vO zUC`48+zNhYs2b3JqS+~3$TgS_>-@7bKh`P4DKuSMJW$Yvt zE!upqe2?mU7<~^5Ye#3bFo;0UTV#JS8$Ndx@5GsGmu=s2Bsx#bqS~JzU4enQFyis6 z0JnGS2Q00s*xhyoR^mr?tYwzGtaN~9T+ZXmN2n z1BbJ#r2`D&av1;H=0WnUi{ba|8@uiDCHP12t1No^qV4jW=Mz&Ax^J*WrI)SoTJNY{ zYP}2R>)D=pEMZ8UvFQ9aToN67q5pKQIKhk0d3$A&8clyuGiq;ErEm#sd6_f2LYfmS zG3F#)sr#K*eJZ;;%fi7)`l~pAY22fFn=Y{=Ipa0e1-W3Jo}MF9?F7ikS$O1}ZeWHI z_qZayiZ0<7KfCGP^G(Gam$hNIUi2yR1FFE*maIDcPYzZ@8q;H+hZNoXxtu`vcI8v#9`k zMAqGW0KtACawjX{6Q~ay*g-+eP1!2D)GxUH2FTSxznhTmDK&n1O?+l`Q6Veu5pkTK zBl!#oS*Vx-Kc-GXDy*n9E1;=kAZr|L7Wb7?)emnzbk=(5APvCALU*mHsTNblo);{H zzUaM27IaC5va|0&xkRASXFhM5OYP1BD6po&FE|vX+ppoKg)4}9JTk)*OFSdZh9}<%fbr2DBU=r+mxHfn`R3U~E!`9us)_tbOuqx(XyUm3p3|G3EcX zeR{tFv7}tKA6B+Tn2>UY=w*5E1N%jT)ax48!^((n>0k)aXA(GUY+bt;_PGT17AU?& zW)^eX&-v{jWgyd(7Z%BO_fvdN09+46x#vbb;KA5UxO;*-K;vH0_T&G+@AyNm0g1)o zeuj%HxFApe<-Pm6)Dz3EID;qb?1X0-5-;|n<&Qhdn>)*!tVfDf_|`PAyE+>xN4r(m zCkEFLVzFx-f+{qB?k&=xf1UdZcU2seb>1J8bBj>|{CL8u=X|Dp{yZW{2~kB&2>ZGg z?)SN=9JDLU@w+57KECJc1CZn%4Y|W|Y4qyqUPkZ}1${k$Csy#9bM7Pgp}>Fltpt%> z&btE30mqk(h?2t^luVidqW+s4SSTgoDK)&DT){`pH&{W)MCUa%YOM$E1<9%7&{;d0 z?~VZn)_q2?bXV+HXsxEF=9DG^Dm5F>I8t87<(2K(Z^-AyDBBCebf zarYzQuS{77$yhAj3GF9#P{FQDv8&lgBQ}&&56lER*A4x|06h$V5+TCEEC5Wa@{-J4xaeky7X-?DI( zusBg4;&_6}{43{j72?$5m43eR5xHd(Pv2oOM`=*%|l}aT|v;E+2)x;+@ z8N9yVyg&Fjr{M10_WA1Xg#(?Y3W@fA=I4dj5eaT}zCH~q6y_>NO-%Y;ViS*Zmu7T0 zJ0^#UNu#;G@ij(N7fUqrJ>ABnFYNUsuZ^XGv#^Np-o||9kBMVKHpaiFo^9nzp6b-g z&EH}LQkLFA+P|m13m7^6Eu40^S{L|!TxBD?-s!@ZYS!h#$Z_+V###}l{cSUCC4_y< zH=bZaOw&ApSD4d1tNNfGCE|N}m)#~{msG-Z$@2rPgV%fM_cBT@spe{A+5*h!dq~8m z=Z8tSr55R&HuV|>$hVnQp5;K=X8H4WION#}%#io-O>w!vLY(A!FaGQ(sP}BQ8+*nryH=bRHk4M+pY;{#z+R(c+ z{sj9~uurn2Kkoz_%O;d!@PohO&Kg4CGJ*9bgJFJ{*1z0A+Z z4g?}1a3;=wg~ZwL+M57TwyN7IzH%Vv#?O0?{eAA3Uw(}8I6e`U7+AMb@K?q+!q#V&a5!O@6GYm)yyTLw zIj3Z&))C!18hCjAVQBWG-RxMxIZg4fTks6&i1P*S8BAN!z95kBji*>j#t@xMZa_FM z%2(hLQ7-VzDu9j2uib7JDE)$o-C#C?m5BXc|wz-#^p!N zOq%ZxFw6muUgZIG9P>!M#Y9~_B%GUKf65g~EFQ0w;(8kd0K{kue|j=B9>?#6Sd?BMhbd^tE4Z+iE5=pN#Wnm1AiVa%vHO8WthJ=Vwa;n8>TMp$ zKW{0+=dyZibM5p?6SklGKwsqa^W$=ZArFF^9#_0@aOoEP%lcR1 zJN;u=?fW#DJlmOX0{hP%Fi}+5&iqqsaLM3G`FJ!w{cp`B#TTT3Vxz;@KXR+yOf&6h zO(`-Lx6Qtr77W+7YNU*ni?)J$l>cAZ;nqWzo3&SEV`fuY2I(@~W! z>E<01nkEVBv7H*`n0a1bU(>MEpeyxuKx$HpEU&4rz9RN)G{5O{O{_M(N`x-7IvRC` ze8F#13lcewpY5cD{U_@LxQYwRO$L=r)QN1l_K!7#n>Y*Ef`?~f9DY~bqe}(HTiJ^+ z``go`)M6SWwA1u=Y5u8SN@%Cpi_wSoRXTyFwfX-|it&IVyvqLhn9rJQQ>Xr0lk9D< z_k^MPLSL${Myo}bQ$*Q#X~()K)wYZ{X5G*_`F~7AO)8|i1LN&1O!@Cjq=pIH*-K6Z zQ^?p0XSWY3npkbfg{AhoZl`Kk%!RMbNZ4sM{agK+kuXmkwP5DzD?rML)%;{jMZPLP zv5vzc!s?7aGnYxP81C(Ht|PRKxkI?DFud2m4-45~8dcQ!gEG}yh=>B?C}R;_{qprx zeMkDPjcKck3F@$^(oXUGoc#?tYuY;Ab`z^LzU|a*e+uDiP7%c?bT(H`Va4O`#{7T9 zEugz&)jzO>sZ)c8v;m3m9euf;POcR$`!jEJWc^kPR|D1ap=M6AbXhAg-`YfNCL}IC zpP&7-j4S}8`hVDa&uBQqXl*zR(J~3q%OsKLU9@OH^iG7)ON@x#8J!@}yU`OhA_zlt z!steCQOD@r=ymvpoU_(>&-wAK^{)5Nx4!p>AF~$sb3gmu*R}Vx_rAwP&7+l1bSRJ; zW7gMIO+ma|`O$_asm8Lg)ff`lo;x-hxcshBD&k!1rjF8tVGD#|lm=<=`VNBPg^noV zuVlxn@}{PO9^?=ztp`f_YfB}GCe4eN0!AD-zD0xgt5L&ePXoH+{LFhnp|KxyKJm{@ zTj{oWqyIEle68NDQxrVWDU@*>ZToNMmW@3(?VEGUo~0YPeja-puK1v{LcQ2MeVO6- z=jeA(_qY!f-x9e`8uSq2dZsf4;6|)<9v3NyDQC6!w0*^@6E^P4xA5UJHl7D>RGe^xC@HyY%4!o@wEU-`(x&G<5s$!6v2=L!z$vza+~gOk3{@PoQZOq>qe@8 zO1w-pg$9h*>d*b zK)k)jc{~rB{WY@ zVg3Dox(FzAFP}bZ5cJt8H|y{IJJUryGL$0JLy-C%kFgl|i6RtYoC%}EdJ4R=o^2%i zKPXTCzfm3sd|2im<#C{96zW9~P6&1LEsB?E@Bx_$Lt$Pu9IH@I#sI970>Vds!k6;t zCf%&BiAAv@ex&Qdre2Q#qmvB-EGdggWWydVDM*wp|Aco|u(c#|qwQY)G;4$)UMF%N zG)Y|fM(5F#l3I83AvAf_t{N0DW@(TbyEju93Pz;ThzLKIF8<#;ZY90#@`gyNy1Mme z;k66l4Q;coA(6vRkfubvd zqgjI^_rqz$6O55V;m6Hv0X!JyUT=~oFLV^ig>TcuVBF*G2wpxJVK>Kq1~QiI)|nt;?bT{e74U+Qfyo z6fm-SH~y_Rt*-m0f&1g{=5~V9U2DxEMd0w^$Ci;EOH}Tm>mu_JUhui*j~YAUd_xS# z5(_@+40M!u0UY%CNwperQ+VuVV>AFh#B*DN#54AT5GQ~y*Cf027V+A}3up`Y^?CF+ zVIdEVmr8x0^>olWSC2R?`_-ZMsm2jP#j4~f-hnr9<<@-+rbrB{BRN7Qj}Idca(1HD zWlwfsgxpuxvu}bOen8n;Cr$v4KD;po1EJChU3VemKGlcU@;eKu+(Bp-IkZ=i`GtK9-x9~%8YJ?<~d)0`+z;0~R;zg);Lp^-y zV?PrhBs5Y$pA`|}Sd*CrzJbqSpPAJHieR*qZT)@@W~>+|!7{>)fr!3@p1wBjBsPF!cOa4I;Q_ILhO*A>KmXj&G)34ktZ4y8PON!w-@;L%{7^qu zY_iqEgN+fW6Nu~+tkq>Lz)#t@Pel7-!|+J~{@7>w;e)wTGH6J0wxFrQ2J*c5z(KUY zcm*%kI-spmQ+cRgrRnbmj4gkwqWH;nu6@)wHw>`mdcNVSvPXksKYqPXp|2tW|j4*H&I!{?b z3-z-VyXGhK*ma039%gUDo=PZcjne-o{E#XU`spWpZvT}m^K)f!>@)uX(8WeE`nQ?2 zisO@RsGr=QDWic-taU7ZHv~U3y&S#9TgCVz=JSQx*hZ1f7KFr2eQFokG5DVoKe-Y{ zAy^N|xPuUXhu)4f=p%g%d;DXXZtoWbb_eiNozT#HY)mS7a3+S0jYh!lSft%6g3p~V zK?`rj^u(Ut^nR7w3w&5j&$5WY*qwMYh1`S?yA&|9g|eswK)w|R4E&Dx+4=$u#7i0C zk$h%~#sWkQ#okWJmt!(`z~qr1d`%;@{9e2{J8?g*m-gbv#bUYi{oqA%epDqRZTq}< zA~!}Y1oqHES)3Gp6ELx)@R&EB9vGTyhPC<#_?;OE3=o7^qx>4neS&>v0XoSXKV`6t zRea)0F@GzT3^2gEwqDZL*2$badVCE$8f)a(u)&-EOH2RXrKQqKOx`@Ll}FZYBnOLF z41A{=?5uSqu|EC_ZQvF+gBXV^1eAtcd13TcaeDVX;6xH=4i&$ckAAuKiHk1TyB;_m z)pZ7?Tp>E)J&Usf>5^Ykw~b_}>n0dzYd|c&XzL9Z!*k8tBZ+zk%MsmLpO&UPEjg!p zcrEy&m2;A93tL3Ke@&F8f7L*+j2lm(%IvXQihJI+YCa1j8xM_o*`k|i?9j_)L~mdn zR2y;Vo5f1$ff}}u?up`GXf*!5Bi*4Z>Yx`KQX8Z5hggj3HE$M9&MK3PvBRSFF>%9g z!Ymt%IKwpV3M}FpB)u(diIcy%MHxUT;QiHRw>`6EFzj|g-pV`kTZD3bliU_BFI z>KA?d3|xiBe5E8vz2#1V1{Sw;U)t6TQTae$r{&0k-`f70;E3pfQ4_*t-w##-RH$wgI`h`gwO!~0<}G(Vz}VVLG~g6-N2$IT^>prlHJ9(y%h{vT__4j#Ov z4-P-D9U6rp#1lOrellQs4m*f;2|$_^z4I=x{>2X9M*eA|)-Yr@*t1YC9X;FNx$OmS zi8yo*>E;PJ95Y>u#96e?Im1fBx9!s~Jcf@Q((#ohgTGf48N;j+21-^3Qxa()H*zqC z_geN0ro6P39+v$lH3SZ}lV&rvoDh=OQ?sZl2%;W!8LJk>GA5*g?5tD<3{keyzKs<^Zz>Qs${QvR0DppRII~0HQXHevDVsvo~Q`k z@E=Mi&*)lpg@)^ACRzs#bk~cFel5lKf?r!y;-5vYd41w7+o5kQ;r6GR_0QbhH zZUo^_>9sh8w-xs*RyMExbHYyzs2huR*Z&h}26UT0$j+J!!B4n6JTx*(&=a!Uv$Y5@ z?9(D${G@w9VbG~0lSNzIRVTNf)B@9MZw6I(Q^{ti`FL~wP1?T%U)LI_`4}U=Lq7D} z=zH1OjG?LPLFv!J*4l{Q2WWG>lGJg$pc|jM(amc**Bah*erzRAZ|;D%RN{Co-S-bj zFcIwJ?!3#tNp^egu3{<#_@yL}CZSHjY8}w&^HT3h;NdSM`lN{G`ex0XT$Si;urUfv zkh~;$QN$IDcVQ}d5o!`!aV5rJcm6W+KIzj5VxirFGHNdhW(i;tpU~MSgT4?;T0UX@ z5d%Cao!dbl6z7B`Q%X4RI{JANznEG4ide$66l=uv?i25U9nz7X*rn6^W@%VM>@H%2 z=6esfqqTr&*qRC`f;c2HDztX+*O|nfgTbBtKJotsyt7bj&T#`gpS2mq*^DDoFtal@ z#bkp(D9`wZ6CFI*X6X+8nI6dH;VoDK1H91BOww*%)xqYT|J+5w2z_F2czv?~y<|X- zb$B0EY?g!M`VRos3us4N{~h837sCu~&kTLO1j=$K6-G%zOhX57%`rXj#aYYQ`mg-( zf4BL6xB36yZTjsDpVCDPbzV9}&yxY$&Gx@v&Gu_tMOsbCR?cSjrL&*~=2s zK};<#abtK*9NF36VeN{BjI%X7uyH*Sq|CGjMeqAaCLYs=f` z7SM5w?W-llrnXALzj=Odsf^(<@{^YXnh_+OB=w}U_`3K?lSD%Ev)pSU!ug>2?cV7! zR?f*UL#b3vn5aq3JyQGgWqz+0=Q9;F-Zr^Y?>EPXLRL12e!!U;i6TF}kAm7d-nD!y z;Q1uyS=E=R%x~?NCbsGVznbeJ=DYd}pP{HYMrG^sz1Ts<i9@KDavz+{uwA#CkW}EO99Xqz%l4QA47^nVKe#kQn0i}-U$Ffv1e9`L zCbmx=g($-@4Q^P8n-Y5N=JikFCL-xZGIrg)jKA%^yiHle^R<9+ z4*l-tvjwJGmhY`0m*M z(7HFr|Fe~B8AwTZIE$*WbSlhTJ>8zMF6#GU2?Kfs=t>K3<%rC%73*hmh_3E2Wp- zNZ#vGdS&z6bxD5+`^vNQSwo=D*3x7X9uOqmO`_)e3h@>?V3=By8FPL7hLJllj9fAZ$_qT|A`o0gp{5s>SXdA^K*na)_Q9fZP1pJF$9(2 ze=RZPxp!$(VpncR4Z?~WopKBBXJ%W>{ z;MT;}zp8+ax4Wi$N5BWzWAd?{RMnG%8xp}mrd6B$Y!6IN3u@Lwqn{6ONj0EuT0@nn z8S0w!o7PaZD9&|@N{Jieg_TcAJj7l>e{}9#3m5%`pRG7M06@q8ED!V`#JTif4|Sm4 zoRwf;DK|zZ7xtJ9Atqj>c-(T zlK-`6sazU&(EYC*_rHsBl7CbcqXYF*T(I?$W;DH=t+Vwaz=E+(ta4|=s^ppCPSm>U z37Ui4EO2tdSpi8Opl^Xx@UPo}G6Y!DRZdItj}-4ri_M}M|qwUhs~ zpi;oTGFF)=fS;B+co588Yl02$f4T{aMNO>S__z#_zCM25lt|T6&(OAwcV<}F1&{rN zA1-6HYLZ#7XK2CLny!BZ7QQ_^_*S8z3s$;cRu$O>b=u zecj_*V}~E^0MyplTlu#Ew+#r;$@OCPQLu*;^`a7V|Fh8hze~PErI(nZ{V0ClvJeMq zPr^TVEc_@8Do93In$^vFU@Xx_(LZ085E+JeZkuVyV9rkRvMHBG@Qj7V)hMZo7f>2ZWOvOu9?&(m26a`*jHFD7m8( zaQ1dm+8^vN(@(+xDoON^Z--NORnJ8m=SM%^Re0t5y?aR=zAgJik{6qH>NuRPPO)v-qy+?Opwz%&w2uisK3_g$`zxTws+h_$7sG z3HX1MSg}sm&E84|rcYys0Y;(MW7q0kP!FHBqK9Nq4=i#0_zn7u{q&gNYG-Ojr&F*t zZ#z05vc~klvZzTwBZ4XtXRs*cf7G|BO*fpvd2m3X`8`;#0s|>*V2^ph^gzdttvFzM zY@l5)PBO!OYP-{PesomODOgGIe}1=e*xd&IAK&dUV3B5;|Ns25N_)iHiC#H#=61S1 zRO>sv3Ff%wl30j-{O`b%g+ivY5t8pr*UEdiF`&@4DfTv^l+e&=y|UY&&|pT>vmy)V z^{3ZZq%{=m5pRi`%$|*t+@vLRq*gb^O{145JZ1N{f7sn9F z-ST)-z*KXHn9U~7)gNJTicVqi+osWf4~!P2T1tdXqrZ#tSK@inbW!09^0jZe#cVc= z70%N5d*DWNMO3L=e^sKUfK2L>uGzHxC{eR!QHMi3Zo!De8EzCD^2&->^kvCxBsVMZ z62q~&tqM2C^X4j^M#Eiq4+_A}?ZUKf$jJS^HThpTA|Wy_Eg{Du)ek%&U!6yVoat(Y z;$V!nfFO~6*B6%d&y#5V()XB4`mFATB&P0=DWfBQ$Pty-4YA}JD|{X(Sr6BSKygWb z6WK&Ey?W%XJ7qD;Z#lg3`QpOK?YGdJ%EJ4}MXR-TxA>uRX-~3DOVqPSHv)-1!eR6gGlfl>7QBbmp z=|%HSGN7ENNh4(HYxMC6*E4$xr*U#LHF_2_!zc=Q`sCEaC;!J{c<$WF(?$cK$3}u( zzCFG;6dg!+kviI!iNDic+raP@lOc5~kVRfHnH8m$>&{SSobkH4kUttmsV zpB^I~?(NOdRGZJ;QO=^`k!a5=JfEeyok#ovz@(G{Tn5y!t7jsa)x3#`7#@DNnofeU_MZA z6)*XAd;8nuFQR|vs@L~DgB(qS?9^#qqiUYm5{4YV9?AUZ(-B7KJ^xYdofxEzV_UYFN%+L3%!XB<@N>tF*F9KniN9R;Kc25M#L~@toh zj-#WjeZlRnL*yx1PBa+8nRSwtaptNEem0)Zg@YwqVnr-Wf1g<_F*Zgh zD}VFVG`PpIll@>@?S1`HrYkA(f#EYAV^G#4HApQw1HqCU%aGECEa^KDu5WkFy#5N< z74eKHNSE@spXsb_p+$yPUfV?LL8per3;2e|qF)T-+&x~n z@2U8Ts-K>E86O@K`yBVNyE*sz9CKTrKk9#)by)f^!r1mLQht?ra8?QUxhiPFt?{dpxyDQ#| zbY%Omfnl=n<}X7D4J7Q1Za_rC3$c+# zPl``eSA$err(9a$KOw}5*-UXq*+ylX4DW{mND=v=6kYl9Y6jF0-A08gU*v?D)*bqJ zLiR=3wBmN>@ZFFG_;qGU&fS=;W&Apd>2h*A%2f1$hCNdR<2d+AIjlcTa zbEA9694bE{)9@P%{3|FN@_xu8+z7_fiT3utO($W*SYlJ>pZ#<83yh8B|Kqj8@$ zHF_2J*m2A(;cnRN&0XR!32nwUI!OYFC&9o3A3Ri@Xf$&$JuHS9>F5904|gOOxN;}D zdyzoG&ss=hzdk_runT`lo%u@QiAF=jT#hk9yo>9-chjUvzU=Ct4!<74wbBVXVI~+D z>)S&^nK?`&ad$#t!hSo+{AumuoXH)^37Sa-yUfjB8%o}fs%7`=D+8rsf}NJaVHeW` zMfte2FZc_RVz%capNwmSY5J-c7{GI>8p%jQyZG>}JgS?5D_Z+L`$I6no=vU=_`uxgm;L#C$QoNx+PU7xjOTlN3hu|ZD<7zerg-vH zOZhEg7IWh^*k-v(3Sq{hXt7w{hN4%GUh;x159DovYlKbgNJv7fc4vPP9AWH@_-gnQ}mfdwpN9SZ8Po%pm) z@~G@9iHc3W3)zx`Ur0AKzn69#6)&J#sxWGKNxtYD{7mgcQOR@47rS4$5)T-6rDV}R z08EMu^s5W_r+FK_nW`%y2dBL24fI;2~ys+itNa{2D$WE)HS4``A8NTJtI`2ziSUtDrTOhr`GV3 zBcAKe7%cz!nrdYru#u+$M@2cbLosop=XQgiFb^QB5)d_#MF&AR4%dl&qlp0pqPvch zqwn!KRb7SfCi{mgOnKW4oNx6vXF7OS3W6k}(ol_(f?pj4edp~C7|)Kaxj`0bj~u;l z5OeF6@%5HRq`y4_-Orff>lkEs=c1(%Ge_IKJs*+U)CDQpjW}{0MSh@Nr?aa4ie)&6 zx?oA$zW>U2n-v+k+R!^47XOE}rj07A9gioL_Ku^QmpuI@BtGAs<-RW$qYaN`!L3$#8wPIWlMGOiZ z%1fpv2WwAolU}*#-kY*;b6uWK_Lb%WGmmjD7^&Abjk5KR)CybujbzrIkHa(Qmldmc zC7P(lyf#yPct{DJZBP$z8a}xy<$^f<${oIFir7cLAB6Y(At%`HXV0hb*8nrkiroiq z6!r<{ri+Q)uPqNXmJE_*hclfi#Dr7~i745tEhn*D| zFn03OZ#y2m!St9>E`6G1Ps^3{6}HY*Cu-lO^0g%zrl~mxj3)Ke;3)I{M$G=a>wZTG z)1NPU1jVX@fuwP=RqJ*9rfsi3=kwjB^G`3{11hb1h#{6cK$R2~|cYiDhw=U<@in-QghI>lc z_p%fDO<7+cdM2A$PJMwPgMK^q(R{htK~vwbfuauUGNb)Oia5^Zv&U9jrOH_=4ZP`u zgV9s?H6;dqCsrkknGkd2%u~Wzi7fVP&W0FR9ZS`Zv)Pm1b8je9YCLKz0qT#OOqO=y z2{-C#kNiY3wRk}noxm%ErH%7aR+2rx+0Fl#U516Z%cJn~69)Hvd=y_W##k-!9fvG7 zp53us(l`ks@d!5HPf=FntQ1lB)oUdvMZO0<&-$G1s}V=V$po|C zAdQ$SV-`)PX3YH4EY@xfWx(>GmTWBHDXD1<&2rMFUdZ#EkDkaXPsS_retd7U+zZO+ zv@oZ`!@j5IFAtf&@XE~AL{2qlRqL%i7Zxs;+&7^zDlzNGe3>r@j#pMQ@ZQGDw0}C* zkLJg7q|o$ytAAhwkP1aQ@c^JM3bV{D-XiWTvoL90DY0zspyg(shhyxDC&3+C1dm3g ztxa+o*4;xp_A-!yH;9rs{_a1#ks-6j0Xfs zsSAdC!R*dI+)t<5!ZNOcvdXo%%<_F(n|9nY`fuZzX2z!Wxd$E3t!%yyT6h?=wXSCI zxBAZ@qnJV$@G0S<8q+P+L+-qq#Kk+!1to`yzP96a%pP$Ry0G(OVP83 z7e6?gp4b1LdCT@PBh!`!)5Ox4LK$(h0gwXat^K_3*orGk5%$K^%LnJOm^wMXqgEm?en;>=MMHNfaZ62Bf z*538lrb3Ydg&YB=c<)xV-a3V$hYw6xXBZbdM&jJ_%sf(ng1x_CamG*5r!6L!#CO}H zC0~uYs7y~Q{wkX}TT|+&kGj^NT;5A7nt{n)jy?H{PXg75ytA!~DTxXD<=qN>H3{A&>GryBC9Bqd zI_@(ddTNBmQ~8$@Ig#JR1i85uT&I-Q{hLo_J}Y!T87dUnCbbeNd>Z-VQLTUCfxy1v zWc_U;w{nC_@J@$}4n|WQnGiOu+Qk(y?`8!2KpaRzZ`*8lAtWj!v+o2C{rs%>H7)I2 zN^Ldu-|T;nH}8;gbK{ ztSVow&nk!J1ZQjRE0vc$PW=1WB-tg$NexA@&HfLz&-RkoW6qQGW{zBJl}dA#(;Kto z#V*P-D*noj82gBjuN|pmJUQB8m$k98KW=OMHI;C$F0QGx%qh=2S!y9`tG#~3@<6hY z_;cZ3DZ+aQpAaR^(|~T;XKB%9t)fI1$gdaOXhC_^ zmVUFD>GM#YrZ-jHkVASlF7a1w2caVnwN5o z)u!>~wjW%K{S?bx6FS||D=S#YyYQNLakZjk+Vrb zwNRi3SB*-&&3NzD@W9vOL^7^)ujcYo_zdyMu@q_xb8>`%Pd}$WcQbJUc*q)8djGj6Ve(`mjRHjYhtx_8zkgw{ zy^s@He4smiEKu|(iT}!u-&11CccXM+&vlr=k9CVN0ofC{rNeZoTKaRj^+((M!BfoO zAVF!!187Ur&sqszo01_7V!Eh?;Pi*x2MJ;IM2_xwF~)?!K5!caZYvO37UXBfA6 z%wM+?jqqs(8G{Ci)nTKSC!2Tu>wI21j0}_oED8BkBYrxJWujUK@fG?VmJI1gSMK)H zN;tgV={wZo($6E&!iDdXo6XMI0E_L-sDv8iV zLPR<2idVk9Mkgv*QeBWkkoWgWZ$xzu53d#ao))T|bO~VHbB`ow-;s@H>|m0SjwRca z{Y~AJ=$jWu!hX?bF!VFO%7g5OVG%N53oe!a|N}kzDr3`A@S6jB^!l zzm2vLim8LG{%tTy7RUO%Ls_hJS8%Syqb*jmv#^ zwEmzZ@s$u_Zb#$=Pi1S?%S&lyN@Mq~6zS(C!1+x!#ls@9P|4n>zAu5lju(V%;ny}iO+ zmb6-R+k8eQ0 zHkkHSqKuNk!K(UUnd7RjuAUWc1KRmMdPc@C5)0qf3XZIA2#$pr4Y3w=hc}rO(LQOS z`Q4z%b!(|)Fy6I;QnF zx$4*qP!>~_^~K359-g?4Y<7ydeZmuNDX1e|XYh0E;w`P9jEr!MW(s~AxQ%M2t& z`ptnXFB^w!+5gBT%YDv`FVMDgCi7S&eQ!NXP&g#>CygjWdk_)fxhJ&`la!6i^ESlq zoD34s#T|J{$a)uX{}ulurY9fO_cAsZcyCEY>u2t&EX)W z%umY3|K3yRJSp{js`?rWIHdY$SslVm<@UpoNvsQ zpQuLIqmK0)OY@EIlKObvayYa5B~8h}1S&8KG`@9m%U-FD5_6c!C|dE2i{M$+_cz_u z;I6V3QbF6M_V-ZZ8T!kLMzt%4fU`j|^9hRK*4<; z)vj7Gi>B{`Od5ooSf-}o-IvL85XM{PdmFpn17Rx-(62TH$0u&j9Gt<|4QW>t2caK8;m zapYx0xjDmG53hl^H!<(&G^>72b1S}QXMID^=V8t@{hlGIxxe_|x<=?otjW^sbT?qi zhOV4ZT0u&r4Gl`x`9_Z$wlYyH zgqV|-4bM}+Kmu{Uw=Lht%>2x}Ren}~Tj`M8mFZc0u7poh!h0%h_>V?}8Bb^ZXns!` z``FeQsLj7PT7Q}U1m7niYnWjAR!WOT4M%?iuO~X)6MaAD_$a3j;#T@W7@#@|EC(D; zV-kq#9XI|sZVbge2wz_j`;C_P`5=Rog1an307=a%PA_`C5!_>}ADu~o$yxCf-p`*} zVMWGo0EvKhe;|`iG*(z`aZ3%TGrTL*3?pB??>P+peZOuHBJx`DQqym~tN#A(%$>sz zP>h$@I-`V9pP5Air5JocezvS!;4oTK{4mhOe)O%b+N_E|-J7O39AG=9c$^an@O23> zwacDV@uI9aCK~#-vqT9LJfII}o${|t`AV6WDw!FwV;&r5 zZqn#%TAOhy^G&Z|$}^I0jZ#4K9Bhh3=a?3~nDDhJ0?JGjP6i)XbPj$0 z^6H_nhS&yGT^(%sa%p0Nv`T_XYy*eP)nq0vZKzQ1@bzRxca|He=D~r|mLbjObkmg% zdhahxKAfYW>uY~^-91i=l}gh}Ou^zO3X{%i{;`FZzwuc6$Nns_i2uf`%H0{Fucmq* zFh-Mn=4v5a$-D10$bca#e%K=VfM1{1%okO&l+qPVRA4_DY82%y)iBdk{3mGvMsme2 zJM#t<;V`r%`L=Sms6}wl{4R&RnpA#@&toOY(mp^9YNDCKlDg53y?wptu*$OZprpSn zxzR`yMG={hhAaBig7(E+=bw^G@kq!m`-$WNV{rp94IJSm_)O!L{kPuM~!4Ww0~ z*v+MR>%yC0M~BW6ppQ#@&UUhq$MsautZ~AfQLX6MuB88U`KG9G7b;cYt3{*G0#7;K zy}ReCcmI^;7!KeXx`(fN_%-C$o9WF(+r3rUC&}B<9rH_^*p|esZ@0DCwL3Wk;w_X) zKGc^WeN+EE4b1T=bdE~rNhbdp{sNENB58b1;^)~iX*Q__Q_0#CmdY^wte(uk3!T%M zEGbx2qw;y_Hq~j=s|z`H*8_s;jnR&8Tk)kWs;+yx-+-lNBt;Mii`!>Rj2J;C@5v+h z-wxDMSRSbi|B3ZkxP7=rPFC6k~Mk zzO+p+{o}Yg)99?3$j2l^{FgL+C-Uk64qe7!<20d=L+TQcwET1izzYS{;|^hAu^?nTA1OAo7(w+6(`MflgZ24?4x?N(6og zF^NnVezBd0`SI&Yf|FhN^<+`$5yfsX_lf;mli&OciuknGR}$)Bl=kZOk=~!S{0^zl zdE%hs9ZB_yWM?*d2u)Wd?hipzpLr~4T%KV>LhZ&^c=Rmhh%4p^XLqLT@tazSxA6Qj z1y*%9#2)m#dF3v*RvR$2gqI{c76eIq_o{IT%u)tn6yOo)e7_BsIJ^aCVp6BgOed%-0yDP|{JE2JlUQi)@}1CVCao{v zqPb(%sktNjVZV@b3^I!U;3>oNOe(jHm=%&bTHhJcA|xI2)I!XDa4pHsv{hTViUhNY1>AA!sN(1(C8D2y{9;4!&b_72q)ChT{kHYe<97E@N~a4puhYu|#Dvyn zfK(@PcIu3>+W}2qI!P}eZftDf{ZsTXmtT3}e_zx8UHm&!_$~GA#<{Abc)D;^tP9(S zs((|0q_JO*NpW-jXSU?7!20^j`)d)8M(yu86R~x>U98f%%7<4Y-X`82X5IhEt<;{w zTunmTO)qKEF;yNHU`(x)ziK+0Ael5_srJ-fWsGruYJEH~>hazCp@aMB&Gl&eUnw@vSb z3b|#!x53c9vnj;l9lCWay|sr^d@1t_)m6LMPpJ1=Q*e3#9a_9}w*^dUtPHa{=0e znPN#ge>AnZZ$8!gh3azO{x5TMo+|2LG-G_aA*vqMplW&`l>GCJR*%Ham(#x?`CoUQ ztv`?!&8v!*Sw1B@`-q)LobBH_6m5NV<}xd@dn%nZu@ovX`M~3$bAouLobXjq zfLu4;UQHmbN&irQEFw=rgiM1`i~o_OMgIiL=}-Vy4@7uPf)NbFXavRI;n;k=KMb%F ztJ#)FGcYEbsE)+lIp|1I=^xSA&;76=@@c^#2h~J|Zo5XHT_n{}P z^wKtB2d)~5dmcLx+~FEc_My{hVHW^(K#IQxZXo>Js7&pwy+wAFEH}XLmk)xSr0H*UcPJ<-7f7%Leh6@zF)^)fE(!wyX;h! zzrNF52SOU#vr#ib4tp4buP$R6%NmpG!Ts>E1{6Wpj|s3~-$-AUl7qvEEIE9WBiq&P zhc1C-#Q^R&W(__Hy;f#PQd30he9mMR734Yy)Q-r*)pxBp? z*q8JM+M&_|^cM;|hhLFEXwr@tOKOguXK# z(IxR4xxA=$NW0kDCHNz5xF!8y6#ZZn{a_UKrvI)f^L|}P^M7mn7^m5Hl_&MQzn6-9 zW~%S}FsF&SsXcD1`>{@MmI{A?CdEFVK|CqcpA`BYNT-MeI+m-Ik!Te0_shy(dW+P^ zQQ&X9b|0^S632YL20viGnECJ#b?kkazB=W%(U0E6eYY+Y`}Dbhr^HSa`Vn8FsIv*DNmMjydumuhjWM?lE_M7yU)t za)qp8_X126<18)%7k%RV@pe3scpuvj{A4$bklTXlx zhdH^HC-n)IB>5I>5^cA(^YSctMP_@BtgbtiMR>#5)@!KdPh|4#%D?|9dvn&umK%Ag z&uo3(%y8bPW{G3hhra4w^j+7zIX-w>p;rCIoK);}&t_XNn;SY>hvM+2y<2PKW zhp7C2FA(_TcWwxM#-ETO$q&YUKaL^lH(E9;GXgK=?N3-ebffJ=OYKfsH@i;GY#=85 z(i3A&ojo|T%$<1f`Cy;@Cgnu^ugV1fh&X?c+^wnb6>ik}GL+h3o1`T+Fk_()?tX6b zrsvAeze6?nz09WP`~q%^U)8p9QTb+N8g!%b%rSqN`mN0W^^L!?ITKa1PJ&Bxm#A?Q zpm7tXBu-dF#ii|8ZrN)w`B`f>_*rYj{7jWp+V^lXTHV5%ff>vBBCGyPC`0D0xhHUu>-*Ct1oSm)Qww=jsJG>iy z5xzWk%1?g8{CDhBorT+TOYU#eOG=BAG_xzLIh43PZ!DT#DagNgCYKWZ7;CXK=~VJgR{@k= z`8bYjPT%yO_r(1SD~N!^Lu$eACdqj33_SR%&8%}PJrqT#snMC(xI9;!te>B+euQVn z=*qd8{AO^1(08K6GW#2&JepYLkU2sX%vSlB7i(y_9m|gLE}n1k9I>1{)485MBc5Wo zkCPGZvAnOB@TJM}$T??^#*g|KPiJ;?;9Z=t*V!rh5`hy|_1Mn;s7Nw+f-=+cPW4N` zB-^*$;4iq4yWHQQhlaO4$QANroA+}}m9VtjzF%&C#u2(v9p#GpYFtwS(nCy(k))1p zUL8|%L-QNd=}Rf}`vu5*z%sy5#g2KK1$4@XlqZ+54mTY2t5OcJQda$NA{>e=nN2ZEwwN~ z@Fat-NI%g;*x(P^vMkr2G*!)KXouFUO(49Fd>=ll^&=}ctmxrQN*$XNBJ=tgaF<9; z&&}r6V_50XKgMItqqAJM@dJk`J-Z(8O5l%=!4qS8Ca1m{N*CZ1d!;dig4Rt<;YAsv zO(y5|gZt1T%>U5Ar4|xl!=_FgSw4xk_j7F14ln-!!}z?h!{mSU4j%@PT;w>dxmthv zEsWTP+Zm{vY;Mw3f0!E@D-S%__~zucF*G*)`Az%qRxf|(GtZ737d`qFN4~B-9{d^R zw*bBMOW(^ghHKwI>r;fY&pAmO_WV$bMmRVcRl4Q|VDYyQkNVqz2ypzF?zB|~@*P&N@exE8NCN!iG zw??jFn<_1rkK~IF?B>3X{eGh|8rb9D!C|Z9i__n)2x;nc3k0uxd?tVgSA>3_EH3i} zrpp&UgmUZ9g5dJjqb~jt`kw4ww;*Zl?O52xmbotcWVV;u5h*-7T_YT4eHXY`^VCJw z9psrzH6?0E$=^H^xl%6}ffyq0CvRL%(!VEgf_Cb8J9Of9n~B@!6Ssf!6S@JX01d^B za?SreI5e+M|c}Nk0lD5 z`4AWCexl4&N%Brg{Q|HTzz#V%y4@&FwOoqUgflGK(K*H6N`1>J)ykDE(*3RCfm26nMiW@q<4= zS)HeI!*~X-yugzKsGg~9C=1Cec>SfNW$Iv6*p2q z$NGS8$?`@dbPK*3aX3&n!Dz6pt7N6YB`-AEwq0^o@R_0Ig-;WNZCj$kX!!$vw1)l? z&4Q7B{lUM>l0ujy zbB_UYuqZ^*_H%`9{}%`dsAv#+Y&}qfADWlbAE-m~z`nlp=8K z#SiS)ZABa?Ce19%cS3XUAt`h;%Ve#a82z8e6URy7Y>DZ+(+TsX z1vX2sRyNC*2nUr#y<*^H;U^|;DQlGk=|DXJaLdCLhb*+zQc25C&T}_^P}{~fK!vVd zcmn=jQEqvp%tpJRS2FheZ@Jr1!IZTZzv$h)>ivG%(Jc8}^3T>zVQK0Q zD-pe5u4mI13?1oYH`|tZ<@K`d-Xk-;`1$*GgT0KZ?!s1z`^Rp+<*r$s&<^eZ%)RPb zMa>f2G5e#wP_bKCj;K7cv>ZuY%M$X19dKX?1MtylKXAyjtw$Q(oP-!%OyFbtjs{q#(80v z+42Ma;RSf{1$gw!hj551$C~PyB-W(JG}ail-Wa-b4*+<2S4QfKUKrP%WZd9*s(Z9q zHdoK%!Y|XJ$+*n;j*aT0hZS~9k5#H4YY@-ummN0Iw}BUX9`FasvsyOY0=qU=k}5Cj z%CmuU$KUh!VFw=EK}c}W^${0dTlJWif{M9dzE~Zjvq*iMc4RZ&4ZW^Ov@RflKicQ7 z5-1nzTphKKD#@{B`fj5f?4rC4W`JocMph1C$S^8r<(o0&(q?GvTA|c|nu8y$Yez^1S62#E289 zOtE(|>L!d|*!~SQ1?;c+U3z$Bm$|-r<)kd`(@x#(05*kQy?hB$-9nY#RRbR!SpTQE z7z^$Z7-jP~sg$?(2T4uCcxi!%LH~12dlUxCF+m}1bO{T3WOI~l!dn>|gn&0rgX1x` z0<`V*-U(y*Pu(x&dN_sS0T%sSvhU?-m-4$BrRd89JMrzekGQ4*>5I1qIyv3k`S0f6 zkACP}(?m~`BgnD^+tOug53S?Tmi^-trJPv7-mw{Plo`fgg?^-P>f*Nne2;w1`}+_= z4oEph9|s3^aze^G-nkQWqi_1;O~suWbffI?5kdTN@A(k_boS98@!%%SvQ5M}L%Bnl zCHf~d=mYPFP@afW$g}m59|uz4@f5d2g474UsFA7SC?gzKeKTqVH|h@dUkLEj)Ey{_ zu;|t7x{0D=29KfFveUwxHcc-0b?QG2+1ePzsV%s}s+LqMxI6^PBkbm*=HeyQO3ip- zk=|rmPsx+w5k2*p>pd2@xnQOEyS}<>QtRf>A>-uO$&UPI?$6f1#-#e#9F-?*G|JrF zqr=z&z5`#ZAHJ}D`oa6`NA63XvMl6I0D-y4nI(2<*{^1vg?Z7h!4a-Y{bFK!=H7-+ zwK-{g4N1dagIzdm0Bg4mf(>}#v>?~68weWt!*BrC?ix*g0X+2y^Xdm3vtff%aN2@! zVA4+O5koSRy0c-ZC64RU_aR5PMTKQ-Sxat|G{0q&b6}Xo1gF%4HnbLn&3sTb z5^staS}A_yfzj}~<{t?GyrS~2Y82FrUD96wrvUhxF_~BvfAAtL;=kQ<;JZ&AKEIJ+ zD2qFQra5uxy@E8r2s&jV_=1?~2Hv4F{E{SZj8I0plGxb9mcdV~q;FbO^HNxVd1ohA z1ZPf1f7&E(0S*5o!W^87ue?XNBkyE?l$^AM?ryd+C8UWVrz|AnmRBtdMtWW(*i zt1D>24-jS#MWbE%fuD(i)u3CW>g&Hw*?00XOQt$}&^@;O`*t3tJoQ%BKUAdGk!21| zIdsV@E||Ujimjky*Q1^3re8;M*D&+>9^C)0Bez_=bjZ;KW$UmU88>+)WqM|sS5=eC zzr1(+!ONtcHgCidKYgaU3;WCYM^CDp^Wj7%9&)gm**N#S}${ zPdVk6?4Exe$7ezvnL7Fq>cb~sIx@t5Z2Ol}`^PVY4qk*gGH`S*IW%`_^1a;V{-^hi z{`5EWFJ{TIBfaS}d$%YT4MMzb@rP;cS$!VObX5FH?a*D(W7y-j_VMMWP~SW%({NRS zH$io1#mR1pgMPAY+YdiMe+oA%L3+n1FJ~Hb)$X3RZ5dooamcuw#do;2-(syYZ z7v)IX@J=>2qW29P4fqQNW(go-{}^euFKW@(&&uPI(#ZCI=M1lQOvH0n!C;9kg zr}{M4pp=frX>rXK(R7pC@cr;M$4>j?d%WMscY757I{df0*r&N)lbFF-9u4!qd8TWI|Jc9< zETW%eruBzHJ?j)NwdxL0jws*k7XPT8^@_(n{#hfHu6O|_f3`h-(*5h!7sc_r#x@|3 z1yuG)7GwH@`hcmL-f3WlV|@l`f+xmL^`Q^_=KW|w=t38=Q}v+-#ZMsbLJ#T=S$p`W zFP|h15nw-n@+Q__kTT)y;_n#sVv+_dgOzVL)<$&q2lc^mPJJ$@A!YG(GFNE$+p+Py zQ<2v6d|n7h@j;vKT{rf3gW~^KE@|Jq^qf7`IgwpjJAFqZvu|%uj?V%+GLin#&dvc~ z4rcSO#SD)BVU32)4-feLuaDuEZciW7jr!R24KakXD>C&kBH#=&`(trbAHUui`EdVw zvjxa@tC&yTppfxk9?*GsrzUn%*D0T+11inKr57g`t4p0;2?+BxKKR4Kl|{W`lsJ2e zzHxN3J%rNdq^-2wTuyy|@GK4FF2W&><@dmwwDklbmK zUhqzi#3pYOZvMX~|0B=tC%O6&&*;ZLw$5h$qMjCaJ>O^4@UvD~l{5Ao{feF5 zcRk%QeV&UxP(hUcZo{Tq~;`k$kdDsf-4 z6)D@0`Xx_~{=*Zco??GAF+YtqH9tc9x4+n^+}Pq@yYxuRv$Gx@1ct`hc>m9}RTQ3yHZLzho1WFt|7Q=c(oL z=1%cO=boXPg>y&IuTWVHsiB%s_E7JQ76s488{r&vZfUF}Y&`_DR^1_&-+}!a z;!f@43O~iJyD8I&gX(8kKL>O&Pk1HoxHOt)hK)rbU8D-rT!8UrmkzYnhZ_5;!LC|r z5g+E_PSXt%W4SwNy`lKx)Ot~-8fZC$-q3OGP@B9)eR`9;3z;VUC{5mzdkNhL-)%dz zIcIOy|3V(`ZtGWtRLqVhkRSZ9U%j@=!~&3qTQ*A?V@K`VCp<*)GZTH?eS z^$u&ho~6+8g@-bK3Ml-BU$(@{lc@r`)K$|d6*XuiuEDSpcZ z-=AdWz$GzrYuwR_9*G&c^xv1 zbpbs=x3U#qL?@axAVlcGCrS}ILLKvxGdPizgYN>~Xv5;}uFqR2To$a6miUDH57)j* zf-ueA>+fTvT?;egeb<67@c17hZ*}%ciQ?<|(8g@DA=A4|Gkx5BP-S^h@A*{1==wr_ z^iXM;N;Rz_K&0U6&8j+7DUE&0w4hTV*_OMi6xlFp<87Q^@BL2DQ(i2jTBeZOsuah; zkk2(T20R2lzT9&4RK&NuHX?NRo^U=tcx^Mg(*PPB|9m(_b{@ zVafx|PC_nEXlwGX+p-{DnJ5a<4?dWfyaCUIS?Re5{O=L2ETp##H-3Gftyw@_p~@=a z0#&)kEDP*f5Pl8&;t|P1dK37nYLNwS2H8PbB6NbQa2$g;L*FHAtJf-ve#OA9M2^wA z_tMWNe-Fglll@`M?;2}~D-pk95Qe=%NiXJ(e_zFIZzN2FeP~nZNKc6C3tTce@j=hm z0M{4&_W7*9s1A2Lre?=A-ezo+&1c0R#UU&+-Q|f?46jQ}3%7E_x8hsPbf}_PPmEp% zf;W?WR~qQ}BU|4>EVtBIyi3AAVADu?bO?8MCoQy|DuI zlam*-l)2J_M970TZi@E!t1v@N@YhSZ8EN+`QWtLSoYP*F+G*UqQ9FmPjgd%u?#f@~ zCUl&WKZE?5!wRyqPDpxHCn*n<-O{JC37w(d4Jt>oIwWrjiITS;AreY5M|fVkg-tb> z>6~|M;@(`g<<>^JD0hP`+o&iQ=XzM>l1Bx}hojS3l?3(5TYT@h+slxvm|3eO6W4f1 zyb302q)a^J|B$`qmUl)Mx;QWb?-;h}$ya`CtrtvF(}PTlkJ6xr$X@!1zA{Tb)9{h9n?y6B6?K=$Ttzuiq;rp|R8-jyfB1(56Gam&BCb22+a@@d|x zDc;>f)kQj zZKA0=^Cp!-D)!xS@Mu-_C{^DgF7-z%>+kBA?Dl2HpH$wIoY1N2TvY8sr>P2_rNvIv z^@h~AsoIHc>P4P$ritD4Qn5S+3zqhd#R4x6FAM!btJhw!x5K$4j$zrYq7 ziFuRMy?$yWuwb)**N&-Sn~|BYQ@^m!_s(C6X76`xmE>s(({m^!&gfw_ZL1p>Th=xp zyC7YVFQ^OZ0+mYm#V2t0;wL4`Sndx>CI09~UMSLD)Cn=WE7Qasm&M-{Po_dVO7Do= z-pS92x$Jn;hq#3?3GY*vCGSEx>by33dAjXXCrmrRfExd;Ey4rG7*0Om*k(8kR&KmLXuNVl8nqhFGL z*&}=((Hr(_`hzbr_#7#6PW~WS!#{fB&x|Wt%5?LhJqw;nkf=^yPwxg%b=vmf?sW6( zC6{kr&1Ahp&{t&t%a7ULxaB7^DziSSyTqVGw{^1xA*W7R{jYc}U%U=a=%Y1xQFqK> zW$D+zuZ~_)`*sYv%)pBz_!zk5;TpMzlGgP9d{*saF{_c&*v8)pWs6zj_3P|n?a_tY zD8a+V>(@xxLRkGbVgcbMEgvMzc6b<~MR|Se9BCWo6pf*p{y$*3S@!HcRX?B{`mX`KX^O*W14u?-xe%j=lj9W_m01*8-T)2 z9p1(+eo$w3jh0OuF+IPiuHN%x2pQh=t{)8lgDG(Q;_m||+kz9*+oAv91H0@+Sm!o; zo;xA*vXUfN=ep6Ahg77C4E}sZje?!7Qz4L^$=KO9GY?b0@N@P`XEU}+W$aOv6^P5< z!Ov#1o#Ha`H}UL5TdG#Ml?wc`<~;J8ec*n2v%&&i0x^4Cnll@qNE-PW_vA|;x_`U` zKI`l^U-)E?={A?&>^1iH?R}uv_5Q=ljj6^k&1LY@wP=3=$u#57<+~}FZmEYwZ^b~C2k%b`7hvGV^ZDH(;-kRi~NRFa;SjAmtQsXdo}&Rrqpu%NZb|+ z;QA1ABy6m6d>EhO?9Ig`ohaEs&sBfoIsZ^|@m&^PM1?cfJ=Kz(-fK6TL}2|(5qm#> zBR6B;*yjZ?&58L(53nu7aI?9^JRVt4M=A2?KwI=H`4)ONBagQxR}hnYn>E8ZW8_k6=^BhQdo=bd#iBzyi(H0x`iB2NNgR?$`-XYof7t}R z^ktBlzApVij5>DnO2PWj-pCuc*0Xrz?a22hxIyoXG~og4mHJe`%Ql8;n^l0zqni7W zo#dQO@=hmtE=qQoP23>}vM=(T;l#19pGT`ac`CZpt$cyVMqX^7Rs@V?t~S_m9D@%*LOPYouQ;tk4aCZ-1~wD($+3NE{u`H%E?13-rZsrW7X`8i@M$?szs^f!^~lh9C2%$92+zw(cs|`h<_m??|%&= z)Ml4*a**1RWb!k&u=qxG@EhyYPP=?(E-=F^H0h`M^-E0Tb^MQowjZ)cPCO8^)1?`e z?7^^sr8vJ-8eH;&J0I%T6-4a?MAl=u{)5vAT`=_E4w<4`qY}74*M6(%si|)^fN}lr zY^oQkJP4l1X8y_3PuV^z+a9`uA-FH*(59;de~1ve0k1;kwRMgvcp=}>_o8Uymif+H z5yy@{e5%%}7P4k#`<-^)RB_9vIr;Vd{EIKBreeoGWtz@dS!RT#Bv@wbY^;jIOwBFX zfuLC4S;$M0hW1HH z&m_qA(Fo<5-2~)bJ7~M&MdR|Qy#t87P!VukG^|J63?uhS*`MnFG2@LpgIpoq?iI79 z@PC@y*V_$# z2-o3HYwZTV2y5f0=aO}FheWBvL$A+WlPh46delm+b;A?;Ej5P6Wy>(UuoM1K(JT1N zGFQjp5iz*T)sl9Xm3slq_5R0N+?C*y-z~AP5z8#zxyvi<`3N|f9WhN#Eu_-lEoNPsRtj-nP{K_$#5W$1!Hc zvp)<`n%Y*UNE-7RGusBh#*OewP)J~v0E%NvI5pX-1*}MVV6hS-n3LHhY63?Dh_W$< zLzgNSj6wTcp(1MEJP@v%m3y6Wn5Vz0pp{$mYA=WxPn^2+r7H6`Y&m!TLC7~m8Hv@t zA^#T56Vr$kvWI#uowv^HV_#6yaj#nCKGJzXH~p7xZS%F)G*fWFJ6!6PA5OzHo3P8~ z>{R-Bti_IWN`vXY^`YJVGxX(WnYV#A)f}=j z+(eRecjCl1Xr&m5bsSFAZd-iXCik93bY<5vdV~9}HS+M`BX1(iGA$OO_hl0BQBNjW z%j=$-Bd&xWIxK4&<;VYl8+ZhKk0Of2-@0iInn@SK!j9~|zdR54BjWj1Qjw$=P4*&( zf2RpoGTw{|cyG=6QS-mTjvCC>xG(tpi&NyDyUnRQ6w;dM8CUAgR;Tg%ZKMwi1>`!Z zS*Sat?n(Qx6&3}Bj!8v4luI0zeZnR-ET43nB_lGMJIOkyCl_prtMX?zCYZJS^sdp< zqC|@C3fsDUSEgG3T^xFjl-OdpuXH$nXWA%x$|K}(0D~>P9Tt&t9cBAS4F1rpQ;(w` zAIh=tG}o&*AK&2+Hv2p#mn3xTi~t4TO5BQX$~8Y-<(79 z$|3*Ij_py~%2M!UcXEt|%PaXxZAM*pjBv)g(NHqi*o}YSJar-qhQQx?<&XU`B+l9V zc>EuZf9rW+|E=U7_~Oel?A}Zgqn_>f-L}&DkavFQk^gNX$2r*K6tM2BvtLfeu}=p- zVx~_WkosMYL+NDvD+wKMgWdObIqdykK5YQy+5#8a;17+bF6j%L0d@K$o+7M8JJ=CP zh1atRT$irbvt8l7ix8s8;6h(RFdKL|`(e-BN=&o!8STX0F@R8F?gT%nFL=gTp=+2+ z(ILLOqW3t~RVRd1LruFM_eu-%<0If~V#))`P4UX8dW2bKh!0ZX8MC@|M%)LeEeDTs ziA%gv(YOy&Qs$jSF>CCV7h|d}#|QnIg?1d1`ljA6WU5<&bVxsX#UKWq!E5=5U-Q_L zBFFLh%CGAo-tKwkEcep+&JEtt)$g>dE<4&pWDLZ$y zsof%j^`lK_(~NUTWUmw&l^vTgQ@28%@dTKBU=NHL#p0t~9Km1navR9~74MbFub#K)t9(a#zH+2vS7$a|O3Z7pDz0SLW?EKjmioJ03hL2qg{FOM z(#g$HMLon%BtNny`0wIw&(gU?eUti>QC$@yP*jc~MIR=MaYBzei*A#Y#v#mo(2JG; z;nmX?z9!=LWTyBnc_uwbo9%PsWcAb{$T&Muw!aCC32n;ZS>bTs%M#jG^L zH%GUwU=MlMmH_&r{%*Wl#veS%R>J_c_-=;}@wvCZ8)a+0n6lfDA|6uAYZUU_yF9SZ z^7$BNznyS8#fE>DFE@0k z@q)dPyotRab9~r zkE7`NZkPP|^Kvoy-`2IYoTtcFU7=`E9+BQ4i)LGCjnFPun3ku4l9fnJRdqkvM5^jj8j5llBf z8N-!oexvxbF9Xz_5*Kp&I(eYy6=Zx(>ykTkiOcFjKAR#F=?HI@{ddFzsNW2<@&A)t zQZH-q3T5&YIIFFKRe57=b6X+Z)~F&4JZk#tn>F^K@9@*MJgi3njY3H-@Uur#dVNA_ zFAQKtM>6c-CNT>J!cNr+8}OalBGLB7oZgUzo>81AM(V^dkdFzQ)eNh#jGNMD{wSm! zDte>0JNv3+K^SCv&*)fFtcf@Equ~35MI4kI?Gx1_I&!~Untmn9H@XgPeaV#h;EgF7 zVMKjCR6Bnj{O!x=`-x@qePTPkIZ%B-$i-{kBD#9R;{-#z3;9al1n2Clo>{+@%;oSj zbj*!tJcCw|22ao{JcJSPxx z{qa5mV{O!LbTPy3P&>-9?cyiV5#2D##W>1Uhg zkKXV{WtMeLb1`Gx=Ch64kCp7P-G6QLyJ+2iYuMxrUb}1#OMaLoGY#1vxN%EN)JUYh z>B}6`Pm-t3;i-P%smnNSlI3`AsJ=f9EB6g4+%VbaPhWOxI%0bG;}5^Uq~9PYneo$zycjORUMr*)pOu(AzvGhvv{_)2H|9QSu% zS)67nT+2*3z1n(&J@T|a7!W_!;s#ewm3`7RBQ;{=H&CeQ23&N8DZQe`Hqkmxsod1! z?Ju1vqGPoFZE-nSpXO{c>SgR~bBbr|L=s3In*Fe+IbFXlC5+2MfwWes~ZG&S^v8to=L_ynihoU^x3d4Is9-yElpavff!4Q`H|DW)t> z#dOT2n-i^*Px-ercfjAz?G)L>u-r=c!sm4IV;?xAdlOgveWcfcYpb%lZnI*mZq*nK zk1i-u_h^GS%sP+wX&n=19{ETu+x9tL)QhR^54v;W?*+w3!lsK0^MjW#nA&fKbMjcFMLO1J?{&rv9#a$!R_%X92H<8fQ_^k;Tb=lyo`OC0ikXs8-vpH*~ykmJ24Cm1wxvy9r4^Aw-$j$W$3 zvupB#zS_6Z75(YSMf>E`#l-YgV_qRObqVW>mj7c^IfpxXG28Fc)S@QfVl2}pZvGitiUs;hdAqSoJ=}KGy~BciFoDiV(Qq74%*xa_jj%W@ z2nPdhqF$u%Vhyzls_nsgEn^n@`Y6Vq=oSO+=Qlb6%n(etCl(pin%XmZi4vMFG1tg;`kBiP|25qxEq2fNG9+hn)-Y);T@5|{*PIS(V3=u#|uu9NKfRRBl;E{ncz>&c-Ad&$z0E&WJ0!akpC!slA zx9@_e3&#b+g8U%00I;aEC#Ni6!C``!7Y0f=Eh!*iv|zNLse;1=z=G5Q!Yj6~wF$vZJyFJ^LZeN^*<>~bGVv9Yqo&hL;X+<&NWk)2ec zy?lzxirv5v7tj56pxY-VnuuHW;zxd@zaVs?lX!52&y$Uf3D~7Pq2HuZcZwtKM5Z{_ zdq@Ry`A5G6%jWzJwAf;ezI&@T7lLa-y2fIn3puchtd)M zf+QcpQsnQ-Kk>Uu>Ot?8b7VEj4Z)p1( z%rJwwiRHK7=?O2$vKyTf!7M&EW3-1z7@0~8r561=Iky8LK~DB%)U3w40x!d}DkrSR zU)G7u#tWGo)LogTk%CPGkBLL)g_2rhB*rQVZM}0 z&Ksj-*ua$>;srh?if-TYEXKpE(Jw5E`Bh(UiCK-?7OU!=yIuUf+c+5e>)2A_gL89m zyT8K5243FufsF3vm>&Jcn)V?QhOM;N0&V`#)0do!xR?DG68T94Z7_|CGyIZh;>>cy z9V1I+B-LD!dXh=SOUh01rQR^;)$Be)55coYOg(#(mfb@7(ee6*)VX0xm#3S%{i`wQ zeqB29$iDKc?)IxO`E2c1@?k<<`u~-f5_ng*72<<)lWG0$#>55pcccxqF1?3A@BYck zcw=tDpLjI%VNWFPeK#lnhzZ##?)id#X=NOL9X~C<`xO1>EKlYQA{WL->oD;#P4hP- zx1|^Tj?((y8g3?K^z@&_TJ=b;-bEO%qaCmf(~@H=rS)CiN+?!n-cYT!-n{-E%#X3K2)~&n+_O4(r zU^eydg@5q8cIHnZR_iZb{m;LMA6ZE>!7rqvA8RLvIz;?pu`WSfALN{tvdVm~e|02O z4N*9_qwH%e!^B~4lk9x9CS0>#4q+7-ck8josSho(SEMj|}g;>kaQv}PCHzQ!kFPq1j z_D!1Nm}u_cQBJzs{Nof`XX!{&d*S9$w^kX9Yr=ECdR_X_SE?@T1HLZpTzc?gj zMUZ1Hzo``5LdPx;b$H0vN5x3GKb`cgSKP)dBkj&w@nYQ`);5uQMQv9tHL~uG_D+R& zk*!zQer-DYxneZp+OCwk`LRQ{h_GYw?avBjze*9h(++uWz#9EYjnyR=eZxvO>fyZF z$-Q}vRd=}%*z+PP@xpC&`jftkXu47NyfnUjq|~>1d9bBu*Lc2-clGwOa4cM2(E4{5 zuVd)fePMBXft99V^nEiM82^bKIo!XKS$2M-pSIgOmF>%9uto4eZP}yzqj&ocA>Su z1hkK6yY5)w$-mBVc7)IVP~!3b_Kq*+Y>PjC#l!iTkXc`ghDQ9Q&GP=g>G@}0bmw1n z!y|rD?&~XqW0$%;X6SX}ZjR_0Pc7KAZgV5`C!TyD^Wk#`pXc)jpUh)D?ng+w%Rm0! zGu}tie5u*D$NfJjHQ}pf~*`g{tUqW^eXXf9r|C%inO} z6z0_%aer415>i6HY!!QD&1@V#<5+WK3iQ1?=_|eAx?B%G$)}o>A#hrj%fgjxyZnWu z(r0e50fm9j0?ahEG$Oxx79Zj*M!l%z+KV>*qok*gHWK2Va;;Y`nKyD5?{Y1-H?g$L zKgio&nl-WBMi8E_>EW7C@z=KGIyv4MbKojD_If+hE2BHbbaP47n5oAs5IS=t9eI@w zeZ3*)%`Gp|9vQ8V0(po1@Z$0XRdDFc9Q29Dnp2dW-Y3$4IxEt~Zx` z8ar`sq#l3T@pOy+A#T2&E}e5ow>#l5GK~C$haEg@q}>=D@uS;?t+!8UEmhx#u7_6{ zz8nF+peI)xI6Q}Vs zoQF>SebcLBB_+Z`!eU{SAZQm2-8qmJki=>56`GOfLL z!vXif)4d*C=eGWR)yff`sPW})i2r)*9{L^_@#PO4ebLfibP6^0W5-;0@`Sd*9?F&q zUO(vwUX>m@*&$PKNzhzRc=B|tKm>TMop*9~LMZoluH^2|&zFu1$??X%sJwmHmKgEm z?tyn;yRqZ`v%Z!gj!v3u*u%$5e!5x$LT!}m14k7~on!^e-gJILe5kGnt2vK~Bf zcnhxr;|F>xPn91(8_Me@P^ zL)?bGJaP1fFFE%e!ZiedqLN<9eYOl z|04Xsrm(aQKSm@sXeD=O9zCZH1oJD|a@UWw)2{a$Y05l*vpn(m;p5_i!-yQ8+0N+K zs~msB9cC*c-3W89nqcSn^Qwm?zHT5m_mag=-z}$J4!O3TQ`;$x;8yXNg)hbz4el2%Tj=_A-^kO4 z$8mZ~-0nO0`ZfgD(Z}{ehg&R?KcP2HD_{A>o;>9~K(LL)OrSiKGJ!IeoaJ7$D&+)o z>fb;AaIMyB#0$&ZaM5Yn+m0C<@|CW$F+JCg-(P_|y}}FM<)2>v`bU=XU8l;G^5gq6 z>V7wp^2*_O0!(tqYX;)$<|E6IPXj#io1 zO(;`B_al2qMh-7QYjAUPa13a7K@34qGaUH=Xl}Ci=p&_?=j=Z+#T$Jv*#YyL`o1nj4HuKXe#p#aoBd5I; z`xE=q@W>na7NMKk@>#o`cm&Mj26x~WUrEY!_yoe^3-QQ(xj{YT^9w5N;{ywjE_-zt zU=C>@cdWzHOgp1SW!a-rJV6Zy{cv7H+sl@?rZUXr91o99=>GpVc7K1RyBz##?&4!t zbZmGSss_~K4aFmwUXJL-r!U^0Qr8!%2Y3bFrn4qc5+EdSNdSt1Nd#CDQq2Bb z61T<6B;3iWi{{=%Y_KB&rZ?SPo*Asq5O?l}rvSNX%3`2v;etM1xnHj!fr9E@8FfY@ z|HrEwv85<0Gw*|4VU-vIiyPJuSNGML@9V2Jf`w*YCvJaqe$y-l)71x z;ElJ5c-ODGFCuAc#0NUSr~AWw+Bfvqv$gwx9;^qda5={h`SoLlH|e@RB5TB~?`p>` zsXL^8{gJ=>`m#CcZ&HhBF|V#?^|aTkAe>xKvw@bJpr_z|z4xLR`h&al0crt$*eozw z14?1=YH-nq-W8WX+ykR=QZX=daUi-Trygs{D^=@S?_7|@c6Z^!r}^h|f(2hRAq8|{ba;Cp|9H$#@< zZ=n8v!L0FdF>ijC!}F#kIcL$KXH5$~bADOr`3pHG`^OV>=azKbS?FA9>LF*tA*=tY zT$Zo0hU9tVcl6v32{NRZp}U@%G>7&;{AVBeKe^IF!8r(K#02)VT&WhIe;lcx9=tA%1Hg}@YjejZ4 ze=W1!7LaTCZJ)^YH~-uo%kOgW6(UpjM=4d{0@nI^RDD3wB~LU;oUJ#fdp#8wDcBxPPGb3&8#Mg-fUC;(bTz!!J zyiVjH@t74G^=gR|Qsn-iLdo~hnBIYnsTN6I5H^FyBm5Bi6-CltqCj(Rfc!Z%85k!qZiyOpGxl$|8n zY3SRb9JtiY#@{tNmn2yqBT6pM(oKRnWv;9VH_!&#>Dpk)zINfI-Ip!c?%|utN7LP+ zPySK!bXQ}$O^OtKy=E)_-L?k(4Gnf{92@x|XFr#yE&firCl+l@Fcfsp$+4;B0l&c) ziSIzu@{eZd%u2+5c0YL6)Fh(xrneC%n(rwQUUZhojQU|zlaTa0t9eBVo=mN&-BwkaW3SF$y>AO!^eLu^;uW}P@ zdr8Ibui}!w+_F};<4vi)szf!c!{8s;_XUk=3oOIuE?+PIHD)wm)z@_ zO6Ptax5N#cuCo`* z_JgNS?OV-|uFyF4`F&*fEjX6*OPANrarj-kvt-SVHbC7Otc{>Gkgn&*rTr}OU-+kz z|7;sw7N?X;}p&38A3m<;k2f-rbs;SGU1m^G3%j;h8J#JG1pvrZ$!Dv z2zXISXJglkj+#h60=2vu-J=RN^p`K-68kMO96!7@!OJ9fk)|Ce>oN4)?*AXicYeM5 zyY=V0xC7+yl=6jB?eDM!0O6zfnv#Hd6GD&E7B*$=&$F_npHdEZ$}))cg7;=}X#KyG z*AtD6=)K2Avs|qEOZ9;k5;sI6z&v=JA7)8-qur0n@l&)*%HOwHaov+kbDmba z<0$nZ$J`ycEr<4{oZ6uhf6J*S=apo!6T+C^s+C)LwGwUS+9jl4WGtig6qt-P;i+zZ zFw^_ZF@l@@K-W|edKG_& zW`~L?+4aRs^_j`wTaCPq1l*0hexwR=vV1D>WZfeuvWxv$J2yfMIL@aLlB)3>6L1 zc&a#Voh!Zt;1e$E$u}7tpsmu|uA?XYxU(gQ!%Y0?!imAzg0dnKQj;K-9 zJma5lTHAjhWdMEAc4i%#AHA4#_a}I?!`WQ78vl!_8NbeuI<80^Tzt|8>vcSt1J2V1 zbb-+``+1~=_%|)FcSOa*yQrOb9D76koEL326pKJ8?NH0f2YhI&t%6i2?cAn1d*c*@ z-2K1hpSOed_W6P%)C&f{-*_Q@!vs~^v_D;e?SzBv58Z;)0<4|d zDCVFxsXIg5jX2%Ny=p0Tj9vBy~bJlAz%9=uPQ z=-Vt~qg4V!1WXbKX6V)ZlcRh6Tcd8@U7UsA8wJsOlKx|AnjPI1g%l@fGk@sQT~ZdX z;?0TBu3KsiwMK9M$W5%d?t&L#63%K^g;z;CG5g4}^An**?gDEvLLPt@3?>i#BIu^T z8gK;g@-~c8C_c9xS-7KU@4F6>W@^+_?$orKSPSB)ICmK3`u`zjaZ3xN-T2qkeI1a)z$RK zwM*Ip_CJAUZGmXLdpWvvZRw`TL2Veh1*7%WXH*N%n^p_=8oJKSw;_WG%RKV2aVE+=k>~- zmnNy@Wz{~*JgNNs2vbN+ou%zZG?=`7fgm|oMy%}j0e)gqVRxY}Db zA(w6+9Y8HoeQebMa3haY=G|Bgp{o{-GP#%~p z5y!{^@vvJ<;(_>%U4~&}8CJdNPW~vyTz$T%Tb}4?%>!M6{S;ik8J`5RM^51orj#s; zDGWUDV|~yy(Uo^d4Japy4NMyp8mKn_fcX*ARooO(jB~-S$Q=mVp;g&l=9Ce(4M>fk z2Eij$XH(CcipPFD0rT*l(vA%tRfm(x+e9@lsG295?(#gipKJ>oUAJ= zJ>HI6$f~ap!y+Hf(YUtnW- z*VBsl(m^e6i;q_uubQ0qF97B0{j)_zyPu8gvMle3J%+v4#4AS>U0#_w^_ljhwxP68 z78AeY3mxY8rih+?beE*JBpWL1VdsFpcvGIdTcZM*jzD1mB zcHS$Zj44BU^Mr`PdJEkH?fTxb0bYi(~buBpxS_M zUJc8GaHGTQfxYBb<6j~Tjtwj+@@eCR@nJU*PEWq8=ejf?N`OkRM~)Vh62dEEzcCeJ z%P)yz6=Ju~iQT!8{%E%7q~5$v)cs`$t(sDQ)#6I6)wx3~!Z!}G;S!8kyiH#G0TJ>Q-xh6!>H{Sf8J1?WL^;H8iqurE9dXbaAQste8n z_<*>A_;|&C*bdLJM2hlaC-QWP1TH@;Lhyr!8z4T;36=!Rf=F{ra7_k4OGh9YnC{?{ zZ^9AG+(iLNt<)iNHxd{tqL2I`SFB1Lw#51VV~Bs*2!A+?neuGVggy`^AR>P6QOnUj z81&Tb0}IFoFOUykv~N$pkPpAK4}Y{4Kj7}paq#&-tb*(TSOxRJe_$@W7uf|^7xjYc zFm0k~IEmT#?fty0=d{6+j=Mf5j@|BQ&bT}x`M1QW+8)@}lX&<>Q>?#ujDy;JX7{qbs+f5%m2rxU;m2t?8a8aZQOAxx$|B-nrl59Pim3GD7&n zzoim$Ngo>$lNn>e1galx?{ti?$O)F9lT(zj@=@hyhi&s(FaU+Zxa(gbF)p!JO6T*^lo?j`6l@z>RcqS~emZX;v&B#66e2_Uj@^JSdh#Wo47dM~y4-%zVf)Cv z5y=a8MP@F)t{QHti>{PS?+&tDle@(02VW3!-!8cQ@X=$rn^4QHUYUORf2YX@Kk1TI zNMA4W`6)c_J>DkGb4$8Av9?_JNoqZ@l^+bWmGJ1{q&QJ3_%1myemKML9+cjWNM}k*6>VI;Z>4G4phHXDprL3y=Kt z)ja7B{z1Q8%s0tn#yW57doEe`d0ewx&bcxRb<;N>x?Y*N1+UV#AhPcN(0c39H|x&V zbUgpGHur9A<)!wNSw#1GO@m9g$=br#Z- za5Vfu2QQ21$Cn@EJhEr;M?H4~z8)UvY4@BD;sEtd2QFUBZ{E4T;EniHT&q_u86CjW zN^@VBZc8uqI#$_!>!od%+>F3ltnKuKVc!8KKm&6%tkNF}!I;Qgj*Hbx?JY67|iN{LnLLf(+m5Hz{X59C(< zl%_sHy-S1U;uOv92X91I+tE6RwGv7#MDSz=Rkts*_@v~;vt;G!)48U0V!PiXMD)wj z3A53Z=kI8Did>&Ioyp_}hJ^fg<}WP3sulM6AnNrz0omSj z#$RqbJ+MFSib!}4l-yFjJg*OlJ$QLuPXKSwiuv@tFe!1u57Prm%KnHKAT|0B@cJTY3p%Je$%EmLpGkS&6woe^jRyUK%GJq^1#pntM>8+0r~sw|~a$dM|PSs(8rk z>KG0<;G~nbsCm<4=I*VDJMc<7qaK%1-3j{qTnK13~ zx)t6jbbQ>MKzx2sR`eio`A72tz#wgNC8S+10aeQOeC{Q;j#*W_F+w_Qi{z;bf4eR9 zxjX6&{ds0aZo+9E%xtM5d(si+@HC5rZ-e89$2lL$ka;bm_ul_6JLx$?zZ% zaqT9>49^%>tH~b|R96gqZ<`GdGMJaSrHT2fKDTIkr7lGX+m+ubLN_IM@~K;zFDD~bBo^WD!fDzw{PUPi4a+JHEmz7-IgG__}CUbb9)5S(EUQn}_ zrzEc!OTLJi`pn{lq3cX9*B9yHled~!1OGrU`%`MKsYbtQWpBGvd3VnoHR334n>67& zs13fAJEOx;rH2)D0j`tAuS!}|(63N1FNTlZxcBVWPy-+`%GjX_Jt#`aGwUK6b)NL^9M{FUt`fJg44b$iE2!oA=v0)q;4$^ERym+>{lf{f4BVyVdEBYD7TgWK|hqqsAr=nD<8x7S1}ug^5} z!%t0AVh>d1p6IPwixa0G1IV(Pf|_Wb9z~S_sRLbuVklJWl6a94n&{a!BBF+CQ)U!a zn-4nE`inMaQ5>MH)FVwJU;}XT*0H*%MH}gf2dr@i<6~QfI6}aFjM8tk5-ldxh-2u@ zq(jq6g*JNvWZ_TkG|k+X)(tR|w3?u1{?|xuE^aWY{BnQx^K7CwavSIiF^I&5J{{dq zc6x%78mluF21S6<{ZbNfU=v>~hso>P%^>&%0v4#!3I0(A5#hVOCayVn0DmLdaLOgi zhDSazw~S5>K>KKd=dq-+kM%l2IkthA*wy962XN@i_xCzN5%)(VEV7eF?J>SO_`*4Y zlM^NuOL<}+iilTlw#Dkouy%V$Wxty-GjRLyyG!pgq&E_E+sQI7KG+GpjLYpA}|I7@ARS1~PWDbR8if@ruX))LKh5{{b5E zL{G+J-xAM8+KVvon4ED7@-5H3CNDjnnRj-;L8TqP4=>U;6?iG`-{>PoS)IE(()n)U;#M*M=ro-ljrS8-&MTdt1VCG}Xz!<7o=+Zkz}+H#^i-5W`8n8w*17O_jtct2 z2@#VUD}K?DIjPd2S)UW6ELZIgQeXW5+OTUqCo6tEL5OkN%_g7hbdCHT5Yza{rKlop z$#v;^K`yXpkQy`ltW2kVC%^Fwgu-tSo;#OQx))Qrp1Pe9OHXUalYbm0_EAQ>f{Xg% z74S({&Bj)4Fe`cp>dnNIyVEE?w?sR>hz*w9J(Zhy#7sUjDGF8b#s6e7`09$k<9RSI z>-1r3iyCN-{CvjtM;3n-Y1mHYEO^#M<}ESig&YV)K}vo#Qq! z%1eHGl!LJwevX;0At&>)|GEB+aY?29;WGISG&GE}1rGJ05A(wV*bd*O2JAX93FCi` z3+oiq=Stjk%fr94@@;;2Y5NXX+V&Bf4>~;kU>*~Z<|ZcSL;ML&b;`v!VLSFZLdxz_ z1zB=I{jQC+Jvc-=n6c=AsuTyMjP zY;{Fs8;y@m{ljCE%o`u6rR4nXetl#j`o4(VL{Lr@5(T+H z-Z@Kw!&#a!<(Cej&$rLq#zTM4P9ikoOG#0DUA9#N{sVrLo%v+$9)Hy(UO^ALli;VA zoatfrcjhP1PY--+j82TN^9%oD{lgE)a|R!t3_Pa?l^xwfj9JS7C3G%@myc}pkCl>;~Zc2bk}sm!1S6% zu+zHqLhZ5?Y65M5%bjT6zMAYK>$Bo%8btxhfApz}Bh~}lQD67BVl(X!q0|Z8(DX%c z+RR9vm>PxKxgdB09rT7f_y;oAD`m?f`iCZ-@yG`wQxJYrZ|PjJ3|p@CLs|k{gZRNt z{o$7lF+R8kES%FLQDu6LBmYjYGJaX((xb<;np0z=awO3GFK5d&{cc&WIV;xj z+W5&|1>ec}?wq)ub0gXF4ZmBMZI`yM9lBZh!FwtP?4pJ4F*yi3*?D=taS0 ze;b0_VD}DNjjS60gT9^*V}1|3=tat4Ibmn(IaYX6)o+FzS)8m{FgZf5bG7AmPeeW+{F0o9i+_@!&%JN$TpKC*yQkCu3OVXqxalzfjHSmoemj45ApO*wy^uJn5QCwulQ2T#i}m;WKp zxaQlbdUM^}<=<@3u#GY|lG4e&@wA+mZ?bZbWW>`Z&Y27N%qHd*WeNZ5gEteF^WJj~ zf8fEli~TNM>^#3I5)Y6<99bT>DV2KEoeeRt)3F=L;LV1ecU<0t*lEoVEF_oh4L*GH zzfyT`EM?{Ljc-PbW5{R8@B#*^!(YoGuE{?-a-ZCAg~zoBUZ;?Sz(N+@n218#H}D|~ z)VPJ}X}>Y=|vXVjq>C11NThL*S$I2|MrgZn0{Du&mH){ z?qg+HDOtuhkv5*tt^dlhN}MMSW~;CkMyYa7dY(pi=>c~5DCOPO=$b>D`^Gn_XCMB=o;+|3H)aEE{Ba<-`-TvajkuvR*&A?^<8S#3KRJQ& zCgEq6c6tGrS+@tB!*pexjW0_|NYfgT;3MP|&}_or{&(h&vvbcSe-JzLr@Q~j&=m>y z3{K&q`tc!ug)6hk#BEo`yIF~ND68~hm-0jVNX2eGM6L_{N|>uR8IOggy;3=*-igsXUT=063i`t7cHe7 zjhcJ*E&`bFeXbCF^@g>ZxCxmc>ki)^BGmfuSPC~I`o!%~XgWrcF7vfMd?5QLd;}fI zD=ICLSF##P8~Gl(oBmQ7%hNADv_T)0&^Dv&0seF=`+5>=VTIaX;Lj}2T0AmU$qRrH zJx~wb1l+Nm)Kfbm$2nt|F|v5U=YR~Zc?0z@3?Rxx%Ovc2iSKsGzncjU%4CY}@ zl}fz*m5zGEXzsH%8O-I5Z$74f!I2|7p0eeAyq-6-jgaf|W5eHenRLr$AQNZ!w(btd#D8r)6TNf11!(=akLoOMJdZ zSrbw+loNP6Go;@FusuG(jXV$cShe2WH@geeSPrq=|uAW&@PFh#hq?L@4n7D_{-aKlCsQ`-6i&0+LrPYF-l(| z%F0{{KV+#38ohb04&TDcQ0r16YV_48$o#o_^I6kj%NDoQC!IXHp^y0Aq@os0mim+1 z^>^+3W)7t91<&t|k`d2wOj0K>^2^)Msi9q1muGc|(JqulW~yxp@FH2BQKlm+eFxzH z;`B(c4wX$j*O7GN27O`d;#scm6QN#IP4fU;u#$FkZxhpw?;}a@2?f9|Ikks;Q`?Jl z@^_x8m0cvm14wx3>Cxkl-weFCqMGGr|BG3*X7x?8FxQeUm&r2R-ttWJK(4PX*hdy4{q_yjzLKEtTHKa;lGFShAA)&J&k$yvJ+?)H(SR~$GgrCvo0P^1`2is2rzoY-)Mtl$P13m}% z0iOf>K+l0ZGylDmxno{U-W<6nX>_LP;%HY)-$j^0vt@vO!}Dp;M?45e_ABR+M!k~# z(-MUq_ABk!{zKP(;)eAOe>~kX*Y1vmJS2a~#BW3Wgk3iga>!qejp)6?g})aVA)Y4O zSa*|W$5Y2%jS$b1XR1Uk^~i>NLxz+y`vna0$9@I=1}2?%N@>^RKz>DLHHaB`MrDHM z$a%{vE&h)qm+F!3E_~@m-vsaI&DYBp1I5dq&X=cN6kKxYM%x|KU9sUs>(_P)@?O~Q zK|gR<{T^6<`yl_li=SfhHu;1f|23lJGXFa}YPoj*hx;A5J$*}^zcEzt4k~(L&weLe zH7R@G-uJ-&zC0y5*|;7aoriMCPum4wDK+LhPRFDWJ$ZX_J5~BV8B?!pdZa-ZK;z?= zbTs_J9&y4J4d;QcVFLx4J^!9P{#?KAH0(mYSqu!T z)?Qn}*DCjdH)^;;^R|or7ZE)mci8Yid_~YNmV^(8Ih)1qx&jqn^f$hd#g>vEfqALdtG$~i_Y8lp2O*B*WAW!v627q z^8@*Pj?Vo~JNk!E;)mg1{uU&k0mt6$eejtc*eLbWUWxINkLgDe4~>vsvv33$-{|)X zFi%bNe${e7{$}C9?hWU60DHz8;M0Uoy#s!^p5}aSl&{BrUVEj-wiSL`<)r79>CY|O zo>~Swo?Ga^V}ox;myN&29r;&<~d=p|#zoqF8nzv*Xub^i;V*?Rd07QWW}we}Os zUtZ$YN?9%cupnwUx8d*0eB>S1_Xs(hLDF#tpJ4rj^9SqPVB~|73t#1w)4$cO97!i` z1M+OUm!V%o1-s%FV=gq8@eb%HX++7*FRz#n`PDmsp4FNEEi~-e{>@PNkDm5>&o3>| zoS8#k^X48}RR15#FMpQ#=&>#%bgOh&3#p-X_C9ureY{CbJ1?KFz2Ua6?)ZPv&pv{m zYR&%3bixOJ^x$&OO{r;3o$015gMuW+Ufln$2$uPK)GcbuteOWO43@XZ82L6{U%zQN z`y?IK7ZEp>wsQCI?R1P!wmIH=>DN=a*_f*DFKlwokB;YVl|L`-{xeUB$+m71nkC=~ zW9i~(knqadd>r+(bc0?4mc^&?7RAsG8>ctk4fLGfE*qyWpDULCbaWkq3 zp6~Xo$3_!!z>Pt-fC!xB9-#uC?2IAq2332+k6sg=TtE5^z5||J1D;$LJh~S=vpCz*aksj0 zx4Ut-mwua_{S%%28=d_lo&77F{WG2Z4bJ}v3%viD>(p)4ld~sIS=Y{V^tbP`l%(I! zeV!ER2ZnYTnkXKOlGkr9^EkJ>2s#>=%dhzVahE^$DPJ{y`92hF!oPf;mUeW1AdS%S z#Qy#x%R2el-Tx2!ML(aM-v200_R^T=QMTHjIb&0nDgW6@={``e|7IK09hxD`c6?v( zi~89LpNzozcO*}c+P5NnNZX~IB6lQrS@MPle^cQEZ3>uA%Q^fv_y#BanE}HdnMfWG z^x6NI%=q1pMeYlI*oI-tS!NoHl;63|8;c4h$b9!FcN|^*s?2JJzorOj3o+qfyos=l zCi($`S50Ov#@s_2pnx*Z&kgtpZFxp)18Xz6H_1r+O#Q4Dk#ytSo?K~6eF6KVEKJ6d z{l6OdQLjLl%1m~CSU;wn$V%@oOI*hMCoR4Tn}#fg`DIpRMac3&Bk1Pwg7?@1{NVaW z1FCB^nt#SB4GDfPU(Pzv?f$ za$(@+O4%ypd#V8GiCY}G-9Ml>&zkL~k?%e|{#tu@gWoEP=3G0Z z4)&(XurM>~yPzD7`g}((Y4eVDu$Ews>Q}769`b0SA%{9iTCv&J^?j{HmQ zE2CyXEiIi+lf+*=S4Q{7novl#bGG0`PsDU;|E%cSFR19%HoRPq565(AK0~8Nk_m9@ zkt=dW-~?Xyk@a~f{|b2@-_IlD-uFQtwsJ^hjk*aPun>P;MOXU$Mul~Q5A$6{V+J1^ zq-MsuFs570<9QoP;&1lK-<$kq#y^-j1Tp3*ygJvQEc`k6g6<7G*QSOV;7=sEX7)5i%$+MYN8CqhN5V9oHEx| zUP5n^3KILi*=9BSy*lQLF#El|s_jdKHWa@dcvAQGsY{o`{o*#{3K^v>v%iZKW_(!7 zvoTA?JeN+F+ZEXLnib|RF^vsc%yqS%I{qnA4lKRMUVVj4o@B~P^Nku`-bM@Jp=l>) zH{PAwxR07$;I^y~Anu3n1Gv+%3v{y?07N9^|k$}W3}CB*L6W& z%h_vdglYN?s60krOIy=4xo6030FMPP9nkjpe1$&nTqk+MCEu9&X@7C$r8~T~D#KXt03qN*vS|J7D`@BgqjegpnR2Dr8T(On)pJYUsoidf^94}XZdJHdfl)Wa_k zw~Q7|q!j)5O5P%^>od^~d(rW~xJPmJGF#p{H>?HN(@=9R zuFts0+lDulLZ{`4_2Va%KiuftO~Es{0(brex#bH*>+)A(#C(f2$dukiA8(=stp&;g z_hCQs0pFmWJO03Tl%C~+J?urj`x7>6!G3$gTAYo5V#qDCePP4(oZnQ9p6gD9k(;s5BYhnF`i08R_%bACbHeq4`h6@IrtKqj{fe0j z52!D6>6FY^Sy*4V*+(Q7pRux2JKd?;Wd4>n9UHFg1@d-1-*=ksvsO9FEcqVmptmIX z-1K_rKer?PsYsd*ccaB<3zs{G&gMESzG}%rKTmQ@Y0S^n7Zc8KV z(t@))Gi_MDqPjS+An77Nahcszx%d1e_uuf2eg34SCq4K7sqy~)^8fexDeu3Id&2wq z9n&wri!23qDfZp;CknQQxm zFX+ky?horxTb;E|;PS#}>nFft)(HRS9-OK!0~-}M3~CZddx0nd>8fJPUd;C+_Kvtr z%S`2r!884203m?hf5z8XMn3_9mjA3h_ekTdNRY-~W;}ILvtA;q&Gn6V#^cnxFWVbY zQomcuyB(hV6Y?KsP2AR#Nq0#(l%`L0Ol0OaA@cgTksifA$cc0OeZA8c{e71(5Q!1kemOgZ`L^f zl?96NVD|qg^Za?GZ=a~A1%Y6B$h~b*RK8jey^^1;hf9lX#*#L6`_i-A+!PE@_Prv^b9EML>_+}Jm1ZI>+0E3^ z;tdi{WjD#A#3t&4z-Qs5yZgc?{Z~{O7Jd3#zdK^2#vbBzceqcjZ#1nh;cM>Cw)x93 z&I?S*V@ywdH5U836(zB<9KTSCC0~truyX&Dm_z3O@iS z{00Tbb6ZjPAxBM^k~+-DnglHS{>REVxSfl+z+L0ga(LBlHQHHsEKdfo5)hv7u z)5DvKG0EA@C=2WAPqCA~51+VY=*|t$qMx=ZACB<3GyDERKIu#maA`=K$;mvYKF27J zaqbVZupeizFSYO3;bF_{`}RD}S@u7#hvk08_*lQPNxrrD9vC9~ zI|AwcaT))d?y8kwl($qAY}w)#y)E>r`r0>9G-4UmrZSu3x{sno;qL@Bk~U=|pJj=< zJpk^^rraLe(%d`k&$3GCxUUFXEj86cd{GB5Z^fEeagtxK8~SpHGOM^o{P4i^Ash3; zZ!U`I2Q(z&u=*Trn)(?Eu1TJQ&AUHy_$}t(qZkv_zQIQHZ@C3FtP@RqQ0Emt8f-~l zK5uc-EX%`N&D3GU{M6sDM!XSb>WWS7)gnvPP0-V|1uVPqsVbS1xj9C;jUJ3OaqHS0 z?HAX*Dchw`vl!4!u}`f%!Scziw{(WTkz}uHB|Ns>P)27|mEW8J`OcAi9ENQ@JHNbX zR-bsWhtPUuG=Ie7GyF(#`dJ!9%j}gk`#>yvs|y_E zZ|Hy4R`q}1D}J$?R?=}>oU5d*wAuAt;j+woTabgGbgJYr_6|orczjNfsyF#Lqj6DcnSS9c!q^3v zqY>^_EMtX}ciq6OO06_lclKSTHAd{k%nMZW0?)4M!#JjQIh*>5W^6N=fok77m{Yn2 zXDoANX60XU?Aee)vCZ;#f~4`-FNu^bm21o_gGFxKxSW$PT5q$>H)J_!EX>z%+1Pi& z5(mVK7~lk-el+g!w?}Tld~)uSioXb%dM=-mewcCRTvn1Q2D3ajF30fyV|nkE{+F6H zJ{)q$nm%aUM8 zc9T_f5wM-Gg6xk1C8XR5yqoIxX5!M!x0?_q{9;YVhcZRk<_rSrCU%oc+uX9(7uJiZ zJt$7eL#2^!dY2SCFjDvOjwpFLmefATD1SM{4?yCFt*CDCeA$UZ(Tmg8W9L*BZ)-8n zIA0(a4>?1RXnfT2hub)z%D*Um3$jA(=D{8uFpc~8VcA zfoG9r`XY`qFolI>ojp)X(;afx(7QGn^OzO9DRG%@Q}_Ib?x-5J3Ak5~=e|x)?*8_; zv-g{qKB&6mBl+H)4=nWTM`rcUP1yA6qw;tCo=2Z3L!PDWRCQj+i?oOScqOSYG=`^; z;s-fjP=t8v@Lk>g>VsST?r?eVi1rwIRgq@y9k*^=nYwlL8(PKunRtcxIE}*?5cSI5 zy$XZxWB0fXE}+)vRnh`Jp*y4Ff!>U5{tPiayLq%F8DMw72Jm^!!yXXZ;HkV2eUx55 zId*qx{uRTIK$vzO$P^SS&?*2HOIfEY^{*ZTm?G@R} z(=3|m3aROkdol614sq2v9PvYzO>B`r2bLmv3FJ?l!#6x~M*oLwJvjlZqr+L3*bgFX zAnyF>t#Nin-?3?6G8>Y!C3@aZIiqz1vm5pz%}!l>+}(xS*TYU^BxPDMr(FY^`C-4Z zPjN)}vP)TUVfxIJWx6ujC&t`bm5G08BA%E@<6NTPcB#$9fE=6g(^Tb20a zE6ev(n{uCaA>5KQ+@~M;IyM<;T0@lp%2DN9^!ei&FI$2)&cHi1zv(+SB4&NGiyY=R z!OUi}rZSPSJw$A$QP!rYI^sbz-6mHVtj6yQNt<;$@bF!*iF-r) zfTcXR&c#Tm1l@L31)pWF;eMuUMGV4K0Dov)L0Xfvjs@+?`foH^<*$2W%MLG|v9Lm;Y-5j-%B ze7$v0lwbHZE`o%lqI9Q7=MqaQB@HSdEiJ-Q((Hl=NP|d7ElR31O2g6}(zWcebS~W+ zFP{KEK)}E6?~mWSGw=J(Jaf-=UFV#6?i0_PbLKpA?kn1I=J=Ne4eA9hjn+@1WckhnuWC#tK zS3b~rwh~uS@}{YHK$OMd}VryK7$R5$s6 zAtjvBu54>(OEj#64*<{&oU zq!k|&Y?FDj3Egcxs8p;lt~?T`7^8v8zV#aM3b7FsD`Ry~|5iph*7O9HSdGvyr%lzB zRRT(+H(Doo5Y5|zJc9V2-K#RQJ4kO;5dbeSunsOC8m}g21cK>Ye|i!rwjjQ8d9l<( z5)>KEB2!o{bjv{^&DAdER2OP;6PL&zUK)8Wu3em0>x}FW|41h9f{T%)g=h7}Os*to!Q3oE zI=>wBD9v_zjdUpOh{h`EGPR|_@3irttR{1{hp_6TqQFHOsv33Jso0M|m@xEoCd$WSC zf<&Ni1+Xca?M))Esh-Wsv>#Y=IHTdW1k>`w>Msg$mk1!YE_}!z$@F3F%N?rFQoj*%=XCgBL z?EAK>3V>b}re`yRL71nKH+J`fzGzTgN1Rp&9I}`!zMgcxOCx(1>X4oJs;qJS827c1 zcqRIGXTAM5o3=xf;hxA$0UP=Uf~m{7x=wcRBD$by~CFao#ciCNAvOe1E8oy>dnJ)r0D3~vjUr3HPNqYfSQVVG0Dg1BN3{I zJb-J+mP#(qIpFBwml%UDAR3#z*F|+*S5nc!_2H628>d_r2gGpI)&9FJnYdDOVk2TB zwix%%aa)ZJ>ibpDi{sf;*7@}DIQ|e$GUYXUBVRrlj2RlHVJ~_H>lOf~7CEdPw` zS=`~a*w#aDgXc2CQiU>`>P(;ht)v!w0WUC=UZ;N?QdB?sLFyB;mh($V&p=5}SM$pI znucTGU=bxJ8mc0L^B1C?l)c_35eZXN*77{f)Ici3qZT)BY@5GVZgshzj3;6r@ckH0 zB{$~n7!p+a)^DLLZ7vuv$!*8gj<=&{&Klbzj^5OdmI%5e&gy#fxZeKyeY@wgPH&+R zT0`%uC0@F>&#j7%au^)y3k!?yU&#%DH8AzfSNC9SE66++<-8Rn)C+Xb;k#<1fVZtj zgs6f{GKJCVA!szwPDYH+g!8>vN28iLyrQx9b@TGbnb?p-qpmW$MVJCMowCvGi-$3} z_L!w6Mlq>-8i<)0TJhD&S$Ln6-37zIVXm@^1B3ylF`L3P5eJ>bR|7ipHp$9-frR;9 zguceLl!(<8w^(BX*jW7Et5~YkcwmEz9pt%KBV|<+Zo7`|88y!e)m1lpyBEn**5b9) zP5*;~A%*7au~YX4sOv6RE&%rni@abLI#?RxN1H6=Fn^bBvZy;~j%}zG8B2jGvwhjy zAgrLt2l5Jycb$Kc2JU{iRGgl_lvAi`zS2S#Qi7EBxb31lnJ|;zGnw*?dBOG$F&(&4 zvIN=exJlB8fcM$NFHqNBX};TZs=uWwpqET;(;Sy!tlOXb8+z6fxttvCH@Q2)0P{o;=|Xzp zg~6*lL0`-t$@-q9KJ(mIy$GofJ*GAJn}v_)0lzFEy(x~cbtK)Z!)Rc&r1S$aWuenc zjq8&%MN+Nhd%6Qxb}8FL-}idZK`L-eO$u-}Y>q4m#Oxeog+ys_ZC!q-R2dC=1Sy2DfWB-d@|ME*G48OD%eN_HHJwo>19eoZS+l5 zYkCW3+nXSVgeYERP{ebxnin=m?Rx6n<>BZkeKtSiV+;X{V>skc(&o<3_XKs-2v+bC%vO@)n5B@PRS$Mpmy;y&-#o%l5LtP^hBmL z?dhqR7>nEX(qr7QYt>dvo2e|!eDb{_K%gEsBHcaB`)GkwTo1C|DfKlVFnM;;N2d8v zyjbsh1YzDh+X;iriG2|Tw5_9_4KwGA@u9W(^GvyyN0{Fe{zj{*Oo#2C3O2vi`87>v6%!tVY*;=V)NIT|@PPe};R@pC8-nPIw(dUN*i8hb~D% zAlz^_3LLmktmyxX>t)h3x+%%{TWH2#wq&wu%&AP`s+pF0%}SH;kI0{;Kgd%r^5jpV z#-SatYC%xXXjTD^qm>F{0I$cL)SHe9HJeTzD&fM}-U{1%-Ef=~r~5H7QQqF>FU)IE z?~MNpt~WHByvi=bwM1IU0|Gy2Wq*fF zvi*aG?u^ZvFqZsagk7EDaUb1 z1r~aDz*E}m3|1wdbbiPN>Y&R@!7qcCf9Qk=diCuOlnna`+U(Pu08Gu|8s@Q`ozzg+ zJDnQAvO!P|Ys(ZO2=2SVsVO?7c;mE2RD{db_1kELz}7QCh&^I6I|??h`#{_Sj*&}2 z-|4cfB@sd67t0kFC*&5_S@yBc3XneVJ}Pn4>)_KpIXmkYV6wpvD+y~xcsA^h%Vwp& zl78$hVgrh5ru#&#`x{r==aV0l2raE7^H=~1xMqdrjT6SvpaK0|MSHvd{*7CnH`}7H z=Q{A(|4KQX^c^>fZD5v4UvG05Fcq+0gx;aXO$&Oq*|eFioHR3@;N1bo5L)gNbFy-Kp1l_dh(O0z96O$E|Be{&M7*XR*-`vd?zpkOGgA)ZR>6vm z*xU=gA!E!z2le#QW2>DE*%@ir&gfGXM-E+`pECzT1{i}EN3c=}ZMel%a-1{45nSqG%Z5b~}rKXA4H12+!l4A>9v{#vh0fCYd$ zMsZ1JRBA9jwpk}{`oYhKGtZ0ya=sd~@*FkWqAmoe0$*AG?S>ats8zDCO&->7 zemp0N^UcW=#g1FFz;-9(gpX9Qc1)rQ0!Ap`p(;X=WMk?zG${jn4W!b8X@d$Vz+#S9@R%TL{wfl<> z^%=JPlL!fq28+EodR75H9vrCJ>ulRmsi*Kd8u$3Ouu`(7r&THX9I?MKZOql{b)=A* zVG#A=O`MoHZ~B*Z+@}dfY`HYaBVe1D7UswWtUI^rKzW)l`mIsoD917A#449m_H2b| z>0vDoYryS?Soevoh*Sxv!{$w;w={K3Wu;jA8K}x3OTWh2ay+yOHd>S8y@;Ta@1TXa z$t>>Xq;=mpY`>r>PLy@5i)Wo?Ec!KRRpB?F!?NMuaUl8Bxy!`si0@*JHm7u%*HtkHe`R0^Ba;tH?u$2^xs80=U&GhxX+4C%T6_KV&tpDk zAWQuGx2|y0^siExxq^B*`^47X7m19 zPy9)eXsSLe@VE9weEj~#ck;*l4>m)d3)~b&Z?*vKCWDy+{Kx&HCBMY^t?eI)*tEq@ zt^SDf0Z*tO1--OZvLRnmk|y7Ln)q6Jk4X4;Sgfl`5ua>p==`R6o(VNxCTk__zyX?` zRngio`|C1m?L|%zpVsv$OJT+GXda|FaXlC~eBlfW^w)ix-eOg#V-LPpp|h_-Tvm2?xih1(rdg?NVsBg9Oc&Hk(~EFDo=nwcP^4QrR9j0c z3o3L!%4eoXao$u}ItAm;$S_X(5kZl{Enl$X`ZXb5`2d!~f`GnNSDB1y5E;pr=oy3D z7rV6+8-(Ps%s>m1(Lv#D8P9{8vB>XXZ1Jjj3ACUi{Lc`maj2|_uV64q@e2B*hKSTk zd#v~@kwNWW;76OIR{F-;u_fqC;d_Jjq(ZqgGlvW(Z-2)$i+0cyNz-BQ3BkbuA-oUm zpvl5^vuLuYKoLUmfz&wy>Z(O#`M5n}f?Wo1_+TAc?OLdhpA-7K@(VT_G7r8v4)ivC zXt5jR7;tR&A=EQq87)MM`r&%yHR(?CyVs$MM4pRngC_5o;c$RtLebFeG9;1FqS!?w z_TlOR`y~v-u3RP>aSSQ2e7!zasL1(TUgE-iyT$A0cvNu|9V_(ZszLd^u6xu%46Moe zn3xUXc#kd;kW#gng4oQBM;v_koye$5kB?1e&`S#{tp)V9X7AE3egLO~t!D2r`5Nvm zJ1bF9<^hY*-nc#9V@%`Yx{(8PiXQuKfGRQO)x_KB0PU;r*7=dekoC+PhLQU?A-!gi zwGY4BO@<%p3_KcKLTP7=n^&aKrTI?RW``HeAZ=aUqZhH?pM=E8a@ih9ml))q+-t+> zoqzJ$4l4IT=+pwAB)`06xwC-|PKwFEIXTci-u*=+|SL9)ov-I_lPU7fhyqz+ud3 zNU7KJnIvTHf(u_MT0TSDzTyPZcf*4&)t5d|G-Eihsi|5sK91l0U;Tx5iG`^BuA4p` zYU*~)&C z66I&iF5uO1uY%V8yk~LCXa!&(p)e^euf7&n@yW8xzOr{JubJC;b9kTn_zBVqtTEWQ zAEI}TamqRuu&l~6)~l(>YqTh-Va1eb*_{97clpitdcUGp_{rC4^1j&GCoOGC*QbN- z2i96MEQKV|i5wzNr(&qH+mbFzp?%|phPd%~`J+$Gr<>Rj>1nlRCdZ9mKzc*8!2@fE z@9cp78kgqX@%4#k+?lH5$3EmXS52v3h!1Og63vG8OLG~G9N2R3+`D*sDEsV9Eds_x z*CqK)15Ue4+X4g#?}{1_8&_I`hwv{hKRaN2()!M*b_~Ke&!Lhv``h4WJp}!c-=4ur&Xrt9r~Gj+kI#=kxN(j-2+vBmHM#eD$6?;8+UPb zC1CO^)c}s>c550@UBU|TtEbQE@0}BX!XXTzP2>|vNCx^NN~KFt)V)Xa0J1H3J9XcZ%IXro^!arlPKj)~w0MUipv~%r@k5}D89f8M=%P`w-0is#Ag)DUyJAZ4;yR!(_Mou=E zi_ooi?&OG6cb1_(py|g7Kz(yY^}B-w?j-X@b#Z%Ji`v+CGLwP6?xi=eGSi{|MDt%< ziWV3@zLuHAVwvA7M`$dvqm1f?W((Y*hg*xT7gO$k@qP()$ld~X*v+YX15T0I1A;1W zpUp}!Iki7Oq{l{OK1yf}c$v`VyUh$f{gd!Hz&9Z#C|09KX-W^|oBE;h6Yqn*(#Mqy zIq$2+^)jl^&3l+Qs;%D!j&>P<582gKV}w34GS*bVvi4e4hd%2tdnme$hZ@sO7+9t6 z`LL9BosH zGr@hkhXlYox>usMd8GW4M2F#0cc6x}I~mUQ+0`}G%z^N8kXWH6d5mYPVB~g=h(PBl zn!ePtRVT9Cv!SssAWFQ1IVKNKlm{rz13U(T41gdbAjkyh{{E<;O}kY{d(}&__q4Y6 zbh3A)Bw>3qVTV6q$2p-qPbPSF`-j2*t!yo#O@OWGYXZjOR|+g)dIE6NG^l|CJiH|< zKbbF=+_@ply~co}hCc}y5UUol_Xr&V;@Iq6l{;$MR05>?tbRa;cql-bhvkl1M!0<@ zM6^Pw?XOQh3<9#MW@6UM0)Qkn#|x0wrAvNX0feYBQ1&R!-= z7?^78SF z()1I(&HS5XP-ABkR_IX`!lbdw-&yGK$87>&p~TAlp{uRXqY1pv{b6<07+|9u^7u=p z6}KN5Mk-;>@7?RumLkx_-L$rlr?0z8Ud-dt)7o&Xg5XefLGbn0^6zIa%L~qY%Ztvw zmX{m}SeP8WEdPD>r@Z{KkNk1x>Q4*1D-v?X&Q-XuPvns7o9ovLK!5T~ACSaG&XS;e zo4TMoZZNH$J-^6(?DA`Q6MmRKeT{#``8(+U*aPGKlihg$S|CUV2+{+3JPknP1t5L| zAc_MP=2x9t!9RG88osRtnXd-9u6mjDo}Toc(e|E6_RfqkEAF0&^CxtVF;9#!PZ}`C z<^f9b0Ht|=pLsHM0rLmeb^ouTD=YuosCcIc`A&;TI2Gr}eZsFx7E83}>}{Ljh$;Zw?d(qGH1R426`zLyLK+a`01rE2@B(+ou_y@*9#ey!#<>xgGQUV^3p8YF|fj#es$NM=z5-iMJKuWO9@h4x%C1JtE0m3VSS|nvVSzL*hfaLkyz0C zWWH<}bz#2C{OEoNerhbfqlM7%WJZSd$l}00=g_Ec^inSocCV!q!?Iy_PpIwkzl%eS z zpi9(7WJ#Ndl5LNn+UH!#^mpJL5d5ea6enYQx9MKU8_${dEy5fXar$(_O(D-eBH0!F zh;y8RRKioKcgZ9vh6h2^u`Eh2F8=!O|CwT;=L}wG&XQ{N3dV*_Sa)*k=Umk24LY#Fu1nj8Xys3z<;v0Tw$hR9i&wKOTxpblSGMe(A$XW!du55ouOJwQ~ z%C8J}$JB%G@ayrYR(AW(F5;G$a=GAT_2y5-DcesSZ^D!Vsk4p!jW1>k$kJJ5$G4p< zMpj+wGR9~pa>wf~iVfzKBxx9dA3j1`TeartJPQX#T9obyyPtGfjEMjK)?Qc&7%HYz zN;yQMc>TZ$ih36sS@i>qw(!&F?WOEEQhKDg3NSfh&D>8efKaHHM~zXo{`t!4XJsbb z*oj;0C7m}vm#8|Lk2Ai0kYO?Mtn#N%8h`0EFU30~*MpI(1MSUbG9?1(OkS%s3!l?{ z>7EzDg|o#K_BbZD>BQUxo)Xd-XWalt-Wrt?*`O?YzH%85p|N*Dv#n{=mk1BfHTNt^ z9e*Z}l?ZHvO*y}6QNonIkOeeuoZX*g3Dg=a-vm4wT;|I9N@qAE+A-=s-=UPIu*+WR z&{<+iS9qA<{h3_Ps_+i3p(>T>Wuv@yk7aJ~za9i#@-d2OvV^Q5f4@XOQ+HXej`BD2 z=15k_SGVn~iT4|AR#&e2A`{oMSAV-_yMMCVA8V$UM!|S|7hkU#*Y%$BEmYSKoe{{` zM#)UG*KnI5;^0xnKFQ21A2Laa9-3SF=i8@9XPt(Tvk3C93P~n79(Rarv zW=X9N2|ZptUS)stprIIG-D*@m){x*G_|lS?Gut@y&Z1UVpMkOePXyZlOGwZTl`?bD zxgpOYYoN?aedGaY#F;-qLc59K=Ll{6`k)`_7-~rNxfx%{D}^W;S#3BesK4q>Uo7?HH1aVM^&tKuCBr*(iI5V%O@itefNxvj<7uQVjgO`F5u(@mst@ zi~Bel#-u%%7aYdj&pyHvGVkPP7FS>Mg>|8M7DgFe)5i=X!F-DcpB0Mq24a_50{KHF89p&2%88$ zTVzS4TkKDL4{fr>&s9mJCeL7cZT`~;F8Pb-c=_Nb&Al>S7x6(gfcT)4`gnQMz+<1) zFYwC~_JImvf(TkKg-kxB#_Vr_x@BpB6QBwsTajlIZ}7R2$UNarD0bKAp|;iFUDE@6AH& z^XP-f3u@VobpI!=VAaS*TX~|b+yYnQLG@N^e@YKam*gkVlhw8N8P0~Frp>SV)$R=MQiWdFQ;U8vq-pcJ``rIz< zW%uyvszqh?_o0mm08$;YD$_NvK1Hd7Y@4O~A)UYY2gsoo=-@wN|ITu~-Y$={2)*fl z*5|KKA33ZLn1O~@(&yUWv;*<*4xML1AS=#UY|*6j59T*&4R8CZ@9&CfLD}o5@o$AA z0J93POHMx#O_@ymo-KL>>yxFbVdk_#f_uxa=`B*y2xLfcYBH#{61N7teY!&dnli?V z{}JcZ`m<@|tgs06obWKZog6()1j5UDT%R?#uh;43eTCTxw*QbrtAF##3|lAs2RI_Y zW-WMpmo|M9h|PQo;*LoT*X$q+Ny2~^T|*$D6`ZERvJ1{dT)wL=+dpkHwZ?YC*&mT& z#qpl4$arDGvVp0bGJGkWQPV3Yn&HlkD^lws($;~NXycJJqw);*q_j6EIUVmND3}{L zoQFL9_cI1GrixSPA-PsgAUSt^V-rfNAJM9l?EjAAz<7;yA(ux^!Q_kPcJThtUQ6i4 zfqyevvh98@J_5?W1bLI!|Pq=jK(u=GHt$4=X2jco9^^a zsMG9IJ9x~~kDb`GL<8-T8SjS{N<~gWOjfv?eNK1`9y2y)AqbKPx~Ww1uSllC4vFCh zN(>QgywQA7AXasmn?FM(Ay51=VYM}*=4P9<>5P9R0}&_EO9J+JW6nNH#Cn7|7ut7akSYRB+pr?m!o2E#&^;1DMJRQ;#vg?82@DQCa^rimq%k?g^G9J zYT<6WW%2zt>+VP?)Lw?7lU142w%rL0X8KZzpdB3+3Ow|x@75clLZmaJ0Y{U?m-);T zhq(&`WuIEAAR?hpzgTx@5C!t-+^tvnOK54U^j2Xd!s6ID3ogx*1FC#MZuIbl_yt*L zmc~HUzI3%%PYpUDLFHsnE>(H5YUEPpDRsKQSb%vp%jO6BF#yX}?-DR))@VGk4W5C0 zR{y)1Haf_R>{IJuqHl_n-@3?4<*3|2&JaW4@Z(^>ugCv(#X~qOzcH`PP*A=?g}0p+ zfSCWZ6;nXs&FTBezUd|kgo3rt7%^)5H&=A5y_E3YX&CD~3yy(ug6*#R1h_ z7TC$j!;a;)Q&h482d{VUeuYKmjhK^3Z@%Ol7lbDpeHgbjM5B&Qp@J|?mh-{;>7{E;YaaQ-gXwUPkr#9o(uhyI0B z=e=k~lZn2Un3T;YqQTepn(8jwgd~Lw2a^wqRD(HwPM85y1Me~0k&mi)5DlH1b^Vg{ ze1G45W91>h!KUFj6E!ET_Ogo;c6De~HN>s~&L&*sdJAqNuVa|q8oLlvrI$$PIy)Ga0WvVTKy?hpI#su-p=$S;$>qp^2m)(FyaMt|Pch3={In%RYU#etM5@rQXN z2_TbiJvYTZ$0T>`>&e01*dMQN`$BR;V?M@s_8 z%U^0 zk%B6)wz2BMB}o6X8+sh#5+%Dopm}#6TcLiZ);xdYp(vp;g028sMnq_@sV0hKx z9h}Os$kY9c%S{E0zl_$r{~9!n=*B~>q_H*Ev~lKfkMNl=z1i)|tEa7B=hkg3v}9Ct zpzo3qtpRVXqo4p4~M!WL! z4JKFhzs~^RC>XFh9P;ADM>|Ze7GDXX~$Cx|$-*_PdN8-)aMhUIBE@miQNF+tt z@tg6xH_=J4gTU-}R%(yhh^{jXoupzLyyyd=xX(`@$z$hz4UIvv&jKeA^HG{MxSlGu$FW z^qi=C0{ZLh0Zu0<>^!1P+xr|@(q?Io-#NCj+0OeA^isan{@`HA+_8T3d+K(ehJh+J z%0NXIs3WC%E^9%eI$x6KJ9M(wStq> z;l8d@3BlULK7By;{ZdUB{qi`lrLhZ+V{tT-Z6xZ)4ztN zvhi4Y=*C^TTf8|%80gtj`6BD51(NEo`0J3LY&tONEd?n(Lci3aN0mwU8J`?wd!MSZ zzmqHeLLbg;A{H6)oBFd)@82xzZ(6zcnX<3#KDKho`6kSX7(?CawpvHR-UZ*S9_HJn z$iup(qvO?t4H1}xLZbBEk<^EUmpRHQGU?JS3ubjE5R(04zEk6wX9u6z*+aJA`n~~P zOT?m&pji)PYzNJA4foDc+{bFzm^5B{^t%dtKXpmTc_UBYXLICQZf=O*47=gs^r6mT zZ(COI@{g`wA_RNNgfUsm>L5;jMpxw2H+0m`Q-c4{3z5f?02%B9!$1zwH&qse2_zEa z<4sab?P;4GEt7?Mm2)EzL7aV~AJdrE?w*8g?6F|zB|-o0qLzq@nQ>L7Y-DW_0)yu8 zsAEAtIzUn7T_a}SD1`4ToTQXCoy^g<(ZYBB8+BQjiTOlVz`w_@U9E8@nz@JGmyFV< zVfZ4Mql1w7g^=PTPpMw9CGAoKwkxU!8? z^YRU^{5FREZSWA3bS96ht=SRR;2ql_oEJY4_`c3NqodqER2Ghsi_rYxRe;Yq(cJCW zlWJ`Bg00uI^bEbP%)fdj*ghr!3*78;^hI(E9&)ntQu;$r=2}-rt$Xm?y>l=VU=M!I z_h1!r)bbvbyjTXKtlO*iP(VIbJQJ=4OOD0&Y!Ad`ROo{2@Tvw)8}}jUE6~imR`y1( zll6pS*EYdHcfcaV4seY;r42a{(>u}U!#+O-1;~ez>TbQHW9;_0x+rpP?h{goU+>3c9wb2GPGjvsir&{kqzO; z7)bWg-Y_4lQEy;HIq4%a_UC%`D!Lf9M?Tn{@Fm(%G&tULJ}lv-qy4eqpF-ln1e+CG zOewS+_Zmto2svCGF!b$1e`W5?M~IUyWbZwZY4Bf_8txcrj3~&EUwo zm7;vh5gg)Hut;2AndA$ZQg#>`JZvqM%4qEuzSo=P?R;&xG@G!d$Co7LiV^A8teaTB z2i1RN6E{~$D&@@#qMi0!?j~iaF(2vHRuKC;#K4VUvC!`y!zFM#Z_6&TJgGL-dXu+Q z5UAn&Cg}q5+t4uBqL$YBRcLtFqzG2rR(>gGqACwO8yXRn!S96UWY+aN(%&&4Kr61?%UZn&HF3LQap|{K74*)m zqZe;^Sf48hcoA>E8iihluKG*!3(;XRLTb5WN69W1BhHbhL>Oa#Obp@q9fJi9gEM`y zOZGY1vqCn&O6$|`#m6TnHU4DQVud7}4HuG0B0hcFz4(!PIQ8I`Y`JF8*6gD$ine6; zp8lnr!L;@3)cU{{C)aVFD}D%njpd(Cja==mN2Kz`Ae|>b+7!gu$Z@4PC>?glrf_Pm z{1dqEZ=Zy263LvcdVT&-Inc>AoqdCjcKjjer}CjM(&LJ?_2-2CIOBs1Jt4LFB5&T* zqb-FgyuR+(@>NT#n{05{Vv8@Y2-#K6>`6&uP{$C)9^^}QnS))TMl3V`C0dlNOoz6U z?cQ}KP&71X+f*)L!DdID<|A8BtsH>2sJhj@n?&YSLO&`$yqG6$F&n%L*lPgQQQlB_ z&J&kywdwPvQ#KLrbSO3F!0x#1CUJ?f zj;CJcGAGKVwGkG)FT5N1P$|Cm_gIs()0RE=Wt8OiDIH?8h!rzxwa^2AVhNT?K;IBX zF>W|0nlaaFq}1Oz98LH}BlpDfD6f5XDM6NB!;&_^aBH4=2I#3H%y4zE?dz)C&W@0m z4*JQ=ewfJM`4|zV5Z?fJIhv4IFkz7IHXA3tJjfo)5*7_klsPShyNk{@>q4EHCr=jr00~IYh!n%J^?PRqs z63UoZuJD+2Ou;OIxQ)CML4*%b#DCy^9p6JwnYWNE zrCgTMu-e=UPVV3TB4e+W@*}t_G1C!$_z=)h62(sXb5Ts-`p$fp>GBj&?lRRDH@=Z0 zGO8YHEQ85Z?v%UK)R=)hPe?AIv>~Peaya;|Mt2Zgh$Mt4$Pvy~YR}h^5n*1`GLV-L zt=@G~<_Lx)iz(VAB+uO6*co_f=++aWi$kg2KhOH>QMbqbbv7SgcSDslo zUPwwzJ*4U>raI*yWBB}ZwRSkvOOENnDG;YheXYt}^~e=lkpMdxc3XZ?S!e$qc(i(j zq9(djrM-E}w4IwhMjH~#Pg*2ctL00s_2|MDO*wN{h507Dcuv2@Hn+&+-{JB-+?GGs z#9=tXz2ajVSrCa2#rKlw;n1tL30AdxQS#4#BaLP8GpY@?05PNeVltV7ddEky}B@$}>v zxM(-Z7(8z!YwGd%Bod7B)Tht&gh_WUHP}dZqFF3166qch4~2QwvMhGXm1KLu6g$ro z=_DiZ5wg&4-I!7S4KHQwnkzK@euIr_=e26&g)`#UiSK!uzGh+(cq3=pSw# z6#aLU-rw~8FFJ=2?YZ#E5wVtib^(4WOhnAv~e#;l0uveW|9`vtK;O5BrX0L(< z>#J@X8E0;mQSl3MeUvAfuBdaGu>*|?ydXz2_E&mVJ@nZ{)1`Idv-Cq+`B|DH2N=hG zpAab(jRO6p=434!b7C*n%#c!^4WgpZP4 zkn@ac=XSyytV|+LC^nIBQ51|9pVEo@ed>l>Rq{#t;qxNV^?E>dWMbVU_!_DWKHIhw zq3lGl2m#1P82dG0%7J6Be9zX$R|V~!P0!>Q(e(W=2|OQW0N0q4=uciQ`DM(rnV)>e zCJQ{$xi2~pd}^D@nBvi-o`Kh&w0ya;FA7_>v6=X2a4>wCjl77OcU?+P(~)X3pr}dx zEj{1!_W2arC@1?zSFRj?KyJqo*XnVz@-!wP4{xT3=8pZ40BMoF7?JLQL04oU@sbB8 z9ey^Pi{*QOMYJa9en%T3tP_9w6ieS2I7F+=JDNA_yLLnAbssGiZ5hV_UZ%hdNlE=k zS99DS(1fiQ*ESJ~>M_)v@dud?eM&;!F6eEkqpIBE2qcibm3Q3J+o;-wY|l@t z1-aGt1MZHxtD-)E?dszdWD>9MjC!cN7$AHh-#^yMs2zbL=M{1o^Y)K@Gr|KDAd~^d zi5$)_JIAd0brvGJy7#t*b0e9nzXrRospl;ChY)P;FY%|424Ou9jxO(nw@AHOLX|m% z`PeZDO?^xxLhgK$G-*wIDBF{0H84cr?>Ls=0-1^TMeCdK=E|A#lQ}1ht|eYkeUQ~4S|&YUsvl@_*v7ZKbm;C7v5DhDG(Kma^a-I32>yh&P#ZRz zEgSUd3mmkBe9p2O=;aqmHA&ypO>6VC@8g2xt!l1G$qq>h$-xx+3!uo8UPM>A`yRJU zNxo0-d!JFY>rE!u2rote?{i&Wm?H@&vPgJ@vMM z{`zZ_0_yJj%5l&l&NeuY)jKB`pX|LZM|YF7JCFdjpgWJqXw+0rrMofMfsdY;v=0d0 zz-Ch)tRt~wJ8;df=yT;;cEisJ%3V)km*bv+Sik08H+T-FQ3RVnA)k-tzgXv9({K6* zIn&?R?7&6w?2)aK-ys-$B@QS$VW5V;4gqG`%wdFUuwjQgG}(B63V&tlz9*yB{5rOm-s_;@1{p?pf0RU{U;^?lY^Pr_GB`Jon~YRopsx0xQ1P zkF7mpP*_$nALD_PbrI=*rNV_x`pU-1DAln{I(ADfDuLAc=1kOja_J&t!_rDqUB0O{ zrkS}dv9ZJz?@J~MLQ-li%ZBnP6}Nw9QsK&1f(n)D=8*EoFEFb0<7+66n> z6obqj;=Mc8pn=DukfG<7DUhL0c+qwId<>o&h1)Y&z$jzep;cG5(5lN72tRfix{L26 z!^YI_V*VH$<7}{*P{^%_gH7V=X|D~^weZ?QJdi8pl8d(x*W(%Li>GNnbWk$8+mP3= zC%;k5lG_lQ$KSDc{^h=xbq}bdC@2pQaFP@p52;joAO5upl!q$aEOz6_A6@-sshuii z*%jgqV9(55?2)l!ZT0$n#c~nbBJKLS#5HY8Fjhu(yu@|RCqln{o}lR2+b;=_oEBVm>cr{;btV-x1XQWR=d~l0JcF}Cjzzo=VmqAACdpYK& z9)0Qt85F@K-&v!6KeEm zKO8hX=2{AKh2eJjPh$WpB+-4-fX$TR6aGNdr-HG5X0}bmOFms~2#3eN8R8LUSr5&_ z&7^gT2?w*{cZ_uHBTpO@q8g7y8b;n~HQP(aag9itO%aF9I)xoF4R8R7o4=BT%~%mE zOC$1u#I;-01eKJx*`aQYD&Wwvrd#G;NTRRNEbUEi_*7wY-HKU6|e-#CyANPCA}@%{Zw{l(4t7Sxg60*C*= ze~Nb)cF3Ze1pQ{2L)rV*E9{W<0^x;la6dKt@8PX9sYMO{= zf9$Pp&%TkOW5XKVoJ%9Lus{(RZsPv=|*g28A(w8aD)Dby8qMOPI6rH-Fj8* zR;v;!Y0g73DGkq8`gYrc+gS&O?79GzKx)4;p#-NRw{2B?>(qs?YckvV@2@0{Zf3W{ z?H}8E`A0(d-x`(R^xLNLzV+!W0Yt-YHcM~|g0-m2+!p^=E9Vu}bocdnk*YKm0cnB_ zQ3M_(A<_bhAROObp(ce-s2e??oN@%K|AHV9mUsp<^J)7W6-T#Dfjhe_)M<$4eoL$eva3xW{pYkjeHWr zZUmTh?|!#HO5^u=?n*FK{?p+4#-Nkn-}6o}t_yaHsW5;}O+a&10~pP=Ku`z*^NS!T zp$8vXcd%n(DkY#*)by%UaN6k*9da5|#UQ|}Q`4~^NHI8pL1ywYi4G$aUU9FKawWZ{ zAg?^QMJ+4er=LSI#SVu}D(GQ^D&_^Ki#iLMwFYibr4k4Nb(YY>x{GZGr~aV8!%ee` ztYms&HK1DuoM5gdz_`;Gfhdp#2SFMv;UNni%9gij{`<`%0no1!Fz+kSl_W(S-)63E z>!XZeY$rr`SsdDoIex=TimbN`wT-DFNd@~?8YK@y4MSp{(o9Bk zmyg!|${WPrxG6Y0)6eKUk~^V;(nEYMKbM~3#;z-gd8AuQjL5JXam~m_UF{x*aUn=3 zuF20o7=u!5rG<@teoDC5&FQ|X}D)P$dFwV4VY{@l> zH)P;l*eU5tX>va;%(cYeP=dyoC(?Z$>@Sd@nS6hS1}^$$C93*SEcO}6^nXf5^}?`r zMG|0eFM)Y|@<8|=iD8HH$pg`+Ah81yqHd!_XjsIP4$;6qDR3!84qRe+pshs?-0RRV zRZnaK>GJZ-4;L|L#Dh?r$v~Sw3|<9-kh~=LFYvoUPs|Xo6UXF} zR2cGSKrui(c7|3T2>a=PTO)k^ey%+K&+9r_Fa0`x!%TIZ+{%a7OLBfW{+D}MBXCRF`n=A-GY8$lpJI%ix&YyD0<~~BJ?O-;K+{fQj}%7>B-xt%q~}aZ>|RDV2{8~biVy%i zzrbokv0%Ou)lCXgkTdpgdcR$LFYY4&;yhW%*Sp6pbZ%6 zN&46Z0qdU9p;HeauOPq^lO<1wt4|%3RpoEI0O91JwtM$+S*7Pv3FZkvnSNjd^lA?2iDZx%>B7GQ&1q0S0f?rA zPBbNeXux8AO9nE800t%~$ zWdW4YA%pf&$?@c)c6uxPMZFIP&ivZ?}t7a-h7&>hyYet39?av8mzCz=07rJR4t z2k8iNkD-zC9pITbI^Apo;{_fBDg;u>tM)<*6f^;ri{8a`Xn`u`C1}q9r!z2;cXX=3 z2K{XvGdLel0?KIm<3BM5bWu^0&0aF-nNY52GTueoX6G zj2LE=p@h4!BO>*(F07myjTSfaLT-9;R{iiqR^0TN9kx&|c5VZU^WP97kR;yqj&xK= z>jH$~G04shfz%T-`e#U=VIyxyZnKyUEinLE0FC}@!PF&im>Zg-n`0tyYR|07ZfFRw zYJf7iPNxE=bm;?h3RnP0l+c6Nm9Q6;PJF52Skjg`k?fJ0Q^D;0Tb-Ng)ag!r?yzqEor$!*dPKd zE0DuU@U(%45W**pizF$xfZgwdegOUm0v>Z<0N{6so@nuc)|_$&1^}LA6df-KU`ZoM zH_2FVdtQo9)!Z$A%c}l2$D}}*hFVe}Y{+MwK!d^O2wsZbACTiP2V>fZ_Z&HAFUa_Z z{#Gdm`s+skNJGa2IN0q&A#j+-RqCF|90G;}dSweBy&nXwY9*|LP>@Igi4nYy#W^Sh zkoja10CGUe!&ZWfApo>$z+nYCnF3+_7i3E80&!*+?Ot-`osw16r+?@ba@?oq!od58 z+_y&1D+a(aHBtiJi``;yOF%KZd4O$9`#?2-Z8~8XtdCv(17Q=E!2L#`d{*?Ai(t8` z>q7`=4tP++u1o59139Gg>JXh`h5^Owg1600?AYL`Stpb54vsO7=Y@j(DG-L&V3UIS zssxfG=pXkLC(xm49r|7M)9qS(!B?(~jY~QQC^uM+82~l_A8HvI%ISAi2xi9{(Y1gb z{MU!KBY^H&frZ|o?+~buqEV*FU5-9cVL1)t55OP>0fdKw1kcYgCx^hPUVbA+5vX?s{=IDT0C&i6HoVp zN6xvKxW z#+l0Ri?9d?*e$H8t3ACU2p~@#P*Arf*EL2gdX@NN_QqPP<41$u7A~_tCIL}1dq2aM zV%_%SAZ{=4BlU4DzLBu&Gk@ErqZH%*My=Ru#kIt(>dAbFvhI{0@A|0u%Wcg1ojhvK z%2G;u)w-oa4vWY*9wA+O!>&n441M@|@3QWgvfm*yli(Q>4z6PgR~59(oX?&*%a_Qh zPqJAw`04I9W30F-zgUe)ns-u=j!F#)S@3Z-*6ZOn!uJTkYSXLCq zJR3YX2u2L;bbgn=_SN%|J;yBTK`Q3x_si!m2oN?UWKUyZ=i^xMSC#c z_LjYLE40_}A?qAfShRbeXw5#jLwvHVV;_V;?NCOhT>Zy)cZq1B-2mF;8m+1Jz?;^x zN7D=5Kd?SnTXW9eO1P}e92Xzs!Z2FlY$TSC8(Ov^7X9DNqX zbwZcSv+&B{mQvvTB)u)B?OGXO16r2%s?>|qK_>#SNjlkT3~z#jU*7rs%8>!K`if8B ztTPYlm;rCQ$i%aD4c@5R0en&F>vM0DBaiI+F*GHe(PaMqjLmk^xtTeoxAtf!i>RiO z!h@!|P7A(BzB7%Rg|o1%ckE;{<~3YrC%WV9q1)&+>@RuAPC<4(-?Yc})+1 z((r%K72an|`HnOex>9d7iTS!%9mqW8+NeQgyd1vCQI08UGZi|V7#ZGa$8^?@vUYkR zRQ?Qcn{EZjuSF>NHgb;~-`S_B3dS!*ueQwN3sRV?3((f4TjnzR<-~o4`^6XhKTn&o zOn=!W$BgYceS01KOz!jHTJpH)Ub`!Kdu4-s$6C2su|0J><0W(J&Em<7h@1pi21`Ft zAp6cz(IABj4}CUfC#!zw@mIF0@83U7nsTsm!_#z0h>KR%GDiye87XIdd18)0;9C4i z93#^I_``QNXVj~x-OKT$>8F~%2Ii`Xhe{EZS7;BsYWkFtyB!hfE;Q<8B!941VPTAjXqj{Gv%vfE z4|#qLWBR9Uxb}PW#2{?Iqfel6%&NX(Eh1D#0@IqHC}u~sqpg{tGDrEz*?()oNE~a^stS{Yeo$Ki@0Tonq{+OFFKY zVt1?3iB)5S(aIe~n%mWhlZ}6l;=yi)uva`E4V+k8T~<}87#xp0p8u<}`lQ^A@kU1P zRiRJ{X=|fqD1W=NXyWtB?lR_%qv&-~t*{N{yGdhz?o&^vT(Nf2smuK#IrDxz$abs+zGMk>@94*;(dRFEdnzk6ZI1iwK>8^dfO)RGWgNxi`i?yu{lH zb85cXo zUzc*b^3d!jcRUj<8soM}&2}>~3e_$z4(2W?<{q<9>c335xFSLb8KI#uy3I8B*B(v< z7a8i|cFBqrwPfwtIDUN4tG)oo6(zS6Gaf;%BBS=2EHW_hZCnAa#Iwo1P2sb+TSQ!& zJlnK(VC%s_)792ZJ{6JA2WiGl)}Q>w_ZVOuY(n$q4*Lul9wy5@RYE>UmF8QC8t2Yl zDE8POpvtvrJ?&A2*q^$>MEB6K{YwnkHm^{V^Uu{NUiwr&gV44Br+xDGG@s+M|NOC5 zwuFmR{gZ9p{Z!p+UXt+y`|deO!tBWOW<>D$-xLq6x@_hx$6nHAs&VK%{IN{Jhw8Of znZZx}n?H?zXBe^1D;s+mjjPzV1f^dbacYz>G3Ex zb~E-EjJNdNA^HaQUC!(z-g&NKi z4Sk<*@A7_{F2fj2lyw;u{60Tv*fbjbBF)`boV=bE8zbpYK)1iBMJE!e7mc&K#!p&F zem`WgI9jGbjvmfmnz}7|JTMeX2xpT?3p6THd3SB~(?rI`IsWcRp>A^y{>LAR5Qi5f zw|>~s0!q~|71fBUs#olV#_jb7n$GJzXf5wR>#ZB*)##}WFYD+6K7RQPZ$hDAd3(q) zD#`fg8=7_7fu`%hS&ynJn(8>(x&xnaE(EQEzQ5sJQP6zbdg?ZD$|%|<$N2sE9?7#+ zB>^&i<7>g=(GI<39df}V)Z2Gkvl9)<)~_DGCH*UP*!>O~zDce2jt}|i)cEK4`yWP> z1Q0aGuq2tE@0#*AaC7~LUny0__O2Up+p7WMhXq+k!t_Dl0>z^DcI(9(z_ zGCkvP<3+S?@eny$lG-(cznzZ^+Bwh=TALw}E3H*FN~eBJ9#~x~w2b56q&2ea4ZCf$ zZ=6@9utIRdXx+BmsSQutC~N->7}R%mD}OdVVA}t1Z3K<>_=!eKHK4UHtHXEuTtn{G zx*baHwvQdVG1 zp*Et=nwak{^F5Fe=C`wajuj!yxN%|c5*yFI+|fB#zen8r zm7vo^Lk;U~6N0w(s4bXEe_tP4f4(uI2(wSV{Q@N9a%H6Y35*DFY_T@gBvC)k87?V3 zezrw=2wrVj?c?8hb^Q}*R;W9p6%v)$H-K+9YDhKZ4qqKs+#elATM;S|6{5QlX|p6q zNd3qzX``Ejr)m?E1)xnBIMikBI_A=zAsel#U_`2vL`BkP3jWApn(m>sx-2ZWITII^Vuz}8exci& zEK0(h*7D6z`TMbZvwv~i;eT=6xW72+>OonLKPJB0jo6E)?0P)S0Gj`T#QybQ+sSXr zmi!hG(4sR~u!B`^n;pD4y`uy3RKz;&+}5DPR$A2KUVMEYSk)Z73;FG?+wyd7aAbIN z8D~qTRsONxk2u^6Nb&K~MdZ?NcJPrvs6vDb6 zo%sHM6J|uK8HdN3V=CX^a5EJ-SSENS7k9Pqd3uFe2|aE z3k;BD)#ifUh~5ZDMWsTDu!67b{cem&mD zjWJQCKHmM$u;MJWV|O)}_*|LtZEci0VBU9E?f*5|7lkoXraJ6yr~Lm731_JTyQ@t^ zPi0Ec+Gv#Dshl_SgIp)J$Z9Q2B}@Y@!Fq$w9jux+YvGyxF83F9Z6pcDEC;k!>x?}W z{>Opa^HibUKkoC#&#l(kdvbZ%$P$iy9nhv9coYjizw&t@pp09p9o%heYc-U)Z&D{%dPEN*8dsS zD*xlV&?=74XAAgoj{d)1iT>Y04EDsjmbFf2QO)N<-LpScFctH?H3{P2eQ-kCeoTnw zeLrfA3&ZA4RQJY+;F)s%Bo_Uus(Gs#O4GBli2YyYOnjr zvJd9({H8z={1AV+|EZ!RZL$88ipg@2>S(oI`U093PP`w2-WZrB$V3otvLbBbNhThH zmA#Q}EkYBsvZf0;lBTlmwdp%7WMA)xw*XMoN})?v+=kX@TxT5 zoe~#ss&IYW>^T}`+yAFvywd2&rPnqJ2VXtazApv9ym+L?m#&XC7Zw$^%$6%Ld6tK7 z$4L#f?>@X}uXL>uMJ;(I!R$7QhnE=KQ!tp!cz_L=y?z$cDy1fvTNBcE`J~cAkF05) z?>{BgGm>M}Z)9K|)n!>_1V6MsjgI=BKG^Nk)3tyVN_Hw z*=05hqIP^GzV|DW?rUD%JmoayQg}jwjxq_JooK3utJkbIwJAA+=HbW}?B+xUbr^Vm zI^JVuU~Yg|yx3#Wqgg*_vvmf;!!o`QC58bj7 zS+Lg7AG3IizBTM;5_&J68(KFTA;2LqSpDkmt!KJVCEowm-Woja(9_#9=;*lbur(NJ zd+)kiL~*^(0KyyDDC7||I+<>RC!@H8-UeB7@}-FAM`bn}Xk_MRwip=qXw8;c^tEHR z%d^H%sEkhr_cW1uFV&BSC|os@cy4%FOW#o6Nun>MzjJTP_qe=)?^WfmA|BFavDLB4 z(of=K@8i;>*+M1A`%LBBC`ck$-7a1Jph7}7YTETyF26Y6ngF>7&Q>B`ij zFzXk`3F0OzBdC(?pNw-_trCl0O#NOn;l6{By1`*ph2MaWrH45oPPZ2NU#V zz;X4hvmB9gZnEqQ!UP#BP?Tt@e=3Dn-&{XD^UIBAJ*cZNL!pY0PeS{VoVVn`49U*l^Dhsmp0U?cm8eo5`XF<0T{Ke}&7>fUnvA-uB<9e?mb+k)6b-c?3 zaqIyyrXYB7lGJ#QlZYX$zo=}Lx7dq$9(33EZEoGqy6Jz4Tz)J|tFT+XZLx7$FAtZt zXUEkw*9|_JzjAPE2kIne$fDmRs+=5inzZ@%9|FgYsXs)kTd7*VGw zos39{D$WUp7;A1F&^{OL;o$ER%v0rj6VQgFC3&J(!nFGsO}S~V`mA@aTZIVb-rUxQ zidzkl^FRNT#v^uoe|_M}PBGPwpWjqIi%yB|#H!ivDb2LYXU{>u{5hU!XrYj^Sm2ox zVUVF{+0mb*SK;hbFRhxXaEp8HUf;~O{`x5H>)f*3Fs?g_5TPCmO-V|F zS6j-6x2!(2uJ5mqv>LlWW4Gvsq4f$5nUJ@}?1;Bzbqnj?UGO(8jrdL9nzI+w?ad?o z%9zO}hU=9|Qak*kbsL4%hx}1*$u8*`FZ7Nk@G3mtr3FuAEg?2OZXh;#$oqb8l^lH* z{YsVnm3;gf;C6{Hz4Hm~OEdNfrSR&+_Kbl?zcU6OEiX_VUp%LT`uD;10JX@zh=uHEoV=4K_J01FaAXIYrK>`ltVN7WNJ} z9hAI)K)WYXC-Yr~av|i`H%Q@C&qRrL=O&>Bv+-w5y5nnq)$R`{E{jN?lIDTE>9v8K z(KI~Pqn4R_vixti;n7;p#$teAjP!ipz0>7mml@>d7@KkAyemeLSH1si zEd1dKPcT*3n$C#VyODsDKQ_;^!J^w2ve2l@f2A#Pc`>F%&n00&dB~k-Jfl|c4R&F@ zyIOBlFFdh2QAFjftiJUE*C@NIfnkZsZ;29<#cTe2w?m<_Ovz7a(eLkUN@>-fb=Z9FCb67(papeU zk=WXDb69m)+m_kRoatPZ*fsF2kpJkr59bs;9^nHQ5hdJhJc^l2fnNBnX%N!&uv|}8 z@Q2)5{Ol8t284M;qepTv&fjAX--b|v$}ErJPs#_=X#WKaf3Wue0Q?mI00RI30Pz(7 z009610LB&o000000C=38k9AZO>bk}Wkr0%|p+Rs&qy%JWR6;_K8bC@)iJ`kUNOwuM z!caqps_BG4i0(rpU3DE%W*l7 z^t;>#wYPSDO6@o}Bsh0oEaZ5&Ks=o1{P)HvR&ls-a3~!ZasFB4e+w%P4#(dS&L4k? z49>$pHHZuc2lr3^>wV_m*Q881I4V#6$ws(1tf_wv{&d-ReA{Z93wewpnG$<{R&3{DhGVtLkbuy~c(*IDD6I)(7)_!@*ikcAC_H7PIz0 z?`DTx<5S)HfO$^hi&YJ5@SiaMI1-UgcKecN`Ta`A%)|jkQ0F{ZPiC2PTuGzF#9EMem|D62%10Wu!(p6^Nho!tQTn8^h~kg zR`+y42xnqFugk(Kuy)aIB`#YyO2YHqc!JHXYSjl-gfaew<8(#t-iP=q%&3X;V?pNl z3h_*z1~`z3gxGR0>EL9EikF_`z>%||8uJYSJzd#m=k|l4*gKCLB_4sH58yLe6O_!Y z1xh5>punP^2~C;)2^A_*8FDe!iw>~D-U;eqW`{QVCcABKqhq~f@w_i(T}b)wK)q9K z15>v_0$cVuS&_Exy`~FwXxK*veaL}C$I(-rJM%-{hRvT)#K8O`{b*GR4Qj9Rt*SR0C+W<8*uh>jix3EOileN5DRdj8m`ZZo$cFO-{t z0mEY|GQ>};XW+CS;r-zja(gEArdi#vzFbxTkdQ%E%ZSiJ6Yiq8;f78PsD`0;MY?B3 z?La3qz2}sAL~u&G{ds7ITCUgCcPXEbuOuJ)uP#NWbdVmdhWgNrG2k4@&vs6Hpr5f^Pkw7iS2rthI4l z&B8|8S`a1~x3t$fq;h9O5O1jz3@YnxI^^F1L9U|sK8vIcuX5W&bGIZf`G7TA-ZZ^A zjKSIs3Uw62Fwian{X=jK`}eiPD8c-`s1n-E1%O>$r8_`NhEV zrtjT87~jH>O!}MyKo6281losqY;cj^HdPe)Ev|Z!@`u(N zCuz9H(`y2Yx{L``+RUm~-P$I8{`qpfX9OuffC!P^=UO*c=o9h04v}Ymh5QS*XTVgw zrf1s9L%mqAOqMiS3 zb;VdW+8S=rwGQ!OU$&VMj3(btd^vn*;%qr0NI$(bWvpkSu#_)y6^do0= z^|fJ$H#DL4D*C)Q8<^+!>UJ4+-2>yUz8CB6IsD$a)X5JNm}(U?j-^e75%gY}4$$s- zb=*I_TfFz<1omod8NTS4)gmI_x&<<@VrgV%*sOpsLqPb_{VlmcE%4^tq?|>?n0?S> zH{=kFbx>Wh`-$-W$_QPC3+qE{bo!XQRV-smdq9d{$91Vf3K4E<;rMgeUQcST&{D^` ztX5)&qN%mpo9zlic-~WHN&e~SymLrIb}OgB<9jd;&o?1w(A$r-z~sIQ>`hP}d~PhE zL?MLlN$sfS<^E1K8}Z(GwYXms?i|D6hHgWQK*l@!0Ut=%&MCCP=WcZA%64wS$Ttwo z?Qrhm+aBB0FYpa79N!F2D>w@ZAu_W7B|bb6@cuXqkZ1B*TAS}~2+yIP?p|{wdAx~r z0|!IEoK<4a7*fzu4#8uZirlXN=*W` zigZ8nlfD4Bg%9?~?K>6{Y=pQlr@t0~GnNL10Jm+k1v z-F22mF&v%;VcWRekJ@B%$A+YN7|ZkH$1@*6bxM91Phl#<;19@p3cQhX4T$^dPLqaaPPmiX9 zlb*`M+;~F-#}vGt6>h5Q8O-Dh8uzOo0+T*KvDXgPsXj|X0my7x4T?rS^i@t1XMh*ZQFP^ zx^d#kS(P#T8z1lR-VM+5S%BUSmYcJP4K#|v_8~rHoG6kr+j0-;uln_|H zCUe3oF@1gd^t)g+z(*%g_WGEjXuHh|V>A%H`qSTpHH5CN@RGkK=xv2~IH|?v<|gM# z3tLj|%LF(p4E9QjqNOsONkd|1JA+i-xzqh6>v*dVWVc?yc?zgm?fsofp=YV-EqW=O zuDM(OJU3|}z&4Nbp79$0rsWeU2}wv{ifeWN0!f~Y=69MWo(DPb?= zF{L*zYU?!y8KP11cKs|wb-@}&xW4>kCx{Iv$r64y!T7- zwSkjOSQ;~6#{vdy2sRZyUr&e8K2G!$c6n0)ey^{hzJ~z?tjC(2^wr{@O5!nWoW4sf zopnJ)=}>Ree~nh`d5tJq+gWo>Sg!_cWaNE#G1N&?Mhg8% zp)dBBP#OiM)!qH^L-TL_Oi^_2G?kY)ktMru}YN+;BSTdz< zky7B$O>a$PYw^K0^K5UWf5Tmxzn`B1x~B8ir|}VJE&jx5-(rzN9ALaivDN120r|`F^i#Vlb;LU$GnOQXa8XgHfh&={*9;pPz<|7cnG z3|(l<(03a;xZY;S*>~00o9gaP$PhJ6eByKsPf>6q9KZOxN4Duzrg1UhZsM1N%f5O& zCd~00e$hzr^_aW$cF;-9N3|4@E4>mzOv_XTaub?2ld;)@<$2hfd@C^-yR{)5<9Hn- zE!xYvcDJUua%IOchN_7qd<`#&7>hJ#E%Zu-8S6jCx&T@^+;~&Mv=2 z)hkr{xX&XDOxK_2cGpjdO-Gu`vP`CxwA#D;KH}LBnLJ{i7WI7C2#nkRY$RXhbaL2a zu_67KZ(WR+3fU%KQPEi_67NU8#s-%h{w=+LFnQdy2{3F>PviB6?$R%B-#)X=mt7m6 zfU{m%5WJLyC%GmIT@1nH#isTiMH4poE8mnob1mRmp|m^U`&0?!bVdnw2M#6hiSQq4 zc~6|yJUsY{T@)AJ93M60`9pb(%J_G3N_$omdhaUn@@Yy5)O#7`l=P0I54 zAomwz+cihy zK4Sj!4f6Y!s#yrZ=eTKGIT$RHYGh;1^ArMPbq5MI29y$S663vlaw>|05(xV-w6+61!V6PODxbh(vE)5109-6!ILU>`8>HXZb&j+~g zCNErukEeybPs|v+gL9cPAK>y*z}w0ExRqu`tr;z!QyM{{RqZh)AHol0*#S)pV=o>^uO*sU5fa}RC zNGgL^Z{s670f!s%0SO8A_P6mFhq4Nd4CXX@opi^r1vX0l+=(&)e~Ne_PCF+C$KZZtp=T{iFLj9_)Gr$YV?NO29DN<)1@u-2*u@9K5Td(`J{?3+t}ewrEBq z{XxC%IqR}Vs>`{isETo+#tggR%I%6xlH0Ep!9U3xr|;SvR&;f|8|mFAJ}yjz!|;H# zrVpgI2=#3ITL@Xo=6PyE1c; ze%k;y&nrYj?N_T9$kGS@`=XWC?}R1gU`vrcM)}8W((2wVyQR>bUxw+wbi%QboNoRh zO8a-Y+M(E_{VL30vl9Wx9)=lgs22CX_{QKTUE&h5<$-qT7ujq7aVwfvXrlQ3Vck|R zQ)l*j67gWoVC`WtWs(!T>|p71CRDKP)09GVyA~^Ke{|o@@}0rx&K-9gO@I)Wy%11M zh-3e`(C9+Ts9HMl7J9{!YVO`efMl+kWvk?p5b*(?w@mgZu=Za-*#MHey>Fk&3Ld4Y zC9uWSm-(L%?Ei}0+?;d{|J5JExq_CY!$)Ls>7M!XGH#<<)(_{t*5@7+iT`iVTEu7l zU@q|D-+_28&@DHs2>2%iUF1m?Ly4%ySkUCzVQR9W(JOx$FrR9Scqi!WjTf6F`F|MH zIb5tZB9K<4r4+hLX55R(5d)KFxcvi(f=nNeW)a;8Uqj7Pmd*FbR4<+jrLlh5wK zeBg0KB@enE-)&{_r-&Wd{MY{&M4AY3vf6g%U~iN4pW7^aW;c`Rv|n)2$6V=9U{NAPo?zZ z=NhLYHau)*V+D*I*L!2LALY33smI>dPw4)Zf?Jt<`K-_VK%ytRag({ZzHrCItb@#u+hW$m!&xRuRWX{$B2jVm*m0@CN8jLxSj zprT?10&!OTZB;uN3Ac8ohZ!S%Jj)GH>iXI%yDe%t(bMI7UB}JVD)SM$Z#$b{YQgHI zW!EDvUUG}N5ZfHxw(+__hE%6(8Q@loYh0I|1>`)7ZHvu>-w zMmdfz>MoIIkg=$3vY`k9gL8w8#sMe2g?m55(^UWb^`0dR>aeYo?YoQLC*>ZW)t<5S z9#wdaaxC0^hw*Etp_UW|0vmU7M$rFSk64Hac~)I*kSscdPja`Zg4Quz^~ zs-eg=nZ+rSSX-3f@$IGIxHgw|!N=q(J_;UdHH}Ke8?e>K0!Z>0Pss<3`2vUJ&1Z^s z<4Xl(yp%>w>XhpReaZ>Rcm_Wjt(++%Qbc*Z4DWsC99JgeB7UBt{UWJ4fn%m{STt$u z{eTrvEaS%xm0K32Jyn5fn$&MGmtDZrL598t^7G`~??g|Z22?m`o?HO#-$0E%Dc zKNnT!1Zuey;KfYltFI-MXmTxbsTL@Gv$mduY3f453hR^!Sc*Rvlq3(>QqL6=yl+Y& zvC|4FJb1sGouA3cr*%FV24z!KN+oeh+AO9~b;=@m!Zof*Ca1MqoRs$^ZM)F9Z##1v zj{Pq*6SVpO003kF00093003G500031003wJ00000004NL%l48NU;u))gRBfqGP-9O z-53~HfPBUTi5N#E1_%&gIK#onkSWISf*HhRgbFheZ}b`r6d@hfWg}|E2W} z6U8$qPMsO<2;)(V3mQ<+Ue~${W5{RH8G~U)h^OZ>Fe(2YB2eE1cMuc(@?6 z_PQXi*>Z%YVao^R5DRIW>eJp&K3#uzK~qe_DQLZ!FW+7)ub-JpeqQDsA6HB1*8QtJ zYLwz48M;f3@6c4M{fW`+;bL^|;t8G^k*2?W_tc_}_%S!pv!#0^Jg}$_mZo*yX^YfS zR(PNfcn2wqF27g!|C^BD@8WO6UAf;0A~xO42Oacn)Y$t;iG;{p`&NjAkGbY}kc6MP zudfA21W0Ip5#i@_4DXjo!K|Q5?RAO&;2d;>mI(+ zBht@r9-*E97bx3@L`%-{3WHP@nzI$FJ_Ixw`dJ`K7ANr=Lhhoe002-+0|XQR000O8 z3Vb{^kIqq}mH+?%;s5{u8UO$Qb9rrIX<=?JX>N0LVQg$Kb7X9DX>%@OVRTJS%L>9U z5WE-q4@>U}A|AZ-R1t*Mg1vf)%~C>>G-Q3{?~T<|VPV+Wd2BDV1|vosF%YmG{S}xK zM32c!2-D3k3)5&}z1nPnNh=IOQ60-}S3`R$J7t_kXizEvwYqrW15|CfKNLVx^O!zk z%+Iqvb&{f)b>r}5Ne%YRvip2Uf{4%LU-JH+i}uNdpO*9UXY%X?P)h>@6aWAK2mobp zVmAHAs`|3Z0|1EC0{|TW0047&ZDMI*ZZBzWb97;BY%g)iqy5b%GRLixXM0(s;#Ye8zD zO5*0BS)CO|xFpIM31L3fk;p0_Q?CFC3MOJ@5s?IegM)+FP|;{0qobogKZWdu5y7nR z?9;K9P-`T<%!cWbZxO~HLq5ptRlMS%KP=M58b=E?kfUrXW7j`*$Ht8IQbHU3%0=n4A=a{eL(QM_h zt{*d@5~)BE!B9iVK!7&l!8SOQ#9=8cn+Qp?!~`c3T1@BJ>pz@8YbroDgf|pJEB;j8 z>UF5)`@(GOfa&G07yxI0w-Et_fMVcLR;V_pb5g(&_0ir; zQ!8S&q}T?riFebZYL+~aukxddQjYMIzzY(?Amz3H>z7jnc`iNH1uhsGM9dPBNLWko zMoxK%H`2xDw6%j~S&Sw+Umk`R9#F6GU95H{s!EvPcsX=5y(w`)7P6V1(T8`8280bC zCV!JB^4X1OGEG7l)stPNL2_`FITyVgpMEv?66s6D3&yWTdbUaOeG+pYEDseCVhMaj z3-r5to{Y#W~C%^^1^ZGh(f<7(DC`FHD?)YhK{<yNjU=)n^7)SdKX81cWN0zg$j2WI)DeO=j>7ZM)^5hhk#2LTD&)q z!|?WuQ^!R@p@(ffXPn(xyy5SZm?SRCh+kd@8Sh zz_>|i;+Jw(cAR85=S1`wX!RpC$(F+Gnz^0GW&8J4kbNo5?sVyqr~c!FYNL<}8lrJT zczzKB_TiupeQ@A9J@peLN~;N~{$AZK_eGX{qU2cMX2gb^>Ni+!`HQ@FKi_DIOmdC+8kXv(&-hyBS9EwjTgIv3D~)!o zC^EC!+27YjrLl<4D@UAwjO+L1@OeRTAm;h*_;WJg=0q^s$&STpJN^OMXq$8-e&pj1 z+Kh;&rVAMdl0R!U8kS$3TFvsU^uwnr+k4+-nV5pCwu>W5iB{3(vw|6Nk43a~|7mld zDxlUA;oz)(tE)_9R8KZ~nR?MpXf2sRcq~3<{uvJxKfA-IB>6PXRCK8e;J-d#9-%1P z)YD9ur2*poq``feIaYS5^OE`wzff>y(<%bXNY~u7>#Eepo9VML9{VbX5;N2P9w*3; zKk@w=MH8M5m~O*5cDP}$s2l6|4=wOjg@&UzF^>82Jbf%2@^PhUt+yR_Jx0a6jdaIR z0g$toyBoCRk$gq)HX@o&5sneW+uK>=r=wisnEaOA6b^;_(UfyeISV@A~9W<7VROH;+99 zq}Pv5LloQNpZ^5;D1)clBlt++blF>R`1$I;?C;kUor~s$!qC@GWH0}h&8CEJ8>;9s z@`J3PykzgfLeU;)r@OxN*Kk;IDh7)QjE}Nj7sgSx)t-4(>zg`#u&22(K!<+JIeZ+6 zwYmF+>hh~UkG$#%MG8pHQUi}w&5q{?Sz&!RWbOT^oVQYJVYh&>O*UuyW21 z*{ZIibV}e_*IMPZ>L+l$yy~(CXSx;3n^7AVMj#HGSod8#KwiDj_;8i0&Ap>cR=}0q zb*1s24i1NGLd^!ytX|*#Gz$tJ@`<4E8Z7TdHl>b->hfdDQ>@?6Wx#gGb?Qn+bv>g% z95`tsCLA7kUUxx1Tfc@9v5AZNa2rT+GrH?eBBc}9H8?lWY^DGhzNUXXepk(O!>*v! zwf>gwtv=61+9$<^pY_{)+*K!*z(r6Z*W)W8FoA5c3<%$LHw=1y-cnkPxvi&{-(s?S z(9D+?&}=(R%4jBE2up8dxP_B4#PN+*bFWs3_N4u;OV&!rx>CrSB4Nx_`^A5&`!e5` zFX?NU_iBR@7SeRJGJT?(Dt)XXQkxE|3A~qR3)Q<4p zj^9i>Ft3E5&;ly#)tCBz%304Q4Z5(Tcj3NULG#Uk^=B?lyiK0LGh`0~8;Hk&GUwFi z{SC1>0zFW7Lf=|)@!)#&q?CqEv{PYCB-@1+I$Wp59XSzJ^11EIj_1`;E-;gh7 zs@uop{1~mh7cd)kT~JUYt+A+vFvXYUU*C?ZDUbu zzPc|#!w^$$p_~FF-tPQXy#^YtLzuIn9i;49Gn@}`NB>-OMI;h^TRO-vD(#~VSkW>K z9O})nYyB~F2!$UH5P-D&5GNn`;COudqBA!`63g5=SM{wGAv$xt$5;0rXxrf82^D~%#)2EL+$y&c*{sP^yFGA zjT|&gKWgH< z=yz;TCL`#nYTt7L+T%ylDWJXZeM!EZqx1|td>oxyLU!_R9Ls5(P;)}&Yu7qd>3PQ_*xfvs%U%aeQ=qF}BSJzkUp40f_5xlP;+ zKUjHNKKq8(JYCGhQP<~ipSCpzS2GUV94jA6zp5rFC3^)m^TA4+yJzLg<>s`~+241K zwrl5Pqb4no=KQVon96D3psYlA`oh4Mi6Vsp7KxBlti-LY!As{Tt-mBt*H@L^nlf&X z8`y4$-{_?8T-jFiCCErymgd;Jr!3Pe9o&-;%l3+U^E!kbCYVlsS)m=9+eXxLuVT<4 zuW%dbk#^y36e$^OwCi|jSv`rj;OUULNXoPBU1oWCBRF)R4Na>kvuxg%nmXaLT4F0H z>$&#a=@6w)DN*eBve%MXe>?a$H8xWgNV3z(Pt%m!RY=CNUsR|6SxDnG9=9-<=XG2> zc0LdN`a113nX2g_%iCYF2d}HeVu=c-004Xt@^ZF=*u z(cY8W)I9E+GZOFh-s7~%D|ZVqlCAkUXJ%sa-SZYv{_+{^Q2T(at$D6s)h2H;R>2Y) z&ey5Oan7|}@LD_cGY@_)AEM767&?_i2#DZ6 zZh{&E{a>yE`cDb}lef|TYv28+ME|LX;s5a#ui^jkmJ$N+|KqKzTyLEe(~n<51&sn| zFi~=JMZ8g!zB|SMyr~o^<*B9S1{-bKRvmbJq-o*vf-EKV3lW9`0q~Pxg!Tgavby4e-ye*I3#iFpzv)3CM`x5^@?X>YpkTx&C7D8_ z2)dz&rJvCEhPk2Zpe8~IbV?dUFK8p7&8RE?b}>E}Jhh=N@EMveFX`bteWMC4IE6i| zG!hc-FS3Ppr*lIMgAYQfOL9YZbU$H@M_W@}HQ0ZW(pF4i~V~5!!e|qGf!PK42MOYhkem7`JX|nozxYhm61RVGn5d@JpOgiNIR<%=#EcF@ovCqN3bydO;6{BENZw zf2|m{#h{z*-JTqHQv}a56U%2z_w1qy5Th=Dqx&hV6T=F8=G~>#0SU}w5W>D~@7VId z_~m{=CA;%d4n1KLH9e2czInhhC4z>`=yt;3fBA;A;PZu2%g2Hv+80*mm(6i0B6-F6 zOId7|)$ZXRQNvxLGsJk0i$h7{k-5YmpmWQ4OJNZZQg-osHq6ALU`FA3;*;LmPL861Tgw7DGx+ni$U+~;Da+tru%)6MuA zLMtqzQ}O7W(NCBjx&)Ymus$XvGBro zkb=vh6!dnQ%%{^czqm+`d4K7C^I*WIb7+USF6=|1_1W`FCGygHd4M+b#L_OWbCNNmG6{G58RdWZC1R8JH;1JVYd@MByxEqzfc~ zsgZ#mF-@{|tCLqWF9k|->c5;Gp|bo>5t5}I?0w(Y4+wt#Weng85bsE)54@Ccwa{Wf zqdC8gQuiJk?j*p=MGv9cuUJicavv~x+?C3ria)%Wo=nMR-!Vc$LS8<=fIwyQGG|nT z^)>a4G>#XkWXo7Jk25X3XHl#qs~}by7rsHW zDxp7m5-W6h$Lq9x8NBN6fKF9CaeNf;jLGxRbfy9a9~nCaVt!;A8cRf_{2>{U=oknm zrDWzz9N}#gGfv}R9luGNQo@lr0Z|rgbO<|=ism6La!~e*&V(qb z_$g+La!j|EEV1~zr;}3A!{N_|DL;$LVPcu+^k;k#IXM!QlAmH^DzkSgXDndP>%cf> z;d(P$g6qDKB=*F0BWSD%V|)wQjx{3&UbcU7F({pMA*Z+k`c_s}{Qd?>mLBZeMfmR< zO8gMMD%tp{fLOATD)xfUcKGt@1)k*!tNz5X<<$TIpD&d!{QliEOj#XGRfW@FC5OLh zg-@^|69yv>qS(Q}qrl_K9Wp5a?$3a&!#bYP`Ag|0THB6@#luQ9Eh8XZ z(sP(8mmKwh!WkF|A+9W8+<`3{z}!*d9X;lXLF_PnTld+X`sLv!+!HYA5#ka%J6AS}cw!&C&*Gs5 z(FyC7#Jq!$;JNxchQ0qZp$6(!KLuD9NG|*&CKcK45=#21nN#U=zxPf$$jlqI_X-7ngUVG-nEqQwK ze8gH1l}*{Cs;$6TSTOBHfNlHxF_T!nX4EB}rvZ5DTKv4MzgXo}3KlGt2k=1EoS4dt^g!fl8}z$$eBS?fCS2gSBGl5?D!_u9sPX@kAc`S^kT%RSsyIfj7sBFQgN2NY zOnB!_81c#<@fNV-DFQUxRs8kCi*b&JQqP2hBbX>Zb-3MEK$!dlT#_JAVEF8*BtO) zA)Y|<1Qszxjo2lSJGX`yzEi}TtkT>O!-_!b6nJ<+Af_q^;u!MMsf~{Y&D<_Yn39+^ zJ3kt6T0;!3*9mFx9e*hX+ouXQ3`Xg{5qCL7i%@#KLEdh4|DVn`P_Z$=%5~`~<9OFn zktzWW1^O{VlKr=PY`Lc~^1Z3GZMjxgn5^-1sntqB*lH1tVS4%Axk1-zM zE-WM#-!p9Ic)L=q?LnaL5s0!ib`KpjGW_{}&!)(dA{Q#H5_)Q1w7?&_g=$q2l)z>eB z=ilOWzwUia&u41s@E9}ghSNF!A!s=Z8K5N$iFwgy=o+=%7d7c89Z6!xkO!L*ZaAL=!h+@^V411 z!QJ6?fAH||FuaUA!~a=zU6HO3p_1pH<^T1y2<29y(JolF==mtMw)xqeAX!|Z^ZWMu zy?dz7_w%Oi!Cb*COwZ#;0ao0m4rq|*Ue6eT;U;+;ph6js(N5_XLJ{r~Fxmi0G#n&2 zW`gq*h@RVfM1t*0F!@6Ee=M zJ3n8MV53|#+Nd*Jf4)`E^LKV25x;+)sO|mnBEQ#=eC^ST^vK%ZuYc$( z5DY}SGMg)i=l`%s;28FXgDc>jX(Nk6>7UB+Yf+rH(j3s6&kH7<22bp-8W0;7eYbw9 zHf*(n2ZjE!Q+OYvJ*un)A_S)T9bNCc5EeWceZCa!4)G$MczEo7nCzP9Ih!lA5zra= zF((sxocE^F@2R^Ds;hHv85L(_XOr#=Q$UI(bU20dTP9o$M?l9P7$%3B(Oy5L9~yp8 z%YM1uY=XpcSQlNNN>^D7aS5v_wd6P7`!gsPN?z~ZJ8+;mL>`rz0B@J~{gGKaY#>vr zQ(|BcF}64hDrE-MbWEZ_9zqc-h`10r0prCF+>10s;i{*Gxp&trPU}S~Ssd(IM$(xrZjs9?qm^ zgC<$v##Ytu{hlvUs71`kEyLOzXdn@IU$?xKBwqQAn9jOiDVP9+aTMY0zTPA>XPKy| zF0m^qYVBmCk(sbA!Q%W7S=lIw6Jfh@aP6+NN3?x6m~>7F}X71eVfYX1p{nwnKG9nhWnWai5|!+$QsvUaMVN{>cyKKI+quAv8oxah!Ss0dmE3;VVa ze{U5pwB0~u%GE6_Eb!U_kP^0Y$IQ3h*cpGafvvKM5JYAK$nNgpCxUXcMZx45!b@ zVnly^RsHMsPF!keFsr8qDjW9|%;=^1u@F4xVcTrM=N89?)7i+iZmq(PHU&-p{xc4z z0fB&b_D3Y@)${2}*$2ji2vY*0J*NC>qqTOLe~T#dy6Axp|2sx&`KZGzu#6EmO&za} zH@LjIyW`@S%UfQb4#oIgo~0cnQZ)y(gvl%EPYV(VEf6 z|6s}>mx=TEh8&xqY6_~I41%(!FUva&v^O3PR>RFZcw*N7)Bjs{eR;Ja=&oG@&~ z{VwXVHD7b;KTb^jqA_W(vrY%-X5}|C`t|Hdgz3=<3O>fa(CaEZ^2y{fuOfyV>2x|r zxETZ@LIAYgE|6{zbY7CRsobXC|J#TKm+XzAtJ zg$EucXybGMkqUX9W>+H{!+jtCUSG##;3QCG4+95#?f;JR!;ADKAr@&Po_~or{rykFPs2c2*M0-%UaxXS!NWBkbr``eyZ7 zJ0C~7VBx&@%~(i8f-Nc|E+h@_y>{xGas`ynPWUPB9SJky;&&_(+$2J3X_gC!){$Wr zQA2hLID#Ck9HKZ_XPR#zKb_XNx`=ys$nk{EI#w~0k9rw349wQvsw;6U*&nT_LuEp)p1(vP@^*RA9Nzz;L-{+_ChCq|@13&}`qOjKC9x~R~iv^E)2Dx^MUGq{`h z#3Lsnj@JO5`Upu;FYw>pV&Wra;sfVS%S8rM(*}c30P*nSP3D!D6wa5aG6)z;aG1Uj ziXx%%?!k4)aAdSBgAUX8M`&6NEWD|g;13B6-NR#iE#FS;jql64xwO0)JsC4W3q+2S zh449#^vjhd1WowNey;S0nCV`h>aRtsGbLt>F4J^-*Y@cKHId<~Bx@H8XK%4`w(n<~ zO`lkaO364G-LG93xQbqjqNgJrissD-rhX2$t5bY1ACL)6-IIqAoFms>9_%17dp^KRFQf11dScdxgawxdi%g(6d)cD-GuD63^hMqP@ z>FW__R0{c@Nqvgfvw7nUL5!TqKu|_MbAVDLuh-KdRgc(a)L(Hzd0xFpSx^LU3u4mfLl=n>o_>ufr|Mzp1%A0{x$&LoeU<6 zPS|gLEL20sw%R&8K5g+CV_4V*=j&#p?~l1uFV{gv36m;n>(kkGbzL&|Q!EU8j|X<6UQM&~xOju?l1@t_j7gW;U8(1a&E zfeawvu;#9D)21*0F{im;kfhNx8cr^sC`%LJ{O?Cwl->MXkYwF}n=Q|KBZe)VtLCUT zM#iO!)`(-`4sM^fYknRDdQ@x*%q=8LA<*wvW!MC zl?nIbBsvd-wCrG0RLI$_ChCycp#9e{pQg=DE{yE)wYCV2k7@>Ob;6Ec;hE4V69z!m z;dX|OhR-AX9B+e*;gAhKwb1axS6EPwc)VTN3QFF?IAsD%9a5yc7x2_@bfp&)W0HYR z+gcqFRtEo>@kT2#2}(NqUkv6<|9ITd{wc?kf#!#YNd`rvG=bl1` vHKzn8tTu%^ zp_niu1RE@oA7-k%03JFxIAcfYE*6`$;z6Nu8eBeOF%oP~5EN{9?GOVmFT8Dzi{l%*>U6+x5@|aleWMf}>X+)uExBuJ$U?XO#&fQ0K zyrTQ-wj31;GYSIm@BhSL%;fca2(b(~E&vn56B8qWJ(4X!MT2CFm(mF1^NQ~C2oI13 z(Z=vhi|I`zW|r6dt2f%iBZ3^%5J-X8<$mjTTiM$g^xo+VBqN|bw7j~gLe9pNGWtN? z-lx|Q=~eiaVi}ff7!|3W9Y>&xz|1z;Qm>c)fCW2Y!o$#@jZn&k5jojxEoWfUBCmeB zsUX{eI871NpzG}BN)vz6G)a#>@Q@-AI-EwIFtKF0SW0lk6uS-!;VN)f3c z#-rRW%3yCP7qX22ie+UiLEqmW)d-UdC~OYIl8;_5hmuncq3Wub_MiRie&ye|enwx9 zhz-@IaihEJFJZO*^{ZtD8$(L-(MzHKzG8s{UqjFF9&3e{0WPf5}Q{{QwdX5>k=6^UVlptbHQDG)zwr~Fc9j|WBMC!2a*PCrz1+Pv>V}@ZH4Jw3BRP5h4d>%J5$12$9$0^f3 z^WFEewKHGBP9@I^YUJoxm_RNM2M}W>c<^;xKCiD-{sL?)oK~H7PKUuo-cYWj_TjR} zZ0Gjp9iqPtNS1-EI;%M8JhBvgZ3-l?`>xC~gih_W*y@1GN$#sKm5GU-HxS7y*hJXE zcQ^oxK>%&0IKg`l1o$5(h2X3nzmtxSyXr z5+Py$T0PYy7TO5a2E#^RbZnF|!l8~AUQQIk$({=56f3gyjo6=kou@!^-D*)C6DH#k zDs^UrphDMe%ak##iWE~PmUD7?PD2QgQk~HMYKU5xCvF}GEwGmWvaNPuhLKwPSZDL$=C4EK-<%e=s)5|_gYL$03O_U zD0ilDZsK^{@CzB;CwJg@y)j8fymsHgkf}7{+s{#O%GA(WlJ_1B?uq{US6E+PBU!4X zU7Z7(1VR{L#vw%Kg#T92=!tUoJLQvDs-h@B_5 z^+;%#!ImR2qrE#sM&8mS9%(c%OyVTdNQrWlKIXW7PFvSb%w#`woiCQa&BNGqcT|fL z`J{2+ZLC`fiBTq#6dZ1fw#wPU8Z(!`fIWtX4aN-yW2b1^x%qP{6qGeu5$zEu~ z(Z^8elTZs{|C|Gy=kLy;_iK%Ahl_oyT|WNpODqc}$m3XxEt_^@G)~-t&O;KpHv&HQ zQ2P_bDCS}YOL~6Ji1AR=lqe&R@Qu*22Cg0(DEK>Uo6GrtRlviUFA0`HB2p*Fw_aB%_b}Jj{$#>4rltW zb5>zWDfP96&3E)z=(3UClFCVO^f(CCzYKXm^@ZEl8wW3cv*Y`Td_1p{-DX1;pXfTg z2sw}UECF@m^UZf@L@@{Afl%zRw!I{5%39O$=k4v8@vS}?9gy(PLL+56?8X$kZiY#R z&(v0ENMmh>PD6&7&XolPOR9}wDG2iu@Px?)^|&FsjYgIJ)s$%%8fl-=5R^E;rJao? zq%T6;{oF;idP;N0Vh(rw%`y|kaXeVZ0_XQ$+*aD)O$yesKa_LIo-i!XsO!Sr+%(jT z$-j`P;U5f0BYQ8+ugS`S-L{1Uwx9|BvCdBjr+ba=FQ2Gzy3OniM7j;iR9|klSK=p& z`T6kjKwki?;(H&)P^s@HzOT-Bz+~&uchckQ*8H(Xl}1`5w(TyzswXAHNFmne=I)gV zRu=RhL13!(c7vv414MR&!7)0qzBloBGg`W`S%;|oLGe1*@nWoeWYPfBp*lkrv3}B+ z7-^ig@~Y};!q$sphxEPvNN6RT&nPugJ~_0%s**+#4W3Vq{I5pI(iWQG4d0)KFTs=P z`X}nDs)Ee#s@|&yCr9Jp-krW?h%;gb4OPFduxYHUtaO$@>9&&=8*TXT@%MW*v*4hB zZOi>Pk`|wwZI`l8#_LS8oTq^i6z z&EQ1QW;4z=hEKuK+QQD^uCRA7{6yg4<|VBY#^bb~gw13nR@9n^?;9Rnvn;h<{9jS0 zMqwu}P*C$goOtXx4jEW!-1P&Nrh2hN#g8=d`YTIiT*obCzU;df7{ew-t9BML1KEZg#>3Xkq&K^OGp4=R0>sCZNJHKtC5CKq3sa*J`tQU z$8_^?Po+ke6NxikeumzZRvdk6N*FJ-t5jbHsHhF^$mdPD?>}HS;wUn1_8@-pcNPXN ztmWDI$Yr{I=SK`XF=Y3DJqY8jPy`?YSJr{fBW8~(K zb@|;e;1WGADlk2PCZln!TaWa*C%Qrf*MpcdDH~EDB^Uz(VR}?_hM0rv+QLxN_gREo z$gtMhh00{CP5G*1LWAglw-M;;L~%NYRS)KBIw1H55$fv_BR9Kw?9_BHj_aFwBVf1u z1(zjJrj$SqtFUK|w_0rXl5(rb=)ygkHpjg(cDfl}E^JvcqIq_I4egM40&>mlL|6#~ z8wE>asWRhU-Y|CT51nkBartH3et5r*QIJ70&Hytrvj>tvLdwQ2%AF-?nUfgaNU8AU zNgRI|a6vGgyYB{*^!A)Quj)s$7LoDI-|psN8nC!aXA2sdCWdWfk=hG9E!jH`xy$~+GfjnNqy{3$Ia#af!M-IOwjbF_{u9noK!eqTGArgz-W z!tSic(6O?%zSgjcoHRn73hNVdQ%FKhAHA6|6^j@WEo6?6cF~eDXU@&b$^}b-?&#`z z)jAv?oku7oOf_~$+kV#jJZzYtnd@*V7joCEC$bS#^V6`T_8AGC%pW4^4+*^k zZfI2`(GFD;Jpv(7w}BXJpDW~cqcP&wehQ?*7H6!|xcOpq&X`O$HtzKKx*t7VC(DeW z;7()CbS5}dPF3nNaH@6ct^=0I8&2qF=dJyd8zYj|*FLqUf)u|#h@ZPZh>9+z%ZU3b zR3h^$HYt8N0Y_o&fCDD1lQ5FyjP2?UARM^{M8L#u=*AmmPWQP4=v;J%nJF@Z*dKV}8rw<0F# z_Bgb&NJ8MlWov}p>R&8H!k&;*9{Mjp!(mT}r42hFKD1A4fJPIi!_x+WBg|8&-|<2) z#!L*2Y8^A@R1s1H6Rxst^CgyO979yH#akAEjPYyOf2*v;S`MizJcx+T@NtUJ1M{CT?o&4Nx zzok?bK55(GT!$EuWW?ld^<6W3V`filW;!SkK$UqS9~FA9pv-sKPl_HIZden`?xpML zFeERa(~B{0saH&AL^b(KcS42<$=u=v6d6;sYq2yh_!}0Yrlt!qsR|LA>dX{Jus;yG zx<^`0k$wRy&Pc>UYo!~=#K1r^LHn<&$B$~7+&dM1Ix6a-)1ZGmd8zNpRmM2Zz@lPU zV4%l5NRWBc`C_TimItz7-DJWLA@`V#tf5`5Q#<07&r%@i{d~F)DZRzkwkT2*z=I*p z4mx>i07Hy5%6l?pdJ%1*Gp3s`Ms^vlH+D~)36J}ygo(}YL}nxuAK_%8M03jwmw3-o z42#aPnx2rbidm3x%oN5rk3(3nIk&opw6|fu6c<^OMB2>d%2Y6L9xD?Q8-2r_3Qbvc zKQ+|O%wlEEohIzXb^igX^J_d2R@!8J-9<)vzCyWj%m7fM)%?%>mR9}Bm}$zOZ+LL} z{(XErXmpzEapUUj9IliUySE(Mgt;_b?vwu{s(<^D77zUK)XdX{j=W*3vc1`-UXQBgQtZAm@lm^2%{y1bl_yU9v$ zxZAOC&G`b!`A5&bNAiRuQdGu-(eL13#E|I2@zJeaBWA4RdJqrcm|1C}$G2ADS4hXm zn1jdpy^%DnLYbohCI+u0Dc zGBx!yu~u0LIs@XsvD@bE4RT`FhN`rlPiSxsF(E$$esd@rZXVZXu* zjd>p#6?V%6MNY;bS33h|Y_^JT%XPuiwVI2fi-?MfVL!%*lp0v5fLqiJ(gm6cs$$Vm z*i?|Fi|4?ax-h;JKYlP6(;BaJFtwPR7uhOgwoTb(Mnjc4n~xHR6$Q2VV2{(WXY~cZ zMV$cJ8jXfoP%t+c;Q}-7j*?L$V4+6}%R~rB+xv7dAekBWn0<@*vOw>fhHFg*ekg;- zlhVxCG!`FRvcnKDWp@!qGAA9xPF}8&hfEhs-^M@=f5yVfsf^J;lgCCWSjLh1E4FQk(0}Uodi`xFl z%tnref#3pn; zc7pnYka+#bjlF{SC{E+8e8G@7E)wk684Ld7-y(VP<)R@Y4++>ZBna!T(tNxd{EL}3 zsWvoVc2*t*$W^OqJ1S47+;%WDaI)kL>x8vphK9u-oQU`vBl8ab{;wpVggTWwdf0#w zXOVr{XP;^GK)S&@yeLQ2hnF25fxV&oD@|NX5fW9Eu?fh4D8tL4(2|L)!A$4pXoCC- ziDy8g;lDkPSGy65uN|X(?{DB{E=qkAt;zUSrPSZU8mm^yyv7c02&c)~F zRxM_C=V|hKPvVJwgqMX3wS!RS0(J!*O{GeEwXmn?;%Fcg_Azl7qs^(_cwcAC;ALs) z%CKRdPk@{m2i-WgxA?x(`|E{m&DpKF9=ensI;^bTT@qlMIb1*{?9wh0N%!I8@|3Wa zj{lGmtylUm)8KZvtOGK1Mb3d~%Ixz?cU^4)j=AA@oac7_{Y-4#AR;D)LxP)SLTVrL zHOzITJ@{>89q&inZ{u}^S&BiExQZ_FJUtObLrbr#9)$Ly8ZN$$XhQIFQ-4M5HCb)PGc!7h1eZue$ElO}%+I^h-op(n5#5PY&Y27C+pV$mwP{ zO@xaG9EMFURmABaL6*z$!_%;4#lS((9HM4b{ZmVC{%RdqWKvxiiJIoBpGM=b&59rs zJ4q79^pL`yj`37=AsRHdW}x{;lm*VJ?}L8#LHSfoN)d!R$m z_3|T6IAw46X*wg?mWjZa%hPI0i(!nC9==)!5$0H!XsYsG1AX>R1JV81k{E`1rI*{&x-aWR(kFMH*-a!57Nl4?~Cp) zWPfm0MxM<{sPlcRGuKGFi=jeCL48cA9>mOV%-FHLe{!2lv*UOP=!iPMtaVa;%WZi| z0PJSpf`J1c$an8d$va;-LkCsF9hf*yY?U!nqpxo9%WTvpBH**pf(cGZgZg0|dY<7c`l!X<+y#f0HJ@A6^BY;|@UBP1Yu2Do8s7KBF`bY#>FeK*0cY z*|G`@8!zDdab6augK)j>_jL9G(eeVq2iMMz+n&<425&a6%YINS?&lnrF-8VZm>Rt8 zp*>-WGX=N)nE$LTXzLlsoCHf7wLuuX1}|A#uJi%G_2_pS2G?i_dev{4AO5;_mhU98 ziT+zogolT>k#kvb+SovWmswFbs*h@*GpR>VkoFT59R`7Hmrz+FVW#ZHqtR;UF6{sF z0>bE!VNHS=ae|X#ENvpters^`J2;*F_)F5dW zHHDr&>ICpV^o()N6hmKcvOF_Th^Q|`vB5$^nF@nnUM9oRuk3%IWncV~o&R`;OfpqN zHx#s$4Yq1}zxgTe0!bJrIh+MSaPkKk+?XiI88?s9;CHRVJgP6cf`}HZ*lG-)jfLkG zsi=BIZ}?JmnKff1Y`Zq_@OUs})=OG%bMec7rxKu(OQTd_XWZ_&+UM;VcAb*)M@X}y)g&Y3%q%7Xf2>71wFj+LKS(k2b{9S6cUOh7~VbpX5 zw{f_A^#7J-&FI7yh|cahx3@;D-#1TYOqV3p0R$`_FOx>3!5KosNVQT$PtoMgY!pPO&>`x{sZjY2M<6PZW%Zxz_xwO{VE{0VKt;LnV4gu=YnJe+OV3b*6yg+@IrCt`vaUT z4bK*cZ>AiNg_Ic)m1&C6vC=ao%B4oG$q!IE4>HY%p3`P@N@cUz!{{USi&Jgrca5Ad zhaq%nVtTn%OO!JGT1DJi+eoEZGM21Ti5HR*3jPR&>5R06h>6Z$`T1sIZslwG`(b#c z|Esh6<=n}MqD`;%?i)5JP&M)9#8gYt-E42flr~Z4FH5=-Bx`8JXl}_YcSz>?9kk6w z7p@P({T;PUoC22=&tI~$&WFv8GA9fO%LrEc7XJJv%#BPeBPRjU;8 zE>SN8EuyhO!2oO;ec9b4`2^@7V#yyg z?U^%G5jWblmft*Cem zo77AC>$I2+zO7rWUD?o#LD(6O^hW(VqK$y8jevM`gB4DfLv)|% zVIR!_2c@{J+0Trje-MVaY&zhUs-HCZNmrzH-gG}2KyVW!nKbp%^Z`<_;3KS7P@2Q2 z>sV6Z77mrneaV)SdEN|qLCD-SVMNC8B+Eq`qC%t^Q=ZzeKU)0Y1u7}(5jp^wyuWBXn|%2*ok@e2)|Hn`c)d>G{(O&j}ppY`V^XMRfa0dTcQ zW9pHjW=xi+{L)pQ`fsPgYNHK8(5dtP@;VCsWoJjh>iTm`kzAq*zT10u2PO5YT9FEo zt5mT#e(crA#PG*B?g1fG$D*x);1~-(6Ku82peCLy%z-Op7Jvx}a3JX4lbPun*377=hQ?O++Wkwz*85UIF1Y%O{+;f`F#|>)HXB+*_HKBT zbsPYec)Nu0M0$mDq-iX9q2Q!|8u!of^M95Qr2~Q)9KF;71mh@3@hJ@3K$KYvESfRV zmu}iH$HZN@^|(*hIXNLEec2nJRFH0G07{4Gg6rT8m~8v+`?gd{*%p`E`>@`{WOY3_zh>;MT<6++OlC=GrzmX}$1Zs$x2Cv0Ky z?j)VQ&@_tVS9ONcmL%>B6>eYE#oNF>-LWh>i4vONej`I^>tNJ!jA)gq1LW|vUV#)b z`tGiO8aTo~By`gV+xCF;pAgfRuVYbB3Ud6s06{>$zZBU?1_`FsAw^~tV|5Wg{v+|R z+N>(mZsz1*?kdsR-{Y*w1u_{*OGXHjh{P%LR9yEY$Vfd^3;qdpWgR{tL-@?0I8Pq(zO7n@Dzh_oT6Xd!Gja` z^A4dg_q?fW0emFj$8V_HEQ{YxzeZLK(n_HTCGx4 zd2w;JR&T6tq9fv+c{O%yaBbO>Iv{obhe=47a!qKB9+)e%fe`+9IAp z^l#iCaGdLmapIL{>8FIxZFKPD77LPBE^fNqgz272h;5cncUxE7uS6xC6pvREai_#I!tt(fa@v-DIYBW( z7cjub?wbK=uO$JnqUleQHm1HS?+V4o=2g*&18c$GMKOc|X!Rmt|vx6FWdfkYJo zTo1{sdj}7Q&fI~PBdNb2nH8t~cr|@K!}ObbUiYO&ce6|Aq%*Ew7Y!P=xPi@xeN!&c zUhpC_31hvfyzsxiYO85GTXG*dS)!>3)&!?x2iVL!+$`?wEsP{eYXdOP$X_&AX;VCl z<>3XieUP_vqQOognT)-T26PjqX9C~=lI9>s72M#t`s#&u@GWD@CXBu5qjOzxEiv>t*KPMKE& z#|Cy>S9xtYawN-SfiVQ=nQ|q}C0f4lR+qPHnx%gSZ{ca$C96XWj*b|B1KZefh0#1E z_a*Bv4;r#%I|HPt>nkqiremAo>a-`hHbg2)!?>caEyhj!f(nYpnj~Bm9Tk~^AGY0h zg~-$`BCaM{$4rO74G20`%DibIgf9&>1`eDDRA8#vqWXq`Nh+GNs% zhCqU`2i3Gzf}rTk*c!0ga^}e_mF}x7nx!iHU)|}(7JTV3f+e*x5(_!br@g$wt)?t= z(MDMIkDg2b5w27EXJpW8xDDj)1Q2&ey}qv~Cf0#%0xQJUwIvv9OH}MVmt=g(Ef^*34JvQ4nV^ zYzeY+(ujdY$73fsb7pNnk-9bPacC&Emo3Cl5hC0YXfziQwdCN8fn@ZD26YR}(w78C!RJd|_?t(fs^O;*0NRQzT+bwI}H4eDBu91v2IU0X*Jo$SVEp4hb z==6OoSkG#F+;W2?>yUw8h)vT`G2hl#4xhq$U#F%n2rlDU*ZA z;}(Ok`OAspq)9AhLwEX6q}|Oc7)h5d27pW)CQHW!6BDBVV1N8!c?!~!iC33S((^al?r^xEz1FaB$iJT2tQM`$(P=~Cg7ag* z7)8OlFO}4;VAoKw!nqN*mOORkn(D7J_z{Y{vK=?j(u(#7J~wUj2GrA9$R|nDQYF66 z8$2Xj($?@eI4;8;4uq#b($~Pl!OcB7X8dtB{#V3Z{1-quXj0Sk#h=;`4w+NZ0H9={ zWMQcQP>Wj&Wmc_%((koqcw5%n11&dK@_q7~>5-;N zEP5~f_LO=C>_wko1b8qp8Q~^ThseKJ%fT8fkNQ{~(gXTNR6OONg{+x1Z*Q$MaMLM* z7plgmswT&QvpdM(Il;irV!YHMbGT5E>JT#Npl9q+rNa+j>I^*tl;2~@B{YJr%$pJ( zusW0ROv>qKm{}F-L`?#mqKpkSuO?DyNiZ#!kNpQi8Hg^O&Qs%yfyp|$wq_a9SW)R6 z4YMCMpC70?9|K(m5`YrI=Y*63_fGgYS{-v=mb(o1d)yAP9?N z7o-=%3{DQ^gu^HnGu3LVhbygHd?n79=*p|C5ZGhH8Pyv~y1ntdNXW?{Se3I@(92rF zPmtJsl~E-+GWy&P_x>%ML^R{6b#;$3(-}IX-Tz1#De81-cZpP^nI~X64mDv?iFX9} zJ5C-)68uerr^SR^QPPjJx`JzFq#E7p#^%DtS-fR7hi=#KsV2+(OJ*BDpdxej@JNKA zLIP~YQbA4)eNKBT?(lvPjqu{TdmBgY*J4ag?kGq<;wEN8qf|+Ewh-m(qk+IPjEY?` zyl${_+jC~81Lm%?f|Q!hK^Sc|+C3uXzVQl^OHjkj?G~C(*v2cYL&51}czT%FW>ZKy zoY0q)WWh>7eL9ty69Ck{6{3W$Sn;ikK|5~2EI`l6xtyZ{!s?Zk&ssxDH#dQ8#kfx` zS@mZ}_t!MM)3~sD*jD3&l4qPO^E`yTGACLCt)c}h4XfE7`H0p+lp;L6a@FrcBwDt6ax@G_>W|{~DUW*vcA{fk331oDVu>6l5yUOUqpm zs+}lN(;pJRk-bFGz9B`K08KQHv;M|^B&Y;j_SeR=5Mctl`O) zdjMiEF&UmB@CcWy4yS{+JkZxQLVLV5j0>TN!Q)F|5Rn(g_Y@e*?Z9NY->21h?7oL` zWX+s8<&=xSdWL-F0%I>4;l9KD;A0RNr%oDA+OSd);_m#Ypq*Hms&>`6Ca=c zfg#B}&Q68qd}?Pe(TKGq#a2&!k^JpPIB$^CzJ}0hkr+MNraPna_5IDD@1{{AGCi3< ze0(gC4I~WNtLGI4XBO0r=Pi8nfRip`cQcU+i4kp%fGAU#sMZyZ1_)}*5wh9D5zuHJZC>|) zRDqNN#qBXWQUd%O)<1wT^fGm`SQY^-R`fv6kr7USf;rqog*h@@SR10(H>|HR368TS zZh}CqqE)5CfRYYfp z$Pkv1WJ%PjS;>;A&*&=hDoaA_=%F@z%wVfJtohmw2ta7>w)X&dA~~*`{EHrTEF$OG zT&t>jqprb8mNk-^i7$^g)z$Q!G{%aUDoQ*k~$U9vnoCy z!o2ywixU1YQb8iiusJAFN_zaP^SW9xY84E9hzoV`xwA*)%;vwbrars%sO1*Tt$r;HA(Cx%*7>-kLJm7>Mm~@cc?Dl z-X>JE!GgxE!hy~v)kzpxIi^D*r}--mHwJ#{H0i#zcXF;IJX|Gi{ldhbI-IFnr^oML z=y@tBhIo1TpA$`4*inQIRpR$BcuXv;K3|*_oEJ3J)VLt}UwhVqe8x;z|M)n4v(V-Y z6*^C=y<3~ajJye9E#tt?5zWteX}|m8bWDN4OFpOn9)uS9Fj9()Si2Dky)@;?M9LpTbOIoDcN^$&o2@=4HsB3Chu0mc|3Xo?FiuU3g0G29`CCn`wKKVG(ZYmqJ;4!4@R11?Q zW4T530p9! zl0>IA`^57ZeML3hIGqZO>TCC*J+oyK4Q(!em>dB|MoYuMBncvfap^FIIZ$cOk2o%B zZ55sSI^FI_==$VKM8w-0l#)~zC^|AMeV2(&9D9aFs*J{)L9Z_3)@OTvz+@MOUY^U3 zaXKqRx68GZ2_WYW&?K@!Bz08{L6UG{ri;-Sgj#$g#9@r+(Li5LMM({g#atJwT3OcY zT$3Thb870wC*NNm%4rq#qEKenGi{4a=}-V-(XcgHZ2=Gk>Yts4?3u8sG%{y^UF^wU zEZ<02@BmIlULYxV$ufI+a*M!sQ;M{<18`9(Khdbe(H1YGB&-JOU zpc-dR8n|ByQy2KWT4nEELtVF)(`i|PSU?g;(kPC*2HDN9D$Oq~^phy9iFOn88i3`F_Si#aXh=;TnS%0veIQ; zJ8EQX%z$_96_VJ_|ChI8qm>)A_L zAe3&P^y;#VTZu!)&$so5w1JJv+WS_!LB!;|L~2KkQZ?O#34Jf(v=+DOgc8Z-yxC4p zHphIqmxN3~s%IxvBoiHim*!)gfX}fLs{jPFQN_(sr1zuf zHY`RW{JCi}Vt2T2@892sA1H~^Uqk^34L84sampE;lq^zLDO1y2c{9iVSliW9*aX4& z+b!5qz<#Ie>FJ5<5!qRTvAW4}F;6DnX15g6|MzlLF>$!zQ6oUAOm`)xhJVj#DEuj@ zu|IY4e}2$$=+q?`fXKVUBf`m`sK11UpPHN<)3hta->6hBTiiUZ_{uhwgyH}YDV$Q} z_ABQK?>PiH!GXb*Fp|rMw&7(~g1T*D53C3Y^KW~1M_`TOLM)H*a`&!LDX?Zjxv^w* z6C0oe{>*Bx)-13JNQSvG|0bbmezM!1aDf#hs0EmgGR=S+U}du14&3*HtJhzVMXK%U zR*0*akEG;`8D47Q%-(ptB#oK=8ww4r><)d5_sKUPlVy0%cOdgen4K_zhtC z{UM*L(iARPb6rsua|hwmmu}uooEi`+m>mbgPMR!{?g|Vv*r{{gx46=IiVZYRN=TE= zFr)Ifw1`lTlNw$%XqzQvB2Y_~G-bq6u~Fa(2+agHWv+ex#;dC;GaeG&4%YNwt_&J# z*a&xi|H%>dd4R?@_nZe{aYLk~y>S$7&qmyH2?Zfz(lpY!X~1cdcz2%0z0hr}Wg?{- z%jsy;0rHI^2$R-&E|wnfI9zQ#_Z>ksSHp3ee0J zECSWClM9dK(-&wuYok;6s#0;1l~Vte-XEd-8;g(*;41iIH#G_CdW16C#@J7%vlcTs z&{I;d&`cXh{rz*)?tIlJ1!MGZUgqCnamtJoWC$5wV#&fn!y*Ml(U?)KUIb=_tH6Ji zF!u3O=&XFZMtop7JEPbwJaEu={E$c*GZ}^Mr$XZ1pf>p(Hk1=^O(-Ze5lI2i_n*ei zs91!W(%0?lq6jKv!s;O~lQ1+ySTW&#x`k9?ToTQkslbvkE!m{w=j5>NpZucuyaH@LLRIqH8 zak7CIz>eyfv6nMkluRJ$935F_jD!co5|AmSE5vGOmBiWU40Z4dd_JgiH)EXx4~Zi0 zn@t~aqgX>XVkR<-daCq~K!Ul3+kF6rp13M_brD{MCUN%=VsM;4p_g5r_qfbMvkc1% z70C?=@YbeiY3c&jhXX9wl!q`UY>w}oveAm>>4Nmq5PpGMU;qe*#LCFYZ)p<(S%~0T zRqC=Ia#B!rg_sq%`a05~)mP_1(?WQ-PECtLB?X0oxELD?jh@^#&OeSRu$ez1ogZ4Tccgw=RX zd}a}ZdIvNrlgC!gI;y(5w#|E(a%b$gCJOJbrA5lrA< zj~OX23?$n<7fGq6|E?SiYY0J76ypV}d?5x;8L9ye@pTAL7Biyt+Qwb#gEa>+G>e=K zt@d>S!2eO#ip^Wry?tm^9lA&Aw3*cC=JeJ-O^iXK|DyL^kUcM7=2sLXJGfm1i0U7fND7y-9cvfk`;eQ}x;PFX? z2Zqx74hhnQ9HXY=iOGJ-#+zsgE1FXLt0z69=}a>C(qwNUa3)DMhquHbhzS8EH+O6G1-xmZ zJ8?65(1mw32?+gN+8Y)|DX$2B-%7DDP`LSi!ie5%Dk4@{%cwiQ6d2%_)^39q$P zOBbbbjdUqc0^FyKZ&jYi>#3q?E(b1OehvxcI;nzSHn$rDa>yg{sd5++yOFD`8ZgjT zea(vpz=KD2^GDJX$3@yX$NzRG>uDgROph8dyj9i&vQkTWltV29FJcgUPrOZIv? zZ&lXD`KRR~_d~-`K7v`llLPo#j%v0F1P04<1S_I;$U!|Wn42j!*yKI)#f_A*nzE)c zxLpRBGRd(+skoUhurQNh)7v`FOYC=hCJz^Jma?Q`#gsckIhCSx_$a*Z#y*NbRp9-h*@cBn^?DP zq#D^v>WJkNxHfa9u;j!{9&rwxxE&mcs)N9=5DFNfGE54nBP~VwXJ>li8DI*LJScwkyH9GPq38dmZ- zIVlho-pdyWE(Up@H28bsw_7R(I_t{rdodGNc1cnOWA;H5n>HivVf5NvPfdZ z&UDRkEo|g(N^X}X+1zaXV(KOw+yFHm zgP=5E&Kw;by~GziXG>tF@zE3^O7eJrGChx311cFqg^trD!UAo-o@&QriRZ?DV!)YM zmhZO#9aEmgRCQPe9OJ+(T_l7_gzyGg(94od6yb}@Fv zVjLA6aNGr&p67l@B1MsvghfYA5q8>uDjrwGpR}L7vn0af^0~3`2Sqk2*hGX?880ZY zu+UE6+Rz=CPT`JB&Q3Wl6_mC&9hRd5^@#htx~aq=XR4LgIYaNlhvS#{Ak~-266+%5=$V(}MxdSrlPJr~_Ud_-q{oLrGv3CLa%ADm zEG;E<*Af1GI-P`f0_fRoEr^o|^{}`ADz9m1dz&j1xAA@yW0g0`drMza`n_2n#?X(> zqHkBhfr{AZD<7I;J#okU`n;oCK}nB~oapgA{kFg<`wKQKeG-XEJ_qB+%?sMAl~<^! zy^Xgw?3`JiS(Ynwg38k}&6q_z+_aizdiVj~K9|I_7YtGr#>NEn8~&p(rv{EEWP)M3$Z1mv{;u!`iZ zFm0NID@ohHK=wFK~EyxgyYq*tbB=j+F-O0Vp=ijDf|O zS!M-ow_J*iyfp`5lb zwR*El)f5D`LCByeh$cl?F z8=5GSyef;1?unMmDWvT!1D?ib>tKllP1sdK3ShC2a zVd5xjDVUzjRxPr>1=FzALV~TbN><80DG*RroJK_^T1B$KItO++4UJhPb*0gIG~)Q> zW%R}pOoy~})`x{Jwp2Q!^E_F|z5?IEVEVI`HG_gg87%>Ioh$XLTYH9)tua$VB@GuD z$|E>bN0x{UykF3`=nX_ZKm>$MIxL9iz z?3ZZ3SJW_LjG6b7=p4NEU+S}Z*C$LMa5Vp~DcV%b)RK6v3;7IA8)7}7qaV*(lY>tfj5IpTS?Ioy$Y}NJXKN+{M$^AX_AEX>JR zX=UmQg$(~WTW^<6ywz0Is-|Uag;?%DL0vgW(iC(9E-7~Qr>N*%f~Jg3r{Y?$q&0Ji z)u1|IVLCl%GUp^yG#48{cwCn?)0IC{G?kp+H5EHGl?j`ipTF{T&QI#Gq&P{p{tp0d z((No1pL1jl4P!o{Ac>uKRMb-OkQnct`eHpfq0Q(#WZ>Gz)00?GrunV(b0+i9x?mAU zkgKON%cq+4l0=TSCB-}<#^&qod@;9ACX4mFy^NBtn=?Um#0f>VeTU3mcaG| zh%0$H9#;@Tc+}~m4&mvnyOD^IV*T)2#pEP)@Vi#_3F~zIzviZBEyEZ!%X?d?*XGjJ zv=7hmpMN4Jo)D%_e;bo2_~6?!o<&M@^0KmM7#LXh#db6PNvA546LGADhFiN>qKZ%0 zd6atWa6G;uDbaZ~P8iuXWZYk!n3y~ayXi_#i4{AxgJNq#MAJ~Q0pjhY8nu=}vB{6< zGx<&0`XaeI_s_nFEF~t$A-#bn=OeB+tph}>j|xe!{_|TGDo{V18GR#~f26>urx_Us z1CO~rudWjj<1vQ)1Ud4=A9l$l72~S~4O+@9Z%LG4%!4+m+nb6sC>f3BCCVg?2!y`T zIweV!IL8&su}zSYVknyxp|bShm!L_kIFHz}0VJH9h7Mj6-#o0ENGAQ39;tGb?>$ z_-c8ORui@)YYuKtmaTV1qID80xM$P!(XajOhwmnPQQcW292nSmk|?eq+Sy#pl9J2i zKaxK`p*KO6LE7nu1Jrv1=V4fLX%&AU01$C!Lv}-^L>u%hfgof9{nEX+5>gG97)~VM z_)ln7!P+*=CfZPQ1+z;{m+T!N9RuSn9s>DeE zvZF}PpDl#^GFa%UU~|l>8vekmE1&kR^*Ope+@l2uy%f^pcOZL_%r$O1?l40Ef|eo+ zUuM0N<^0(nkB=Yhf{UyJS-JTb zL#Ft7@)SOl-boWu72LHsAC5|z+e7UdJ|I;;#?-W}<6zhl$x2r;zNk{e&C=UD+P-nt zD6Q8o;$sw=KZsvnqd+yjNN_iKMogv@0P&Xh!p5GtK`TpM^`5<#beFb5lNgypy_G`EY zNgUIm8Efi&tp#5Cz2iGNx}6kd0km>U6*QTc&ZD#NcJ}NJY*wK1$fOjNw1wCl!EF4~ z5VOh%|0Gk7kD#bMkAhIHkVCOu3InS?f&Xe|T!0`Z1sWR)S1{i%QelSpN1B0^l5Tkg zan**R`Js|UQc@JQ+?T-3V zHJ`krJ1}w3g&*4`?VSJ$zVRK%Ng|Mrt>gt0FgV=RlknrtqJZxR0*osM-TshsuUSi(iP#YO2 zd($Apu9rgR10$(y9lM4s6{(&NfX`@+u-lCix%y|RrJ;(3gv*qDn87m!>#R6fLsN1U z#$)yziiCwGA%0X~?f!KqPZp$jW5sNVZJqARrhntBDxqurIQViQX}@!;@+_NDs40cwPbo-u~d(9cLb-(G9bGzq=v=vQbNwVOrY8ujb!J*=+SeNcqc<)}uq-_M-!_4s3F z5Y!dpv`-N{UQSAJj*%?EX?#462NzM<{RrsWt7r8iqdzoiB)&;!67Byo$iNW+&&gj4 z8I9NkLDviW4lr!wnKaOD-)b<1w>UPFG6hg9bGRcaFpyY~QATGh)*aDSwD$Mj^Q%x~j-@o7Zll99CZXMhMbm#3zb+S^x0hP4u`b|F zV+_Z7qt*&Eduu9AAF)cu{ZCA$rR5@5sW6$ z%WGu^2C#hcT}IbM=%j`+nivqAx5g^?)%y|-5%fVHFZZ(&Hm#X1A^RM<9YsJ41xOKU z15q9#T*72OG%?m#qt=KjDnW{R{cHmwk8sAqT-VIteu;I?WY4JRsHG+@M6+D<-|E|} z(h^k{xlw)Y?Jj-%j2VF_HDX9;_pWM)6Nh%!6F&Y9+Bktb2>y=A$r{@nJA>;ZBc?Xk z&b)AhWLk0(FLzw5Y($tztiNRci0i91X7|T%++x;n9UjEL-r$$Rr4!_RLu8NqvdU1pb zgm*pk2|Ba$Y)=hZwz>Rr2(3Rol_IzHo!Db}-$(h_V($+q}}vy3X&-6-F;cYUvgVcl`HcRJ0jZ=Z+oY$*5Ka2yws$0H~S z%KW)p(g?l={l8CZ{S1!G;eNj=8^);#!!~hUY$)*kGR!<+hI#_p1%Yp(ujb$P&n-qL zuKj(u_;4Gmb$^`4AQLa4a`^bA1yJyhV}As=T}oMU&t=TH7c*!6FBC8C1;FGTL8VjC0arb()bnN<%piKKivyMD97kG&1UQP%G#gA(A*X^S znuvOx311h3yuE|4bTaKIZ@ugy$>eoKcM)R)@kNqMBmAd?tSc+(ZoBgbv zrb$whE?Lu0w553pG zcWarxr|eVDuclf+FZcI`<=qUF0O%Wr&TlL(yF!uRek;35SvyHpb`gW4(9#Gh^)5c{ zCyvWyBaOjsT!E1woWXUQ#o)|?mouavoG3KK^fslb^|DOkb%&`5-6G?(Qa2T{exWW@ zxlr?CPr!W~{U2{&kT$9GbYFeP3iWJ{7uOX17LMV70%-93y7OM!K||Z`*lCamqpe*6 zwNMRSKf*t|>jU99=$qOgq56jSBL0gv-Y1$M_EX%Ajdr%KpFq-$UUq}JYsqf-EXplY zO4Au^0oA_XTJ{H}5xA|s@D#EZHX9?*P=m&s?H?CXzV}hokn60YJ+fG5(6BuarNtkA zNVxFCJPa7Qwx|v0DSRraIuJQF3uob80M*e6UVJ2n(s6K%qjr4cxQ#L$qZp6FvH#Z7 zsJT!~qT{*xB|`ggqa`$2zCmieK4E_b8q~AmA3fFYJSVG)*bP0mwb$$o56lc9DZ_ks z0LG#`c)g2lx~X2Tjo7Fkts>N_J)y6Lo@i!4}veGJz}3w(~ zUKH3$#o8sTtVx{(J(yBwHBax^DJ{8?^7i)btqCawnwjjXaj#&(eKQ{k6=VD$Ect(& z1dy_eLlWby@Q{nt6w23Z8TekAEVm=SA4(kf(qKLYHRTs$3-=m25A?J z{%EURzI-T0*sW$H1a%D(YGc7|JHJ)Ib<0Oo*&wJMlW$ThP)=s=@`^O}FMm8b=gTkvsB+ zcE&6sgWA3sFjAs69ToD1&AvvW7WTYR3G(Y#kXUVCCh(~$MC3IT1o7a(T>Bwd3uT3uENt57!+=Hzlnkjdx zL|M)ogTL%VQ6(PoZ`1Wg0PP*kr02R4DBI&S$P$Ju*4>6IKKN8(PT@xQU9 zZ?-l)JP~x@gn_)~j4{EYh*-QeV6{jf(A5J6j~(9QNaK{?uvXVRW~-i-27^BLi;>ox z>UdPh=Oe7z96wrQ(;Mb1jJQ>Y;uh@O-~>h2pl>V&P3m76$!|%j-|jfhiCx^XSqb$-->(Bma$h=;0(!hPk!3za+EEXp22A~8RbQ@mf6l|(%DuJ3F zGWSDPkYxgQtKlpB1(%e-vOE7;Bb=JEP?-_>enGY^uHLCZ#mk}8;1!I4i<8~~@`$dE z@uIwhvXzG+7Lo3n_G7DGrSVGxV{7X(y*JslLe9t5`~$5rOF}$~SioZY$XH0_x@s^h zer#lGr30E_XmV|@Fd1}nmbYEoK&O~5vXLaQL}U<5Z}2XMiIb8SvvkhGp{D@ z<&^$RJ4D|r4|LCSR+IWy0^Y9RhPY#u#$C?iV$P`CybqUgpKGjn(H3q90^-chQev)U zd7;!!mzPY?^RX#epcP*3Q$szi-LF}Ci_*A6Z@mUCcH%*=$)4TE1AXs@)}(M4^1Z0X zFxs9tGoH_vq18Dn#is7TUx0;J5ay`jLX}4e+~}Q9j-RHB|bT z_dMAj2mhkq6ntvz2Zoedc5J29|mkoQz5mksmeNPT9j_E3cqZ3|PmGEZ|8+X=mADvo;-#m@D;uuf^5VkqY z1~mVy{>I(`xkZ99B7c@*NnB6pDKyvBR&P}oc*CKP1N*3%391yv>r+@2MdMDkC(qwb zY=7`6FZYXru46O(+jSLWL8o@x(-Mn-2|tb&k=3etXl5e#?mJVk=Bgqs1=jYkh60zx zWr^S|U=b`4_?OyyYB6Qm*BLDkd|*_D(xjkLI40^|DIVfgiW2EDpNwIxJ)U4c|LD4= z>CI6L$LZ&k+6z_r9%oSp*U^gAhgc>**8?wCeAc(}e!$0hU?`rAU0I&%-To|0mL8u= zf*n@`J&S!b9vsnfQ4rMS>asabFa*?)ngCkdue$%&2R>}zIg1)kNjJTC((m6S3p%=v zUxW;oVQ5ERwM_Vm8pbE0PN)M`&3LRGybcA}?&@YmS(Bb^$GML*9wbGQlA8uBPSK85 zsKy^{>QlrDh1RTaN@2%qWo4jn7m5@5PaQ(kGapl|)d}EbrpNihNZs)8umn@1Z)L^& zwbSdyN#FU@qEVrS1dq-Q+1Ctt*9&P*zm9363FMNSf=B~Wt~Lfp#U8g#@6CozCQMX& z^{@i?xd4@^&~HP}JoPa2^-UW~?uxlqzRfhn2DbA=*eF`eN8^o_;`qTbv&T20_ij*p zP&nWvltB3{FIo*KFS%Rw(&f5}ZIFR_{-ulOmzAWS7U8O^)15>dgRPhRkHE&Tnw zwS?q~9krP0!wbz~iigYj9_W|d=BGM0+F+q%eM@(Os-)zbdY{GJsKV$f6II)T!d4|XADbAvJ1#{_?E z4{3Vk7WxDBgbA#QBXa0a8}DxA0z|1^m8wMxihXx>_la&&HK%<@Xp zJb?;XB`_O}=_4^30-qvkoi+XiZIFD8FD`Lz@dMfG-bMwJ5k7v%#tXzxC7Ex!XQ>Cy zb_3Y(d%1UfxF>=ViQD@?QPc=Y@=l1W75$%T&}+%>dN0t!!^DR#t*z!wNi$vI%A&LR zFbdV&YQ@4dH~a8DjoVqA`o#%X;ewu5!s*}O6PX%bI66YBdUeZq9TqFd)b zRD`B{=38TKzvlW|_j3T6=yH52cb`W#r znH5kGDh!VJn;W8+>@KVs$8ym`yFkZjs4tpILw*GlYVU;EW4cxd9m=MX*w;j`aEZ;c z68UcNgTio6=ag)Ge3$S|8Ky)wwpxw1Y#X-K8PP9z6&X||bPSKgz=c~Up0?DnsHA_R zYKKmy2xLepE(y8!It8QZ1%#-S_k#%A;I2fVeiL7=D`BjP=Xl7K2I01$1d;vVrPUd? zMxhoib4d9fFtUY~{;bo_@~oCV5=HJ@T)gix!7Yeh17(ee*|2HUZn1FaV~7z_CSedo zhnw%OY)2;gK z#gj4!xN5Awcu+|lL-7hoWrlKhL**K~Fcx6$(nSh)Q2uMB16U>6bJFT9AA|5mdx`9L zjo}KHJ%0qj7E)a(7ChCU$Gs-grPt_dKNB_jwbQKvvZu_HrzqO(=^~y?%?a22jNh8Y zNvi&-2+j_Mp$8uKq4G7J=If+)XxC(=_%`#&Y~<(Rk|VsZo<6ahh!6~QG=Jc5%52IM z_|$v$h!|sK|Jv#rwG;V`AK|3;AlOw z!aRgk73U%M8n+X_WkS`>B7g`G$L!6vFBjkwVDpD$#lxam*Uw_A=1s)5dy%fKH!or& zgBQXV)`N;$v=~njAjg9aL!zs~iz58qV^hRHDpS<7*$VVxfi64bfJI;<>gSMK6K_$5FeYu|e`G4<8Rda*LioQgQYFcSSoFdC`W}@7j2zdxJ2F`quP^jbpx%MMwZU zK*YcBi4KmrwpTgN;lMcn>v;K_d_=JfDXz7r@X|sZ->SY8`_d{KjFn* zew80zO!3s=DuqsW`8?%h$fwyz54{TQ#J0yu=amo)qAxUx4z<@HQQU-%T@gr@GUx_6 zbkqgmG>VOhD2iT%BNQp!(XQL=N*^Cnc=EiBV&8{lA&-wq8~C2d4qwk!dX6>vq+)J1mf2D4N zYch-6^+o`Ly^y#R%J~h2DEAsZLO8Mhn)})w-MyCRR~tJGvu$i=o7<6DpVJ@^UMR@9 z#q(Uwss*V{FuX0uCskw1@ z97ULNc-2hB(uB3pGE7AWqi%M&MSyj*^rdc_$#Sq-J)%s1?489K}=L1q7 z-9t1d7%*{9km6qgT?@s(fCjl~iLwy%?TOTtm67*ShTPD9a)E}W0-jZb*khYC)aC;e zVx2919$buw7lV^WVK$W_+=Q5!#Mf>`5g-CUGl^#s(5 ze+9F`J~yOQsxty7B1|O|ZCywxtGZPN3S38j(=ibq`ZRmRgwQ%s-ASmA8rk*1$V$ z5JU;#uK|_cLNL--_{C7k{GGsnKqrG-w~Sk=EJ7e_{Mdt4+P3LQcq$Q)ZDRf(grm-0 z2hsBWo3C?3*RYSn(kU~nV^$!qbv1wP_X4=99@HBACI>ZMeF=y@n(Z1;>ULUl6vfLYxn^N=GG{@72Z&zWviS|oy z&UKsY{YWLPdLd?Tib5}GFYii%d*Mp7K@bZ7DImWp@VWai0XL{3fLO);o=8Os z0KCMKq?PY5!ziOUEJ7|(37qw7#_c-$wacrpdP(IuPCrB|RYCLp7l5zf?zCzzskt}2 zq{S0F*NND@aPwHEKi5>0`SqmL?3;>w1`UoQoOgWF==arjxX(e=V&^Yqh`Kx^{9-Nf zF%WAV)nsADwKJyLQFKs)wRalV8k{92XG6x1<@h%dGfNK|T z4}@x^%RUwOUK@<}2v>zMv1<~dqPD^qydrPkLlZh=EKqftE$5zt=z%Ow1c*i0_-Ut=^(nfPfi`%zGx>FQ7k!Z*juMPPOEcM^TZ=1$t(D*LbEPGgQ<-TbC}|;53nxmGcC7Ut=+Y}DA>j<4ll~) zMI1(WFN^gFDGSwPr1fd#3_>N#MLnu?%j}>k%v1)#USM_5dHPM=rzmonm|O-H?hlqSeuO1LT>L7jEeJ^z+no~VXsrxehrsy&PEik$nR6%_tkpWBaBP(g z#1rqjTzF+qy4J2yQkV9G=ak$k99KfY(oQ`7$jg!`K5rZWD(59Obi~T7`jLR{nQ|l^>)r-+x2U1?`us`oPE}A@L~N$aYgN%1caq4oan+L6qEG zQ2LMW;~ZimwX4fR;59~Rt#fQQD2LQATsKDt5^r-ZjCXy#?N=1eNLhbzWVM7(qS0sG zMML3W9e6Sk{K6cf;Ii7Ra8BB0jWHbk+|Y6V7aZ7_R{8*sd!j0R3D0Y-`r25(pKQSK z5WNZ@>e4Omn!I_FR~xU9l2siO)wUTyjXlnYcc}GtbsQ?JwZMB)a*lRWb9FoG^{K;q^-J4&`0}zv#AQH%g_>avQg?( zydbo~#Phv53*rN@?~4J9yRyLIQRix9+@oUaU8yJK7zF&77N>M2v|$GAGm+YgaEhp8 zyHt5i+qTU1P^#n`EA$@rmnR%c*2ezle>-AcB^qd$i34!OGEPF z$zTnIx}l_9+d2*0G!MzSPN;d@Bbl9vl>n3~{V|fO6y;aWkcEn#Fe(STN<(x8LUAxe zn2AM+3BJ^7Kx@rL0oB>LZF_Wsg>d+bN@#iTno zR+*W1QlC^pNgV;-?D-qoDs#Y!_V9xo9@lBfLZc(ai_9Aod5WnN?!Ifq2E62TGy#7T zt(6(vTRAu;&2x2pj7quuLFz(_A!XpdZ{U;U(|T-7iJg|Nq9H05ORMF&@Cx~0Rd_|G zq*MtHK)EqQ%jPHZ{v)tb4i847(eKN?*g)Hc#kskDh;Cd%hxDjiWT8XyYT0e5?jKev ze@?ecI2lty@}%9ZYPZUqxU56DH{Tc^hd*Og!QU11*057=eeJx4_F9dDo}C=nyc-QS zie!N_axb97>hIfe0`gBm0zTI2*;t!K%IyJJs^FI~46K^##}mDmjRUNDj9G12NbE4l zEwz4fL3Xr^wZ9DH)n*!q*bX5xh|a}`Y%W1Ref4F|e$(^lgE6Sw?kS}gwzzy@{L2CB z+AyukER@)X1W#2SCrVTj;o9qu?jZvp-&ufv2mkZ^5M1@dyAepap+G4+6*Nva5(N>Ahhu;4}{E`TP5*hsE?jC;9?oXvha1 zeIO(7ui0P=w?Vb1i_P*BVqFA1v5Dxhv@I!gy{@Gxf1P7Sq92+eQhIja#wANkMVwE0 zkK%~(vg~C7;|DNO;PTIIfeK7JZfR+OvKQ+5Rzv#cepq`5`B*9n3wr8{4g?bR*tRPm zQ&>7F4RkunW;hZYfKv#J<2BGRx+`g(dIU#aM7BAe9g2n^(V8$ZSDN}8s^Se;Z~?J+YtWQcg506ruYabOS^(?l3d zl(fVj89%f6x&c&ieTo%XUppQ`Yu{Q;jT;_cPLWO_Zos0IQQAtnhw|a z0p#LZ1{SiK4A6B!*)s}y^n=o_782U7S@c`2*O*mkv3g1k&U?YZ)%q_IzT7*g%`10E z$%hAmGma=~m50n$UZFf24h754sZe75`ZJwyn{j#wb|@ZWS@eoZR;Hq1p!;tjQ4Q^K zt%qb(3|=hrjN5fDkSz3%um&MB<}2~XNJ|*m!nLWgIxw(*=^c@NX(u)5zk4Rjl|7jl zJnp2UdEv5=&>~;dtCTh(zp)^M62YlvN8L<%v1ftPf7z$VOSSu;H##NUn-2SkTVKaZaD%z5V=T0Icq@;sk&ddjclw@*o4M(4z&yVAPM^$67w%Nfx z?WsD_;C5p7wlyo@4kRshq3864I(UGA_E<(~dUYuLqjF$D^a(Am1B`&OSLLpd7&vyY zMw*3RMGQ-Br^eTG&KniUR`)GctTcrB#07^2koF~#M4{JRt=RDx zU)no|2R(^C8Os$P-JMRY8t7|?+tkbe__XYHg(kKM{9VrH4F;dHLxaDmh%xe|TcJph z(&{(9{}W&Xm~Sk_XKV$>C$4df^h)s}_X#CfGXw3=nrRGa!7Oh;6U_ij*&e^vN!;lH zsoalI>`qpOfid11d=;h6Z7=m;VsegDUy$~G&$^?1rn#&hROFQ_2n)fioDV2LMnyr4 zT`dJhwR#2=iW00)n-q`O7HhB4K{6#rb!751xWgoG>2dz5KnM+ADx<<5PCf$4!PX+9_>I;?sP!Ow&aD zVUSQ=j9%ODf=bTtgau~9Y$3NbI1(%a3aC;u&2_oA4N7Z)fl?M42g5MQV=;M#Gevdp zz&(qfOi0OS>&A<2Q#98>eGlayg4LK&FU&O3dl?6c@Me+q9H#?IenE~0y`FcGAE3w^+}t$ zRPKZY#>Nt0*lq3JAZQOoYycQByKwdZt#qEF#hW_h0a#FUZw_8J_?RL~##@30YwR+_ zF7Ri3-T-+^x$oJm#CxnGjg`tFM5XMSnz%A8fHen6DHv5WA1(eUdIX#cSVnwL?2`NA zbG8P;zsKqnw;IbAKm*f|1L(?LE1+n^w1ikT`kfWk)&_#u*BVYy(wfGUAHK-L{luAU z*hsa~wwJ!6s5<2nqgM@3BfgvI_-r)r=3eWt*=;j$tfP`QqXc&6)K! zQe&Y{&_s(JlJMf%p^=43M8+!r`kUx!FY|f3u7-o!w1>H&)?<0`oNPdXV3===b!y*x zlcIo`kY}1`RSQY8k=NAgWgQ5-Fj*Zfj>0U5P=FybA|C zurj>3Bk()n>-L1povm)j`)-*b%>i@CXOG_7#-}V*YT&lCs&%yy8XgoM^B~j;d1K7} zr@l<9a1P3Tq69x2nU7+zMmi-n+D5|QK>c{CM)S@FvD3R2wmL}D|ApZ2Nz5LwNwKBrPE z!<`-Z7NexQ2tn&80dYTvxfHal&#M!NFzbjCo0pCLgAw6?pKz|V&|39ZZV*=I+xsEs z4S+y03rLJn>es~ZL`X@Q<1olS<>*zVOs*lI|74at!DQb6W8=K{I^uU7Qh(RGd-yrxx=N{dlN8NPq6F#UH z-qgd7k~S!I619m6|JXkbQ{QDJ`Dtq&!Opt$6l~%z$M?Wp& zp=gUK8$AQk?-|!U^yXg^#ycaN?`xbQE3R)qp}yZg`uvaYN&SrFiJPdA%vej1hOs29 zccEA63)P9S{W7@k>F_04qB}6pM>dta;m5ocx)}DEp@|li@j^H4T2UG)DU3?c)77*e zYaTYwhKg3|lM(_J3Mlm)R`g?wVw2L@fDTI$ zHaxnIdmcuJnTd_a*O}t?m=C;I27_&`U7SA2ukmJ5UX-1D=j*P?Mzx5;33(oxbO9&K z!00^*pFoK$clq$kCBV7{)1w}q#D0mao|aG1ilxqevS)pVblBVF3Ma62<7+t@?Y&aR z$Pdz|IMgAzM05_3B2I|M3RgI?+64$~^DssVzhK^Pz3AyUe?`;-3hJhe$`Y zc+^piftSf`Z#RA%;9ORabOB`HCx#-w!&)h*Y47CU1o=$ZN?g$2D?QOU+e;LgZ$O&EaUmrDu8QB_#$?{moJ2ekCt^6AYK4 zIp>&IYT;ip_JG3o2+bfK0qO7sa95%!#{uW&3kzNVJFNY@0A@Ot=}PRKQ?{!}v_-Uo z9^hh+2hJ~{Z?T6G{l|6w22k|N9M`MadRmZN+u&}qS*YAXReg|I2EP)`~zqHrxHyZk)pYonf(@!nrCn>hv z#Uq==w9npdT0&MNd8G({x{(+W%-`53MLvfFf;Qmzfz2w)Y{mGHe%Xf~)LjMQl_xzT z)#WOk{|NE_%X4IO*l#0L7^eYTeIY@qaB7x>wNP3x$MZ%3e%CZJ4S~6DARu>~X@EYm zBrMwUV+v>-=MDLv`MvEvftpW0*?VUVV4Ciyj$pUuris$nxzMn^NnFpptP&4qBkX7^ zBhYnOj>>BTld}|>?<|7;J}eRN!(Lc1ee69hh-RjPgHrko5k>VeA8%Ew6W$AgT{Rdq ze-o?zL*6vS{Qjo64CWo2g(}{$9k|oU(Zr+AbDeXyD#t)w&ZnMTk4<4MC!Xap^D#8H zEV%*5*o_ZuVuT|W{Q<<5%yrt}X(cwR9II#j+*{^I(wa+5-o{+zIs7BV+ESD)h8v3? z7tD7AM$j9!R?h#xJQ#L!HfC)4m|Cu~^tYahZQ}Z=XN>BDkYSVeJ>OXeU!;{Xn7Y)% zQU8~&d{E~G5-u z$Op|QCdV8vfkli_7Gqs6mSA6?FQduqoTStu!_?%e3lp*+2>*A2ZW7M|6Q0zq%Is6? zAL>Yw9?B%+MZCvAHh5Rob-vkH3r!d~d6y&YUL#_RID!c~KfUAfliy?Yr^c3wka4yg z>PAIT>P&D>DleX|y9h(L6(BAQN0>^TAW5+c4s?Q4rN?pHCpI(nWBaW*2 z4K0xtPSiROfPP>t01>@h3k%BYcQ;VyXW)C)@E2Z-&MP~SL8-9w7FV#jEnzXtFCB+ZW(6sq_LUl#(@sBextF78Xy z5p#V)l2g^{9rZK#kP1gh9OR32QLYx|D?m}I8hRu9{n)^YkY1@G>5bi=k8?WrP<^+)DwadVL z3aK=|V~naXHn}ILu-;AY5TJ1*vS{KveH&`P7O8=Uh^S$IkH$FaTI&hf3-V$VmX%a> zmaDaq3MJgC|-g;iOgmuo)_>%WUOubQ>a95&H4KZEnOyDXa_r&Zv_= zrpZ$GGe&p;SF&X`(q+QM_4}wYSFf||%Qa?taU0)md6Yu+S4NcDbl2X1EDaB^cTv-PjR(aj9o zXw?emMA69ypyKcH%2hIqj1oiN%e*ebo6V4cZ1bWM38MV8@i?H0KIJ^iNpV*4xuSK1d9(`^vpd6#S&kjEFwSPG->k-9-=k1 zwjgzHPcbH%Qw#tp%dKtUj$eM3{>(TRn7|<^SlpYYK9b*-4+IXeD z)!W8*nu7Rj!VfTh*<<-dn`@VvgpON*zHFnL?})3G&S&pG`aPC;USH(TBm;U2ix7mL zrt|rakk_BhMnEBrzCnBxigysscV#%ylI&vrKC9rt?V>O-lVQAKXYyt>4$lVPs8Gt% zK=;dAc>`@;%C`&o@@ILU)}Lzlw+x81Q9slOKZx`I;#7^bK; zs^dSBEn#B=b}kjN<^sow#B^cD4pf;5zeL>pC@(f=HpDEfr;jGV2kn_u$H9niii52`B*JZXU&8fnn#1OKo!g_!+EL?KrrQ3NSAYj|RV~@sgvYI># z_TrAM)za%2j#U=9Cf@PZmbFM%if?2W9qH#0ZBY6t`FZdsN%0+9sHHi|G{Us69fPc; zZU%suoUotEv$l-CDx`t)+f^_6m!WN=c%f>;igXGK!X+-p3Wb1t$;%hjbQS);=RY52 zZWf$kZ{lPC^WtX(pyE3vQ%ZBzu2vuc%Qt;$)0_lsQ11EW!U7WYNYjzGA< z@ManY2hZq_UL2rpEw3!WY-osbO}Cq{jH}RH{&cw zU0#dRPSn|_1wcXGIlekJ9d)A>X?WX9Aetb)d#b^S0Qg7DMdn9x!980BZX)}vx!Kyx zIH?C!m7)C;w+nqQDTy2AZIGQ~UzL8+wRu^tW?lV47q45yclIJq zgxk?+0$L@S@O${sx`!eWUmKPyl9BmwvrHI?{BWnH&kMV8n+^!WY-H^eJP$G~gYCQL zv@>mO5q>F$oc(nv!^2O-+DN7W5Vy71>j3X7Lm~D8S?t*I5SyrlH1)X^j(FwGAO-xT zdCThBgE_qAb8Mc}Q&>353{)K)2I00o=3^g}Dh=*CQHSuw#e+J#(g*65ZjU9zst^ zUjfyde2s}OJmP=dLkuhXvz^nRmN7!87e7t#uep>zdgD__L?A=fP-gbp*A`l`%r&lzxY6S!MV5 zS1u_V>wb)(`VLg91vnesHs7~*GVn+P!3FoH%TopW{Yc-suWP_AQ{*8I}dqke>ZlEYt9G+j~JkfM>^_^k=s%>rvGJ0|i%__bulA?< zUj>jc(&Q^E{t>t3XI1s_rd-6uV;)D7;W|VhI3WEOo~w z36gSp`^1(gIh&lF=~$H0yC3FE$CRD!*>iR}hV0%seP$Dha*}V;F(`S@oSE5JAQdM& z(~(#pWqZ3Lkp+Mh9g75R0hH)i1aJ!gCC4PHwm4^(A9%>a1KzjidH(-jRoz?q;EVBb z(UCq=Tgis|^A}4^v*}1CI6i?((PpwHtDw)8VZlKfaIZQdR(`8&mIMmFGK0~<-e0LI z)A_j5nS}*CJ&)kK;!m=%aNhIm-Z2Sj7)Wh(LvA&@%me3Wi3uM&f$k)@TP*3W)vWVF zBX5@TZA=qZvwoN@l|MGkg=Oe>H*tgO3%WDk*Rt(0%U#Pm-P)CO4a9{jP9OPn#x#Y} zbanwb1rJ>LV#?`)lUeYqg?WI!ICXN_1>jmmh^=e$Y|ue+aOn#lnc-4tIp4X8&6005 zx8MvmPF>6Iphkvcahk(4NA>*jYPSB%jdH%Zk*$~XgwrJXLjZ88L~rEZDleErap!-x zJIzA-V7tfpRIZ$Fhl^ZiA7+X8F93F6C+o0G3%s|}2Err}hsmMmMS8}?5|7Kg>@aXA zRSqs2%AfU*)P*iw$J=$U7dg#6AMT$F^`CfQn`>O)XqkBcA*v{EBlPx^4cV(%>8p0F zRWqzgGR^srH{ zc!H2lI=mEtY7+H+ZaSkeE6q~yo47(S3NGX)PAZdo12Fq)(C92 z(_MM^6+ztD7$1g z3%3$L$7UjFbx5>2^!jT=aJ)RUF|qc;2Yyo^<}2Hvz}Wf)x-hhQ4lu3-#uac=4Dt1& zBKjzx7vr$v0H3-Epk{W z^tn;*L?e9uj}{U(g0QqP&IRc6!UgHX*Ox(Fo+MO*lSGGcg5##(o0uQ>cPNV2KJQg9 z4n@MfeM3)hJ(6%iG$Gbp9y@9|Oq#1&>s!JH0RJBT{xuuw(O*OD zjY8@5XszC-w7I)kuw&?5Z}Bj-3Gi>nE1aU>;aWdp;lBoL6yYE|OYIK8y=wkKtPO|W zcYarIu~2uZs9$LALts!xt>dFN3r}5NmVj%h^<$ysn=D#p+jxZ$pDq4SgWsB?f%Vc^ z!Lv93V#3muubs`egu5&8phc{`F$P`-`Q*y0y6UU$eHwZh@VBb z?2A5@e6~A|Y%!vE?{yq=fF@k5{UuySKDmPXYMHA8un&cRD~Rp#zosqY&qxg*?p;yi z0~Z8ZI}5q6OPvB_)(_o&R^8-Sn`pjHFA zcR}vnYeuOf?x`QQYY}~IiYlNr0!as|tLD;W1deC7YQ^d;{XoUs`kZt5G6%a#?-&v$ zm#|aN`}g?&Bl!5T8*DT@hN;;#$%PPy_+&Xm%JykDqdgMs%8DUeH;$b1s>dB+7sAVD z!uiv~qfmOI6o%L3OrxiIT!O$OnBlho?yyHK;7m$h$Hug{VE}q^WyoFfLCw9?OdVbK1o# zUUjA^vreiZEF=YETXYOl!qowhZJ!UZzXl}ugv}tBiA1aos^i}L6dJO^iO_Qd}o>L<0e_+9v#vw17Fq||2%`u8MATSL7P$;+@W$J{>r)D z=->x%`m0`NnT9qsY#h7pwU5#GOd1k*<#Dh+a+E8aG67|p@Q}M?b?6Lt)yt0r;bxCf z*k~j{Q(FOT8Z!-+C>!TVjFmvBzazfd1Lo0wN0z_CH$kyQ+h|61W!f%7{>n5Z#E$Ae zEy1jC%77z&W6Y7ZiDRo6b?o`SebDw1c0C5g7u3TKZpgvPjA%_^vR;B8V`tqk&p5H> zimh;VkioL*C@Xv$n;$EHL^7Ofvo=&=CT;MA6qk1bP}K$flB>X_1b2k1=}bd2RL{G% z+5)m0K_=hi{(JmTiA|enSTb5{F=_A}%I1NrNqlN;{ro; z^5s-2jcQr@7Q@m-4S0PQzEQA5v~<1`$0qgd#CnD{1ekJsuA4r*?qpIFkto8*3-p|nIdgvB^%3sA)#KeSg}WK6M4qOiaQ*nc-9&Qa2G3 zI;)bqzCh8bUcF09AvhFJkq+Oz;~~2lS1Mai?-F^}{u*SmH4Pk{CQJIZv?~oS#mVX^}tgH3qdeR?X3b0l4)+r^W+R(V0un?=ci$wSxichKf1KAp{V%v8Sx`)ub z@Vg+<$2H*(p=|VH87TOb`n0&4(1&~HZ~OfdCBGsaslA3Z@7FP|c1j(#+E;bOO6M$> zo-j+#l_&I&2b)ieTnm1wqFiWk#MUP?H@Pa;lI_piV z-B;D(cOMeKtU93so(_=SeO|QWmO&*eaw&R`7;*lzFI$~pHX`Ws6&T7)YC#4<;be`x zh!WF^9nYvw3oPbiGJRNuO2-xWrnkO0qFz-sujdpp=SK8iPGT2dF@q_Ep!P1=!E#kz zIj#3OQUbWT6#4?=tX~YwC+1u=nd8Tw2{Hn? z5xeX=hwhxZ|q~H@?a+ZS)%rkwuDo9=z6$So-ES**Mx4!e^Y(DcVX9~ zY{vBQ^_O?Vz0F4Gt$-CwC&;qW8piB4-RJ8rg{SaWnobA3pDEDLslOcf$~Bc_C${pM0fft&AgkI~3aL9ItR5}X$BxR4x*jROyhm@G z%Yr&PoE1LbJ2DV&jjgo>inOZ;r?Sd^3`owsmUY~+2mf-`eo>U5Q)~M5V724u6FIM@ zQFoVq+H%!klA&1kAc3Lk2w#l>X$tv2$A0^S)+upyc>b8LDB9QZ-$Z`Av~YTTR8J>n zAf6rs`m=7-SWL+GjyVvRr=H1@KAs)Q!b>MkAZXi6ec*B61UFQP`7lDFAUj@KURYJij$edCoi6;VW`67G|efppiTuJR>BsW zuzdbmYMniV@RX1}Fr0_X;EI|e!&hh&LQ|pI(fDHr_I+v=d3wQxBLYWS5oV@%ur< zl-R|RM;JP~Dq&TB6LeInj;s<6{h1EOSJj*VI&&Qj>Lbx4l^zf^<%oD%#W$qqMX*jf z#)}5yDdQZ@+o!J(6 zfTUoJ)KjO~;fx<|p&+>kunb?pbPZGgN2t}wh@fw`Lj|D+voRNvZf{H6p)E%ek>0=Ff7uB?Yt}R9sZ2nLIfY(-4QChVH}POo8?X8jx@dP6g81W> z1Frv)%^0^u$AZ7X;}wSzIOg_?_dnEM)f!PWo$c&jysb(+L?w$I(B~CNsn-mK3Mz z=j7l=EG`S{{>I-X`}Wt>Vy6udoYy-J-JtMHhtG&q+%gh&ALl`8yY%0m|C$sV&{-Oc zABJs2dW}nr6csFv3)V>SgfiR6+{3~06PB(eAn zRtw!ZxEth@x*os?nh+c6$@+xSC;CENs^|h2P!-CHi=W=t<_e3Ixndz*wIrF=;oNDL zQ{Gh^opd##FXPY!Are3C^No!6i}CT^{*FlSRosKZKIH=Hz__aBA+W0_77gL27WnZ=Kg5spj{gDx_6?L=vSnNTc|6Uxi-wr@U5V z*SjAas8_u=#RLW&=3;*XIPu5?IjMRBK09%ln0`^stLi_q^_N?M_vH9**&wA?k_6->+j?4)gmyik**h|Xn7+@jKo5Qer+Vet z2?UhGz(98N)TJ||?nME85;{mI>W-#EiK!T>ea~`L;2^C*zuf2#qQvWvh=$&Jq znl1LH8VEzbF(rf0{d!@Z@w7@yGt?7aXbzx8~o1R$+(>r zH#psN5kR}%Z(BagMJn}pLw)BADVp({Jy1W?NXSXKF|-_D_LoZ$BHtdu&!^Bx=`7*) zW7Qn!oA1RF^@)hXvvFArDMM}*iJ_Ncp}=80!TZl*TO1)TlP>VmAe=NWn0Um9qi2O7 zaiscs6`v;rdL$3;Hx4cGFSGH_i1{Uw)7?2Kzq?iZvUEV_ykc2D;*u^+Ieg?{`&o_D zTAv%F_^6m|U%w8I6kcomCyq$V@OrFb>B}|v&j>yQ?Yt@$F0@i1sz5ZQFkiMy74Czi zokvBtx}*rtX{PE}sNU`Py4HX9pjwG|?VA05eH_Po*UZR26~ijp#-CuoJ6TsRfR#ok z{e`w*-yE&fPQ=*=f>}w*UI=$cbM-jyYGGmgmYnYi?a(dWBh@mak_vZjqkxIV@5!=0 zYBsHVey#gNAYBy#g)^|uwCa%^bc~Hxv&I=Y_9%%s(a*{Px$|2V8iOdTO@U5bXTd7+ zW2@jhhWqHh2dAKqGlJ^EcXrH}4uTiHWgW;UqTdX+Ns5#fjj=1KYLeH!RzR2{V5j2^mAi`g1+CFaC|RGkMR3=OW}{(o!Vnm zF7pt(hg6NDUZ6cgk4i#NX05W*ps@4(H zLY0H2?RK1KTZ;_GzJcfcXCtgoXGNB_SP6oyv|^P?>JZxvw%GO^MLL&)M>W z)3Y%{G9&sv6xX5W5fL!^gD8_>R-P74-3`43V8-7SK>33awE5@`c%LuK#6kA8=~oEU z!*kbw7F7LXYQROHw(M0)>2p(cL5uNoSv#1$|Eyd-+RRo0kB_a8$RmcuX)kl2U>8RC zp^ej7dNsh2Yiot7hNhtAffaRuKa|UZ4Y_+Wpt(_CR|pmm9I;PI_LYP!l-NPKiyF_> zp2e+@*4DzqIREx*Iu*cxR|Hzx?LHUN48f&f&5!SQSL&D2AR4* z^8ZFRyyR}j@WM9H8|8yqx#iow>L~dF$|s|OFIV^sce^RLI=CmL$7tvE< z!8B-(UPv}s#~ii=k11d5(3R>dnKZRG-oZ?2(o*mB@HK%dwIQ=(19G zeJT=A%QJiTe*{3OwfE%Bz+*tI(BMADGIk5GM~|_!lm>hz#11Mt0V{0l|SHKWG*6F95gi7ogM2KlB#n$tB*SatBYA>hhJo#%Uf~yz}x1 zVOh6i`r5EBFvTrFIVtvj%7ASPf}1YsvNs`$%vJhaQ^5@~FA+Akb?YD&Dk+bNe$Fj{4h(Y`3<$L~2s~x?D0}^M-e6`U|HYScp9( zt_#caubHpakVfK}gyN|cPwX_jEdkq0)70O1VHY--I{;ZKiKS`f1Qdafqq9k*5W-c? z&Vcc%Cw5hiJw__gicVe&qF_ijQhlrP2(&_3x~VJi$Q^b>C0wiT&NPur46Lu^@X&zz zB2NF7%b_-Cmsp_JQ`5yqiK)=qb#Juv-n)4>OPcXVj4N!S>M%BucUSXabl3cik3vf53P|&nBEw>LRJV zv-E{iX${?l4g3WHb_rAJg&iT2Yj;wZYs3{Vx>0b~X5q)s-XY^#oT%Hp|37d=t;9O$ zMG)@$6mQs3E0+~=jd1&@-t?U&=sTSA*d?VObk!c!@5r5J{dIdOvOBJcz!%X2N2?|Z z@F{uBSQrMA-hwObt(hw97Y4O~YK%>MDuTb*jNw@PGNbHVB&85u9Q(Y_%gPsBYA#x2 z<82)4A*jE&g%YA6uO8ae1F4P7G1sO4X{^v z+8F>Fx19+u+=isr87=AZV0O9~KP;!~;|!Hzkn$Fc_+-*V%muj?=Fd<#Z)a$8t)n2u z4*GAS0t5Ag=0a?SY$yOPK+wP0N%9_*9ZxB=BS7yjbUI?G3UA2&%#jIgC>OSF-ZIr!g9PbQx&b}Hc`40|?M5)x$F3(i zI=Gi2jPb)wAk`$ny+Sp`W6`ywI0`jA11?f+6IJQDqhF65T+Ntz&g~1CzfH4vuf*^- z;4*M;P;~;v%09s(p`~KV6usVf8Xn2U69Fq8ONN&4cYS4Yz`C74c$=pjggQ<^mTy|~ z5%n8pVXKDlrU2%83N^ECYFol;!3scm@>I9qPA&(;d<=**^yR-DGoR=Pu z8Y0Io=;;(7GtGyG_GtFV+ASa9!GLXm=(l%O%TPW8r1)FIq57uXV-+eLRttnVE0nX8SxP>W|xZ`;!F*b zSxAw`o$LXksGg~BVq^)MJ&3H)Wt4&p{cZCK$Pw)Kz0=%aG6N86+t-`uQ|34;o;s zAMW#6Nse*9_yhyD(xnHZ4pA$VHRt)Cg-MZ%y*&6v-yxRf(AI{kM@g>D@y&JpvZf0o zF(&g%OW75K>#gGDYCG-iH8pv6%@!i+K8|Pgq<~GFOL8J}tPa%R#rgdFD~r@E(A!{n zat}rDl~d|?DSI2!3$b>EI>F_7+%OiaLkW%K+`M)xwRgf=HeI2Q=8O^wEhYEr{~zFs zZvfA+$!It|g(-`xClC};rg=ngYJ)*M_;sOKSf5^jcmx+(`?z=GFosIOVDTT|Qt5pe zBFx=@%6vHqPQe&pN#>28$|dzmDL&vJulpCQB&>EJZW!dyh)}w5ug(l%Us zwjOIor@I4^+Xqxw6WoUB#<-bcdT1P6d^nIx8Es~$xen2^u8RwawR!4B87KMNhz*o} z(hzQK#O5{VLWvQ#8=5(!q|Tf+Tc! zNALp?JsWCaFqlH_rQsZS!sRU$$k#SB=MTMl*Y0V!XL{mJC7cF0+9^}_G5*BEC$4PbfO$@MK)vzvE+p(*?%nDYxYeAry+#m|(B-kG%g|aKx2XnWGBd|Hrr_&% z>Ai#;7O+=4uPC%P+#L~$FK5HiBS$*~ES=5zzmUy2!iFx->EWlURrYfN>~2e%-nAfQ z+3j4{+9g|GtW*{k|Nk>0*Dv=SJ4AAtJAR!*jP}(8uQqxj3X^fc#}5huRbTZ5@#`qk zNu!rGv#J5Dxh13ZCmpe>ahmMq|1SI?`4|GPV!iaF(iy7A9sV@w zTZ09#HX0X?*2XAQyL!#@JAlG?q?4P^`!A03Qj;{Xk3=%-|B)qMGDd#mSR=Ax>ouvKnAH|A&{F+ zJQ3u6?>kFqf`Z+Vwzs*tAwcFYTCmM@0)5(VilGUkp7_n4+D3A^EadyT!a_q!AMYee zy@&R2K}F(WWV^g7WHYHLnNqdPbNgnT0u>LJ1_b!Aal#*t3vclFc8Uou(-tc8;Ajem z_PH9IR@!YPytWkehZFJ3J($u6HUcwS;PIm5UMRfdy7DHEz-Y=Cu`dc z(%}McpN0BQfH|%<;@_-2L8Q(x6aL=z5^U<1F>E!xRUEn)7>FVl_z!|&sBTH|bZ27m zDYZIG4|KCs;J2v0)Lx^rM8Apjz(wF0^=^HoINMREm-HLDbdLFMbuzlge@%FtiYLI` zqd5ce+|!NznRRvTULkD^6zKnk>L9qna(ogTDxjUTuDewBPzCOm{mB@SEp~u=A+!Onx~mrfO{PDwd=s~2aFR~yK0yq!pSt7w zm>=)Qo0#RIuTgV6L29MAi$N0mlUdG|w9MW^rcD1ZJI%YrEWe6FPwcuH!(*?}H&HMZ zFH>|H)gM~3jLNy?#3vkSawWma84?`2`OA0~GRgv6_FD&aV_LDq z10128CgLcC@Eg-{$1$cyC^&hE%8BiE_IfKHWyi^_zSu2H8fkKs1iP!>kQNdZC;oxt zRfaAm(Bd{)e;Au**uU`gIGZK={0Vrs#}|wrQoX{3XJ*viLNj z5@qRo@HGdJVE26I^Pr|9|XXauUjsi3_7iAzOWC~g_Ye(nn%hk~+G z6h_SP(qtvDMDwr95Wid9Ad>q6v1&->M}i(KD?eBG2nXS5W4N&fqoIe#Qq(}h*9TZa zveQ&G;wUME<$nSgfSo!ez*kRYZMp;Q0L*pP)D}7!D7eV7pUxz3_>zMXF#lB_sxI69 z3oHQn(x5Q%BOe!}SJxxtT}Sx(srSF3G=XPWFny@(X=`=LsN3sI0wgjai8*jAUp-H` z_aCqdNE}~6Dq2K@jU4H1rH;wvZ?#x_vIQChTd!A6E|T&HKgFU+CJ2+&!b-fLX4~5k zSLb}K%mgO2h=hKF*T#Ci@ABR9VJK-{#b3{X`6^4^B zwwQ+6{TBf2p>&`t4xnTI3&JAQ;ke+(cg26Z$A8x36Sx3@l2Tf@fMPXoaqK)l+v13{ zZ_^<1IQ5X9QQobqlv?-G_^h%nr3pGIE#4HUw|7kokxzhhIYsv8NQvtXvln~c-$3Mo zrOV0-UQCtd1uQxg6NZf3qhu=fR58B(Bg2H-g4rKQ{*FL9Z4iDmx>HSfb zf)PHmrT1(x9S6y5{A__NJTgXnyN^d~P3AqrkD(bJ2_Djv6JfwM8-*X)I8udA*Ev40 zRaJ$%{!0Z>!65YCEC@T{vk9k)26sb8@V6-Ez9)UTaWj0Dq>WK;Ff?a7ki8_3@JRby z0F73r1jPZDMWc&i8=$A;f1go$pQ zGP}k)t1?^m4cylSQ0Hd4Kjr7Aq~SgljcvOggphW-|y9bm_n@x zfzyk#{RaRFY2a{iN z-5bdMl>Rqq2n#xWoZtkx1 z>~OCi#MVll_kIC!sg8U7~Jz39-$k$f>xnRCF#)TD5M(sq)@YP=+x@+=M-YVmyx&ylDjB`H1_h2 ze1k3;6aZ*5v#T+p{$gE_ZTx`3za zd;ZS_!afsflh#G{yBh8%)h)Z~?xxTB&Uoe;eM0al0_G1e-;=e7p0V^_SnxmhRhQmh z0tg9Y3Sg(`LODUdeMFI~L3Z_Q2)4l_Uj6*Q8MLN%Bx*~J=Rb32%EVCBGMMkk8Geww z&%ELhvW0|*r9p?_BG=9SP*W|REJ_x!gFJKrOhwVFsn{=nkGHVzACV!!7Cel=LiU?trDe{d(k zKvKMro>fQRT?C1`k)7rc;F|~vh0pX(75Bl6=&aiYhBu(`dMMz{|DTSvP(~uh7N;y- zH;*vG`pm<8VIkbkRUuP4;kEWJBEL9ZEy^97rQ+kgr(tWW>h{Y2)3)rPX$(*uD*9LL zuRW15A=0Tf$Y1@w2_TqJ>}sc3(I*!t6DdNS2^+3UsSvHc9Y`j7lkaPPQH`2W5+Uzz+LrQYRH1Qxp_r%0hirVRD> zyG4A)S|aNO{(_Vhei6PICR{&P`fe)HojIdeycZ()e6geVTWeT$1ue<}|C{bAMi~5= zcv^lqyk2?}AyPYCkUFZ`^?&xZVMFF-v6 z4#05HyW7#Sg1$d5y6Dn%9_6U@h*j^b*Zs*9XdX!qLK!5Xau7TI5xqhu7cKu#KSi82b#6@I?*gOj7%VVT+~Lo1%ON8y!jl zpv$p1O{Bcs*IIs7#iA3pV+8Q%Hn-ft+dOoEBL+TD-9zGt`hFXN;&BS2yp&js5ZwYc5!4(cN!~uevHq+7BjT8!WXSHRPR-Hxp9+K-rvg9YOOokCpIyx zf-WaHlXZY2pc}&6gC|f^#6LKIP;>ljiT&kn`2`X33AO)wbqHNZxJQzP)*k^Y1rPXl!L3(!y`Guuhz_#sBfior=IeR*o06dOx?#(TgcHQKyB;+py$Xw+wuMx&Sz{*bLy>*3m@#Qe+f1= z>4+C^EP%HM=U;}x%FWsdmDnj>x1o<~ZkU7b1!+9s?!mzDSf`U7b*2ygpk(cBX>^%O zRc#lBk~WwAxz$=y+qLRWp(e1aLB9a|8vSSbj)x%03Y4AM;rn3c-i{~%00^Sd8!9d8y<<;+*c`!Ypv^(P z@PJn`#Q2HBj?3^=AiAE~yYuzAR%lt!zO$t3OLOqKDZv(^zIHV9%dW8CQ-bHcFQCw~ zlmdRjgOYOA&^N0!fn4+|)hXnuV?%dikwt_?^CTAA1Qgm~Sg1&U>lKpdmKUoDseIf^ zG%?~fMQUz_Pa(B+=^}X|{-@^Kd z(Fh&^93FT54ZtJ#{YHkDrQSY8EA zjG*|loN41@!fJh9#or`o%CUhPa*}pRGO)I zpr}RD>)E61qT>P@jVtp`s7I$^JX10y|6!Ol1kLj%%A#kGP$kWcdd(B{zZU%=Q@h7< zzvjy(!jH2^FmJ})*p|duYl47Wel`0s=W6tUH{V1Kw~o8)V9>wOf%BVK3id6C*I4|X z0Xb`-(S3#7oAX1l`4f!~=@&sp_jJf2PqRJ~P~iq)Zc5B@@NGFh1Lp)=JqJ`KTZz+VzRuw%n6$H8#)QKP=Vu`0L~756_AJ~M#NIr?~z zV*%lfk3o*d5D1VIZY<1Nw1%gkmBw0rswB0RtxP+ybV6rRwj@-d%NKgE+ z!e#R-s;hjJ0YiOn<%scAoHehN+M^iwN4dO}(C5j}za}rmD0!v0y=fp+zg90d0lQqR zAqd;60QXR=yzxuN2)4}|;MJgf$92dLOxx4{3RJGM_gj|XDmgNYpx-TwM)*S$MiO3^ zpyRXH<*k=as4ED^&yCm1veXZ4AjbDW^^LMCP36%toHZPV&7Ct&b!6-NwridV4UrE1 z6!thpyUh&l>o4W#V=F|0<;c(L>+4JBSn62yZcATJt4Wy={TZ|?+x2DByiotEx;tJ6Xvq$O!m?esio0T<{@_t0ra@G;Z7$K0yAu%@W=EoH2jI+qzuB9VH7=+}kkO(~f78~Y6$DyIU z*P;DfpW2{sk-F7M&UXv*R7%$N+NIe;A%?W3yTI zoXq{JT-^_*vF!OFLP~98A@ED#9fr!9DTP+dK^Jt0GqTcFYFG>R_MXhqR?#fS%QGs; z-(KKZIy8+;`gSQ7_`s;w{ob#UqrF`H-|ae7MtDB5adDZKnR?)~iS<81n7N8Vx9BGe zr-Eaf`TEA!_I9^DF!@~khVs90X{lQA1a<>`%VHh?!0Q4B5_sLO;w3`)I%q+GgIscJ}$n zW0;@SR52|sfN<4>+st!HsZ-=$jvfy+;B z6NB@=g=4;r{AwP-uO!u*1NhjYqWv)Aq^((^stgPC-iMMU#W9BrAWMuqD4o(R&%TjQ@T?gmfSP>jSY*+fG!HmHdOu=1S&)E&Quh?mob!P7MH5h>(@%S zzI>0Dyf^Hi_bSwXZPX2dN|KQOlSD>Fxwo_N_iS-5|G$JkOcVSeQ=R1DgXD2;)!@QL zIy&eW9OEbX<@a*j1aj!5;bR}?>N<7?7$Cw8!lUt3;jZ^0Ej6#&ps)uT;=*OA@S+Nhdz{v981TxAs##ue7TNru%**LPf!Axo+c#`@n1wpr&VQ6M zY#1K?JENWv^1BfF(4&AlY+}+x$ zu?WhUy<208Y*KP^GZujcDOt8f00*EHJ0{V68lWs$0=l<(i-ls5>~1#Bd7l6C`=if` zvBAuF*UFcwGTb-Ze1%j#mdsa8t7?^ZF0&PrBc78_dcA0<55LAs;4KaxOT8Qv0ip64~QZ5vi%4NG!y}492 zIk{V2+X0rVl#AuxSM#p5-R^Lc&2whLW!G6PqtDPcB)%aAn*jPt!_yPvnZyG%ekiO? z!0az6Onv0(fZ-?Dj;%y7{7_>wIu%?$EO7nb2i(3cSpP$$47~;*^Qls*WE}g!yF4P@ z?~ur4xhgN)YwhKRS+Tzci~Y^EZo_Rjj@1)Cyr(_<_ecPGcn}aC*Lotf(M4&H>1-TQ z?3+RFcpW|CYHyGfg7{|FaXxgH00f0JQAM-dGlo;o(6k{8B;@ z)l??_+}G~Yy>0m9hYg|fP%acUclKsNyS(p7qj0%l zg7Z0KG5nwKe|+cuDEK6U{xSl7Sr?95-?N}~mT;hh5a*i*GODnzW|S~kB_wP@^YQoQs1REMkjD~Tcj2i z+~#0`h8s|NI4YUY6?-w$m>)?;irj7pyfyV6ah&N1M*C_fo^UTP z0E7)_Bc%F?=hX(WdDZ7oT+aY9pSS zFK?0F@u*ktAK4Y8CA?@KaoaL_QD5-bAY*R*#j zdI$}=yV1^B*kH5fKm*6F3t#w@IGci7Tpoyp4ir74Zw*xDd~DVkuOopZf1Cq2sBXQ1 zj>6ZtfY|}_`UYAdpJX=PzRwI=&yGuDorj_b#d(Nw9KQ&WjV=XbVf`V7 z4z%qy!bUbeC&X5piEwjI?19L2Z z31<~iJN`Ll&Gj24QcSEJNESH+(~^3#H5j#a$VR`c-nTCqd>WzorX{3ISRnB1E&eJo zMSat2cL`x{4%Cd_Y7EeN(3A2!Izy}e4^v#s+4P0$jGK$_fINm(d=4&iNFcX>m~giX z$TGkYMRoxuH81(76(;LqBiud;;))>-CM6$g41fegj<^Q&*Sc6&P0FFLKn!0*htsdt zR~-y*SG4}}xzV<%1rwazN<9Y_)bI!VcY>J%W%#7$iXg^Nt`-2Fr7otoVU{x+y(Acm zx}NQr_N}X|b?f-Gi-M|?JRx0x*RSWb>$O!^lyeEXxWyi7{)LBA$KE7Q>&-V>;leTu zAYkj&kAyA878JznuQmHOZ}fCzx-qEiG<#A!N7fxH-+CzRgeRRNA%$mX<7B>b=(j5uM>|4aU z6LV_#RjO>Pm;M{~xOQ+{YW+y}1`{5Wqk+|sF@ej+%nv58r379R9ATU;wqp8XZ3_FU zpOt?NV<>${D47$@*XkzACg*_*Af@crT7D@q+gv!A}<*GFcX=|8^@T>Rl4|2=wF zL=ZegJ%&b8aLwH8+z`U4tm$`Px4TwsR2Ei@LSx%>^l|}BYdu@P^LEyJ1pdU{_B=2u z&MO1T7r9K&a8TjJI?&J3G~I) zJmRPRGtq@={2`iM1GJA2!7f}PlZmKH1+Ne(5n0t*jHVN=xA=h<-hu~*XNT(#AQn&R@*M6C z$mBsSnKZ@uT8Jix=4w%}rNL31w|fah$vfU54S_68Gf~-(d1iR{VLuIsKriYzCP>iR zOXaFB!SbSep;4VofV}Bl?~gz78EA{{W6&1R&5!+_A_6`&as=F+Fo8GW2(cR4i@uiH z#Z0u(ZS>uOouqJ)q`IUc-<=%!LFLu}enMu0@<2QQJeqaK9Tq;z>lS-59D}Q$=3t(OkLzEx`|ypI4%( zIX!9caAMnr5$#>RU!~1BfA*6WvSKfViu^a&x5ykl;C;v7pB=e5^(h2&c?seQBsWEP zHFj+5?gl5#za&Nok2L%Go%PRjV*Zego2{8fPCLcQ)mhc&^ABWiLQmy$6iQRE1(}Fp z58Bx6?Kd;?ij1Z@ui_}|EGml9^gN;btFwUSWmQ&(KPAOj^sJx3ouh;)GKYBTYZtWG z&|L#XX-|mj-jkyU8rD5C@wDrSXkZ#`^r$+x1 z+}xP8cwWh3e3?j-5hL<*iVJ4+K=Uz2%xRg~k<gb8HTzFeW+v zYf7ru(d4dl_}D_GSAh38C~8;C}~r1dr!yT{`N2 zx6ywT!}$9pq)f4r+uu;1_fwONmVCN=3pptDF=&CRoX4{wtEE21A`$v8`Kc6vn$P`6 zpyS0`?oh9?+3E{Td*yU$_K5+Rfxh)-`jf2@J>H!!f!@PvtKV{ie*Miu%M!#j@B6E% zUv`>3emp=X1(k={rTdD0$K@8Pt9CA1?6i);-a7RNPtOr_TZYc`Gn|zMO1|N}2bW;l zx4kQ}xItv;8JG*udeV6JSx~ng0W{mGxA1l5O0&?c;THQ-FQ}WPn*Exzi|65%*J{r)U*D8mk0!Wd}+SRynu7t!%s5ipC`Law8g0Yw&4U8 zHIs-CftmZwN-U?}u{pt&L@rQD$`t>j54xHmn&@GDqm5koZ#f)($T%N_=3*^E^;hfk zGc#G!)&EU~tN{^W>z|1?q;VJhH-3k2l~l&M@WE^q)_>W`Qx{N<3jA%EWJ_HfNC4Y$ zRhxTby>>gKg`i$F^@oAgD*V@`OOE*pw=aeI68S9OZNA|<;(GHtU0|rq2c}jTKqnzN zdmXTOSo~l2=Ko5uIcBzs9SN857S&YQKXosNa44`JE;vVL0x zw8MnYMAVcG@ZMUk*-tvVZ1b*HtW@rXyk+(U0qj{93v9`j-t%6+6KkxYX@{FMsM=eKu3@{ zAAQQ*nxT@ZYDD|3Z+4u|opJCvIV@wHyCdp8-Z4(=bkiLq;L|wbKUv^`AqGcD1No&A zYsuVDkqD7nGx+d4nCbwns-1srQb9OpAp^BHkLqAgbl5fu^O@$cyq?cO525(*jbr&? z=<#eF^hft8r{xq*%@<=Vb#3k0ojH%oYo2XYHXCdIV?M*)s{nrt8;!8+%o;GfFPD+G z`uNi;vwqgoAt96P%Kj`1##z8mC3PKCjD%=Rj1LclwfM;J55D{=y4S5epT?_YpjV=EFr6uGp2z zvVUj)W46V{?3&>Lk=@Up_DfWx90nhIQgcJ`NFYovr>cht@^8*OX8@-9`EIO$@smm% z4b3T7_i=4wWl%DI>@#BocvHLtS>;MoA_JP;^9iVW<=(hBOq8>+=cv*X&LZ`cFfQr? zkdR_uPI)oaw`4j_^s`ubpelS05!85JBO7gV+&r(F&k?mXi_ux4IyyhCC09M5 z$9K2Y3=@8oBdi!QQofM9S0tuf0OLciNb*%f@_yk}rJP$MYv$p(yM*`WncOfha?)l} z-MwO_OsQ+id~n~^ z!4%9;4A=g0l=uPy(v5J8_Nc#rVGyFrN0e=}x379F`C{J&~?=3#Si|}NbTNU!o8tWA0y~l6w6k&?APOhKl zBh0eT<4i|f4NvS?hqMH^3PaDgTRq^}`GDp$K#zC?F%dG9LhO_F(jF_Nk(i;d&c-jaDZ5ldrq>zv+d3psXU*hQt zTw=>;liNnST*WHCV8_X4QNSNo^j0GFgUNOY z*mVST2qvD*$;%j!K1a-A(aA;@r5u!$VzvHj)%0Wt&Q>g8Vt{rvYU*(KbWDsAxp{Q> zJRm*|+|YLv>iz@x2DIo)SozADjo!1%WjjZ#9fJ0ki%3xXV<*PRz1Yme@US4&$jhU8 z`hY?X=G6l!;%D8Qqs9lYd#OhF*0IP1`KoRpNMo|}GZ5ee>Hz}_$^TbV0xtuEp!@Mh ztOr?#JR}bZo$w3$@szBt3`aluK)5U-;`mMqqBCql6lMLNBa0~~u@2#D0S=s{J^Wuh z4#mv-E$dan9kw_G75;@L!L4Jh&-WVbuB4}-`c->l2d zGfA5Ge8Yh+w^oofwSw*X@qeb5!Ay~7;7igx$i(~2+A97ffqEbUYV4=_<>RUfpNS5T zlYFu-Ivc5HLH>CccNF_JcZ4gPye-@I`ZXt?XB*}s`E-R6cXb7Q(`l^o>#3WaTOawA zcG-)eC0Y3Bx|}Deo^7CbEDy!-4|r?iRh8YQHFgJFbfmGng`7gr6C(Z6kv9}Kz&QrG z5amtDJpMh-R- z^LPQ#xIX{i~f|e7kJ!QoS{Bk@t$VwA?h4(bOz~NV&0fJY>eFyoe;9Cn9nE{P2}6Y)*!oq2=(?2R!m2?2zIdK*VhMRrd*-RG{C{y543Z?b2xtH@UP5B*gx=7AG{7NWhq=Hos~!1_e`cW}30% zY#v0s6J#X2VOEq`{Nm8Xy@d$(+k=4RHrFY3&CMX6mWo0us4oHN%^~aK`b+4rDc48p z<%frh(J3nP)W~exOk46Ht9nt04p;4e+B$C6&fVl%3jHra-@dQd;DSnudY@0A=*LJwG;b4j^jNuYFDmvizs9RGAYVjL z-56^lHH-U${p_4~(ef)i6LWymz#0Bkh242uFh_$RrSDU=XECaaAv1we?d?0I&?OKmQp0F^E$rn{s>t=+%s8`FY(`ckb zKjdgK9(o6jz`#yTquJ#u+!&WaYxfm&oRinN5Qlw5RZ-yzOi`L=(rCJ3UyOt14gc12 zCUE3t=|nTyDJG(`AqMp$)co8@(G(kd-yJ}TdeR<>y$@L%bv2&7mk!KXkHK z-7XzL(SV2`1EWhU@NL4LG-Ei*PhR9P+DcyZf1kZ3q_ys{916zE(j}yelyz@HMiReX z)KX}FHIdSG@&-CWt+vk(!&cxcSwlSjIgg`Mq4W|}*IZlpG1!HAxH%)!uZRjXdj&-? zov){r$b#+m9C5wsJ*9_o{~v0kOE!d*DlZ2S9@^x!=W)lY)JG4=Tw2Bo?|Q;CpiglT z?!%hfJPn=3PH`~9SEPC08^k^@jU!~$Mx>y=Y<5K%m~yU5MfMKYl;*hK1q$^Qhdj)# z8G)4So18brjQ*r*9`KcOxs<^AB_}H5v)it4N`@jXZ=8>}m-yajFAKCI^k#h`BxJs_ z`5=`WiqtrIDsqzzr>evjLW46q&ahmM@YH+FS2~;{8^4tPm}w~+m?(ca@x&Ye?m1`o z^8_*XMp)t_?Lr{hP`g1hPxUQ`y2W9ze?e5+j3OWj?HzNv4=3jZ3cZq@AWRF;Pk1ja zg1}`6k6pT_OGu{2%Ksty323hW?%@|(FSR+2nD<2WiII@a30Oe!O!tC_TpWc$eh{ii zuWV%%J}2nQD3zNx_-QMDVA;b zo|74pYA2M4^z9MCI2eHgTIA;5)R3n(ZD&;W%}b8w6q~E!&C|rPSmLMu5usf^ML9Bms0fEDp!|eaPb?0#WE|ZY0av*9(^-azj8^rZ)Ph8(yozf- z=)Xg1iN{E7q~zBqd^ZnO9ic~F+cc%A#+wzZ7_#$4yUMeyf300^HLa(N!>5#8pM6uQ zKX`po-ld?J=M=$BrSYJCZ~CGRd^)nbLwj@?dVr5mn22>xsLga{czANsH}I3X{yGjZ zS2%0k1*{6kS!hnt=YcM7+rH#j?5V0nOq}Qu7itKzKh9C+(Z%D1fpP{iisuQIfsh^I3X$1Pl zap{jh+X{#N0QpIv-|4scZCwQOPkjd#?q5>9Uea`pqfdiUI2l9^EG0lu%T=`t-R&7- zHFQLfNSY~u6wGKkUJLJ0O|$I<;r@DBHm)k4q}Cj_rftSa9p&bWck zv_0W8xtphx>k-N2(T`gF`|n~X)Mq-~e0`jIf8-}wDMX9!eiN$p5lvR(>r-Q5?^q=;NBu9PO1_=Px|U6 zT0Ep1vKban0W-gK#=rbhOIP6UI6gxR!_RP3Ue9iuvnpR;NCxe(=dQ#7<`C=Z_|~!5 z(=U8%Xh$K>c|1i*z91Q=we-GK5A&|Q(e(0QhJ4Uy(b9>01rLxf3TSdX;G>-dyVVO~ zTCMc|4nnO{iMGWxdOKs}DL;Va2LM5ih|7KqowD#;rm-M9M<`)lTw2b|G`AUW`;cpK z+359Ut+*;S@jqFksq#%080lZ|jYEu9R)z0h5`@eb4IVYs)aNC}l~WB!elDoef_Y$k zr&0;V@rO(nGP+^jkM6J&8ecP|VLo;8D`OD-2S2ZeE#1v7w7im{%#OzrYUBsu@2zl{eAwxLhP=*MQ&uyO}3^QgkADj!7alhe&mh zBE7IX+TZ~`{8gnng0_kkw=}5v%^Cde0*=MKD+UH3P%N>P9&NJ)%`@Mqv?gNTTw>`k zhYv{&03Lwhf6owTLYJM7qxjC1y}eU-VmPwr(APS$=dHk=; z^_LaCxr|}Awd^}!6kv7bm~z4B!FDIdP>L=Yr8XJe`wN%zsyZlF@@ZS3a$SC1%)|yP z`9bZ@glz7u92K&aNMsA{Xe=;8m-rDCJ+>4IdS9776*>e+C(_mWX(cCfCvogg35sy} z+f)p4Wo$_}HBNJZ9^bFP(8a*uDFY&N^&XONJ&q5l?mU+RcyD_}SmC(drHkR;vXPUh zQ-FA%CYYD4xdcX&eq3tW_{{)JK(oK9W(LDWM&P9R;3^jenj5d9cn_(}vnX?jAzx_v zMHX@hWBG8or3-`I>%z)_EAxkVvI+kLqfsg~<^*Jlmi$du#Hzl%x5W$IUel%0#}QkZnZkf=uj%jX?p(HcrQx@QW=qw!3NFL8w)^0>LPNV|w1&`XP2mzSaIU_WPuMg!naed=!wq)O9M!%PX3FU+44I#%X=U>Co&? z8jiQiT%UG!^AC8p4Vh?~E#_BG#8CHgQ!%HaRkpZwLUV-t{ftLvt$VcIrGmZ`ydG{iEB<3rJg5jF=Hxx{h0v&})!8jBaYBj(o7}FO?>^;0Drd#=-A^|+H#?r~l`EAw+g&c)ZLHn33gw;6okpQ(d!_{k;-ftXaRx13 zy0GI3BQK655(8R1p+>cIW@4D>PfRwKcQAK^X73pdkt=I=8}0Vaa-jn?J%)P2>WOGf zQzuU(deq^G>EV%q#Hf~tPaKI2Cp5o+jrc%KcyzdHK+y+c81_rW0#D{xd8zPW!&-CE z6F;96CF1n`V(pUUHW>**6P?otuS5 z)na71k}q-@f3v`f#l7w1_239#MLB{QPK)PN5%|3U^lkqp#%j+gTGv2qIvrC`+{ce) zj^Z8C-t?`LzKDSeFEjS#OXCx&PUA0;x^6tDWllf*v#9fp2OiaT`+j9hE;MyI7@3np zey+3-^FpFpkK(pq&p2mbbVSZPH z1)E+3?us2~eC~y+UUevMK2_vcKD76A*Z7o!i?ZgkIa>P8my|N}Ij-on?ijr#1zr*1 z2AF4@e#1P4Wyu=^x*wX);>{bR%c9ctUN8^m(-5d^2(3Q>&-u|k-spj`-$P7%3MIYz zESSJ&T_NP8(jmDe9Lt}qPf_E&9$NFp3^@8M$jwxAmCO$d{cZZsk$PWqM0oP3nX1v1 zZ#d(Ml%uyI;x`PHMs4X{KRxv(PVl=BO)>N_G@m0YvJ>OUeQ)9D`oR`4CgkFz@P)k_ zMK06l1{DimPRUtMUY|`dBBzocbj0X4JtM>Zr0JDMC!Tm6oK&VRa&64LoCF_K=dvK> z{eH}kmAvP{cDG{Meo_ePd&7EB{1MUA?y_;7+a$6$5^zg~mK}om^+_P@xb#qtT+i_R zc|B!w{Q|rQc^9QH`-+4?=`eE;I>w|@z7T*2f&P4Nw82YSf82U=; zIJM6&y66>IB0>r&zh{SZh}bBl;|o*K?#%$AdFqy?Qw6Iur9dp_N=r+)Ro2p)4Fu)Q$JvUlfC)v!uanA zPqULyT?#58umv$0s3PA?+5LXADDqW+*d;XXtHc2mS;=mrQE<)L4+PqNg40p2rr-B- zZI*@_u>^X|AwN32_lz)RYTkUW;>Q8jJ7n-oCsazKR2~{{Jr^l>II4aDk5N?gOrDWG zW-o!9UmpjV^j$kTW_6^_}MTXoIsuzUTe~M`NLqj!1>Q zqINDhsi-Y<=Yp}22ZBx#kIh6XdlzMOv;X?+P@^Phsdw-@_3!C-2}FI*5;6`6AwwHl z-&r}N+smGoA#DFn*9p1k1t`}ImmQ^YZAt<+9M-P+TsXD&ansQm*+x;tcY=M_|C-9J z>?WXIHTgQAG$HNB?0Lm9e2>ow>@&u}>yZs`G_iXbDQNtr>X+Z6gKv`;S8JU ztRQkkc~a4^$`@_xci*FJt|OR=aEpguf~kt3XfgfuYPvNn&y_;;)7dqq69K`#iuqAS zQ9dq3a60>2rum&zW2*+6ZK`n#?aAN z)xM}vop)EPGZWeErWN%iV`niH3voqXRi7U-p%{&wrB(&^4nURHMQ3RDUkp_Z)k2b| z3{rOZB2iT{2dthZzh@5|+WPKeD~!VxkbG*T)h#=RpOcm`(qP6bLo2AGp~9RNO}b_< zlj#o;^UKo|LU2`7hZY%m_hjC2zwp6G_?R=4<-)uzDI5G!BS67@`(Wvm?o+{jz|*9( z3=ssg4*9_3vDu>AdfAZ|WYmQs1`}hctDf|HlyKIZ1s(vX(N|Lx6XIEJhsR;a*N2&_MRG z>cd$Nq!B@Z&bw0sR$W>bm22x9?lkTdZ#ChWHFJu^E5(8{bDe$eAdM^=PCR~P%M=qO zmg56TwJtL8DbGU{-T4D(~K z7JQj(F7Z=p^)=!Q*Iw}hyih_ZZ?Fo_dCXK$dd9O?tiZ&Qx1!ZWmLEX!4P+n-$8@qEds6k!ZH)EaUUBb1{}Td2$##0hz^8r%$pJDd5HN6^Og8m3%uO_)J(I$-LA;u1l9hwu5WB7mI zy-(ReXMd$)`Zn%gY_&3mUMD^~eZQ$G6_n?LXLVKlyYOE5L@-DYC}GgZ#@{qDZ2Ks! zALPQU>{HUJ=nLlLw-QQeMp391%_L$2%1J#T3eF;E*;9y^(_5!@mZ1#r-pwLpE1T`^ zDq~MvyIff--}PT>p?TJA0lLd1yJ5X@mlOOs$egwvUNp~3RvjGNho9ZN{AEfC#3+?+ z_yvK-(K*2McLNG7CVDW1I?BET2{a+<#Li|{w&JO4&p}aM=^`Ls@-;tWE}7Z$a93gA z>2ErZ>;RQ*MUU+bx9kC_9`uXOq#&GE!t5yS$Gsq&17EkJr=#eQru4+pvAZ z=2IlekFM7~V?#Z)K8lAP$vM?;Y@x-hkLK zcSjAKmVzK_u>Nq$^mX^12ulwVp1w|Ur~BE2Hy5R{2x&8Zt9RA$yR242m9x>q(k}0j zoPpwOQfJ}wpdT?*~k+(5lKV{Zn_`z!P#(I9X>8xJ(BohL1KrXg-a?%}dbZm^!ad!okJVe^SBD!+@+XxjP`T8o7>4I~hj79SI$( z^}Ac=`*U^P>24W|91AnBS?DfJA?=>NE~GrLEYl+Ba9c*6@u|#d~$nDEQy5Hw$^r+MKo`nGrcK9^aDMgY zH4d5P2S4L`pJkN#?*(>O9pq-GX!Rd?OCXC$KQcG=sSc!jx$l@j??!k(ViA4pW28!O z@QH!OMc2#){UVB1K0-W)8Qe&Q)Y`mnManrU(}zyJ2GK#wAgx{(jPUyPdnKrLb=jPT zI68&hc_wOk&%x{T;bOI}(0z_r^KK*G0)+$YXNXqa(N?#+)#Yb|_W;C?c)k|k8-o*1 z`T8ZpS8xhrd)dkQMxp407SECHn|21?P zwFw>Izc|@UBuD(_Q`0}m7dK8t`qvwVZ@?s`iR5@bC&cKsVx{dUo?U$e=p?exBOyFw zm~33(u)rp#q^_SL_!@kDP*LgRztct#rUE{z!-MJA2}~(Vbe20sSeXLZeWC>g2swGb zI=|EDg=m(OB1i93cQ_j!J}y7FdNej7`>ME@ZZE9Q;&g<3=<>CTk}b28Ox7FECla~` zPvDlaX1}5i#1!2bM0?AV;=j(|F+m*6jFhFFQ| z+2uKxAHGrz_=a09tXW?yH7bSyU{@R7(Rij&{lYR&K2;555~s1kg`T!YSn9J`>PzGS zbv$WE#iH50R@GRLSYO$0s8C&V4MeO?_xho zLyf8nm8D97+`P$Cd>Z;K8|^E)Rl9Xg>6+c!|7G7<`j=;7Q9sAvK&-LxH(1NW5YjT& z*jl9;%yQi|Ur~G(y<(f_k>yOmgm3rx-bIRTb4FLOJ2(^7xmRtV{=awQ(4~N6GWQ?c zMz!LThsv9;#NxmzR_Szi?tToPP$=i>7k+FRhAu&8VT-DrH#aNA5?nCjv^Po#2mPJO zUE2&QexkL0jH6&RI(gyKLTemeLSAKuyuVy2>@cw0owZ#oNbl`b{nOuM2OyqJQ7p!G z9GgY{CaOkh{Cs>E%z0+T9$7Gj#-sktPQPW>%hfq&c z^{*cL#B)s}sA7cT=e3NqP_%Z?CuN>8&wyPhkWZJaLd6eV&t*X+PS<=qEWPlr`~cF% z{nJ~~f3X{t!mh><)6Pd{LXEqUMgFzSvit~uW#h+J+_IIA0g<~-Ab12;Z!Cc-%Zv!) zS5}VFM2seFIQd>>+u8)$aczD=ov4fFC?}Z3N-I*Ws)(peiy};dQHA$@!ig3EG*A<`uY( z#vhqoQDIt%uqOR{$to7iRGXO%Kj2?~v)u6SZow3wOGPqD&`<1Yp?uWO<4oeHpmGbv z(YIxzD;u5m^9M(tx@-Hv6_b465Jqw1^#W^D<$th68rXX@9><^i-Cq#11V{0q7%nat z%rYOZu{arwk`AKsKU69UW)IYSk1%-(yc~lnzB2C@iU~?g1drcuY!=MeHc~u1qE{N1 zu!~QvS$bz zHbJRd8X3@(C%(}bft$+(^F&(SteOMk%Jwy$$mseLE*@3s-td47+_X)60yVCfJP!Qx zWmAo&VXd(Bzr>-u>5WY5oi%=F7}^DMG^3D9499^|>_hGWkhhDDqSzNJFfu7$U|7Yp zF~<@asFrY7BFwp?rCCtG%>2z!AA~UOjU%@p{8%A&RhW$PYfC7eKz0uJeRb#wlvZRl zNXqXX8IBd^Ig09c3sq-YFE3fVHzhr(FkGo@Z(h|-4REu}g)V#9T`HZ3S@XVfK;zn) znR?;MQpJy5xKK2mc<6%dF=s?yEASD;y1TT@V^F@p#IWDn&5@Tgp-S2885D@53=c## zb6y#aog(k^6Fmwu`3}}UerL%7VsCER^@%7cKJ4)o(AQe$Jlu3(VsgwjF5(kWfav|W zZ=>zjz}YA*$O9)7xl#Xi7!=^0Z;!-ug9B=27YbKGzftrt6ksPK`j$b%=>AuJP|s4P zKXhgV;=hMKMY!7kY17YR?0@ackJFA2&7Cuabk>4L77q@T#bj8AaR8PWu=yW3BB zl55Q>h-~8?*aYa7SLy=Y?t6$MPSC?7JGSV8caOuYEuO<&#PTvHD>;RX-Q*iTih|SC z&(udi4H}uFuv5b!A95HU?Y8dekIcdtDl-nTZ$eNAfMQKdJ}3CfxvxH*cD+F2Yxk)~ z5t6o^mQ`DyfIqMUoHw)RdeP|m$o zyPHU$l-ap^6NwE{b|#KQHbBa9ED|^kQZJSW;B7Z`bM96xKd4kCLO3ta^ZbAR zet8b#DTcL@M`v>=sC!#l#vJ~e%b}9Zve@&n(wE@OG}`#B3c_D_?)Jd~8kQ>!>8us+ zIR!+Jx59vfF9*k`o$ty;fHuI(FxD4Y(u}`|y4>Z%`zH`p04Z;ASKK8dA=UeIh7S)A zbM>trR~7tj{FFjB;R;j07tG^vZj?g`QMPYu!^rCE0x4MM?xj9yqQoo8k~%anT71 z_2F2__Zh(d1pm%A8uZq@j#TF>aIA;nC>1vHM|&?DXbiSTkwS6<7d6wIOb6$~QjVLU znWDhgC)LtZGodQ)E*QP9t&_ZprAdUoO$?mc=B zAWf%uHrp9A5t6g3{A=C-;dH2?8J^x}^Pu*&WT>DcbPC^)Qw>MJ%F9OV~ujfffpX5h`8eM4vop>SJHd;joebu}& z3^T?MacyecRXi~m5sQ}Kqb*)n$qFIz&D3)px!T}5UGg;P0zY?na7EvTmc*&cIu_j+?VTtZ{Q7r04u9FE+P;L|1>33SurVD$4nY|VK zNe|9=--(mP;_G3Eo&!ibIv>2gHysnj9%CaNYrm)JQFldqJwzMe&(_H>Tq@0qc!I;4 z6ZKT!qcF@c*db>TsbtN>z%vY{z{koUu-{2g&apy2|Fp2f%j{qlG-}?1Nb#abn$G|d z*+Mm;p5tG2aZ>h7&i?{%AMUT2Khs+yayH+I8|$-vE@cHg%{=FOS_m~;nYu7HR+!3n zn6rJWK6-^z<y6^QSJ zb?pb50+kr=9taygwkm7`QH!*;l9IpQ+(ltnc=;f86R-sY`BFqo2@0=U01O}`_5j0AHQEIf(z zjVzDN7-DE%Hs0WVUMuT${(<==mZ!ZscqN~>Ns5}?NlVeEV1GrbN8#!t8(!9*VsR-$ zPz}`<{Q7+m?UEA%cR!tctkY>#I0 zB4iZW)T)DPzWiE#SB62Z61*B+qZT7XJdLFo$zYdd#DLL=B`lC7)%&7N4s|> z2C`(%I+imyS;1DP!hh|~dsfLRVD=8y?{E0M5kuq|TNqf$XSw4qtmQ+by!wIK_e`!| zGUDmkSs`rR(S3HI)kj!%P2=UOU&2-&#N5tr;xM?HO#UlFVwQOTm)wjE)Za=Mrz0&W zoUN^^N%Jvt&HQ1soa2;bz5z8k2uGslLE*jCv!xw+ zlt18mVw-sxV=Vu#c3+&#%dCsaSqydbu~9z=C2j;ljS@jxFZpR!7^77tZwyARAmUT1 zS7tl)s?~yyB^P)-II3n$=df0*Mi)nq8j>pTA2%}|bM>4gqE@R3bN-zO{IKnWXg)}y z(U-6`6pqKoln%86<&)Go!B+vMr0p}!;;mb?Dno->f2RoJARrB8-KcXUmUyL8J*+6Y zi07X{3=fWqb_!u=@#W<|u$8BXTjlXsM|_bc_ZsJ2lIsh5204cH&r;{;Q`cp%Pw|CQ zoxOr*3FuE*$(W6jmE;qiUEXv{e_U@CD`+Q#eW5mrJQV!GWDh{67923o-EX>l;Z&(o zwNmnMS8qT^F%)hIa+vKK55X8l$vj(+{`7&=Fs+8E1e{((2%7xwHMzDCODjViN=%!x zUX|aitz5A^zdD3op0vM#ajnEci-OS|@}vElwuBIWZVTCB|!IhprlThKSX9KZI{ zW`l*|ura7q)2Fyr{FjDjueoPKhR_hqL*&!V^UQEUal9|4smc64kl*(#wF}GU&0clX z(}wkxpUzhnI3bG(sj8k{RPS$In`a(1SIXay4J%uxCYh&B*SHrXzFtxg%n#${>1BhW zxQN3)z$rBr?}f;p3dd-okF}|6Z`6oC00qCO z)qKFO^o+(~0)vkE?)|L|Ysu)R#W^vH>Uy(P&`&}AcDftB%YLoRCHO<9w zZE^5(I3ll9eZ!C?jr?~Nxn_hF#@PZ&L-J=#f3`ksJW6?EjrGX}xnRGdm_-&&A~)@8K;Na(a|Zd*vw#tId~upL-jcG@XyQ zd5koP=h|@L;^G~sEVY#x$Jl7YLG};{d8nWCVKQywWKYev_?|=875fstXzdgpx-%kd z9bh>(Lwi27$h-1}deF zN;{j2t2ebDS4Gfn%p!1ZT0!l$t;&;1KM6APA^Naj#I(EIVjTUB2Wc3lEQO-He$tF4 z4sG}LEJz`jnF}xr_VdMaVAkhmdXjf9DTSrgn)Yvq8qMGJM61xH6-B4uGfr|9^ZYpu z$^Gbe7VBsHZG6sBy*YPe!JnT(z#U{8ALO8w5qaTU$ePL{rr-3Y6317;+g(qJ#R)a2 z%d!Gz`uICN5xM7S-@!>Pu)3RkuDNg6SY68xjI_tgKl|hc^We<;+?Iqdty&8tba&BO zCAIOL1G{ou>A-J-`yXwJZ)b_<=bVtMRT)ux%?Ppii$se85UdM zF|U%AK|FWKs+AqoJ}yB5P2e&-)`C&r+C|W$^;q9&B{WU)Qh-)=C+qK_Lpz&0JS1jmu&Ta;!wM`-aO+u^ac9L*fo*Ny!^u~jZA7Hu0^hp1gSh4jQv4q zVK}tk&?8(NIcprIQWdpDok+tuL8R;uK<|C7S)|qssi|L`GSw8wr5i_K(<{I_%$#pc zmTJP$%Z_9aAJ7>nF0Z9oEF_<<6~jZCSsq_UkdS{Et;ImQ9^MrLG(H(~F<>h0=O6`? zzJoN;^Ui>DX`CW6c#JZu7oe4_HV3BOa<`t=vEoNSG5ez(_Hoa-4~M&N46*0S=oXeU zgeyl+xlHLX&u{hbk5t>`)4W8l%QMX?yC7AHxo2mZEZa@L+H9^thOg}Hc7gQ7}EoY9YP&R1>)3sF&ZAJhC@=eA%+xmkJJkC9}Osy zv&~YGf6A6?%?I$nT_~+r&o`{<;&&4v%E;Vwo<2c)Pon17A0Cce*N$q9XE6b&ljdM5T{@Lcq5g;^ zcz%2NtuMo&Q2?zP=CSH&EMG9C`tH*pyPGi6z)u03SbzJY{RNRu#DU*Zt#u^sE(Q8j zSQt1hAoam8#6EM9a-r|_%T8Ll-g_Q(%JU=z7x72h+m;Gm+w-C zqb56%dSLUs&fi|o3UnsuIc0w3iro=QS`W&@eV?;f7!&gu6SomJthr9}a#t$Je7>cv z_dnZ?i$+=0+(N2lPUwneQZiHY^_v=)ysawS2EH>9F4gk%Z<~I@8X+D4+_Ylb6LgVw z9z}4q#qfAy7WA|3KjrRDaO7Z?gXvcT<0X5#VEam`oSBjc_J#%Xg`t+Nq8kOu-|6|qHO ze_hrmaf(%W9JNg-fFkSV*PQ0v10|~y%-gZ+!ZEafAQo%63ed*0D48zKQEv{CY)Q9y6i7*JR;@tAQOJ5l7ZG+$?hM6ci5zYro^7luMhM zLD?s2wka~RC819sE|Z0TBoa0qr9dv(o^<_8K8c*@G_T$!sKtuUHogL>8p>yS*Jg?N za(_)D`0Jn8Arl{KjV=;j2ZB!MT-;uiN-<9(+%qGItJf*hH>-y5VHm47ejCR#iL*?voc zjwJt(cWLDBK<{g8q+a&N;`bAaevqvlwweAWPueIC<&!Ed&Has;a%=BBH1%1Uoh3rK zWj4*l30i3N@-_fmv62g2o@!y}qKzy&49(m_T3F?oR(DPIAYga&?poFf6NYyl9Bfha z0CB={XH6O1&)4+3z*d8Pw@|gzE~6$#AF+$&)q&D;Fd0>l{En>Q>U4FjL#+M`_!_#8 zg|?c7U|N-{W1M`}T0!8GD+`anoO7~HY@3M@Tl800UYM-E%zN=RETu-{=cp5}ifeWL z!p`bl&jK%HVJGUD;M5SC5qPKGsKG|ks6V&*0dE1ZmX=7Gw|>PDiivmi+jAlI&4<*_xaSaJ??6JSAA|wsc(L zw~MN_YaZF{8d)Caytc;WnD1vk-gJu3akMA+)LWUd`|g z(g%}{8T)6~P0Tqmsg5g5Ox&}DvZjp|*67W}yk;*+S2{k-dA`MA`;w5)jBzBEPanQ2y;uYWM@!f?}9_H zI!p0OaI=<1qK%f6H*Jbx(f5U*F_{?B0dOD&JjQ zf|G1j-&0n8P{Z0-F4SAUy2;~nH<2v=4a*P{Rbc|0+EcA6yo@d;rw3;r)CswvkqI4O z4)4#U`Wxp^?{5+)I#q9hX(d{3lB><1Xe??Dze8jd%%vMIXFcr6LL_96wLAema{Lzv zY51UlR6BecX78Z_p#HX5N}D?`>&#VE{e`tW8%>`-bHbO z(wYR%{mRrEld}2Q6}nI>!Zn~Pq8bkO?dwZPvfyvD z*u-9T-sLG$U7FEYvMU;{e5fI!ZePG9c3SC>?X~oL(#3DF{^LBX#zU#a6IGivPRYJa zoA3%h`v98PxNL4NfV+Vo_YRFRD%OOT7zKMA4(uHXsA(IRa87L(QF z1c#^dR_HWMag8ru8l^Qs)GOc)UVOon{>VFYVbqrj=|hS-EI#0bWSBAIqR+1rgRPK{ zO;XrHU^sz7!;pA{;pg@stEP^%#(SHp{(55d!=6Ig?Ap!|3C?rEoCl=X{;XZSyT5I# z1IEF|QMSo6Vrq|vHjEnjWhfR3{UuFxP}~<9R4JGKT_YDO5Aaz4SD08o<{zi=kfO|q%O!zp&r&ex!I^`g0W z&O_<$2WhV7(yZNi0ZyqSDJKOs*rlX&81CV*_%wrEY?Ge-z{20~apZhGXyk3}&Z1j@`uAJXfE+h@^)6C;KC)_K-Zb-2u26l7x*>C#tUm z{9E@WeUOV*`8eG~IgJ@buza~IU&spG=K1HRtF!0Fhg>&_uBcP4fqcN+CtSFKEa!-jHU&DUzWYU)wpOL?bi z-`Z5v>;khI9~3eScGK?dy8(u#xQx64Q3D}WPW|}c4uo+VcD%uo!>mA zfMqwWcS^jeId9*OP{h^})4R7LMo@wzhwcvF73<|zr0cWpz!6{Ftl#CNx|*A)xCJ)m;oJ=^2b=F{m}Y&5OZlWKh$ z_;vW_yui+}s)*Taa|#CN=J62r*W>z;khVJXx-%z4>0tQQN=x({m*yANi>92t2olc( zVaX_5l8Q@Q*UlO#fy-ZM$}^KS#rap-+& zJ$CBeTog`5w3`8rG-RufksH;0H~2FEOq;e_fEB9pjP()YIrn*gj>(!jQ3ZinQu%k| zn5%<{K$7Zv>z`Ou?$x9MgVTJ1n{(BL+?;8&XifGJV;0?ppv4AK*Xa1^{?U+RM4>doyuu#nO!UHZXa1Y&CdRjAHj<(y1N&fYY z{lEV3z}wP~{sQE1^9?T(Al2r%eu{PBX)BV1v8a_lN(D^x@vO?ibpDvDt=jLSfv{)! z$pHp_x$9Yh9Js_I3fvi(fM{5iA3}`Ev-WebKVh)Y`3Kqa(>FHRpSxv&G)u>A{Yn_^ z|1Jk5l|nz!Y#7vSKSf4Be-h?0h$|cLRfKAd04Jgb$qb_Kn8Tqat(~O6iX+Wt>U82$ zB*>gz^Wvb`x9}A=m?&khMAys0zsNRv3hSgS{RuBEXdrKQfXVtqxi_uGYh8oLc-!=< zj`$fYlJ9_Ur2rEMF2JRp<0ezp{~V?!rNd@>tPM$5wZ9Qocau3dUI@aTh-@$QtU>yz zP@v;{nj~%uX|rd1gJ{k0h&2fs+nvslTxov3ceq15d zaU;lYMD&4G>JiVR5*^{%Bmz9F7{g={1^8g<)%Wm>ab$+e;uP!oIGDb?p=YSWq z<=h)LWU-Fmcnhv;F95-h0MY7bS<^qFQkz9BfXB5_Fb`Vjd2S9Lj18mmcpu$}@9NQJ zjTUMPrFnxdOv2L`uKt)SSz)*AXBv=L34Og@$w}#QNAVhc50sX6m~u%wdq)W>wX=xE z?jjI$=l3`Q7jZBO^UF7+GBf0pvcLwl3|BVK?S58!&NJ;D>*H0-L zQ~uP<^=-Ff7mKgJqS&qNwd1Pr_9u3P)NB2uA&cj>9**W|+~=WQ7S&_@KKzML9S8>q zP^*>lb1HilM<-FL;aXoR5orR0h5Q7KY_*?A1H>RPoDLX@_Wa#yIhQqM>(7)dFeG|u z;^UQ13^9X~tjDRIVdxx-dl8dWUDKJijp)@Cxiu3q-Leri6a8@WIE3h$UFexu%U5J+ zLJl&MO={)vQ>JH0nT;3Xnjqtsls3g)RHdE(deuC}ZIGXTkIc%#db7J_(l*C5o~|UA*R#uU^N@0TJDxjo8e0x z($}=IDUL3R2SN0L3wP8=8^Mbgni7*{bt+7hN%kTs+VRO832wc4Qr7ahOauv9 zs<&jJyHK6>77G?oRr-~B(gimfgn>U^6cOO$rNPmyTT>?DC+*sV#+y;00ki9i0Vx-N z;#EX!LHLDFiAZhFTPj56I)~)hEb^$!c z6#y%Yd5^!9>YBVbIl#;bF0m{5pa}3=zO!mrt|<u5_vfu~h--~+T6`*OJuJKELs$r4F2@JpyFj5e+KL#0 z?H0-8aVB33&IdgqBgiusQ;P&I`lex&D8e2sU0!^LA$R|^2_Sw0nQ{~^WI1Ri{3p-6 zqE3|VsEZr6524#=gB0FIc`{O{y@PH2^Cm}vIX5h&Pw{M0V6$sAkL;t77rj ztCX?;azH-`KF6DvviLJzkl~~HMp@Qw7PNk03O}~ic&~OFdx}7yu)YYsdr(8h*#`5x zaJHhQ_kqT-PXK@7PTj|=IKV7#59L4SoJ`mh=ORIq3O8XCW^vlHj(Bk^|F^-m7yUN% z)^M+V#WNo1vG%8S7NVqO>v5ru(+oy}Axp^cV$fTpT<&Aj>Wtg@<~GnYVb0#cQLfeA z>bPDg2ka&zHy1B5wi?P<8;z_=y7eRQw%s!d`U#+;I4+2H>T5O+!d!pAHYL!P-hs{e zI=-Jb;S7gdMu8%ez6T;%_AN!>6R^t+PRV*j`0PFi2~n7`?bV4YQFSwD95oC2&+2}P zH|)DgztC(;!3MLdBcb+fU@$5NaDA^j$d)eQCk3D?4SA%CK6JJ*1mH-F!(rj@3dN!9{GkZ71IIJAOgD55>dxygDt#(wY7wxh5*Y6l+Zi1;f`12grjLNEm8ev(UPRpT`+ zU*Fv(;b#R&Km#-TB?o*nUQWV_kbz~7t2RJJs@^I4oHm)bYT&WSW~F-T(;5u;UK3@)Uv z9;j;YA&FQq_7_gk!c}<^; zd>CattKG>-ET1_5EL}~WqZmdx@TN_y4#L4x-4_(i4rdvQ;-S2$oF|mp8GR~zNqfTzH-QNTKu!{c* zC$(od&2jWqvh=M`mFAPqXtq0_h8e%iJew1}EuCrS`zo2U+b3}B}qJIZy}-uI@ZAtPPhy?V$e?eo|;9(RPd>VJYsJ>rMw z1S03svMG)j-6xaa!j;t1yjG+e`M(c5g{^noE9P=6(_KbiSdo>zwdz3D{`*CeXf9`k zO;FfJ-C32cLpvKPNE30`9E?6%h9t;s=6=rFC(^F0tUU+iF;LeIHHB9G^6wgbrI;BX+#a3) zIY7q09+WtZU2(?bNBdX9Px))smhi;5GNB~};ol+%L--~HgI&?`D1sioO9HqYNRldN zhm6AW&dRt^gH8Q(Ope|r;dMYHx7ogLKBjuyxGv1-iO1hI>9H#BYgdZ7_1W%HThozs z>(kSoU5#GQY|5Ojscyt8``RQ7r{?`v52 z-ds&VUx);}e~%OS!zkLmmgeiC%!SG~1ozpS8mJ*dE6U#|jerD>HU{#Xta+n_M-iUR z>CU00=X}lNlq{_(qcajL`?V&w4`d=6`z<`9e4&uMfj=6{ zP;I$Ba9z(RmDQsQQjOEh?u{X?8)Jl5+&5UW(-|S=gf3&{Z)sGxhqvB4JH9?R&&1=N zn}8=Tf6mZELemz7zrKKCgu>wbf%OmN9`x)68*vy5z6gg*uC2UZl7Cq>QaC%imF0WL!rdhu@oJN;s3A6 zWxx0Lp`l)L?kEHo2bwo%?dP@2N^m8=jq&!Ce+1!6msM(|O`chAtp1Uc^%^T}p2fj= z#8$G6eEV;O`wY+nQ{D_WmxBiBf(pn5c_6IoPxK@moPjhX(Nl$ady#|6TUDOu` z2el3DFJYh_)9Z3pJO)mz>v^9V2VtDz(BY8Uu}cHw>qB()aDY`jF z`udenf8v;^Bt|(os8VO#%f@zwFSFpxdA8jx&KEalmfb6Iv9hwfymEbcg`KKZ=Ucpu ztYjBtb0&EnIL`-d>kqE|rzIw5wsZU0Dnqv_0$TYgAT=1CA@YJEnOB718Bd{6e0C&s zYcIIG*_@!u)*e}z-F+v9)jeKNPHgr6i{9fW3=C|!*n9o>f~jNA<8KPlQU=gW1s%2c zEeA~Y^MwETH7$m)p2NpA5e1?a=$SNg4|m8OP(q9QYn>%~oQc#ErnXO!GzS6x+SHAe z;}~nJT|K5n3ze?jbIrug2^`x*J~Wp$ZpEmrKV z#5xl95RSq_ul!?ax+6BWkh<}z;PH$-+T819v%M<4JJ@dbwp3qoK~sEm4+^-kK1KdZ zZ;usOn^rSkA!A3uVox$)!s3C`YBO7H7_v4~hsxY|e#M6u>ap>ZgG5;0r-7(Jd0X6D zbU9F^cdD_5zCI!i&e6hlTzQ54A$qDAe>!!aaOR*gk%AI_U?&E3FQXh5V^K?M| z1%<+4L`wk|?GpwU_dfzvLkH)GE2lhJa&IrR7@}(hH?NT3LKWQKmV}Q1$=!9Ib_zih z*->-UPg_{8ZuY)}Rx!VHl$ygamU|;Y(o>r-91Di{_9{yFYI9&tMznmJEKQH{EF@Ru z#O7VX)BswQc)BqKWHMIAp}r$~5{c?wOxtv%3U|M>fn$Q`X_HEyGN@&%F8Ko(1LoN+ zdMN*?p)xkC&AqLJ&h;dmW6tQ-VzEpRT~b%GaheRyrt?{2qQf4vcqTdAfHj3s{haalPhK_UyD8-{icKT)Ij8Azg)7qWNLMIfgBRj zi@k4+6jCiAEgCSDe}N{0&1_SeA?&ipcU3T*Q=TJOX98Y4cY@SuWrO@B#A1&)t)sp- z-K?(3aeS?Lk~CHNg!fk$=6zr-zkHiJH-f6%#zq8yqgxl*Y|U4DQPxrGV&nrYU1|f3 zJ&uMXC*5<73oTpEXr6=z-ew02*4Hg>dm}vQdmnLRVnFWzO--hOf!3ov9&d7v3d-XV zLq;ouCv}1rWxV1)@>BpTzPa%l+(xvuv`)!mkRLcf4C5SOJ`fz^R68p~j2$vq+W>iG zT7|jXaQHIY+XOL8FW5>3!a}tTR-B}i@41~}Jn}_}V~M{4-Xy!~A7e~NZC`T*AU(Od zb^WIf&fDAZZC6Y$a-Yrn?N5OX8(jDGx4=V)3K%_Bb#&R@S0ZL~@LC6myO}cC;H@4F zgZ5L402hTz(8>CnpY)jZfQ-y)-|s@tXVqT0D-~N|gM31;dw|QQrP-p?_vK6(v=y=O z>1hgpbiFGqY+`Mx6SjnM=2pZ{UPqITCe5yH#UR-zaWtLgv<)}Z^P}{ zO8zD?N!t)$eX#=VGicL~x8INR7$lL(Zb_L!p>btBVP3`v^w{05nl$qlXQq_GJv z;Rs1a-;x7V5ni|T{?q~b($=A>g>1WQo;=8ti~2|~4e<@%<60%Gnbu=4%-210>{nvt z^^NrPLi6zDMv28f)Lw0=)kWu+szkLTwb`(uO6e;3lpC^f2OKv0AYw{aCT$OG*lD@s zuBhyNUi%Uu?nW{Uswk(Q3KMuCET|sHB}8Eq8i8gDs9f=%Fa3|}zv#^#N^kbcST)3e)F3B^|)i%3X@VG`LcbkS0Y zWK1oCvIc3&lF>fVa3{H2oiXM7HUbPs>+|xj;sbVMcB|@zl zJAq`@2~`KgO&{9sCXt4(b`13!-o`^z1EAL!<37#+kd{%u*A^SpD z&`cZ%SNDdcERb0QX-|qxCS{c6#^U8_Hd8A-C^qPfL0x%ylH}vg?4UjceC;8|&9&Dd zg-?V4mcy~sS1^&sV>m8-SA@-U4a8ehDxh5wG1y6^OH&6Y5%A4Q%Ydf`G+wtOyBmj6%FkYIv1u9s0pMiPbRiu`(%jj`zySD5_*VlIse~ zD@!)9WJq0F^uLyi53K|sN&T>~Hb~$EXw(a35;7-1ix{ zO_j`Bjk98@cqc5_sbea1Xo>y(cVCEMQBCVBH$w>fQ1!vET=Yju6*vbi$lmy%uz`^- z1bkqQr749aA7TCk7&(={2ckeUA)xv+Jf`!tPdw4s=K)UE(d6wlv+|GE4UisigU^&o z<>d#`43ciS?v)id>&d_!fR4pF`T_HA9lHeOensqugpcQrX-v>>4}tckX(0Jzh(hme za}uE{`Uq^I_La|QW13kAegD@~j$u3T-b10>6W$d32!yWoR*>4bqmXSV{+XA~%mia5 z3)2!h50#p^J6m}QhLqth&46Tu{6*z&oBS{n1#@&O|L;Nh4NqViJ|+Fs5xFw3>?e#I zh@DK;X7X>^&;jmnVaWTxOQP1XbDDB9aEK9p+$C3aGZkzJTd(Eq4y!Ng`ZPZ?`!w>M z3&P0Oft}@hJ~!xz)Fg|^%RHIE-Zy zn1z_x7c?-M)R#BV3_+C(#lsaB<_iPQ;ELUGo_c!P)?7?2H)oFk9B^hT{od^F#vcIg z%_6O|zQe@~tQ#$s{)wp>&TtFw1kxSqI4#7A_0Bb|8c5G1qGgc@e3TsrXCNc$jPhNJfGHkqVni!fGOms~$&R+2N&MrlEoR^LKL3(tU&D*6?jvoY>?&aR!Km&T_@ zI6Fa55r$FA?h#J|z3_uCb=c}k_y7NF`wyO>MAc~V9{?q&%%sYMt<~OTg4WC_+dQ(7 z)P~`a5pYCbed{M$rGA*Sh^mT(x7~gxeGSW^77T4xmR`99%h$2`1VTsL*j`Ygg8Ov_ zVg$o+(JKbnoPg+{+jDugwMUQ!r@=mk7?fb=8y)Nxiw2^xEP;XPQQtFQ>T3kuUxwlM zaGbO>c}U$fe}$mzReMw_-b~tGa3EMnHZ$@oOkaAS63aIzPl9Kyp#BAdVEnFU8Tesx z9ne2EAI4%pV_-H1$?q#XhQleugULHe^~!aUk%jhw2|5h2A#W~(RouSnjB9+fc$z-! z5hh0MZOF5{AViX*VsbI7j!MfrnYY&+&s*3h?F!bm+Dq75PpgPOIvf@0R@Y+o6=9?I zG1bh(Hg<8ems~DMvGW{nXz6{4XbZPxqk$<;?@2pe%#<*(kh;lTpb}BIxFHoRw zuVh;LJ{SKF5e~qggkOiqLkX@a;@6C#%EmE`*C0Re^cv@^rr#ZuSI0qyQY2q|d+t+! zp}s`YX~_Av(0$zH!Ny>4;{lCrPLpd3vh@DJ zZ5(%+_qTfnge+pFdj_EBjYMDokfLLY#DJu%#I{6`lH=V?BvF#HS9KRll#{!+>aE*^ zlATSxwYxUuy|?Nr7h9B*yMOMDMakKE>%Cf=Am!|Pw~568DchTkL=Heoax9YQ0Vq+n z2%rZbEyW~e-r?3;{D&k8^P{`J&+~caN4NZkcL3X`yJJ+YpvJ49q`dr~x!SOt-9+!X zTwLQ=`zE-gbe?U^Z7HZkq@l+1T%)Ux7}WHC54rx zTIuTeFK(?1$-GsGpAi1c@OG|$Hna4tSRVq_1)rvrzZFVGwWg6qVA}y{0y>s`3MKgG zUf%$Tx0ILVc4=wW+$b-;=M-P<=R|fNFtz+3zpq>UrnP~}f#ov537x{EN&<@<-eg^B z2^vz>RY*KG^*J%)XYtkxrDGr@7DC?&hVdmyxeB%%)Lu~l9rU$$yUM%GBGsJ!>8A>k zSO5QP!aPVHaBRIj<*#{>avRjPGz7$PTF8yAwV_@Zn#c_wXqR zeXz^L^oF&sYd~?ZyPEYX4ELcV@oNdQ9=!ziAa?a;-P-~w|7SqGg0|O*i~yIs6t{I3 z_6rOpDB0(??&SnAjYp37Qk4gW*G~hWhe9#&x-ufqXnu&}F0!3f=o0dG0y$%}%zeu9 zsTx(qK@N(u$u}Wk&F}VWN$9rzY1Aty6^?tgPEwzh?H=~bqSRnMmQ4WbnfoSoy*PGB zDYw8*6x59G?~d|qY0w24+ENSUdqrbVu)e|VgnJP=kwb{eK15e@<())S$+bK_v-M!X zo9IibKujZPfb#4?;i>5O5p~q9s3X!bMXnUusVsB2UcRa9n$`OBF|QCsCFv$I33ib? zE?<+CQk^qK&|27zVyz$?!At)SL;X$BAW}e{*TC%xX+gb-)X>*YJM z5xS7OpalcIevO=WsDn{l`zeQmo=V5|=ekmnH_?v$>f4~pJtO7J z5se`~AUVF{K$@vi*hiz+Fnmg_gF1@62wu8|^Mp$9b};&wJOi2VrH%?a?#1SkjC;?| zvbxrzg7IIdxaAE3boYUmMPFx)3MRs1vI9jk^=!DflERJ?iOkPb8&!0cZ!hveIHo9a zP3-EFU$NRHUb9$q{Hr>H;}D4zPEJM8Xt{w#%F{LY z+xq+5u;j##NVX}C9)SyKC#$)8l3hRZXn}I!xIC-Io?Ti)-iMKRt^DaEcQjtT(IB3(inSq`&I}3JO@ly*?5l#U4P4!c_;TcTR=h`$0UvMG7Dek)Bih~5n;$nX1UHqv6Fk3yQAk=4Q$_c)3 zPz=aL^m^$$Xn{G}$E0=|n_Z)P7dkq;MF{*pjs}xj|0n`IG2iv~5=~Xu#Y$b4F41BH z29@|2B8oK3O_lr&)K(d58^9tT;QBn>V9#Qn9ay^afD*I(5FnQ9=?tzLa8agAYO9E3 zlX`zZV zYHO)SGcJlSpy?(3l~#EP6IFYqe3gSv7KXV`J=hHrKJM%8Vp2};{_W3Z38^4V>-FZd z9wK!qIdX>GkhO8=kystTJvb0jG%?nahwaPqJJ)$+)dojimS2c5k9FS{^f9(UoCeoz z0ws2w@)KTwr?MF$>f?)P{sp%+*A{8_89uJn1JPzy(F|He@=pNz5VZ!8*Di`zCx*ju z{&OeHvFty=I}^9VU4UPyE8(Fm@_teISudEABy`=0YGQCWvGx9kmvrI03|T%5cNDN& zELMZJ^w{of;?PI38tb~V*Vba@KFK4}5EVYdzXd5R4O54d(~3Fwj^}D{;+BLp(BxN< zpXyt4gS?;{b#qMa`Wweu2x^-yEF74238omTI9Sru|!PIds>ImUC6=z07jiEWoHUPQ2kq>zZ!!Vj|zQjsjAPj>|6>${{U#=YbH;VvL!wD zPL;@qs~4jK(+Q#S5Url<07Z4 zo(inG!wMiw+neZ^6pmhj;#5*gOkv2O-i$cU85x5xWuRSFgJ}MGARm`VWbx& z?SBJ|gK^)67HzeK(}=iHI{f+8%O7dAzA9e|K9H6`W`kbJmZJNB)WB@lj|G!VIKj9- zwh>fCrLjDTXPCVB zZ!+^vb#rNft%7^T3XV`=H?8)e$Z3pvzufFjDZTgb*1E=wyv2*FQk~}CB4Z%kSpsS( z-v!FS(}KBhT>K>dJcVi-MCOrpI@pe4e8khwQpqC+?nD+pH0oag60GCl^=S74QK@(c zbbPmro4h`ZS68CRZaVso;l&C5wmNv5A4E&a>n+v9#zmt6c zGw(CRmo9kx5uJs$#2ZSC9!ehEp;ns}RpHu9pBCD*|5;WTtX3|Ty<|{v&htE5TnMN! zBk^jmcDhwj;tj2e5cia|NeC{+(TYbJuEu6d!>e@}+y`lwLEUZ{;x3Gcs&LX+b9W|I4h( z>FY$B1$X&|9fZH4ZW|A27+yvswsn=R4-C-oV?-R8Af+-mout25j(b(*S~-VLm`I! z3D`?{tiRB#b+FS>mTrOv%#*SAD%PGEmdwA;oanGkEBl z_5rGowKrl!Yn^M`EK%P&vS~-H5B=*Egu)gx;)3PdKQAujZmcJ^c&*U#pyO`gh1mYPi6!wM@c>AA zYsXS>7kT8RGedQ~Aj`L=`ZgkTt)F-y8hW}e(#qnGIR#nc!=$xwv6PO=SNWor)>3tsZ8;G!1COXF-Q3k ze2ZwKG2X$I|68H~3rD29$0TcgUqe!|3fVu!JeocU?i}oJ9tMK0UWDbt>mUYFhBxXY zDdr>FkYdNY4Vg#Ufs-or!FhUO)U$Zwu*gLzChV&8XkBk_$N+;+Jmmp)Sts}g_|r$h z>3xWDhY8Y}Ii%7FD<#i=7EDZ=kFe-96ghfHtIErDTVII(Y#)v88|$f80OuZj4TU$quc#vF*xUC zzoYZS<=K^%huanQLyu6129Z_+-3{01Rq<{K@WA57kVt0XuyXhzps!(sboTE( z1AIIR!1d}jMd1V?T72YO<1u*@d>Vob{QBCH#hTkVpji1Y$g!%t@nn-rinKa2R3)`P zbddu$y%D5&zHR!)Y}$KXu%C*TgATwD@IMG2Y6E2Xwa0{0Nw%!$x=*3r?w@b%SENc!J#(7tLe(0gUP^f$yET&0 z8lZeX%}}GujR#Z#9*Z{UX>Y4Y?R`rc^_YeRqhe< ze+9_H!oZVwCX0r^2pcdT9u&N6a48IS+^-~&4e!TO^Qo2??UFAV@su$fI~h0{p6FkA_^9v(pAO)i;@)!kAfGvfoBQMS)T zS#t9)yhA~}a#=r!eRIyN7(2$a`OF4H&F_MV7FY(hXZ@5oCJ;!h_*AX;4l_^tkorJ? z*!J>TicV6Mj(CSa7?Wm~t1U+B*MM8)OGxL#M&VN)u68ndjKc)D1qQUP!+jp zXA`hakTXu^{Y#J|w%5O>J=*4sjvA0XY!BX8yu!E?ftM7W94$PT^?M0+ll66avw(_9gO zPGNq&BJbKjf|C}-%~?)y$8Z%*S{~{+@Y6i!(xPdPIgJ%V%7g-5KH3H@*H}sV+i?Mk z8D~e>`U|Q;tm{b~w~GoKLP3FD(_{W>TdKIblg3)S;3vuP(?nyxD5xUnPbYmEoa1I2 zAht6Pe00=tmS&8+Y2Vo-qvQdQY4bwGbBm>PoneSw082~UIf#6BSzCg)2cc4T*TfWe zF16-d>)~z+LM+(VHURMu6fA##QWrGygkW?Z__4;d_4b(S-te|&b?IbeW@!>p6E@HD zMW#z5gl@0oAsw`g>(|Q$;#J!pF8Thg$3{@NLVu^i?36iubE@uH$OzXg#H!K=x76id z;W`?Hewp;OS%Ct?2mFWx1V7ZY>>&aMKh_ofUX3Q?!L`*(I~zy^MnJMxkz0MuNh?cp=q{cc=AdQZi1qiJA(!jTNc{%b zYd#qhT!s9L@8Y{zk?9_J)vkH+v-d6%g(7YMjXq4tMLB8k!~W_6Cg!Nk>@Stx9{Pf(Yc%-noT zBA2<>53|AuE`Q}ke)mAV&nb);sCOLUV`KKRpM%w43Y;G3Upo1mcHm=yVp@+bmm>yV;L4!>UBn)HX%4Ha)Sx0+cS~b-7Ng_Qx8xXQix+4JR zTsSfX@a;dUh+)~@$$dGHQqQ5TVW9IQ=y$Vt9%w5FZgb(G@7G%oBB(b#2$)`DO$epR zeL;_X;($nl&sw`{t6}+9$W_2JPj2&+8$8Xf%t|eZk!-2FO=d1UBH=~2WEI%@C|e#! z?%J+3G^!8~-bU2pUw@<`CYE!>`FY=TL0ryNcH3)TZry;ypU_@G)Nn(gnZ|1DY0S~f zy-MscrFgG!3*5tCLSz(KQyb>=q(L{Tl}Vm|n;Uf^->h4+>`84{cZ=0?wug>LSgcOW z{YmfIy(xxlj`yD+b8nynthnOmQ&lqstyKlxwpTnA6tPk~+>3^~qo+FWti#XU zps5dI5bw##bNFPg8G(j4`OaVpX|iv{i<3udUsjpAX0O*)cp=wwZW_uq&7FeF8(efzo7zb|cDUEBjxpBv3Mm|u!y0i(|rAHhk81EXwekw!tVU#42Mg`7dbQA5U?p4BjMPaup z^nvgqh+oX3SBRQ(B7x0$C9yX@I$iPr;`(7bxS|r;x+4^Vi*BUX+L?AK5m6cvsTj3o?^(&tI_UO+$ zZBR>j)}nfjAiuzAt?iF0uXm5?vNhS8b`qnD5{%U4RoHqscT6@{$?TprGaX*vPE`)~ zuO%FXE7C^^(3b5!J@V_GuOT8m9B`?L&VZ>zxiDbIVz1v+s1{XY@%Y|Qu)C-GVE>LN zG)4DPK`)v^!rjddUJqr%Z;q8?@~W};A@GGi@Vc{Q{91AS>(Rc;XW8vE=z}&ZA9TZ@(t-o8?(3>i)aszb% z-FL8AiJ!)uqmbK6hU{GIJ9DkPApsPf&TN7};qIQaJA*^3n}uD;s~OoENG)aAs{|Sl zG*DG(ibAyK5b6oW22Ox@TbmmJ!5R9V7~u=lcnO^d*xh5WBH3qOjzaR$1Rfgj_;QoRrSd^(BvP$l)2|ji)HPHI2mQeX zB8XIn$?-$@DT>mu-7;tKQzyy291jnGUR=9uYOhfi%VqhGT&gXc(|F0BaBqYnnR2vl z-b`I2b8hvA*&9&R-$7g-i_S{p8f?&(xynk5Qy227i&g8SG%((=EDHvHmO^8dHU$gM zI0FFVkQ^|D-7arS&Z_N{sZAQ9uTX#n4X;D58+*|+`m=LdZh(?e&-YOFy;Z@0^o$u` zPD5qYu5VVj{2Odm&(j*2aaUw+^OoT#b-Lfx3wpX)<(y!#H_&;0Doz(n9UjM<_1dNE zcc6ZY>Dvjy&I?{zYNk|B8ZcF~VDR5lG>=IQzGk$dLhZA>VGg_AKDXw7|BPGrORgE< zzb$hz=Fu!toYKSP7AtgCjgxRY?m|1dV!bslB81v>A-4~L$8h-!xU;HlcP}h{1=;gh zIViYO>KR`%1W}(Adz$W00CxxRu|v_;govL8tB)qiV-*9eKat-nnM>rCWuyF{ERR*l z8Pu;_9^>hQtel8Vs>Y_eDy|UWWijWWX!oSD}5%< zJm4NW=MA1OUx8^k_)Cd*L+VvW{tqXts#~V$JntmM%-T&+gN$p@m z5a{d+fP!0#RVAK|qn8gtz0e1JqyeYFPNeT4;zk++FbbtriKi!L78gh4O;drZt6oq- z^&2<7N^ecX*S(ehK8KY@w1Nx0u#EXbr`(LXoO4@Ja1Up({9em2)jTgg7RWZRrTKwy z{!4qRx~701d3Y;`q9Qa1s6XC=LdPL?EWQI|zIDef2-W@nGHGY+O!l48`lcko9cLq7 zc_2fN?4h2-3*q=PWsMmlyejAi4=#LDcwS+&zlmpI`VnkhRMO_Ylmk3fufnJpjO{y& zXxt|Sb-!wN4^|_yqcpf5n=4+*MsiQREbHc)0;H|HWvYdy#0&klmi~E}5RWwNT zB{}tga+K=O81M00+v!5u@WDMW+oE;LKPhfk};B0lwDQ#y6NsYjFm3NhX!x{PI zlFO!w!)_!%%C#-Xg@Y+_t`q(kp5e=~f(Dd9gcTpgT)5oG!Mr5IWse|0F8o@d^yOBZ z5hd_d&6DjEE60&u(AHvl&#!$-3US+n{Dsl3lDtFa!%q1+Dkml&SBe;s|9}AL!VPQk z0YtKLMjrNTe-QN8mws?yDzUiD0^d@?7O(&7`mY&tmOZBMD2bkfs-XhCyPZNhTk3p^ z!*&Do(x{EC;Ey35Q+%x+&ol>dup4U)N=V$@8b21*^;mONMDa-KsIUS`lUmh;9|Zf` zV)0&IwZB_^sA+J^k!P=!Bkx-`O6hlGPdcDmA==Yyvc8tN@dbDTjb~n3=le3oo$gJHj)8BE#A=;+B(f5kvrlGr0 z(ApDO{Y_g_x!jz{qsTvqQOajRoo0N~=vR_&+DS){S>G=Ia|S3eqHZ$}5f&MX0T>H> z18s9LR3$7Ie-Iu>sOFkCR&Dm*6?BcX~i>@QwCpRI6>MB^XFT<~RzFeH45& z!ur(J=7?~tE|lPr>D++>lYq+kwq)Y{hLoAe^$SO9N76FiRsEdlW~0Z8dE*~oRMnzn zUSHNXz7TXfU@H9MK~CfFzzSFUJ)^S+a~-q)1SRe+U8J~7^QVK#Z3k&xJza;6+cE1? zyJJf`E+?4QRX^8h+xiNAnVz9)qz3s;Plxdt+Z&s>J^-u8sNR_^U-kW41fK$X!mSzw z!VKZB_e3KTh3U@R*Hdz|mcgv@8rx4-EY1&W;XNym`?^rks``AtvqGSy_++edjL~Ss zm;Fl*GB;5~B_BB);bABGAhvE*szX5O`q8&F0O7D!3)zd`^~Pqu$xxG%A8^0D#_*`l zAU-Y$t6v)2me+3VsO#gZAub+aOt{mF-^AuF>B#MhXa<5ZiR>6xmh<|4@~tbpJml%w z9IK6o!=T~6lhTOhKZ%eKZ_1%CZfHa{!k0T!*&bM_#Mv(Xx5B8%o}me^&iG@&Fcf@K zO5vsb+FZUeL*O$s> zAXRoH+qp5|k`+!zDG;bOP0@Pa<4AWAoeq!Ca6rV<1@oaKtF}=+aBgq%F>C$|l z>b1H@sPsywN&M_4a6xOxi$Zn1P>hxDO)p=Gq7mCU1In1-+AZ0j8X; zVT(z|V3yVedjit3&qU{e$wji*a#kudu;uD0N4+iMMz27Zxw1W&+gCw4>zJOry;P;6 zsCt0I?ZdS*vMMm4Fii1&_2@pb5@j$X$LxX)X1Cds62z$=gBcrigW8@6h4qdmKT}~k zoA`Q*CX85)^@Ic5EX=2YM=Sm>ttte76ehNNvJfo){D4@Atn!=NKz2W7bDI%)C`*f^ z_N=xO4lRj17b9(D(|<%jS2Q(pVfhlE1DC5@=nN#!qGs+XueQJ3PJiW*VxqNU0t;z{ zB{uTnk~voXPF*ESqcr>*F64|HA2GSyGSUEfvC)Oj+RQzcB^!{sOloqcI^<(D(o_M~ z%MU-q^=4~RmykqmWudYxJwgyPa>tPG%GUZXn}bSzF4(biZMRkZh$e!8c7n8% z1>qBoL-))+q*Hblk!7N$b}(1{h62oLY1GnIehL0Nfeb5~#C(6(9=HJ39s#U(?YRs~ z@gXM4)0QRfq$vZ~u1x2{2rICUEAi@f%V)?zcC)%??y-W68uxUj%uBFHmrglJx^!}+5GM721`F-vO zRczqi<-O(rqBS_m+V`dfmsSSsyV*qaf(&gr5ND814quBDzFeEI*SMbTvzjgeYauYp zX~tt^9xugpKdbIL2u_jj9y7}h z8gjTf^Uh4E!gKM`|KvPx-))PYj?oM&54=d*1Pr~py`-EG@Xd$pwVWk6^qrc@a!bOD~O*>Z)Q+Zpe0^rvJ)gxY#lM zp^M~JdUQge2j%C3O|Cn5e_6{%L37&yw1Ti|hONJPgo(2QSlEQKb%rz(>m}Ut*Xs!* zrh=4fCC+NKq!!;KF00m0jno5tjB)i&cwYra^$$l-Qd%&bQGz2g!dE+-t?T~(|Fo6p zCmo?sbO4|DBPc;BcXaBkD@VBX>aH^9i2P^`t76wH495exa+yb(5A^wU7aAQtRvLAY z*X8~J4=j|L?<0UeffoL{@N?dlKe|rl3C$$aP@#{_1qFGicS0$|Mx+#AW3V2|^L>qA zqU~sFbw_rT=}n(7GujwMo@hfde>~)TkjQFGo7xvqn?TjAu23-EeZ0G8Yp#d3Sbr<| z{ZTV_27V~Q4k$p%6!|g^K|`DYk1fpKR}E{0utW?liD!%YfMkg@KW+DG48f*&{!TqYS+)$<3-X&--pvdM{?-BpV31WFP~o z7l~+1-px8x*tl6E(vX60Q=)cpKZc}69~MGJZ~QeDa?2}?F7K6We`gMVuYzi$UTYzm z`~#+A1>Q(tsK8TZN0;>d@@~?dziIVO8ApAF2xJ&7H5MY%Y+pdPIwuP5qK|URFLC&G z1?;boj)r}%jG~Pp8|L99rsi)Pglz(Eg!~@Uyr30rot`eTD@(5f5~*5!y~r*BZPcS; zfzgi3i=H3*Qsc;VpnS`UW;AVVA?NdQ!vBJg0_QZgf45iv$|`(RM zo8_2z6pD1@F~NXZxXIFFVT5E4gP^QALleXU6Ca^{F*<5L%R2W#O4OL4398svlZS{8NpE zZ@U^l1yE#i=0^ycIZ;XF?F1uxEeOIWUy{xKY5nDnnz6l{$D{0d8{H0bv$Qi8`9*zz z(4ssg!PjF|bvb;L@Y`8JUl+te(PwlNo=Vn#P^BmaqsU6f6R8#7Cjieu@{07Db%F3e zYZlvy%GZTafbZZ_$dX?ID6ne^B?k?hF&3gv^U#a7faqN1U2_oiwIfxLE9YcuI(uNP z)LbeAzQ+qtncn}TgEMI&H{#{l$beZt<$RSaPN3JoW7lzn%J@*uHvkFPY0Q66r=9Uj z!FS6P*o4OR49sVsgIketimzR!djN8e^r_%fuNTz!9C6{cG$=qSUa-D)Wd`hzmwrfb z4wmyzdim1E{H563w0uMj9J|F-8CWBHJZBz>%5ut>-jpf_{$$zS-}#SL-Am$6uQ?OBJ#@1O@wKnEGyJ=mF#r@ipqW2jP<%jfiX9`hd5jmU--XN$)G30~hUz{=Ms} zQ!Skzv6g!-Ql}aRZ9*~r;(+MvS7V9Udxf2P!Pn`#Ca1jQBTgied+p%vDo^15$}x}B zlSZ1qAvx$0aX7i;rXyLY6an_eJSkE3HI^R)Tl=%FG(5%lq zLxc#8!srF;34@G=Nq&Yj-Z4r3{S5?5Mgco5e-T%LcSBL!A37LakHS|no6F#K8jZ4z z2OO&A^bhoCvJVy_F#7&1$0Ow>@@bxXlEJ?Pb#zdT9PjDbp(-h%ihKK)+XcHo@T36) z$5o$7A$3LtVcFu)9-H%XgPkt}F)|20kOJj*>QLt9T>&q$cBuKgPY2aLb-B1(fZ$ml z5i7BsdxQ!1#7UE=gu%lhKJ_jp-Ao1*Esr2Ea;m zR}ru07b>gLmRHy#nuaF) zm};R`h{l>h>5A?p*xCsb)Da8o;TD{UujG=gtsTM-igI%&_G{G+Z8YE#^P=T^;h1CI zd2U1Cu{!4e21V7bYao#Q?TW8Lck$wfjrBQhp6PWPIN9p|O>p9`HdTF|wU~Zw2L-x4 zTgl%CPXt`alqZ&Ii?0PdhxF>A8@lJ0g_cmNX$_FJ^m{o6JgvIJERi~O1_?oRW$Rs$ z7q#Nv8YK1{Hb%0e0j~oN{@ zy@)-Mj;BsVZ&?TeiL+6=GJ0QfGbaCHC$-FRPM#aUSBt2jHB!>+6(H<@X%m)n!;d0KQ~XF}XkX zpTML~_1?5B6rt0t7dA-&U^hS73cgl_>Mv6{%Y}9PVzcU{y_Vsu5w33|%y2W2$R??! zxjCftfv^Hpjv@WBjAjmS(J%8GJ|mS4x1p%ejH%9=isS=~Ky%4mr22AUUo7C`u{ zvBn+K`7`hmpQn|;1Yn1TfW%ojb z`v;(qy)aj~6WP^!g?p~xa0Pm;AD0i2V^u7;~` zPnB`uk`bw9=H4xO9A8|%mqyPaNUm`(-n}`&P|*@13I8-l($LXmiUzUOjmERW$5YaC zy=3+rhmzdb%SNZKNRrcL@#$g#w#mIsX4O}$@MjXvyBXL85!Jdh=iD0yjpR}{y>k3$ z$%EYm@t)(DnW}W2i|I=?2HCfF>;3}*#ju55j z4MfGnK$r0BDRGL|05^TawADFCmkz^SHV(>kS{4#Nzhy-ZAd$~w9;|)zYugiSDBV>K z#9p}KL1S%tn#Ny%n2*cq6`p@?h~_FrXzUV+IGm~0TNDCh(bw{nwmxskfTJH@u@86J zv?)J=fk(1KLROt$z6|0`=xwt0!@Jx;+|MqA)ka5dfpmQx-HB}OhbwRJt!e$^BR~q) z_CyWkxjSwcw_dr%iuYksGqnr zVhT=#!kZCS(W|8^#r^vckF=xfDNCm7VWSl`Kfz7%!mz$g)cEw_)vd z77*5%%*BEv{t9R1YY1jxZP{ci@~tUG(bR1lGo(t5y#p0d@5$UN7Av#zU+U#cAMg@{ zpG=H11chNxDvaOCEz)CitJIfG&rR{U%@xkaP2hKwUl%ysKclzH3SjWRC9z$lA9CB^>o2@=ns05+KCXjR;__| zogIM1`o{HDX0h3YiZy!GQy6VWC@$bOk?=L-Lt0<#RCNs+Y0AgS?6bwu8fc>SqOc~$ zG?tb@iXQ4=-`FM1UaT9A>;(95eQ}a!$E&z6Wy5JOqd$N|TQFu019iZ!LWMx%C=XJ& z)_|e*&>Jq%vnm%uw7eb2MbmHs#2H(tRLYw<3kL>wSLNzMMH3qo1Ojr-%cNc^E)F#2 z$K}jNwie&5syi_1Ora)4nGX)SG*g~T6NzWYjqMAQO4l$XDCHmHh%^waUP8(6{;77H zC&(u72ErR0Pr<|ZK$q+9Vuf}f(2Y>`75q6tbkR7lG&T&du;Go-QCZnv4*1rgoEiXI z6zZV$A9=qWL&YMINxSG9NhG|HgXg{r2lSpHIkU!Fmd2aX-}XFxv~wplkTuiU@^=yQ zz$st0dO&;jWn*g{3~>Z^tZm@lJ!y4qvC~IjKX34rf)FM{pq)d6L`UOZU~BP@QaKXt z_=Hi(H-=yxR!1Y^a8$x8asi?I_q6@|VK|dq)rdTFjiJVbVu}VOo$fwE+tB6ZNbbH~ zsG6O#FHKppc;hgXO?f{34Ua;NUU}%U%@3nDzrShsa#TN*N1a|ROeNku^WiZs!BlR_ zHSD75GRJ^1Qq@?z`(RJ^@$S8`{%-Vth@o_%X$pk}7xiC&-dP>2;vBIb6CM5Q$@JEb`)gTX7LTd?g{n-OjWMb$>v$ zD0lqcIPY81ULGgJ2iz4g=^UIkldG`*GM$p&KC&D@wZ*$E)ATcB;c9fjs9+OgT!%{7aa2+{WIy zrMLGelYkaPSe*hnH~SczLmVhy>a&Ik=MNyp=*&Z>k)u(oG3dBA`8NpQ_KW*%>&Y2D_gq%`CkoduOU@EpzXTKX1~Iy ziw_9(bUDs^yLCMlV;3dLTATH#25Bah{TLOx8vlhYiO|!m0gcRFbY0jXcsb?9Tkhhj z9ipY+@_TtSlu^4SwZTbCAV0(rHR_y)$P5kvIVitXsh2Wst;z0IK3U%Ga2)O58zSse z$B+$ZCj_D+EU2pwV_Jk}B%?F9BN{wzZxSe-3%2T2n0s?GPwvwG{-{Y7e&={?3NI_D zMm{Z@WjL3J!SY;cfGqnXRBO%se;mDWa2wa1=lOfD8-z@v`@L>}qGO9d10Y4ml86RL zNt3Zif|Q(O6H5f8%+=LhEK$zvR^8piqU6lX)zywgIa7PLJF!GNJ5^V88;g>Yy}P=N z1WL(P%}gYMl$=yzi)?_DWLqNe08o}A66n_r%5p5C`X@z0&qHJ;It=2mpVjzvX$4=DkJU=IUDCO^ z26lPjGdIxZ6=ovG2eWOho@RLZ9|RhI`@AFZ2^>7CV3=8>#li|}N%&+wvTLHm{)yU# zF|v#K5lN=$ZHPSMRWIoMCEw!)PL0$>I?&T3&E#4de6N~}r%X0clZkn=7$wt#*15(n z8;jSI{5uT!YRPyazBq1mhYS*abIu;v)+Y$@!PopYI*bxmnfx){N^v|c0aQP7X!%n7 zjrEegrNE?#Qe+qOP5^4R#ly1JMu;6>{(hf(!#YH^`#3~p<9A^II_1H1s7=u*&6qXA zEvw*G&ka^)t%I3=YP*C)8 zk=s%-$vLl4!InSzljrE}`31(E|3%E(;iq<6Gmn zf46PclKCy+%&ewAUf;KBu;0r9G^F^X42qzoD_4(E0jGr-O`e({LbnMFu%H;iZWWQiBY7H@DmT?>y;MPzTad2O?%h z{gUtodunj_UOcW|1N*u&1ndgHiJ&td-f>>OOn^C=_ZkLgoAY0W(nn=x_m-6%r(9XD@s~;04ZFCjq3!a-0B~#;_qEfsL$$dzdZ+O z)sCKA=V`P;lu)i)E@htcGk?7WW0Gi}dQ@vtsU_&UZr8h;i?{)SIhpNI7B`r8)-28LeV4s&H*Nffrw_4?T|J*|o?MduS zBvW-?`B)z)VyU;bAB}wALDm#?Mg~_VQU4qtTGX1lClyJctp4@-Sumx1*x2{fP50E& zKS!X4)a^XFxrN2Slfnfr2QitVy9Fvc_r8M-p%8xD2#<>t$BN%1>=1R$i<6Svc%HLK zF4>+j-S!lygAA?H2Z)4*$xubWvFMfYQu|30m)>=c!c$AWV**ms5$Z9*ZMIXF-z(BD zdF`ovxk2lNViOlee_;kCv;fD>@*YY z$_{sWBa$r?o;9WNV)+gtzU!Nx|Ne>o+jwrE$q^BXXb<6zoJjPeyJ1!C%Zk~3Z5Jt1 zT}!spS#g2Lup{@PZLR|U`9_3qp2AAyGZ7FW6ODcbKZghkWs|)7Slof}&DsLI?-x7* z3SSS1dFiwVMbc-a{8EsG&rrnRod^`hon)m@fAgWEYqkhJ9AtZ8&|d+qt|-6eUa!-K zPR!FUZhf2L8kTMpo4K5y4rJW`T)t`W?Ba&H+@RmE${(;qeY*d3#8Z{`1A4G{tYR&Z zyS!VI)VnNLC2!jNi)oMJFq>PyP)?LD1XBEJ0JK8*#9hv`GJHQ&slx}+L6siS9-^Q! zPBb-WDXHUj`)RC{{02P;YX8n(G!#~Y=WYgMFH;3vhfjJDArP4^n{Z=(?1l^?t7ucl zDrRim9ppcEcj)+iV7k#(GBo3++_ol4^h!p9#mV+qmhY@ztiFQFGQ6LYe0=WUfThtk ziyrK?Y{-yA=6KQF{c0t6|!Clm9th%(e_(gd+FyiBX-BrZ)&P?~z%jrNkru zaT;x&%@LaWAde%EKuGxU0}GTdocI?vxpd6?^)W-%;yVPr2;hJ_b-(N9PRipgiQaXO z3fXb@aCJWJeydW1Lch8BchcX zxoW6Q#;f{b`AJS7q+NKkes_+bo6JdhlZ}emSI`%w7X)jG`DSI*=zS3dr+I};B&T^d z&Ze<^Lq7Dx<=ZP4kVUPH6f*FvA55Tk94dTJ%I~YN9Fn^Jq`qRU$o9Ksc>w(*_pV~m z*~edbi3+73(%S|dSdvfWrxhgT<VOKJ>0kZ#%Er?1x(YBJ)zBma+}_-^)NMSkijW2p-gX1;1}!XqGTF|AH4)4}Qjk z%47uU`yz{endP(V<#!kHGs3UD8!}bA^iUpz%9axr@cIoBdBDQ~AGegM7F>K=Zx21~ zzl(_V09at#Ru^a~evW$W`2MWAG)0k^4ObqT$W~62e#N8KEbSKN(2-v?4ysqBg9`Fq z2-#LXq4<6d@C-Cv@wA*%+d3Vr{1&KKQeN`1lQ;pk0~ZZa4A6I-$ZXrFT&v|+&q*zXPD$`#@b^YV^aBXb{RAB9V74W{^& zBERG5h6Oix%Q0RrLdVs7;w~G|ZVPsAA~UO5jOmH?EW#cjlxr2xmyQ_KzG8u7HKN2VvN69XhDmB+qv~d&nE$w>-z5 zmUqEi`3hLG#M7B4w*lYb)O$C-g{=!QKPa@I@`kM3&E2@jG0Qv32br*b*Q9_JcRi8Q!MTh>6E;NYy!I(B_B3?4I(`1%saIH=Tj%crz6 zm~R{O?r@eWrFP@)V)Zo2KQFu$)^7OzEru1S9$hi|wZ%t+xDueZ$g}575)oeYU9H1q=UgT5ja>(cQW#9jP(utA0Ia(#t8)dyx;Wx>qF7JA8Vgd>^FHIsm)D@~9c$fhXp z>xW&78i^YzQ~A$2+n-Db8`w@6j4F-Gm_a2DvfB63#41U+L zF+9&>uR=yIK_HL6ty(qMvC`heOsY-_MMN{=TxrozUI>rn5UZQ7=A&}?#1g!~k$!zp zoFB@6sVHDjx=mR2X}|PA#ifyV6H8=0KwnvL2OpS&(Aujh zC~N_=g@NL@-$cqbd9qj=5k9G9mDgbN5D(jJKf7$A;ojN=sqGfzTV|k^#IbYB_%(XT zRiQ7IMy@Z|(bxib2z9&$CXzqRBA}n-Ue=Juhgp3}ieKa67$Px)AEzOQSN9^>s*Gc* zIQU;fpNNKIar_1?qWY=P-X4vgL+)-B!W^T-1XT0WW@n zG$lc0GN1tZrV4abh-uZ!!cd2@cMvvq&yc}VCXnsk6H~N}#iTY;_|y~!ni$bqV=+;d z-bIAgryGX9TYOf4$KXt9n%)H%P;~hI45&TM?~dzoUM?0tFIw8Orrp~Yxn_m-RSo(c zVfEoH#EucDNSnLFJwIP78=qe*E61Q!Aiz7@|6t-IUpye3+!eZI7Vn9NE>%%elpt5b z0P~mcY3ooZf^f1UOdkNjkzd{mDUEYgp(h^f^{Yrrx^D{|dYv49BSs2&|Bk1&=poL^ zaox;E(+FIp*+7Xy>`sU#snA9hSvYo?1OCv6?WTI0(34=T+I%(?e~P}PYO)P4&eaGG zoP!`u?xGh%ct@ieTvZHHdajj6OAtLg_?yaNv(um-R9Ugdr( z<<9mTTAKt79yvmkcmsHxW+F!i>3`-U9+nYPJ*R)fC#$r=r#9Dy9CUA0SIC#kc zTsu+C;GtfYRZc;MM-et+V}fsBY~ega($d&Tu@gxG~1Ysgk#yct+bg27Y(v) z7|ljsaC3qhXt9p)Ke`YM)kW>jZh0b*#$gL6KVobnDg8i*7>0 zc_VrnW;yf~npLq}*f|E|0)attK@3KAT5X=R!KlV(_rC^4$I#%^!Z6gT^2kkNO%rAn z@xwsc$7N8G#HgJNGJe6@b((UMk=j|Nr@?L0W$S<-x1iS)W+#LAREkVkx-?&|hyMrD zLfrWd%?rrcLj6eU#vPa!c8#_QR;``?_PlEbdjgs0Ft0WI!9+1QPB?7ek9Y~|x7mF= z^$2c>s6iVO*~WBF!%)zVjTXBD(d1F~0hbZnukwktSphOyDVF<5&1-jE^!-np-~ZS+ zDg4+$L}laCl+)tU`rP1j`HTix3?956tJPr(g^&k~d=BoZF4os)S3d*J&8<*p^1BG^ z6YC6V%{TPYSQzt#!(@85L68vnT!h;MBDm29pYaMiX_j$U^@p~5F!p03p=i>NZ#W~! zo*rC;ZQXZ}U()9+)bmzLx)c_;wU&xy1uw0ora&b|nxm#7S|me!>al}W%NUXipKVahrph~kdiQJYY%WFc{`tWPz)x6X1wU{D zI9E|#fa##*&DlHA3toy1H8#+GK9ZU#Ho-98Ks!TsyI*$W`?g%9nxH%-FaO!i3dH(p@`M|b@Mk{Zj! zzN#rlv=8sYVa?1-5E}U-&=9R=4^vrdW$aLknfq%nd9>L>pY7mSNI2zPW?IvVX2cjL zOK85@Dyof~@BPhB05;BBeel&9PPICh30FXJE=#o|kqL*0dW);Nov>{6RE`v~rvmvj zM8lW7|7p^f*$7HEjPcElx%`O$+m0;F@UaP`GGWF}#{Au5qAMZdqn1m` ztZlr;kkZo(dg*1d0HXk+} zs4G%(*&0*j0z#qE_XD^-+v=t7YE0SktDX|cmbQE3mFXhYsL$yo6O6zfavzA<18W~K z;f<%cu#3mzJwH-UM_R!_@V^p6&Qx%P*AJ4^5>ZyTfMf*61i4n^_R6cPb)EVH=ZS`jAs`Qt1-bc}K={^bW1@9iguhy~) z!d|+-lu+;5Eg==vKP~{M;orzbYb6S26gkwhCEH8mPZvD+5e`lWP(ryb`iO}_D`ad0 zm{(Hv@ne}q5e>oR0(A7ew2Z1vTC;27BV<0S#ya@gyFnCRo8VNzQ2VIl$JA7GHoSAP z6PJ|_!G_kzGR9L&9FHx}*g|aJJsdH?EQ2%h*DYpT^=tDp`Plx*M@(vpCa$~qxOSg) zB9TftzlceOaUnYLT+PKz80=iO3oWe2I9%eMV@I~+^y&gW5dAO32MD4QsYC`#v&Z{c z6IlphKD6_)6%B$}DqiVRt_M1S5lKzz$T~|$QxZ92fNH_-T^`ga&w}(2<&GmR@uqzC z;Ph5nMcpe+a#4)5D0lHbn6@IRU&#GRDIkRUif73&Maa&AOjGTX7#o&+LxrUWTSyx) zO{$524zJcwP>8O!#tvReO*i-?v+w|(XL zGw02e@^JVqF!8t~3yZpS)1jKb;ow*C2ln!tb|mr;YMvE!|9}~6hY&|sX5%~OV<%Dh z-k+i!ZUdOyYP+|z@Kmr^!EaVq{H`bJdUlE_gU1H1Pm5+ew!;IH;ePG?X?l#zVb0;} zsEI{n(56U|`Orck4Oc;%pFN?mxgjD=&=e}Ob2N$^xs=XrC95#HjmL&Bxbzr@L1$VC zzQ}=R;$yOT1INjH|Fl24(LlZc(BwM|`t8aO;fzJKx!O_fKgu4-hcpkSbeI%0m?E7y zT1d-@wF4e){6 zA_DGq&qNZwlFTjj@EXJi&mn=h<3;j;o481c46}Oaqu%bjxtF4BeTSY$tEKY(?sJ~M zJdwlVGYHn9@u2H9RV#rV`7Rgzy0uD(py*2^bG-&{058;lFH7XDZ*m&bKe7{J;Kxsi zD`)lmC!Tz)J;Lf?jT2w#b_e1 zJA=&xHRq&jx76u{gpRYfgx~a3-3eJPx>FuCw|^~U2v32sp2=-RG^Mp*zNM}$U{1c= z+_l=mz1eW>Z+BqN(R6mGjE>Wipic)=B8ob;orE*#;3PRg7ge)R5P$`fi>Gtq1|AC410>%1f}iLh+$n_Z_FtAQHNyx0Pgai z#i(H@_AX7{ZAeqe&zW;S|EjRLKd661;3-v%;Tw_1$GOL8=_yK~Qz3P}^QkpO^+D2w z3dxA@wyZ8+O?DpBjrn=hUOelj8WX;01pfm6oE)Fh-79hm&$ZteoYWAfSE4(3swjk@ z`|*`SxWc~t0?EO$wzk`a4p)GsMEnWb`Q{4G%ioAw(-AiotH00SyMnwD)UsUoDz#G- zuLLxW!Wq>C;c29z-Mb^D2#>XxYF2zHXFk{<9r+zlsIC9J`jVD2!R1Gu)<7PT-~uux ztZua#Ri+K)rRSCSyzvq)|Bt{LhipG5k@mO1f9g_`6 zB3^Z#ZTFWnmEU?b`BO`gWXw*Y_hriS!p+#B+TPzfpeswBSL5;2EJcr}2Ey(2U+`^* zY>rTJf@%ZP9tm`7q8xfCif;MkS+ZPGINoGaTH|A(! zUv@4S$~3+&TB=EQ7oI~{X~D)$KjEdL$iTVSDrqy3DK|m;(uZN6-O${2zsvF0BJd81 zGK3uT+W^g9F(bj|40M6a25A3(y%N>}o@^wjVT~l_9s(rZCHje?6_+KsIPNc*$pQJ@ zAVqw#G^CZ64~voOFQqtRJI8hvrbnYy4?`XK;IKc-P>Qe!(tMMsLwc$t7JaWH5Ijlx zhm=q(MV_|EGKyG6_x&X2-mS zzaR3oP=H0rOr0hSlyBRWfTps1??yvEk(erO#}1Ir{tFfTuXdGwZVd#$i%Q5xvkdIC z-2V3s8*jH?;>m+rUogVxK^07#Gu>QaSZkgF5NHyzkD{R(!;+6>Qe_@o)nXH%1u73|jT#gBF=j(}@D3;5AF)Bs z&)^8BbbO6Hrm(=pS}JxK(iu68T_&fHWHd#H5qn&rcs|<<;qxPek9tMjSD+JffW&4p{3;G1NzhA zde1D`;WpnE!?M1xN&kO>^_N2wu3fYGT7&X@Ypjn3?!nv!9X{&>HEUB%h_!#$IbwJ0 zlWh$V|F(?>kW}w`Gv=x^ z1AT$TqJ`h{Bib^L)wKSJ?a)9;$T-z>AS;aaAhfp^Hh|qCUBIb!GQGftz>r?d=RSwn zwi49INlOEX3F%+WH^f~8X4e(%cL~YOqtqPMMrlB|XdqQnwq@;O1-_=XkYDjW2 z{FA9d&yaMTJR}+fm1gLOnwL2mr4B(DjMogu_-1;IHKv7BxD z3Hb2NY~+jh$oWWU$!wNOin3I^7Y|8?rW{3_NALj3g$eKF$50eLS{G8;+VClL%>`EY zqswC~-PzB25m&AopJM0LbMdxEs_{2(!DOmJo>cvtk zgTc=MWfrz6w-LYr+986d0G#f`VK4V&K0$@&V@`1b>|ON!P%FTv#52E3CLh(fbDasG z-1}4&-OG(hC1sTK%NKPy{Px@%4f|sfg8abx36|VqLYX$XdS|oc!UXca9 z{A$STTuN7k@MnpRz!x~OOmsgjjIT@fAvNp!VF&$;@9=8Mj0z(A4&V%gU zQtncx(Ax8LU;?4;IRzCqk6g$Q7=yevwLitG%4&?f)7?QBRpS#{4{LVS$(_gxL(hXt zGTHW9wKi9;`Ai3))`T(@O#s{547+>Oc^n^a+|XiX6H$s1N?VDEm~NH2l=csMR5<4W zV|2y+1Z;PbTyv36Uema8Q-ZWIRf>)i0}WAkxE0(U?_#<)vP$vxJ)CXy{HO=&rKLB8 zs-62+j1LQROVPxSIFmDg=$EWa5d4K835I$~G1Nol)}aoEx2dFb0{pH;qwX|H$+N>G zXusKK#3b1jKBE2aLf^!DJdQuRKtqtC@gR(U;%OV3g*(b}r(U6#jA5jXCpi;Xw})R{o_=$wbM6H1x7j z;@7VWnxf#BNfy|`%PL3<rm7N`~;9M4#qEWEC99hF;aMs3HqWS4#kwx_47c?IZT`72}UC5 zXI?w@%)mb)sKEWb$|zx6-Q&qFJ_2$1e4Uy?JBC`xtF8V6TAACEU@6=U;Ei*VQ*CCoe|5i zf*#Or->^bTOYz2WDA*P$_x{ABTHIWb&Xx9qAZS-ai1+{JQ34?hZd97D#s6R6i!@u9 zYC_a#q8M#lwn7y3k`mx86P^)r$9$V;IRQ&Q0aDZJ7~dT?ggtO{Y>8z(7xfdYxssJW0souRJk{lnQuw!E=)D zg4p30Zu33X2QufKIQEwjxA+;vvBY8ez_8pr6;k99_+udGmBZV$#!?!`eq$tA0Ls30 zcCKN}4c+G+369)|-WT@B?jzQTxioz^Npff}^|&`>G^y7Xm>JHaXH69Mo%6sAjE@m4Fx@ULoLDF34W8YLcU|ztj%dTxiwLZA z2D`7p0<;2a(j*#^x0})JCa9(qJu_IlEo92f=s);sc2>(g1~!si@>GhbF-ffYIU46Y zWZT3@J0X&L0!901_b-5O5h?2Q6)4d*KI?AlJ$#Lq=S~~!=xjGjutzZ0GgZ=z09}Va zFReG=aZ-ZE9-;}ZaU2Ot(?YEk^hb7ZAL}R-{)SuBS&6$%kWH_}AnI^`M7m3iCFyay zoX+GSq!`YXI;x6iO}3%ni+u~ zS;!kYk>4n0SX;!5OsfGT!_f_Th@cTB zJsvniZEkwp{16#pU^Yr+V>svQ;O<*?F!o15WVl~^aq}RiP}AKXsP5KqHB)5TaO%-5 zmq3;E{si0%Ckr1Es9i^m-*eW04I^t#muh$DC9i^1C9oif9f#FeI?|@7ap;Vrp@_81 zI=##Bt3!L`c@`3bok&TW^IRNC0o8(yb0Bx^reWssqU&!1J*ngu$KZMhde!b*Qwk#X z!N%OJO9s2|oUb)Eito*{h&&@*XQn*=ONL_2Rl_K?f66Z}Y#uk6{U!x`xK)T!e@BGt zfZTmB*8uBW1_D6NimW19*OGHBZLU_9lyqpi+g8U7O{o?kYqjm5 zP+^fPCz53yhT5JAtpP7mQ3ajRRxRo}3(Mjs+-)%ypwL431k(!SuynZt?$=KeM^&ik z!Sk3UdCGb~Ki3Phng_y1tlkmY8fyxpv5aQUzaiU?K-7vLNW5%_a8yUIC7XO%=TZH`=aw;^sAMjza8sfM*APibR(deB2r|&Y_)+e}mnSsS6SC(TKOtoVe&@RugteE|Mwla1eR%ad=8o#4!l7cR{*ier~;qFFp@&7 zCA^fF9>~K^k(@GCMUV}Cnwv1>PCwI;g;F%+L~e#-Cbph45`WDdsk7*j+c-CRG%D?3 zbPDbg%oTJ3=O07&S{Gk*f+Km!@8ITC;*6$rm*`C@tj0M{__rnMi;Mq|^?z{;daM*R6o?XnEFpn7lp z@GupoJOzeZ+FmpStH!|M*=^XaXHWWx?5LvTvBA>Obxm7{p^@-xb`|pYR8oW!%t6-+ zl~nabez_z1CuVtt7*g8vc=scK!D7~r2ur326Wm#|{in}&CgPby9iT8MnPaogG{fXm(}ZEmR-g4U^z|G^9P@CqKv)b>ko1zM$Q zaNH;bv9|tQ(UHrMF9Lv%Wl+rd3TVKbe_dboKKUBz>-6nrlITK+2E1Xe3bYF23eNQS*4vhx<*LFOGsb zv0HYsQPi^V$g6QqTa6Y5R(Kk()j#L9oFRMxrsD8Gh+M-(cYrP+5 zpe|1`1cEt9oGY-Tma<2B{R-V&@$5dw4ZZ=TT)C3Xif3W>XtIxz=zjQ__@q>*RvG0Ucf|Lg_@3bIIO+&#O&V?r zs>Wr81NUe6kZRWoUl9-91N=hP%kMBO_%V*3S{LG@s#20)8|p6|-fG2OQ`lNp36$O= zT{a!GFzGlKXPf6M$!Pr%mR5=@z<%~p{d4RodSXS3T`>mf`Z)s1Kl@MvBw1K7FQCL0 zp`!+*{w>m&LMe?;62({CAzVuZXYnN^MO+i>JlDe0`m9{<>L#*pHrex@v$e;a7g1y< zL&=BoygpO`^X7=sD)D6GrxAOpJ-6*NQ?AZ-uM-FyUCfQ=ybAhmw46iZ$k3uK+GoJ6 zp6620^OgVuf6(-m^(u^Sp8xhW2=a5eR8xRN-Vw+>mKfy4GaNl1KsueeuQ-NUJ9g-? zk82j_ZYH@EBe5{V*-Lr&TjbSSANsSPE!9g$SRsAC={`~)1)z?bSrE~H*2W|)Xm0@p zZ#U$V3JH^rCB_$0m6g4#o9*ml2}+BeFh0 zwf0O>VwVyt%TIx8P=8BPT^j01va3x|lGlzTWc;rQ|00$`FluQ){$4iz z2~cF7l{Bc;QYm?MFNPdTMH5f7+g=9In6f<*LeZ^mQXF8A*^+G}-Gzprr6Yct%qBXq zBtzCgvtQDTj3QPwGsS5d3?!Po_vXKM8FfvL7;cRPUvzIDPyxm5+TL-+#i%zl8iUy0 zpw=f}=1ocjVBJ%w2^gV$xIKbZAj$_{n41 zhNwmQe7V;tP;?iS(5(A9UtF2SPl0lyWd&a#;TBrDYH7yGqPFClyTQp+R=b;bSBxrK z3Xn@n6;qQk;s->6hgNq4L+foq1?^41C$^TL({KayAq#_{E!-@@u3Kd{OMXEVrsgw) zKNhrh@xlq7(u4qPd@3h*htTsZhL*h?@om?#^3_J5Jhc<&%o}%R%~D7C z-3qgORJe#2H-3Btplm@Y8^$BI%;@^^3rY{Ua>vf*#OOCD7G=AQm|B0je`w`b0C*}A zyb>6E=ulo3pf<@h4oR{2XR(L50YBKHvP*l?vu^opE()R?3??ToYADmLO*>9GGJmbn zS#^vlSYta;-ngK#d&zv`P2B3P^Hdwx*MUxw)B`5_+<+~g;0qk}^AF02YPpR+f^}lu z&3QpRrM_=$_1r5RiTLacOLQ5MhS;qT&SYkN1i(*uWnlZttac27w?X5n0@rGpVtd5gG6b{F8Yi=4{+{d05& z#6Dw04=4SwmDksCYD^W^MV?@9j#%qf*%0lQb_DQ$t0q z9(h!;R{wRDXp46}ApCFZe^=pif2TIui;u^c=a){yva?X}!IxDBsoRBCpu|1IeYKh2ML>^Ru?E{?qai_z#X5sAjK9~{iXifwJLNVO3{Lo2 zVA3s8S#eXRhG-7Q(%4RkGe{4wbk+f9zlG4rXxu&9@Z!BglEPE&{+XG{Y7`Fd!9gXa zKPJ01G1g^oKE;0o1nY%T`F}MRRvXjBHQ9CVG4|5(6d@3cZ;uLNJ_Yb$F$!H?td>j1 zicK_(;b6U#9qWERLv3Ky=$(%p0HfhZGd@7uN_*o_I;r3g9^kRem0*6~k7T^A-Po0m zq3sP!rpHW~@+q;<0=Sz@MC?f3C-o~MDVYl`TWL(c=EsMvtB z+OGV28`eGb9-d5tJ&TPmBOX3c| zRBCd0A{mF%;^5VA%= z`Wp*KSS9f%^)aGL!W2ts(iDsEd!+0d&rVtzVNB+M-~?IoQPNwsdmIxgzqKO8ZmaTPkhGtuKMG&&BL#EFp2jnF_#`NuyCA>Bx_bQXThe%hE{78rbYsIj+Ykp5F*!#x`FWbkd{Dme= zV2}UelQ9S&X-k%OM{bzm`A3$Cp2u0eSS^p^6cyhO9}0cpjaxU&wd%uwS5DAU`JZ>% zK|iO^5nI%!;d58CP7 znBa`nb1!J?w_Xxvon5pR@kB9I2R#-2EE*hMR|k9Gfv+lueY3sjjh>VbX_}9{z%r3- zXv&2a;HWkbs+U@laj`{%(xelSjLGUQfV;;rq&hvMfBfD)!66_6m5$H8UQ6GmIyR|NOEk61SQ4EBo;}@$=g3Bktka5 zYieRa%6nB)HF*}5y!~t6vmtq=_ODo=l$oj8iKPZ9+cU9AHb7BwERnbXD9M%x^lgB& z9Em`0bCzV01rls@_dVx(K40|hd!luEI_X7y0@XC(vn!e1At-Lx@5?8$y!GmQ4=ENK7h2;*SK1zM5)N>5Xhn>U$|r&sC=sTI zB3)kfq@bS+Q2pfe^S!k^JyG1P<^y!c$_Xv<7?emrI~t>9drLUCk_tl;8Hp>q1V%0P z_q%YGNs0N6;yfY6sSyfm)FUV(2fF}w{^vSlTQ%k)nHZhGqC(YY;60Ec_Z%p=T9e;+ zO~LgEtoEMl5<%}1vPbKko`etFAvr8`>B(~EFPD$YwHZIZyUXH*jhZR7L`+MDUt{tG zIA4O&aSftORl}5X3(f+YLk)7(nU^J*jzUi4Jgx0II$&Sql?tRla_%Ym&^l~62Exce~ zAWo<}PZ^y)5P+Gv8^8J%a_dHjwSZZyk`HC~I9Mn!(>Mj(jGt``WzbBkOTZ|IlOBL? zC|5u}AS??m3~KekVevj0jRx^pKo!Z3%|5sY+H$W)kqG0q%(pD0LNa8ld{$ykT1L4k z=>#ebCf91DwQowM9rX(|fBdNXY*#DdeDcVc-h~oDUu=V285z4lDEhlf zB;rDMFT`~9?5N#DE&6+OEqoG!^%KGj`RxnXWd1?J&nw6&UN{iye6TrZ4F;7*5BLbd ze0y7Qw0{Q#b^tjcpEJK7w%PWY(Mfvqk_U6`v=|ne;>{7M&s!1yd2{}^aH5=wAJqF+ zV*iEe@X^w9f*~bpb6b%qQzz`u8@WSeqD`=~8X~8Vyv{-F?b42l;n!ANDV_eNmMaoA z|D0BWytLAosObSuDUqOWs53ak51iK4gPToeVW7VnIxkTVYuZ}~@su#rv?q|SKeCq7 zG9!L?zcI%$kR-75|F}TZ#S?rizJseXtE14y+<+K zuxnN|Rbd&YVFDk!s%RLCGkp`vP5Yi3Rz~r>JjK17H#H>x21z~XMwk^QNvVlnExs!5 z#BOy71i+S49-DR0at72(`+4~=R+GU8jYzrO4JL+&Y-5j$%7c`F!#F(Dw(zl=?1&@ttnE|OSi6eau-W$}rCNPnjIGdT9FwI>P`ztwn)BV&VmV`$ zbCdJH`^2JlXd;5d+BBP7>bNE?t)`7iAysWQn+D&Uxz6mwPu#6vABePf zlmA;_>x^AWwGzvO$1?=XG9Itn+1fq(u^M)=Y0dd}D$7OHgS<=??v=Et{V$+3JIiU_ z#OyOzz#bBSgTLpzc=ZwsSep|Hf8KWs)ToX0+iGb_Kk)91g-ZHFw3c$YekFSBHrHrz z;VGmugiHJpsH52~`(_4&lEC)Q{_cvsoL($(K^8s+o@?W%o(@%ulZB>h%BAdWz;)ae zbx#oJ{rBuSxQiM2y(FCT5VbD+#Or!jyDzgcW#5s=v~x{H@(EQqcz*`3amuF8H^Zp% zTM%*0XKN>rPe4(C*5`PWO*SFZL=|T0p8nf-Ot@F4eS=;T+%1>0Yj#X{&kXHT>$w5g zH(f0}D&}nZ7QvCL>iKvjSXjlDV(>(9S3KqrE*h%0Xyh0$Zryx^h=0eJz;?QTa zRI`}oKwDv0^#<)a^!tJU34n93R%ms>;uDI;*J~u~<-G?3D{FPOaJJ;PYBMvYWGpOv zEMl0no3goN7#A~)%U8-aysSnwvE-}YDgkK)c*r|jxoir)2oikgV7=jjtypM1n>S2r z649vbtw-;{Fg(9$!NfPfJja@82$UFzsa(C`x{CwrrXiTWPA$vG1plq&@J@PC5p3MQ zFBq)Jyp(R%rkY^R_9XAbTQfyLETvtR6*+otb0PAX+rApqK#KS5xo_vZw(S8vl@nrt zn@7%c>IhP1)@0lLkgsU}sl-|RH$h&K0WJ-CbHosSO``%k2bfE13+AP(Ir;9SvEfPs zu&F*#j144*wS!_l<{nc<(m%bxID;$qd-c=U;dwz67r>wK>vvXLLGmJ@G-daTrQa-X zasS2CYKV)Xj%_9f!`{Sntx2Wp6@E#X!VFXgS<&Yo(cuVl=$O%bH7lAH(s?RLEU94H+ zo-vZYnn;$!dkZ)CP!go1co)vvkf{GgghT*|H~sILlMX?-+*E$jfg+Sl@%GIHIEib5 zkOcITeRgdoo6FWNLPRh>s_Sr}p1Xi4fa6M<&)5I+JzcR_j4FqY4M*r^Z4-srKSTt-7-F>2E){JG=RDcj-UAxj!~P@BYWv|NpC{)P)^`~i{-!yk9|)lN@Ljkh4z&TsmU<(okaw~ zJ)sY;H2oxW-L<*gF#N4xR^{^~(~yWUD{V;UEGc0weQz_@WsQ~;HYyxlIrow#m|?oe zca6b4qCox?y#~>%avvOtcTL}yXHHnhm9s#G%GI$Fe?GC6Bb_59c7c%Z(lRUhLv9(4 zrfMx=G(TiSXDC#})>H~s>e`$IxF zKY%>Qh2xjP{QDkGfPg?~>mt3?qPa$^#Nywg(X$$hgTlUjZCpk(nsjYUK&vBGX}lyq z08-VyPf!<`fp^gfkl10)3b1Xv23CEYH2wQ>f?QRXUhWCY4-khX>$J}Cq^&y)#%lDT zQhA_JZXSJ>(leHG#Zrp*bD4A2LvqPSP+XkHa|{*DkP8dZOgmP5J~D<4FS< zOQWiZ8eMPGn=iS{TYn3P;j(7f@Ugcb45KSK9J8XoXueEJUEDdk3wNf}IJklNZdd30 zL1rh3e{YBDNovClyrk@-^Kg{hL{>zDOaI~XH=A|16$wD9{oRFKW!f6NhGe`-MEQgD zjY=Pr-v*kjro#k=%+TigweFK^rJ=&l&0PF1hQHHnYwFzTZUol$=T2oQN^m3U|H&hy zfVqP-zrCTfNwv*IsZXNFOeZ}7_hcVMhzzHPX_-z&!epbdkFcE41EG{ly9=x7Q1A|l zn9%#S=nC%th2U$bU*yLvpV=dXk?@Cs4x`(_QjcO_I-P`ZGA|mDE^wsap3w6B*Bmu} z#*BdApC~H80$RFH--?`-VB?+I9O=6kidzF8#HHz zTw_*$28{vhMQZ&Uu>g1}B=gi8cF18)8aHpsUuqX6Am=fB3J#Lxj4JytN%KFDi#XAi z)%Y7E;;Ly-K73L_EAjd6u-QkK*j&{2K8!+jrva)=I#64XmBxCa-UgWvIOdVp8I>RR zu4zWXX(vsuq}8s!OErlWZsN(Rzo);mxX{fr@H&W;mzSFT$E)Cf5IOJet~uV5d!pdt zbs3G&cg-&3XBtH~vo^eeJ&m1mG^=E&Dz#HE(HpUp6p7gHD6vq+PjUDMA?$Clcy;D@yOqDq~=>-U+*jlLu>uuW0oVv=r&? zU0!}!dFtXxfPavA#N6r?aLz~_gf%l_~_aH$3M@Tc$-*33r^h0up^ z{{Tv(F?l}!05+Oj(a&>G8WN9F@?SvfZBA*=iy&j4U1`SOkZq5!=$vYn4uvLZfL~@p z?-qh1WIos5|9NO9=5;3!*`fW^e+v;J2Y$joM zEEr0X3r9Q2c|Pzglt@AAT=wD~^WALZ)aS6yE-Sw!R8P?Dv963L5E;<`GFsIQ2%7s!k%FD+W*a&-}DmC|E6B7;xkpaym?bswb$ zwjHt+4q{Hr^(PZ1j8mQ=vAb#4bXr+Q-=DJ8k!4$im!RfJJgxEYqs{zBfV27Or7bAr zY(w+%YiZD^`xhTE%%m=-iHIr=eS@+bolwC(4N7F1DMx{n4nf*@Ic&ipb9s$s9_o5) z21PeEK;7xg^XQQOi4YJu+lU8rQ~Bi@Y>|)_&9E4mB>gE_+eScKkKk75-$BfpayUHejgZ>5yL_kX5VLf2IpxZR-xXG=_!Ve!v-5{;;Cceo zvFOP_PR`TM1yij|gvu=j~%0!OgCr z#=?ZOXIsN*OK>Mmll(fOR+9ofo?fI9do`ZxO?({S{xO^hB&v9#1QE-leTfdwgVt#} zlQ4GIP_z#iAof(okv|j_rC7pmhQGw>0qcUtg)G18oS=9s@D?dTWTl1Fhqkb~!*lB3 zSkH!ct>}X4SP$}m5Qs02-D?Fb}PjPVfR zklMWdCuaYmQ~9C%v>tRCnfQcbW);^Jf}R8R03n!AN~qoDoA*N{pg7Y!O9vg^i1~Wv zub>Y3a%6pDi6ouE3{P}fBcrFLV>{e(HxVGNXdtS*%Y_gK?V!ELeOyK{7b* z%6KOQ=a|VmCtM4omd*r`%G=}Haik%gYmQY+q-8$W1oi|}+|0KP?uX6h6l_8+EF4Ol z)rjj(0^90cKc!hgYBChJU^pKcZNoMh*xbSMRq-19F_~Qc2ZA917q!i z(<(%iuk*Dtgt>@lKws%~T;EG7KH4b7)}(*0K}&)4N`=KZxg;wC^^0eq07EVVV)8zL zL}=|7gTWbOE2(3?jAX}P$Ui>=@_n`WamH$;j&CkJRO<5M@%k~6iNY%{1-lIjOD;eDv ziv|z($MlzjDurVJ%hDcWwlQ*f85mps#G)N@k6j$BKf`ML2||pGR%+bH zP&1`Tjf`Xb2^ei5n32-WBntmC9%I%3l@bqTnm?t2;`js&t7m9CaxEeBj%jGXSCd1D zd!Qh8jz(G&3)_a~v(e7qnpU&*bAZNWj#@#{iXz8H!v&uvLz@kgt>BchgUb}PlzY)9 zZ(19oW?rcJ6DZ}t2DcNH*r6#nrgeEyAT|)#kyL~o0V*Dh1)~$OXia@hi1*yaozLyg zrO5^_KHVTrhLKeV%^QjvM3neX7aOtT^C{E^MNJLD#KQd(Y)a{QT6$mB?q)!KpCBTG z>`e=h)MF-r02?Sr$%j9S@g}`4-HKg$L!qW=EPs06L?gsQ84rpUT3p=~y z8vD;!C2$(U+OT$v#@ZZM8DB=NtFSQZL_aVR)>L5ReLf5vCt4<;t7FipHJn0|t= z8(2QORmPs8e=x;}-?fmdlwQSsUnB$s!(%z538Q-o^n-CvQ5mA)gMv>T4e&9@3i7i& zO=RWj?5ZWmIr1(cghU+9zSP@`1dMkECe%;O%Um$E*-fEc&xu#+h z#(HmAeaEmC>*Js9tASU(NCue*J>7__NjR9SWZxk3YfmJ^Gj{xu9pLr;1HW6-PWDCa zD;n7&Hc?O2`8I*NCsU2=goK}bvpSx_U712P{c9w6$-6vSY2R^vf9=_OSd zYnqkJ!tC8sB%f`_`QlGIHm8(ukY}sIuziok;p^#>oa=;%uigEj;Vhb0f`50VA z!iNB#!5?4n0+$DCU-h@5qmVu7!tUk`m>2rxqQJj3x{bLAn455r>#_vxeU~Ptoi8z+ zLrK3qaEJ9(yxOv;e}VCn+!&cs{51}PlgXxF_Uyf`g{?Y#(8r16@B24Ioi*&&dgr|Q zCv6Jb5z6Z?E>hshDYvkQKjNajL6Z(H{`ktka^tkjRcjsj%f}rTS6AD@CJgW{fBZrM z=)RQ3E8{3d4={=^Lb#)hm-s0QuE;&ZGn;oULl-h8uIN4a)AOQk?DW?OwfmkCA(JG4 zTYDES4N4xl^By(j*lKM4RFOs|hr;-hLU)PCq5UaE^SAMQ{F$~UgugGCnlaiO?C@q? zYl|N0`PJj{S4Gydo6;+5b`yT8Fi_S>bZP{A=BOOGojne)A}Pi1M)Ed!#ls-=Ky^};Wpwgj`CVI{votz$W#}NA-`5n zYs98cdrkVFnq=h{Lj%8dj&tm?lDR*ydZtw4jd7X6O3{8nTg#Sy3Rn_~x19Z$yi%+C zK{bvGhIWJ>I$PVNm3lk|9hAB`(}X|x;V{Hjhow5ICV#gbb7ghRz9Ns%{B0|oc;b%6 z4KqQ$hdHXcW-OO`oriyl?w2ZKgsAMm!dv%Ph*Bx|t;K{9+2#7q%{L4jY?Jq11g&g} z#*ZlWdkI(M`iQ^VVPlQQoi*Vp9jxaDP49Ha2oJR2`osPWHr~81L9+Ulv^md<_>-v7 z?~2VX+~dh6geMKC#irEb1u3)w;W zjFkL{(ayI-BYxzFwpb#3RMJ663$;{y@SaSD&kc)eyFd7Wd1zrR+J zDCGBdcIV9r33MaaP`izg?g*yfjEr9l6Rn*{s*QvfC_eH}K&YH7=l`WKO6qyH4t}4b zh3iR4_Q}``(_Pw3ix*r2$R_fUhdQ#!Kn4=K1Y4>43ZWAMsr2N1gH!4^>I6Vt{yJc9 ztekS7^F}x_lv}v7L+`*E^Xa9NA=bzJ!ywUU?gmAsZvR`a{h6>8G|h!S5a5UKz3Yjl zL{_b-r|VL8AuM#}CddN%7Ocq~IFV5xW$&kEpu!)xf#hcanAEs2L>e#8b9tziYYuM> zn0D!f0PL8SGCJ}PWHz+gP+C*?I1B6}=D`DXN8He71ULa{x}SqjhWa4I2-w!&jMX* z%2N=f(cg{a1$`%!lX|gDINZb|?KvF}H>7vPQK;iDmH1*~RM;(#t(54p_K!Uno5@yni<@CVEho){ zqdsw@T!J$~@l+YwsHb4t`d#6%49~MGVC`b8Gi@ww&YY_7;yX+-67(R4Nn8Ms5phEa8#IkE6b*kd_7 zxIF-7XH@%ZuH)&2AkSFSdL5v}Ko|HEvbR{K|!g9vEZZ(%bE1A+1F)5pR7Q)3$1kmwC z3xFpEF7@YCdyfyOSBrM=doN*HghBtUhN=D_i(;%Bbs=<+ck8Z8OX(VOEl~D!lIelN z(KhWi;99WP*+$7u>lEik*w2S;r}jt!&pR4v-$dAlkcYmWd$J6*P+v@5o|CXA_FKg7a4 z3HNH=b<#?~C~Wu*b1Btq$k$<(S$`yzX8F7&agqX)I8LimtoeKHV=+E-8s8EWO&`N> zxZsn?Ae>V)#&326f^0gvc5?Ijj}0~N?Xhf_#vfqt@FBE=Cf8!)NH@BHntSxTEiLK_cV6^g^0~aU{$9A%t zCqYDlf=>JKQLYd~wY9#JJTTcCgF~AH;;HM+#SGrn+jkN4Z72}f74;!Cxq^Yb3V3b9 zOEW<8c!O;zGPsu8Uuax6E0bR^r^>3U%U?JBoHR;9hJXis$YbMfP@k>^u>G2l+`Rwe zv;a7akJ>`R^L8nmSO0{-?1+1@NWDnW>WA2vx^OewJV-nleOMIR&@p^e#mTT&loV#B zxRZnV)m7r*7oEoHhE@2aY0YPhYT_C*On8pmL{-BRQE)mO(ZqT?bcSgx)2@PA`!J}L z57m9pUtX(!+O9GPL&dz%%>&MrdJUgOD2hFH>;Ww{e?k}5#D&|PxdEGme#QWHu&jEX zB(yAgD#_?`gOZeE%B%9%oW(QpQg!MP=S?Orr#K{5p4w|TipE2?I4hoE_mF`d{9oV% zsPJA(-+lLN`w7gq3q+B(5N-zrUEu#C9Ow#&Y)h zz|SIkqQ?**M>`g4cL@yab{fTJYD_2h5b}fxXYZ+XMSA-8ZYeJ3np-yzuhoX1lev*i zRuvDwAXn=d`6yfEAw!s01Nu2k({*r-os`JlhG`U(^qN4 z*+p(ikDt2#YdTrEHPkzL^&OBdvblC{DbFuZppVjj4Sd7&CM*?CnCcS?t4S;cTJOi_ z*nkqIu*l~b_<+ZQ$w^sTOlR2-{l%^T{W zwsEW@tGkcxfP?(#W)tUOq_3gz>X3LJ%rOa&v~r$T%`Fzt_ZeAULfg02NcD2G$1Kqe zrdjXu;Vi^km)afIHGdfZ!4N{}m!zA$s%wHB%PX5n{DJUNw$Z;mt7-2lArLzd+=u1U z;`OBoKzLp_0-@!7ee!*;5QY<7>J05ghff2vk$iHn(2hG;SffU>UY$#Ro%e5WImO}) zZvGa*zXKu$Zf>|yM;?tWkJ?2 za1`BN5rZ8|-k@Anm8lT5zN$UJNVQsUY=W?X2wgjt9FTmj>(;wzOwhE$1Cl37k+)YO zmk#?Yo^U0N z)VhqQ8i&odChJgN`uMNmQX@I~z$y+|F!r}a9TF9F4bA*5!sU?h3-__}pyB9TtA4}h zx+@kZ=-4<|4OHwv3pBt zDE-(RT4XyLE23mz&DDZ80~e=9)`}gPkB6i^S+X1;v9|#+)RS7Fm6|s^kJoVq@PXzT z>wXy2C5%r%{Q(uu6m=eWIX;8h9n~gz{k5ld(k<0kNP!49Ws!UQ8@WSICHDZor0H7m z&v{@u0Z6_wr6>*O_`3NBxbG>#GGFRa{N^nuC~!xlgAU>$!`5s^i)hv8nadg?YO>LMh1UGz>G#l%FBhrybh z@{jN(f$J=8x2Il^?FNqiy?w}M82 z2lh4O}Ma+;hA5#es__)R%bX@jR;$c?BA=7_m-gRIRRSu>gwoalT(`DQs_sG~K) zzFOEFzIAgqt+B!0-#|UC_$ZF#K6DvhD87dp^u2WWAmjRAvhQLMLk$-eZ zqF8?zEr>SG>^il;MOh`(M@qUr87+M?-~h+|{fjB;$@jb#!< zgh#O~Eu1d0C_QM9X95kYIo=DdsozyI8cqYdgKCd9+xQFs@q}hHc(uznMgHWvc;^_(9eir6`d3H?zYob8uae#X!Q%2ZL+hD)~_b@at8S*jUMg8;+Vif2mF6vz!ya=akJT)LFT|-CCDS_G)RIg zeCRHQjdu(ZJ@hG$esCSq+_kias%BD}{sBU+GHEXT5oB$(X5Z!1M)KECm9i)aG5VS( z927MEGKzTwu-rXK*Y434mXTKHa>U#+S0!@&^OE}~sPz7IG$vr-a1f0{jX!jahw=l+ zpJ}%`^$!PkuujZ-K0YpO+Z;`_+cl2-L>hRAw?ckZYCZ@LPHSV+?qj`~>et^#;rgmP z{cw4iXh!XO#oXL6t#$$ll^wyvYh>GJqGm=o+7RN)k35Ljdgf;jRaj~tVm+p>Phz#C z(?$SCTd>P9o7ZmKl2-!$AJYuBDCfTZ1_6>?DJt*#iOC`Z_&Luq!b*t&UMu2E`TPSYQI?)d;oHv9a=D zzw<1|2k*KbmcL6hB+BT#E6CR)JU=XAvQt^A{p7&P50E-A2tJTiR*eha5bnFg;T9Qz z;I;4p*fXVV*oJ(uh1IGLHD0*l_akGqNuJ(WZkU-0`G7i^!sp=lu~fo^>K8SkvHOt_ zm(YKsW%Lzw;p=~)SkH}jCHBPOV1%6PMV_>(YEOgFrOAUNUg}lZQ0?IIucB_j{$161 zLIaZkeRo6`T=jLmuJ-*W364(pwW(U{+hRcJjht3dtw%)HNvZ+P2h2)$k-{fx)fC`z zRecC^Wa*AeZj%K#ZYTxtI(@lQo>IVRKegFM#mIShRl_MtoeFa^BZ5~NDQ2gUW3HB;kfwsCU9$x#^T47QkWYM7lspudT!#Pe8%_{XfHE|DjlWv~NI&Mb!187=BIM>~u(U>pkXA;7aRRSGGcD-N2;Y*e1_Cql|CoAiWX zh2>!R7uqcYRR>`UHf(Dv_R}mOnFKq+2>i04b<(fQ+y0R<-#)ZH4e~4WK=3z3*rfxn zI~b_?OY;|+mr=MU=?fh?$R9hwR;BqPwYZZ177Ftts8qf%{8|V{wRGjyEBmt-xTc-|BK?*v}b%DgO(09k7tq{7VA=Y?_4 z=K4Qvh9(8zg|8eNTi;8(B(k!M@HY}T8{WS{ui)nHk(b1UJhFZf*KaKFaOWx4EBulW z;Tgp(7@G_s?>{1%<*fYE8gIoNpq_mR5tO&5zpJtM+CpI@+?>cJYPk{XOsRHr_4PO= z9~GhVfQF`(qQ)Of`pS>cnm^$w#F`-d?*a?c{4Z*F!&f*#!omg0L+D2c@f)3>btuGB zd1Y@};T=g%#2kM~$R?cE$(m~}^N|-6kdhynO4u5g?KLu`G+ycYW3*%pb>I-c-8_K7 zFLGj?;fv7tapbC_$S_`cOxSS6Q~uLXEp(GQ{H+yEXbANCzX9?Mo!LmnmNV70{bO|Gx%|$wu?OGVE62QsrL#z;F6XoLYoKnL+qPt3o^WbL9Rm@hqoe4`X%_0?wC8+ z(+Hh{(diNicQ$7eVQL@A|ELTKQ;E)RXzNt6^-*Vq`K2W!gd=5jcs;o1ezjdJzDum zO`#`HC>_l}r>`lHDXA0v8ak7H`-Z($qs$&*{0ujS)O0kFjH!qPRh%*YkZ?kf#_g553L8f-70)i z78~>|qOi>^#aCn``}@nw-S$i1s2;MfMm*+z3YXQ3Yzz|}&TG<5pt;i-YK8M1SItwo zKC`E5625Y%Tku}tHSq}&GMdICU*jeY%m?0rn+mKURy||d^}IBp8^Q+}xwyfF?}9Bq ztyQnP!8cVjg?4+)x)N}Or5Mn<%dKvB;4u3&4E0rAo9Q9+VUe}V;#)4KfxU$ng>;o~ z7d6cXMKT&r7q@d^s1#fn8E;13<+!g!E36M0!kwBNopjOQHb@qpqC$(j*Cg~T5a`Xl zX8;W}3a`S)+HPDIym6|jYghEA0hCX52yoB>qmp=i%3^oNQM`zJ2_0G#dXG=onvb{x zsxPV;Bq*oWh!+8=O;Q!%A8YF%rF)PawSWAfEQ7vSH1cRL4-`d@|)O~KH{1Oj{E3XCQqXOLKPxr`?J1-QEC9z5M;JIzd{;Ez|$*(t$V zxZ2~1G9sVzg39BANq&BrSA@#@=5=D+WnWW{Z0?hj$YGgc`2gHT?`R(sG81)+XJ3$hOkNc;DG>+aU(eTe4wh;I%+sZ*&0tpqT7?_3-8d>6B?L z3oBCad}aQTRTx~`i_r-r8yFosEJm^1nE`aK)OQBy#k??8^Crh|-)%(ugz?@(!8Rp` z`aE$uO&)Q{ytAcH@Xr&zFotbR$G~nM!JfFGF zHKT2ZTc~BhqkH;Z1KhRUDB+d_zgGF}948RrYpZwdzC&*Swp*9M^duYCt%7SPwz-xz z_bPb853oLoyP$^q4)yQs+Oq@4`i`WXh@6<}G=9~z!=Px>va|7X5xXAR!FZ<#AIL=T zC_V&pRHS>sw&9Ot2LK}iI@*3Ppo_v!<`Rzy_LIW)yRPCm62bdG+|w^_c5g^HfdA(# z@3NsPq`(pP(!%edn4FjJ>gCF?2UA&S3%2!*rCqxZ#V2t09Wy$_Tp-Z1ZEyB&%)1sn zoOZ}>O;J}H*9|Qq{18cxn&uw;vcsB8igjzV+P*&AH_p?IKmh&TZ&l{rrIA8f)}jHx zM`w+C8#HI1fWu0|{!i^TKuL2&TOGY|pmaHGCWK62ZOF4tkHzrLXbWFB36imlKK+6z ziW}sCqdd@^Af_6K_?J=cS0oU<-sr0DBV-54I6OOn40hniVwpz9U|Sp3A|h#8?ewLF zHBG)z;q_+46QhoCGO4+7wb_{uwxq@X3h*a*d{Udbp=t!bIc6C4?sgs`yB3P$5UxQ0 zP4w?z1f}^u5EM&bU)zf$;wCh|rMPT72O;y=)*IQci>tCx7-iTC$HcQ?jga zgwhneq8;|Y5Txu;lx-3+o3`ADWDu2`{=Fi=qlhgUXn*x00lV{hr(nN_S{=WAJKO{O z*N}*Mr)V_#?Ka>vLeC*M09i!08c!>3SO8CHfe#f|aO|%T$TpPP!Fpu30{bh z7H%$ATbw&hz{V%$d{Y&#w?cUZUZ-W=7V#{Vui?~qK#MJ=coPb*gjOTYDO&N%(MH+?@M*Dt~Onbq=rvT6Q`bXxP-=?;L#> zxcDK-OJJ^KC$M=Fz?>+0a~T$C`pft%tjeLVdbBAreK@TAV;ni8NB^c$n@||G>#C< zw1&osT`SIor7rQeE_hU4t1W2u>9HtQT}w!@HvaDBLO0}Q4Y#9NcGHBh-1VvIhRHpT zaR7V*jsUMf-T#Uem#B{OQS%cH_%*Ao}?!Yc;sBM!uFz7s{e zX*-K+X$Vx%s7&(js&O|4e{6XjD7fl&vpKi?w#Hd!<`atmJLnHwJh1Sl9V?t}cFBEv zTp=2d_*_48(oweD(3&by8<)li z{~JYsEZ`LUh2E1(_lqOxc zk}BN{QMtKI7?f^DpzkE~29Ck>KFa!%0vYx%yeh-NJ9TB$`mh(8#v6cOMo_}7d|f(n z$LzI6-(BFJ@z^qXXF0G$kQL7o-w>NAPXZ>)*ZyCY91e<#o9aYFI z$HU_0WMq$j8NQ-SGHI~mPqvMZC0Hl^p#p;3*}gXdx+3ly=LD-!6rIa@q4&B*GKhA` z_3%o!2iy?srX;N?=)P2d1cT2kOuPK&!CBFW70?!5eVZSWt^V!`>Vu=o-TcoKnBrmA zYxV?u`l?DY<;VJ}&78NfzPbM2H(~dIUvFXVj;%WEw(!^&&%==;%V4o53-YUK5JWE*4KCa(+HT66CHqJ1G|`RVPi@c>+!|n!btR zPc8URsgXdkd1;$_oK!o?m-mQliQu^S zb$l9hVfyhQiX%G&7f9TlfXJ()%GVA>t0^TSR|Bbw2~nVS;sIT*aoM~L^0;iYyIeag z3t~ca!QQLtS0mcMQ92b1c~H+SJZcsX_@6*6jr5FTv0DT(HVMx|Xe@)Rxz+h}gHK_b zTyC;So%~|R20+{kwK1sEdP*P#Yv%JD ztUfFei9ZZGOVSOGavfmakiq`@yyfsh*3vSPl5bzPgPpN`Sa9WQEgD^nk>A;&ruej& zEqwtnSCsBrckXHY+-mn_*q053Jm`MMcYdK zz5B$RF3hOGKN#F9=O*WP2^zs#CRDi4NjI)nxi$Mv@qyqoP(gkwt6 zjV;l|dSBfW#VnhR4Eo!g>jp2L<%Z!V*Q2HtXw34#4|v2s6>M#$NWt)W8*!5d)YV)wL_Tp=AU6kvw*GC|JTA9#kOsnas0cZWO=s8JIXd%EU|PF zl^MtqixTA&7?N1F1QY{SOK~z3DB4EtdpBpzm2NPiPP`9y-~S z9l&d2iAN`Cw?>pm$#qg!7Dp{R5V#L~Ant(s{@?u$_h(1kZPP*KRs}h@w;;*qH?O0~ zZ)Gr>Xcbc3lH2~blIZ&a_NPF+upfaRSc9<-xtnJ#hjg6MqYNBMJkWFT@T0zTdQ(9iTsAyU?kxay8*Sp>PPtV-6 zTZm3X==;LdR94I8li7kcue|hd=JWZNL7^Z2|Be33FP>Kk9Q8qNFN-RAv9^ApKv)*jV9GkcBIChyvC zpAVAlZ)w#V_fGDausn|RV{s$?cPSw*v?J9EOqhx1Cm^BD;-9)qR>x=nE(iE!Y!$x& z*{AW`1CquiK`r0`#`5%pFsFRwV+blLw=!#U0ja=K)cODkzm=xpv{ro}3Xb(lEFrhL ze{wvjqe-gW6uyyu?F-G56QGX3+yV-4bw`RLqDmj$jYt}uo|qg9ka?JQa%hBHlnQ8H zyaMci_|V~I8o3>b0_(UR1P%BJur+i|N=bh{Vl}oHYkA+-Dd@@7accE$9wWX`*^l@l z0EmEhe}sMMA+Q0q$Q|;VA=IQ&WQ{M>eSwZ04;baT%q!6)(h!es_Mm3G4ePO1y3XEY zo&NdHcMvbLyO>lzLVNMe)3eKLYm?PGgAV9XZE+Gy!69Z*R~&1mg%@#nDnV3Lu6ad1 zH&PY&vrtN8ZFo4lBuB-0Xb;n|wR27?_c4t*2+Vx!x=NphBhXAQvPn+~ zIr@^mD>!t23*LqH8+$uIhQ!RBY42~nYVqh-PPMw?d_B3#)>oqIFdhW4?9UxJKiij} zosO0M;?qFPd1v3eWD(ju_lmofiqZ!uy@VuXi3Wby@pE@-1)XzRp%_1F3GBxK$MeYc z+1}#uwxmb%cv)tz6HuKiu2m+0&?t5O_=W(GI?#Q{Z9F1s$c!4#Xfw64Y={WI3iY1y zDKYf3nV=lNw;&gR$2OiRO>x_~6yIbwD02ea9|?pGP^U*nH;N_;#R5RiO8DWDhX;M; zA>xzcqX%LcacMTjD^5b*qlt;)mBd#N$9fQKe3kp~T#y`eSNuFe%ygv;!n!>a=IxCa zT+%I4_Nga5`%nOpKyJUqpGaJp2{(2?Whk;)#39t{Hf9DK5z9$BmKb&jzaqA)fef2} z)p1F4PF!?a#$11!mOy17j=kK!|9=3TAN8IEw~2asv{+3HC#>xF)j}G z@TX9jPWdQpOV=Cz9KKkok)Y2E&~_)-&+S83-olq#P(}m5Jq#COfR_QqLni^oP&8-I z;f_kzp!J&ao_J(dmDXF{pv6^n5}sqqF17y2DVEJ8SzT9()A}+_Q+gR2Bjok;xRETM zAb{Zo$Wbn#=LF7o_3Ok9+lThY6noQKr`tO?eAEa(nL%EzfiJo!cY|W2B6ACxoqwI! z`(8pBmAa$e65#I~`~{}Y zRyOhx=l8h(E3#iWjJw*O2q`(n^F&c6BSWe62D@X*xzSM{U8y?pod`NkOwTqaf^e=MAAxH zSk_D>pnRW;MpKkhDw&L*@x;{zqE6U=-a~NW0na|5#y%qjit~CYKwyyTic^p9?)!f0 z>Fg}^EXU__{(PUhp*#?pSPT08{(o-&_ag_O{2S~~)U~o~TPwF*4IL28L+PME ziFj&~9F;NBO)|3v1qB=&6NOD2Q5<#6#7fIia!9}G{$8)&=eqCbnG=K9w$?v;!5lab z^PbQ3xvu-ZpZgg;X1u?LK+(6YAoRiQ2l#L+ZaoAa_W3@39>U)r5ZLAa3H(CgDPG6- z6a?M44npVXWTEFn@q(a^6Ea?ZS?JlZqwvy*VZwk7%LE^9KjBSXM?wAiFk#XYlLY^l zf`sJgCj?LY&EW$CA?Br-LdOnWg%76t3Grc_h1mmSLXa#{Sfch6#)Y*L)~eqY`Y(A~ z2N3LX4?gti?$ zg(**s1rKkbt)HjRIZ+ULj(lH7Id&x%#OB^J0j1Cn#PJ2oi9v>&X zK6$dxZj`^!F)S2Mc|4xCUc&V8lLTFKJ0a9RUU(hP`*UHFgc$z;LVWyF!jzo8!V*=w zu&k$_5H?}DFlxf9La$MRFnRoB!5duV_#e$-RKi|s}U-rgOB z37us^{P3|tWbbG}HDJ0B-G72GA#s?Hh{x|Yz+31#p_kBi2_Da)&Un3a5Jrtn6nyf> z2_vHMf?F_N2%705q*rwidiwhbeUhgLy^>!QMkS6CCcijb=s#?d5cWiG;mwy`5)xmW zA`F`Ox)9S*CWPWKkHc%M7aoUypJ*YnPak2zxTl1~pk!eH{@>}c$#~F_LfFd#gq{yUt&b&BW_2X96_ykdU)^l#o6yQ3&hPQ+OyR zNLZwvg#SB6kPT@o43l*hGVr?XJ!FCqIzkZUmp>)+=@}*@gTvUF{z773=oGJ**-t$M zy?|kdAbi{o7kYIv)eCJsA#Bf%xOlQx_y6L5@xS!TU4E_f zgY4t|0qQEzwURp#KrYj+;Q_9{HnjgA06=++!Wl<5UG>PO)T={#z;k4@L)#B{)qVZ zd%Ayo4*#PYvHfQu{f83O-}>uX{!&Z7+v)Yws$lL2$-nV`_oNU!=gR;@XDlc%BltDD z$8Q461x5wYxgp&3pW^?)y*%(=7q&n7-v{ET*cM)BZsKk_x4m|g@BBw>#4%Y<&yj=U z8zR+s`n3Tdk!OTNf~8RCjK;hIfHAW#Ef1DSuiU#lMV^!hS;d@sfNI`z{a!5qEwqqYPHER)c9EK5=z%kNFkTY>C4K7 zhKA*7P3+&CAM{^9bEl~xQprQ^6l$d{ev6p~rK$d-Fp6=PZ%L(Sq~KhXslGRVJr_^U8#iQWk#a!E z(-D)26DK|<#>|<&%$&%8;CkX?jMDAfn@BnFvm%Y=b=rc+v=+(S5pFb?j15h}%hQ6F zBhs9ssR{2*O-J$W5KS!v{d7a5_!5uA9aSXB=RZc1VpSQ^eBFoD*XkT;)-+$rc!cWvP6FQ85-UI}b+U!t+1#_V5uS9vl9`ZE)E%apKIG zGYJ&qvFY}v+Z4FoL}>EXtt&7tmq~fWF`Xq7@+NZu5Dt!~kjZd0n=UfCrF)CWbrvCT z&F`@LxHsGOIq~ykPVwoS8xb-R8+BwuQ#>Wpd-rMSk)|{mtnh>M^f|A-`sy6IdUgDG zc0;~^%XoxzjnB}h#}DRjgW)rHRtCEZdXhHbIx!LV=@SVFzN*w;!Nubav-%r@K_wth zhZ2~Q7hGiK3o{ZE6K4#+{lW_~X95k2+lixw4 zDZBCOxZrW#Oiwj5&6zWfBOxf`Uls4YI-Y$@pOUb!TieylnYhg0PYk6Oiou&GrQqq? zG!w7e;kQTNHGKOqd>$o$E;S+LSLnq9Vv#LJMNF0NM3%NTCC+3|_^n~1MvRy-gM_hZ z6K8NMF(f2$*eKllaMp(s7LiP8RQwGf_GnhV4mK7v;58F3#Zh2cG?(Hiv6#DveRPyQ zv1slGbWMyH3--AW5R2ILJR7C-^m+3b(nU>_+bFN88q(5bzYYtyr25X0sMun>OPqE2 zc>46|bWOK2W)K<@4k=_Ny^3FW;r56Tc;@H|bRK&QemrvGctxZ2)nC)BdZq+}N}euw z6Isg4nTdE2yucycO61a*HEULgEj~;fHVjBU{P4qm>v8qr`t={uH|!r;Us|9T49c#5 zK#)ZiL=Kk4JI7JTC0>Lxd#)G}5fLBodmo7RK8W~$-g!g-&%C4j{yY}x91^iH5E?_1 z>>kTBqH=TG97C$_xN&pbK{<=C-J$!_&z?;XsZbD?(W6Jx-2}oieflO!F{3HX;Ps1F z^{~WIqehWlewjE@mY|SVkH2RwH*R>!6nOzeWfO?s9!}|N2F37E9Lua(-bNUR6uUq2 z_6{K^pn^BVdR(uMivyY6rI5@>&t~c5#&XyXgRxwMvVF<+qXgk7hhc*f!R|+N=M;!i z_wEthw|AG~D6wEvY-AXnbiAiG`C3#;r2&Ni{$>zOs^8^l;8@1}+gjae*RFrR`fmW) zg?EIAOy(#vM~r|1nOtU& zlZ1HxSWg)6%+Df);4`6K#A)}Bq0mgfP<){u=Moy4m9;<4tG=|pZ~RD?RN^@@Es7eJ zQWh2OEP-GsYHGGeusabETeky91W~C$Y!#z>P4(}`>gG$mr#gQo`0Hu{QT1h zcBNRkL8sGs^Gev;`@N7!qorK``2YRi<6k}g_*Zx`sWL+?J8>oiqqtWtvPiwzn8pe^ zBJ;v163L8Pl)*w0L%cs?+5nMZ!ye@^41Pb0(BShB3&4DEX!C(~luuwmKt?^m9E_EIOXDW|C3u;CI% z@%75Dzy5k9@mNXszFvuVn&IKG^1z@$ffVd!(4db#`e=|h#d{14pghjFB#sin%$$C< zQPFBy!d}sygCorak-@COM#)9_YxJ#Qw{8ss3H)wQ`N%8etFHhb0Vw~+*}&>ULFUKx z>qWhUdLhd4^S$!Ryvn}l(4lNUT*m%qBtrAidn{kRuNt6&=FGB?!)2+2<|9#qw60_U+rW2N-bKMcK@kRMUiXhOVY*K4;)S!%l@I zv46k9;#tHcij|NJZl3-6nXkoQOr~6=U|@*I)6WA+ZZ3f22J-j_@8Cjkh|YWOaWY?h z6@sUfT0ZpYGiRRF=@OdHaWxOm!3r}fDC&PE5|rDIk*9nGS3%K5V%h!CdyG3o$-w{( z#aHlrFGwbokqPzs5n2HjM44B9J_9o=UK(olv_BFLkNN0cwl6#xwxBP`g|xDLYYm7j zTlT}UW!shk$Pb{y*las=XwRPhEPi?)@e`uIs2?S`oClcp-QOZEJ9e~@TxQoUfI*+w zWJNY>kY1j)Srr=<2Q1Gz#LDRM=u6Ln%QFnf*H`g=_3D%<+u%~?IB$(a|qx8m;PIS*mDS&h|^n6@zeW1Wfv6} z7Z>$B-~Fc@@3(KiqvsApo9+(P*}OTF%;q(SHse}1bFqw*#Nx!|*{`E(Hvq{qOfV~n z3DXLR265m3aS6;lfOz^jTTGII@OZP72E}~!72}eaxasy|zp#=_(WtwJ{^~}W-mD0w zNx9Jqi_RzCbCzbZegqC*GV z1(_T6)?XY22nu3gN=uQy`fo!(E8Dg$Yq#u&cI}oeYd28j@&nYe%moRjLXk~qK<54T zd$M3$y3cct^m)GMXd2R8D>IwnH{-%m+11+e4PSpfb}SQ$J@DZH;&K3Lsmu_*wj$$deXzbO7_LFqd+ z+qNA#M;Q!U+MR2+tR0JG1DE|k$qZNq4jkw}M2h!$^z2i73S=M`NCvr#sO;LeugyN( zAerr=@+=+wj9S&?x@Li=FdLRv9I!ltsI9%a^6JKoS9u;|>FaB<{sU7;GVuG{TBznZ zCoGdB$?zv^5~*g8H?=S*YiTfRFnoXF%wU}{IOXmo86K?62)QH%C%(X%dxitQj~okF zc6)=$&wuA=9N@4j16&^cu-}IthSqoRitD$ZS3l5^aik z@1u2JdjAZ${A|PWcV{ji@>m~QTE9PTKgu!G$Yo!yUHfG|sRh}rYHzpWOF!deTn6DO z-Oo=eC|$A#xr(C^shn#ka@jU;+o@CA2+Y8resbbsC)1}-A0pG|JTakM)`kVJbYft9 zeRmNVnvyf5+aE%6EU!3X8H@KVwO6lhd~qy;L!OV@jRy}N+$dr>5LkQQxhd|bP!jvQ z4a|GqNM<3U`4}P_k{>BcGwKGn#>F#5VKycV9-J7QAdU-jD*Zx!T(^#}i1Bv^$&kCS zG)83lu}oGL7q`Ex>_-?){#uITYhnIb`D=;GagaH=Fn+e{^vIn%@k2}d*7QHb$S^1* znR7gq0ZzMthfcK{$ickzlMRf6T!;(e6v*s&t3B?)WXNX_=g;p0n|;)}r~9I02AILp zUv?^w9k9GCiiM(W4_kcUGh)G3y1^?fpA>=Y4;&Z!c(=QWc zvS5WSA;t6Vne0YN8vJEb0t7RIhF?MwQ6E#^;_ZaRiHl7yTrvIng_f=h4P|;k{vs+Y z^7D_cJ>HG(efHUBOHXDkBr+bh2ApzeL+Lw9_Uu^(Du>SDolC|>W#GV7|7f>!Cl`!e zG0nNW-RIgVAYu1OG`tEpzoS!|efzja5^_#UDT?}evYAkJFaMkVj+HT$G24t9K<~#jq zPtV|jp{U4^%0T1XBcBkIa{%$lPJr2oJF8ZK3nSysTnNkCVq7E1a4vns>Wt~8Qzw#* zFR`(x2n>zuyNczNkDai*_~Mf{7M#n012BGPE>ej+ zdi3KczDC=Mq(>he1~5h%2tm7P03!TUwT&Vf5ut=cJa8TfuPD8%J$TUiHx-3suvp- z8a=*s%hpV=F{?)ty+I~qG)yKTB$&9MgGp#@_Rdq57m&v0JZExqL8JfZquyxpe{L2c z7lb62emvsp*8xi$2$9``400G0L&|voU8Ypw{O2eC_9WgXY}qoEbLlbpjUI1I9Yem~BUg+;2Lc_q z*s*XhkBVGwiNlGvyay2&%0~$#n6pMy%6H|GEO-ud z5}xwOCy)xT5Q$HE0nEjVt9mgol3-l8*svfNm_F!Z+P5Jh5|=il7BZQCj~mCq%yH(z zwes@IFHsPdKmYA-uT%8ca*%QuxKQvyjD}(kY#2oTGAQtXJ1h(gV{uEoGi=zS!$PPk z8$Dx2A{luC5*ZBUuAOBv70P-AUlRbW3>$`gh=y|aN9+H77cL@}uWVdUD#yjmii?Zm zSk{Uj^S}cSkYENlkYS}+5G}~V0F9)?NR0)ryS@#{w>Y!TT04nLK&&glUB3pae!7 zMn)nFl7f6x29_deR~^%dEOjfGn(b}Z|`r8H~*ey=hF$Pku%UX(5U>@x>0 zoXjIjPi~(}n(+{1%A(~*k2a-kkJw6sl`NO_lH%e;=?;NuNiNsk7O@Z*ZvGb#C;?)7 zik;>@X8xT}mF?PhzOa0sBNIm~qF8KPP$M6NR(iZKjp7NG&!({PWN--#d~ebu_gF+Q z_K?7YBqWex6i8%NSu0>tnoK5zLXj2{tO(&VZQl05%9i5iuYPuv%lf$89m;6-rEK>X zWk_XJYo$zfJb!67XE2P+_x&U02Ek|MM;0{1$3rm@HT{2pTzb8Ektv3~_wL;rP($JcT)uxy7gRn{&DK-XNs15NUz8T-O?xJ544%xKJVs;dL@h zA9A@X8CNdr%R20aRLaV}_yS4n3y}+<`3x>IV1O%`M;`gU1_eNJP=lJdEIJwyu@x5c z3Hiw{ z=HOH~%rp^8?nXf2T=aowU9Cl2WHDpLC|5ELf}wTYX_UxXsgz}MGwCHQIAI2Q{=`J@ z0?368CfJ+&zw@`2@)&Wcr_nKR`Qpp9Ypb|ga9MhMsf%F11!O3h)gYP0tCdG-eNx1d z8npcvrToRj!npMAMXDk5cdr*0E*uQWg*usIosr3o#r7mD`#OQiv11~bk6Xav#AQnl z`2OUBl+47~l6&AP8|Gj6{D#25vm}*CZm@7JqehKt24-|Z0=4`J3SBFeGI1fjDAI!2 zK>w`}V}Umx&F8(!v6TU6-M*fKdk>-jCM zB{C|MgOSJ*H!*wh&ig3jQE8r~rQn6K$yd-twgx^!>1Zl4|R z_KhGnb#7#$&{a%tbH&L+(P=SQ}n7 z0|ogDxOC~lYJl?SeIgiFxj1v-qb~>9NHXtYHf}t?xGdfPF5aWv38PmeruZrie&Jw@3KL?t_W&mJj}_3r(qh@&?T;zEt(TW?7Vl-RW8 z`|t1QWA9%iEC56P(z7SI3);*!U6^FLe9YX1gtM=@T(X#ETkvZ@LKvo^mf|76zEZrx}|89`(|;YaxnQ*AU=KD9!^kW~!1zaxW-BbG z&v1(2!$+`n$)gyb5hH+Q#IRvAM!_SDj7u80sI0B6AGhk|aF^i0i3w5~`-)a0Jx&y) zRY_uqvU&7zKKEjiOK4e#vi--E^mgFzuOUobdST4l& zBrXz|k4Y}O_ECHJN^{>Ap(x3)GncTnKs#q=I{c6v)( zhC6cMk{K~-MxwWo9esz3uGLD}qe(8;DH1j%piowL56bht<%Gi4x!Tdt;xTdRMFbOC zR_~RSwV!4z0S2yL1vqP~_TnagLD=5COP9Km`G#>h*KXUPurg5Wyo#E1M@bRsYxzv7h0 zXbc8HL&>-hmW|*-^OYMn_TUxSmMtO|t{37$OOmJa1^sNX>+s<(3-&Z7rm5upSx95lxm2y~ zfK*n+-cO#)cj59Gvl>w_+rAI`KD(iT(%7DDd`_8l{hx@%axa^~{Pe>Iv)N#@v@Q>9 z7#dE-5eo^XGqAL6%X>@e`FYd7PmE5{Zuob0LzOTYq#WHy~@0WLD_;b znJ2Q92S_l1feOALZbUR5L9;=ojVPIp_V^awZ{u=oa~nQPcK$s4! zV8Mba&gCd?-MyePA^mF(`d_uu*eTyCUz-r&0n*vKqmU_hp$ zBN)`mZQDvLZwXqM$1R*$_yrJa2fUA}O+Gf4&=44YVn?_cWFi3{c>C*yz82@Dy` zMwZ2L5AwOn+5?Lrmkld{1rE_DSMWRrFpSE?$6DnwoU9)vgCEy5-93?|Smg$*HI40K zkvC{G8X%WZ1b5x*FmdS(fteLrKwJn+eSJmN!Ym}Q()y^reTO26EvTqi;J}50`ICcS z4uu{1{`>EXnDet#wv$aJUlg;Moy+^(x$h@aL*}^NIN1iqNiY{Ww|&@Q_%b$@wK3wL zKNC#!CC5VfsVARw;gXBQ#j@B&o4+i+x?v@tEMAOfwy{x{FcV~?EaoH^2Qs#L0EvvO z-)Pj)LH~w?R#sgG%T)%2m2)wU9^t};*We?lCYS09M=&5WD{5VVF)uGF$}6g@zJ4gp zC3}?(&5DZZyI{e|lhnZMbxdQ9U}&kuKf=Cefj;>}5fL(HNN*85P=hC=^pw;gyAMW@y&XcPfVVb>Z>|yZp(K3rl3#*>p@x z(Wz6b$Y3t6TD7Wo?<-gAV=>HNz{SJO@%hQgg2&A{^V;m_=?tbL8Na9*WHP3gPWwLQ zioxCUD;x#$=Vp0qEG4qstGTs&u|+L&mjk(hfoyb)xabn5Pn`Y&S4(p)zdXkFpBVYe zNPFBsq{w6`DJiXQ6(iG`XfFoT)p^E{QCuN5E+cGMhO=s8_-)?Hid^WJ*r;`R4UxvY zg1n(oQBgyOR@7INdf<`LiRIsZ%$y3XBt}74PHTViJvlS;Sc` zmKVe$_woFQTZFI;TbyxF$$P5=Zfk z6=vlXL@sZL$}1=+KrYLQg2z;p?O&KxQ8Bc>v^1=0L31vS1sS-|@nD>d*u<<__2w!X z;}-||KmVL3vhMTQ&KYjGkYHRbMg${@hFMH3(Cp(}x^#+O5p6G&UAasJm)b47Os-{( zKEs1s;?k&7oQ1plfVxhfEf{DwF5v_9pnA^8U-A=p>EVpMx z6+}fvMj7*rM5bV9R0U|T!z_VjK~)$mCTyuAmq(lnWppt1qx1SNV=H6Wx-qt7>7s2= znYheunTrUfb7#jMMxuhad>P3sHk!bI42tG1xU*u#GZGiuFbsj2@Z^&dhzkkEp{GP1 zBe}p_76&pg;4*!pJ(>gYw8gJv!u}_N$&!|4HCWT~beo0`7fs&|#+l1-M&|bI5yWNF zrufJLC;1CwW@BaSP|Dk}1aW>K?GdU59Bl*f?B!io>U_ls?%GW4>OHc-D(hQtBKe*nXgi$!ffnVgoUkSk`+Bwx2#%cv0}T=jy>ZF>w}4qq|u zUmk_)D2hD5DMc!)?||m=B*371aTy4w3EiIvLgv^G7OsQ|d2~$wY&3yNw0@ zf3`{H{B&4MPX{jCVIGFTtXcE$!=x9M%T~m~X6UGjE}d4axa6ppC*5#iU~*|ZhPw-D zG6@SE!^()Hj7<3r`KqOmr74vTof4Q{7#NpK z_N_m#ybGyt!BA0lEH;{S(uq>pCFtcc3C5Mngb5ND&ZRb&4fwM>MqEfSF#fY=6}n(5 ztx|q##&RDX=_<9!q&J&Pk-;NJPIP?!?^cZ8-t^1u;7If>#ym456S^N<>I>Et6jZER z*P*_m>g2+O3-gi17PxY;W8qxLVD{A1>|wIuJwGKf8Wm%mzoYTHd;In_*mHKZu?eOv z35KV!cS$a7nZ=+aLv*=Bi7fhZbo7wemmTt$i(aPk&a!sn)m#F^>?JoBWiovKEbXmi z1sB?J<(_uw{q-ShvP4Ek8X_B-WFv2k{KYx!Tf_ZgYma^*!EAc$7p4{}k=GSO_07tP zDl08rSBe}4xs)!*U$`)9K|V5>b6e?%MdA{+rzT;=+vI zt-(kyQBUFKoHp(44%4=yzX+ytXJBc2nFTq2mrEbN@-eFc3RgTMElhUiGIgqy$a3ju zKB*Y1t%X!jkey8!|LUs=zO4=l|F-ZDcgVbh?%>9aku3*D#mG$jWpHpLZMKM(k_xf< ztf--A_e^UY^`4*662I83``%eG}lM0~Kldqj7( zU(dEfaF=Vn$YFTr0xSUYV2cK0f8-uFsaEdX+1BX$b1G}rbSBg9d~7o!nnxFAFe|RJ zMD}Om^59`}R@AU6YtVfIlPt8t#r~h$Dv!Yp zR2?_)E+4%lxI|?^E5rrPQqcimN-Iz%F9_?l*8vNUKYjY?r;c0>?b&|x==KJ-_5wW& zxjq}Yl(^UpX3tEBrZ_Q!|%Q;<}r?C1#9}z`>&w5zQUQy1eV8a4#VvQ zrP$T0d@c;WU%g?2u3ABQvD|0l|8={l-jOv$s@0JV4GnBgbk=g(+7b;+)==cJin1(Z zu?|p6enmya0tdNBRM;XiC%qghTC%;N!9ex`FmRY_A{U6}8kA#8WIws@VC?_H&71S~ zu^z@@XzX3IFKgCZrtW3)=3@*B8-rPKc?EjR6_>|yE`Q^BjB}Yr71^|D=wMKYv8EDi z7!(rBh7Hx#Bp6?-!SX9M)BH`*`uPWvWmXkoL2XTgYP9+8{;0eHkjWzB&jJo|e*(kW z%B7siXO37tb+8xYv7+n-i$ST}vxm=(4Ln4ttoIeN{8e<%W-uSP?O=F#@?kPwlG(U) zewYm?KP*m=t)N0VRul_EM2Sp1Qp~Y^0h_7Q4sMi2k!b)%!~!rn;-X*%lm5q@>_kGv zHpTY{YBHG3s>p^k+PD}@X6^4A6_ppYdv{c5XjVmiR#^qDPg;;q>y*OwvTE!bhxqhU zN4YRA{n5H)(`K&OOR{nQ)U|8Z=wM_pS#Spoml~4_;1GD1NNpJrovGQC3g&SXC8+!Ukd7U~!NOxct!nP!YHo zvX|6kXBQQn0+@kpG-g$=-dC!nP z(vpy%KtYCF#<+w=MbYejeVG^BpILu?7J8Seux|f2-kgdnm#uri#bBUSWP3OlR+3%Y zxw98bWLG|?lI%ewvbPqswwb7KlR5vxZJiZEv4$J}$7uFx)G|7jJ3lIAw|XHitb?(0 zVderb3M-1`1Y|Ll+VF>Qu?h7KQkYt;RG~c7Dbj+|6f`=WK1ob%gZmn3@X%E zB9mRe&V~T4uXyPt&gE~mK}(RKgDS_2;d5iPxr=l80Lx>H^p<=sIkrm|ULzBj%czw9EUo8%-IWVl6vGBAS3dtd zaY3XuHWC=TK;FU`W7;sygS4?g%H>81C-kjR+vxB4{DG)(8t z?>_9xWsNj+iRjXaG2uhZsFeRKfpO)6N_op^irU(h&$D&Ou$WZwye{CP{A0PyZ?dRS zF|l<3{A@Jr{9>>cQk!V&-6d?*<+k^?feV3QSRT9r=jU8tFs*V4LL%b^^G{JQ zaF%yrF*YtpWmF#n$ck7#6f^eEPdam%CUO}=N4=65jpYtK*R?k&2-n2(6dCM2!mLxI(c56QLf{PS-xBX zvp+7Bb{}JF#z`q_nX`1e2P`a$&7L1LTWN|+JG#Ar)?M;tG1T>6V{ja~T)P)8Vh8iE z#AS^b5|Zn%77Kk`LPV!#p%*BRdNMzK!;F791YqeSoaNefhy|a`x zHK$DfaMW}rGNje5iE%@ zzeuYrN;`VAA-hP;4&~oNla}0Hs2-yZh9$Dr=8`GcSihZ%BN%qHB|l`G?1cu%E)Vfr zas6&w#^jRiKfQ7gT1%Q5<2j72>$4hCxi-nv_R}y+Akhbp9mDVqY*WRrzbXx#dE`G3@XchNXsb7(djAoqkNYJT0=QxX$O) zDO%;n)?ctZ#<-x75e=r#TZ>v5S@*a(ZdaQwu3V@}Uc)Amqp7iE?TgsV5Eqv`#=y|k z6Hk!w=N>o^c=~ks>hRNN0@+f2TGR*USEZ`tzdsj`CY3xA&Z4A~Bx^MqO`uLe-e0h; z;3Hh}nCsJMB`)ha5ENdG(Z-hU<>H{08kWOID;^#mH#}txk!fjaO)=sWg4XwmttDiG zj{n;$_ip?iF#ay+EZ=qD^6tA-Dnl*DR`8ae8cGI*bCLA&y2!;*FwgINVE zHZE+=^6t~#;L^sCOIt1%=q2`8G%J*OqfZS#TYM4SoQnkJi7{h(@C~-e)nqWgm&ee&q)KHm$oUDI&6=D54d|RP1BzOoYIB#; z(hh9!r5P0`EbZVdEQif^eBCEEK`(})B4n~tr${p2efQledr&SDx%44}@oaud7l*jH zYo99@Zu_*NUuyYRaIvt(N-KClCUTkV!sTFYIqaUeoK7OuB!P?`6`4+@GNoF54QlJ} z*jc8e!|x3$xk;^rVC3X40fD$S8$%R%N#RMb7vi#;O}l_gDY2>Q(9Mmt46s|vIod?2 zriM9-?P$qleuAK)$h1gxQE^c*gYw;X-$Eo;Xo&2}x5#D01z;Y!)~9X;Sg5XtheK z!S{D8$kKf+7K2G!n3173>CJk2hic4dT@=PM;pFsWE{Ju^U+5%zNMqgHad8mKwq?s| zwu@z$^Fge48o;HYsHm=3@=6d2C@h2(-bgA1h*bCSkjXu9*eB{G?>!5~*_3+07{8G3C7 z#G(%j)B}q-ASp@1&R|K4`dBHp4$VH}LRgMB!@{W$mhVX{TjS&5_fA0Lv*N^X<2s3*tfh(B(aH>HMy1p}b}dd>@5!^oq-TmC_0(7{4Lc$1;O)l#3&m zEyQKe>C>y3TEfo+pgct?Q>DtyCauQwJ9d^bUzI7dE+eC`JR?J^&Cu#8m6`QAT>xG$ z@ELZR(RGdiwXm}!G?R-R%gK}d#T1szw}R*S$b(*L$;oNjBAVkbK0-BFaZ#UbeNG)F zYvEk3u!0Poh7dv*04%`1Y8gf}7MrMQM7XmFqH%-gL+v7B7E5IGEfFBZoV81be_Td6i!RB9UTM{7yvbvewzuwec| ziR^93U|L#>c!TL>vwJSFD`-!WODiam`O#qVkn1b1J8*H;3**9vlm{)Y4Gav>^KqC! zb7QKaI-{g6C&Of}wERAmvWEwprLrz3Gbb}MsV*r;YeJc<*99w*k|1JDfIdKz6wWdk z6HPcPk~x;+#~rD3a}*0Z{qEe^v&BDQ=W>(nU@we%;zQS)s^a?*a7Z)%L%M-*U{4}Tp zvT5YNGjNxHz{XU0P6zO1n7)vHLpkD~!3y1d-aFP1bDEpcI+^4sXS+`Gc%Fse;0%C5N=vgmCLpCYCsM{M;V}(qYA^z#GHo;QKK=hTUUot*=YQc&SYIr zRMsAE7LH=EVM%uQJN8IUP7Z3QG^s63X${IEZv3Yxk#R75@x{NSq00|uJFj(jj%HlM z<169%l*XdFbh&hiRw~gRG3AA1F;tInE`M>$<%u4omJKTx2i8(wiE8W&wJ<2h;Jq0+ z85+~?GG__7SbVJ{nWQ9bfF4v#=<@R*7E~euW;3ZJDGBK-??-U?;)@RUec$hnC4RPJ zB_(k|Eyi|6Y${T#Ea=jTeSBCBJH-*`L~ zf)d%cjujah3?I5|naem=F8&W+wy%bv-UZcIc{QEl0$|F^hm=3_44qdDTpZQHz`VvQ z<=n*^22mC}eI{Uto`ya2fsHzFF=^qzTC?SM;1c9(GMUVBoenhU5$JRZZ$*fA-a7Jp zV1bTTBZn2_Mg3S$RK66s(AMv3U9c>buq=#^kC*xuNixYcC=_$&Zf{7l7}QENu_@}4 z{eB4n8s$cLK!7$N1Kor<@^>))bPFx0G|A;`pWi$_J?Wk34NnQD zcjT~eSbhPlg{b7Obqp#12*_~JtpgkHeKUsTHl8rVl<4k=VxtXwY=mkF+Nc})aEGs(2O z6`76^7+RPIs8Vg7+ zW_?~Bolt3gl+hasVx7Jn3qN($TDn?F=R{s=qv9YJ?)n^xL;7M=5G0sv;-XTL^ZT%R z?9^d8=;E4`$|No@7&oK*HZC-e?8JrlE*CD?-DSx2q>`L!tF^i?BcrhJx&s$D{~K@E zvzU#`=^;ag)Yb+DB!!fS-*$ko3sjg-zB8}?`>gzjvS?1-H-#nH&gSTW@hcUfezJB7w^~{otA=TBYaw?~W1Z$w3vQZ#1BvFqsQ~kB(nvg|(PeEO~0+?`)Bnp2|a7V}bj|S^LpT ze(|H17eB-6J#v`~e+feRVp55S*zQDy>t#EcJ`Ioo4U0af4u8jy5TC;jaxM?Oy<=XB zi(>GCm26*{;3wbr_rG8RbN%{>%o9g)Qme}g$+UBFPB?LS0m~SO6Wc+>Fv^Y1$4}En^ zW6(=ie}9{1K;^`d6XY(1&ORW0y1ry>#tLWGqJ=Vb z=v!#pONA~EqQz?@ub==X6F}awo6d&JmLzj7ZjI)o7=4Kg1%NnF5xFc|#=x-75{V3g zVFpu7$6fR}^_?3oFc?Z??iv`6n~;kum$v>#m|(7RE+m&Bjn(C-t8#MCkd>5QdX@`@ z8-I&jSYJtlV*!DUinBVoCW-7RGn0m5EI02jmmq7U*(_I?v>H@o0ki^!R^$Zg<$68Y zi?Ch5e%OBPuIFM%|Fzz!qT~cI5J{#HHuF zAP>%kv9axxM_CM9x;WYkxWryK!3^d)%Vd6j(Vcv)sVK=ZlEU%ShF3rP?AJEE*b~`n zPF%Ls2GS5el31gT?E>GJYNns2p?*lFu!&70wQ_#l-@wJ1QI}~l)zRZ+YYa4UxjBF> zyf6oxp?R<`yg+4rsFcavgW*cq+imaO)vLqzhLL8#Wh=*07+m~Wuih=NSsD9@mIF+5YGJnKz9#B|@dXmWD2cqJt9H96rLd80W% zFE`5Nd1h+(>wgTTQzM4D1w&-AY*-d_TOD49_wc<7`ig?tN@}SQsVw7EBrXwiKWH$i z)dq_dZ%U4(xX)oXT*zRg2F{ktnB~vewW|%U#@4)Rug79zV=o-(dW4a=KBPRl+P69r zuk|{5;pHTipXGWP`{LB*T%-|YbTEMd0fFpzWL+bA2)!1$Jt-VmGMU5p-sC;y{o|6M zRjctDAWKX_D=SY8l%H|XK`jWnK2eS=<3&3;K{MowmCPKII5eQWg@ zm$XW4r9q`h(rPnuGy!IW#@dPq#5m3g};i7_k=dRgX#+VvJU& z5> z{|`S%SayE$$tTWSl$s-TN@Zo8PiAr5ci(koLu3wP{dR+CKX2Z=^z`&O^AU4cFs-y{ z)1FM9Y~Q9AfB);(QIW;6^H_jNr(M>Zu0G&$#E0~fv%!_iU;p~oH(aogU;SzPT{N2q476CI0XR(QWle_#N7={ z)`GokjpAw_AD{2P-^L4Kj)ZCD9G&3p6DAnWg*q5bU6HZ~KS0l0*RIkuKS_plGXIhi zS^G9^<~anQkXC?Y$1%KP-@51rH1y`}`B#BnvU8zS_XU3GA$YJYQ8qe-}_L9hD zs>FqbtHFeap9wreYx-HeP?CfkPh0nx^>h@>{T=G3=@&Zim=1tOr0P_Sa;*tA7hpE$ z1r+4{2ps+FWWXgZF0Mtzl-AXS`_v(P7JR>L+cw&EM7*>+$Ek>dk&J)#QMEyts7&-=) zmiRZJ-Oq^eIYNRF7b>$Xc32EsB73{%j`l3t*qIQOV@_OHur8lsh#!*JzUtKS95{8! zk=3Z0Gf!N<^sJP}AQ(3D^4GsQk+B(n?GSN244@Qd(rAHJo0FmCPnXgvyRVCsJ*<@) zlTwwcrt#zws>p~-fH|N*Zp_OIb>tGqxG=#iT-c1u!oH=T(zPprDgFNBxpVBmN(y4~ z>8F3XXy-Bzf?)@brD-!WDltF3*dgL+&(2Z3L&D;~ z)R2rF@wH|18;UfA+KkGWV!o_j`eR&A=x%&f~~Z6)LKo&R^@ zqS(X!haY;-fy)j@E+7LoU5-g)j){9IT)1%k0w1j$ay@2fMyhk=DHeZ)a5gyj>L97aw1O^;+* zLs4ZWs<9*JD!YZ{K_YbW#d*H@=Z0huvlraj?G=CvoL9H>pA_9dJ~#b7a%&vJ4KO-g3_ zO8I>@m?pEC&wJ)i@O_`z7<2?SsovMbh)z9$0zI` z|M;dE7EUE%ZV;W3+Jla_@bK^qHW-SI9PwHG9cwFX!N3$3i(FV5bF>x-OPe+vjE&7P z|H~qmSXL?f`NhNxfi1v7Q)IpgH(w<%&p-dX4b0b5D8`H#^90De<_zY*fxv*(tHn|1 z9M-`km1r`k0|yr}{`*#r3Bt`3E4ZKtj6o7RLPOZNtxKYnImWzDCoXr*WA9Y-C9x=r zD(k}Q_Wt7^PP-_A3ftYXKb$3qpD3I!k-ZVDYO)p;*L`QB!UcoI-=D^pk;z24ILV~F zlU`U5l+DLtFZiwS6J7sACM7b|WEq7jYr0J4Ye~O(bKI-1j(?V&5y1%zC-Ver`6Vtr zw&bqdpg+T?oI$CI-X#Ng>N2$^+BHvkpGRU+nzWkCm^yUBF_|S9g(x~Q>KGT33zxXN z>7{SqzRTm&8q}IfjYd(LgSJ ziZ~a$TpWl<{pDuIh`oHl&+ocej$H?rm?1POue3DXY)Z2>rLZASkU86&%ot8aWb+#1 zayoEvAgv)IGMXGZ47MaGr>;b!)zdMEzBlhHm=qa`F)g6LT<||+W+0E1l!PZ~P4c{` z_4k~|mMo87t|lmzl|`jtd;ejlV%yr1nieX<*yL7nGFvCxRC&aw$YM~cS)JTf3IbDf zzGv~NmblpZen&8HeFnrHF(oH_GRk+&N%vJL8&U*57!5G)$S^dV4O>6n<8*k})u$VE zje$%v;b@w>()3bzT~3DF>Z`ino5IU{sroC7iD9cfa&k~0q47_mLDPbJ=CXfz8l0t$ z0vKL^BC**_CcFX&iPw=3qFPr=Nb>35=+kF|6aK0gP}uOQJ#- zAP)EkpuaPlD2=J_FBd9}e9c;QxjHqKZELAYH7MDkQ8^k@p7$)f!^GW{OC*w5Ws$a$ zjVIUDh5f@pEDjyMa|8t~0++htBIVKT+b!8er|QV;Gh>R2faSacm!5ayB1$Hjk{B!{ zCWhy-6Gx7$K9b>^-qb`pbo<)cKoU)ggJeWBQyhYkp`m_Qie5+CjVl6axg#!Gs>YOt zRHfQvy`Kg{l~KA2d)? zXiN;Hv0uyyTKu|tb%`<^b(pe{Oxp2DL|1DEa)DYJ0~^okjBwvbj6R%U24nHkzj<}|opaF1Yymaanz%hVKUeTWJyrg$me zs88CQm$0NrizXPClp8|w?Adc0>gtLt^DMNuPkG)#Yn9dK&!1YQ^yz9~ zp+n{MsUVVjTULi>q*~>LX06HU_GyD= zWi5bt?m5Qgz=6fp)v1AeA$_1uZZs+s@&Jv7W-l{yGECMK#``|1CdJo8)fAb8R-=|{ zs9ar*e{FSAUgWGJJWhLJWw%j~~xTG45a)nNRMw3MAVUfo)rUYJ0+^-RTXfefV(vWRa zRGO5kN&*8k8naO`D^VoFuy8g`SXj?eS5n8Z6d{k*)fKa)7jTx@H1g8?HI*!4>7Gpo zz@UAhgDvQ`*kGWMOj0+{k4gQdo3MNv5A#O`CE1`ugtL?sP!Fq!eo6*oL@{8!Ij z?dCB83@WNh)_$0+hRPDkV@FD~CZmEYMpTOn7MROAa+XYFucAs#Cb(2)R+2mIp*>*d zvWVH2_|mScln~&S1M6fQW9%1(TD|eGcuDHmZw+Jp)YbeaKF4v=ntZJ^>mp7owv=axjBNb) z>C>ISOqw+5xu+*Ry*Q9n#&Qx(x!xpiROwKc@sq#mf=%c&bt6aK7|F=oComu*v&t(o z;SyStL9W%R3rpC5(CToFUf1Ao(ga5?`-k>j-VmuYn@#3AAC0y$GZTR7N+=Ea_+&G~ z7soz4oL^EX#TGFvHQDSWJ)m+PWmqAd%?uTpit1&gM0F*o965pxhl=O(Tp#DpcVa|h zQL)ANsmseLgZWyU<}}T*sT49V8}FE2FVM&FpKOO;b4AUD^Ahii0c6GzH!c&2#XH}m%pQY?D2%3^J@nDOl9 zWMuNic3n%%Mx$}L0~uQeiz+BJE{|_Yvs%=J871T`nLcE=z==A$;pqGzX-LW?2YUd^ z(TMHaYk)w1vGQ(_@-P=(r5}31RrBfoa4j+AsT&0q$8s(|gjkE_zMiSepg-tDo z>jRQB8uJ-VfFd|JVQ_lN{W~;S5M;q=c$J|&&Z$F1lu09I_#aEON@HH04a_XAl>I}a z3hGv`t}`{HS?F0YWl#pJJHi$#bw&43(vTd~?7XGypphoTye58vF(t$SAan)~$OS#2 z4^8$Tfw}n{sZ_(bw0hKccr2A_7|1S_G9w1Pl~1OhAIdI#U!ju5SkmzT@bfvW5IaKG zK0exCG2WY!GEz1jE;Ie<4J%ikRh(5c(#d!N^)xMshu5frTC^ESG@Kj0nr(Zjk!zAP z1$ng14q54 zmZ?AnE(VV1#BRi8AlfZ6fdVAL!ArmINJ_Hn7IGp59rO&#Hf`%3@4ffEANP3o^i6%; zb(dim&QH^aabc}kN|FF<8N*t1w2?Wx;H411UGa=$9{c(&=;h0oZ!6Qcp=F|2n2aZE}f7So%%4Yspz4~?MSbC^ zVjhhpHpwdVKI-|S(Ko9)<#{jN<5De~~ zVlia~;25zm7AnBIR8>|L75Es}08)E-^J24na`WPa&qUIW;q@C?Vz$_QY$MmtAyO6g z2R;Eg2<`%cdHwp;pMU)Vp90WAz@UZ$k^;5}Z`d2+k~htTnAlgqx1f4ozscTQUArcy zfGbYasVbQlbH~pOZf`blHEIJ-5hEt6E1?-TgEcH-gvfn#AqsWS1?C>Ml(iDm?*Biwp|Ij@BjeiI~%9oc{|!Obg-d2+kd zAYK^WAlGHGOd|Db&k1_W>ifm&)2G$^d%_nr-^YC@wdVO1a4|P5hvjaP;N}4zQP2ia zQrGXf-%%T6JJ#|OozrX1=vKqZ9JC^+63jbGB2ok~(8PKn~ccZkLK1G0?7 z((fABTM;lieg1%4NS3qV^GJoOGY?@c1xdM7QZt#v`{kJo8jJ@f7_uuTSlpv@=?5E_ z6*VN5zE2CYO~epylmlD&3@3a682|a3r;*o~U09`{T-2I!fzHt1CYn_-893|6gf>-G zU0(%50&cwOB0b^S^4#i_ZAM9C>~ijn>lg4EDPmw#dnyqN*`^7f0T5K&<#mMAqE+d_ z1yUhfJsXW(_cdT-I=F2`4$Bj~BkNU{oS)c)$B5ek6<&t@fMK&c%V1l%+_Ga0 zXys-~WiBSwH+K(EFCu6q97fQpO51x9ke(jDD|c751RH=o%_o|>uUiM72*;IvyeF45IrTyC7QAx?rz~Sey@J&zbRg`uz>Jb)}8{Cd7dxoN-s)88;!^Yx!VT4 zQVomY-IrP$6QL5=hzshf4Uumldpz1?%sbYi3Rxib_p7=V0Z)_gn7rzR%UDwsMgRw9;m8_xjMy7+@<;vn)UoMd#!vlxxMWS2_V&p>K8*#v+4M00^1$u*yE}aJ=EBJI z>9-;W55veIlq5vP$TCaJ$EFhF{OM-wqA_~E8bY8$-*{ghyPKYE=U}$oIewfUYx{Xp ziQM6GHjO;_$32!Od5qdL@z);^XB>;YVesBq^rrP9{j_9{pYWKVB}{E|NN`6 z$tfR(+Z%LjCLMm5W_Sw3zJR$w0q%?J(fQ%&XvfO!e|$MT8?&ul{&UC&k?RPYJw8i6 z5*_7@{y#c&rZb)COlLaNna*^kGo9&7N29+1n~^kRyf^>=0{{R3vN!+$0RR910Nelo z00000c%1Eh4SU+Swyy2-cs!iCE`%g7(47(6wM|gvAwCBb8QdXulZfoPG|m72FLy23 z5WYXU@4e6ch-T017I>GIWJ#7@ExppTxAd0Y(*NvK{dW!6m;a`LGy9ZZ_x<%xF3+}k zFy8nbrrywZwSI5qvwxnSZOdmfBTXBQdv0$y?yu#)QGotf>y0-J^zZt94{fY`dS-6; zKfD`*jdcV5_-@=U;O^2_w!YzKZ+tiOhr`~gf#KcV9em+xZhxr=wsW>t0bm>qjE8Fu z^v8E-pzr(r*CIH!b9s4wc6PqvW*>fnS*;(HBS?MT{kSlG_aW4;ZOt@T^RRWUBUUc`}BGarbaD&uwrLuM-@jAv?Py3hK2`%%q0^-4 z?PpGT`Y_=X;5E~9d(iwhD{eX6P7*LN>|Hf#gc1>_pLxPR4{oF86+9pWx9fZ0+NbM> zNy0z1u6(!AyuHs~CfZ-sk`NT(y6P8mu?p*Z1V#Zq^BDTF&|9 znL`pU{rhVa{~br8zXx8Ipn(td-`?*jezX38ka`0f`kCn7fBX9MpPJPE^Jx?f2A^%{ z$Hs?!wWnzxDx~@0%04^4JpcAJdie3jOZ8r?r+qpwN#>mN7{Sgorg@O}#m zaQ69Yl0oa8P9H+%jiC52khwb={wm(LaO5LV_K+qI)AYaZZ$EnkhaubD*Ldg2g#tL_ z;oJS~-`^gR>Fs@bdwc&afd_cDxADI^;Mz`dOTOJ>?%&chxw%isXKEXbW87B-uy1D` z`3C*>+cZo5EBQt|=~;H`IK1YztebDrd!8ogmn;>x^4WVxn&#P&aKN|ho7wa8Gk7o& zsm#B9OFo(Qk?uokG#opb76!6!`SZ8i&lTfX@09`Dxz7Qg12%u2O(!?+kIx;G?c4(V z84CgbO>aL{8>hfE=ls*R=Q7P6Zm*lhNpO4z-h7*>?7vBX+o$1S#$sx>(Y-i82`x|`wo-`46&LR6h`!0KchaeM*FV9mPP_OX5+aM8CVm<`}rehut zCv6*l4KFG(fdb6#xn|fW;OPyi;Zz0w$l)FO?Vck3_yX|cGmP>>_2)!l_L^Zd+v@K( z{N@n+CXsyoEz@jw0RM^J-bRCt7w*O1PVdw9+Gp*KcLT5E$&?KS?N6S!9Z7j|%jr#$ zCZE>6`GoLf`T+3%s&_wc!{1KAPb_*!Z|TkL?fMTo*Zj7C!>j0XcN>1dy-)EVO7RuG zfp1^mCbEDt_IYdmgTb{IgMmcCd};j$O^+uJ$zV_#*jD&KJh+a*0E6sr*2@o5i`xWV zqwxJ8Vq2^4Gkh1v%7Ytkz5ccKXMT%t_uy#b zI?(oreLZ`vhX(vU zX11IZYgpJ=a^bhN;`>7v4UCb8S#_X)Hy$f^e~H+$9LHL5pdSr=w_k8z{pH25KQ1^; zfB5Q{?KtPo#fk+N3@DaJF;y$stIrgF^v-dLyq(L-3$)=l%LeY|6yP#}I45BHJ=g3F z9atfj~5r`9{_)W6Z#>P%*E0dOzkqhKSug+tmviw(1qVSwsZ0EqjCTfl*Pu1 z?+**6dM$q>VDHK=hJDw8=Wf^+2uJU&iepwB2kLFOpifuJkNoGq=FFz+7=~WaE9dAv z7QbRxno)5s`mcH8@2-~dcSyh@e+O{2)G#dP;=J(Q#8zNHfuQo{7VcKMfWO3_I>kbx zQo=3AR(P#qUErfH(BpA$`SD-%$Kyx&2)X~+FcxhG;apF#n8 zu2JHl!h*^>%1u)bOfy0Q$l>Adkb_*~5U+a0gYjLXZ1PZkNzGYmnuO|v6HTi%Yi_UP zUpFYoE3`a@##`cf#i1{fyyP*VuyBc~RwvgUmUAn7?!nM4%Ab77C7-?U{3YkHhy`tH z&2D(D_7D0!e;bcfcmNLIU+6u3nI(yod731g(@wSRg@Nk2L;q?k2S{A>U|4iNgTg8% zrd(tRr|c$ZR_o+XXuLyk-Kct7NI*)7ht&fHuC(7wGoVq*uektt%)Dx&*YygH zL&nBK$`gZJFvS0 zUnUrDO~ZszK-GW!`7}zA|MUh~2Q!Dhe2_(eq0%-DJ$n*VK8-S&jlQNV{yKmfG#u*) z62jG?@^n7>8Yglpr_*UB?!Kzyc-;l^`9;Q)$s`#wnac^$8%Hykz6*mt&+=Ku#UNzK zG*1A20{`kZ9A}!p%x2U4ImdrxTR(|^1w5Ctm*@O>23B5jQ8!QHUo9s{W-~;?zqt(b z6X-vcDvp2}EXt6@ZGG3Uu@i66N&ftTzH(=zlw$IfQ##s@%JJq|4ie1-aV}Vl*TX@DgP4QXYej2CuE-7Csf39 z1dSz3!rCwmJ+2lAp)pMU!Z|*mf|5E+VedKJhg)PvJ<8M2n@_Qt0Yf;kg%)u5 zv4M=AuwbK@|EW<+T z7kO;ESUtcLWa0g4_^padetg9IuQ)65Rs|m(G#lh!)h8kM`}69L*7(c-0jo4h|L`UK!DDg0ZMf!bf{Hs>(D)d}Z z{9U&)^75TXPIMaR>ch6@75Hd9dVKBy@~?$sMuor7$t-)GaFX0mH5sfUzd2OSyPH$# zDtMrtKN>KInLK}|NMJ=GiEl_9Jy39LMDBV725VL;F>~R&J{o}5%7v6%h)0n?5)7t< zErjFu{$>CN8`P^vv%&-F`|eev!BfaJVmuatvxo)thJqs+ez%E_!*)CvFsLE;NvqLl zFixX;0h4wfh-?fWv|Ja!#N%7wTENDDj?q9zMehcD65Z!7BH%Qh$&3NM;ktFNi|{Ss zGXX>NAja=3%P@6a4;hm$f{9!XI@k;he1hnFx3dA)JjO7(g)wM;7F3_E+a!sH+4MnX zgR5>wai{PES>fSU15kni8`gD&hOU#yk>+Jx?XSRVz=wv>0t200izttEp#;pU0vh+8 zY+a0=G#wTkUq=CC54~VN1>{kL6BvE5-`l#ufBdX!vG(D|lZ)i3U8x*k0X#?-7r5!; z==vlKo__osWys&wnS>g&VI(=Y5Wj$76VN*QneeRSZ~rd%TQGoIQ3njT4SZHM8~qe= ziu`SsiFot}RDo{VII17O`+fy7v8`y7O_9Hy3Xu-~U|>{lwJhr}li=d;51z6NdY_Q- zBomPbPtP>mW5RdA0S9;OeixYp15&1`hzDZashGzxfPMe`(&=O`u|WPcOA~~*1v@VK z7S9s2&K)7!x!_5XmT*r7_HpjRyWDl0?AdGP2~P^=b59EINcZuK%!Lz35xk%QF&GH> zT_(ghD)_i40X%^~KF^+~_abIO<}X>>bdP0!(E;c`l*{MmY5qLRXD={{AD=rq;93^V zzybUxf00w~*t(m003}F}{F}WzKj)ISk9WREt%l8!J;XYY+&d|DSEWXU$dZ1f+qT;d zCd(Fi{`@?f2~t0my~E_#WFlu^AR(u-w=j;pcPgI}tba*QW*;G)!${Higbw8VWcCyi z&H!5tF`LaKIWhQHr3*0Nwz!<-yuM@4?~nn98kib`yRhIHy6Iz+|aIuDxae^T-nn(1cVy0V@g8)S9Hzq^wTD6AXl;S{KLx zBaK>b2Rz~RW_S#FUHV_GTvM;pRgd^D{-=-Ho?~hHd%nX6|==JXwEmp4^Ab z{r+%mE#q#9>D-?D{&-kKo33TA$h*FZpbih{JC7?==g*hQaIqS|i`*@q zQ--vX$>Lo3c<3+J;2Ips-+sw|E<1pwSJ98~>2eKRSh}_{c?93b!_Dx|*YMHt7)iv^ zwgU_HWq5CKPJE3&?Z2MiR~%$n1J>%cJycpx>y-@T3V*8T%lY~HVQ;=zTHE!4Qx%`SfjFtSr0`55PKVBkzYA*k79_PDR|41MY z=aH2dI(qT(;u2}=%3}KO_ZR%<3Vo{#BfdNw?pzkkt)ouOzIzS7=q(&r-9T_lVpMfM z=i)*YygDEii&j|0BaT&=aLWkV@izWbnQdX%>p61enw-h0%n2uA>=_m0z*YFMs^#tc zC$>L@#wfo^ls`{rxfI<@z*HQM@7o3cxdlG=VBB{Kv{vCs4r%&5OXZ|XFle$;E%M(6 zpEIz1zlbn&2xL8xQf3*>_qiKV%>v|7b$tp|zN1g^S?J3!7zL zx7(;FJgmekdskyLrfpccR}2eUuE<8(myGEn&cJgtKocJB;x8G_k13u!MCKoNJ-96S zOA))KUC~`+@VjK21Kp}M00V>yPB8Ks`Ad^N{;X;@n)5@l1{!E-ZOWiVS+ubrrnL%- z7>x*xiDtcrerx)aOrCy>;?d8i)bk{Cr3x&kJwAyzvntiq)d1_(*nlx8KCfHn0Jowa z6Dp@8SOtxy!edX7>DVoehe^a(SgCr^3Z4%4OlG1KczL?@`4v55qMIox-PM^niMb zI)*VzXOO)dOu4dAcdmZcy% zp#CA6c4gX3O7HnQ{{p!W*mUN}ppNmMUYBj%eo%OZ{C@;^zhT;8{ydvaAHTrU%V)DZ zY3u5}3GG0!25x+{gz_ULmCLtdcd8!e$g-lMxbD1P6 zjsV`)FaVzl*TP9EVsHTF1CQA+(4W^rgHAuyGJo;M}i3}y@B#0jY_som=5HhP{t|XX_rDZoQ@CS!Fx@OdezRaY#x!IM)CQ3 zTJ;ya*VJ()qN=U>Ynun8s-0fzZ|N<)rT-7owlGnxA8q+?2Y$=x`wd2OCpbbLYn|sr zMs<7~cY8NR`g1LOZru0pwy3IZNxq6RUGsK`yrDY4zl9lI$$Y2`tnpVRbE9pBrLN=g zfUv)D`hHH{9xQ^dsMq40{!;eyph$%KJ4=9%-G9{&UCCaFZ=yEqiZ1F(@Gj&s?Db3W zfED@@{x)Yn@0KHYS7U$u*WgKYQ2zCsad~?G?rsIHo!cvs3;yfb|JC?Qb$Y)fg_rBk zSqpqvu$N;c^!obwSe@QST5+{qu1%av`V(`Cmib3lMUT$u%O$vjC-|2>SdhnS9iWW< z#Q4!=_YKqeh!Lo-8I|Y%*Xd7J8Ms^UuLT^|Ai{L)Q>o%tQ4zbk$pS7yYv=s};D*U&Q<_K-wN>~gWUmxXH*!}7%Glb{1N1$YGS6iu zX`7PbCn`d87yaoL3IgDPkMQJ0N|8>oERi%u1An@TKJ|A;Lb=#GREVhCXe0?uIOnhs zxJhongI256b9;NxD)~O5TNnXKco=z+phE_eXhs@f;J72Sj;-sasp}-lrN;u1MWoU2 z8jT~vcpL!3@>|zglE2KllU&9a{fEcjk1?PZ;o`ckbIRoNWEwK&sqoLE44BU4IcAOr z_@grZGh>FKTWH{5D35vm5%n%0Cs?%##h>a=*`QSzFb?q`=Ea4A<2ilvUGlT4aqYv8 z^rqpOhOSDrHyB7a9R-Ju>q@H2rynCx@~6zyRjuxIz$hvn>cC+?MKqP8zq7wbS>mxL z1`e3;<=#*#Lp^r`8B`bJKk@uNhCs5>UoL#30etUzKs`3(elE@(HX?X*f0~IH`BQu# zP`<6oYKzpYpwvi1>9v@V_@1S4_IDz)IKl>GYV`vrNj(+p)M}{h8wy?bAcw`zTNWfwQH}Sqxv!#WUE0U7H zziar;U@#td-6W`MeW*SrvtTw;@*e~5G4H}4X1W>|H*Ab7>0oUefmEvned@sjLIDMv zA$urg3LZc&mZ7HuJ_hdx%7gKm_oV76?LA!X;^}+Gyh$*6Q7ZZr4>239md5G0P(X~= z+-DJ~vIrS?=4rhv3{*~#eN-B%vwRvi4alDHNI8#@^6Rx1EB^z7Xy{_h7VGYnkv9HrmB)qO$ZcC$z;zj~}gF>(TRZIM|}!SkmuUHlpDcBy?AoswzPG6}$&L0k|Uh zw=g2F4qy*~;iu8)xirNJ5UnD6t%;il;QrQtx`O^5u&6%A`>s#r%Pfl;MnS;Vara@% z>475AqGcdo;aIqdc-3;RvY8YFhFvvq*SeU=&Qr`3%21H|mSe#<@Mp_y@acrYuwfR% zrsvVUY!IN8bsW6gDB}w~E>Oeb9?+HqW4Gc>ihzF%oIee(nPf@mo9q&e*`26}N&^^t zcHvx{i05j{xL&};=@gU~PsEMau2xA`-1FdMd@~qKk{eR5)nO8I{poZPso9Nj*STH` z!e4=-2cg#{&3e20OVQU_n@~c#op!DHYvH#f;qbq1vsU{>B8;XQ5ka%sA-{&#C^!Mm zpD10hlIm40_&0gHHyZFQy`{JGmi`x~?WgCrrtuc8w141gl;z}a8UT2Iyv^=<8X|GG z89rK)kB9NTVldYj;C{hh9#sIpkUw4HKgUPqj-jvRN&l7b$CAJ7BZs;VKfH^E+E8go zF7uZ|6+Vi=qZpvM-}m8gTm(?A@TaBvXy14D+>TQim=l;wOQ8Ab`~BpvkA*K8yjA{G zg}*+|8Pr|;Zy%KxUc*n9e&&|^r$X;^!bk1ZXzu??Hp&5YtJl5&LBIdX0Iw=gxB!zt zY`^0&{B)Vx!_z;Qe1ZR_@#_?-R|X$P>*wbS`Z8K}KI2;c zBD6#V#G~c$5x1up(BU=$6X;}T=i>$H z{UTk)DNANDO9u>AfEd1b#3~r!wnCdGr6Vmw`jm=63kg-{;2kFDyRFccZF~I5(4gyl zjWf^CjbjX;;02yON4RMreJZr~KgB~&#{>MPeaL`r|_H~I^s&`i{i z-H&&T-z`)RFxiMpX!_6tMHY7ze|k(9mFp|n5NN;wn`Ws1xO|)lD7|SNBVpt@@AK*O@w!s2R-60p z&QmGmNfe@XrLL1iqIl|ThQr^7TD|Rg?E_Ry01r$G#yj=jb;Bh>D*4sfH2CoTL(LQ6 z-plt8KAA`n;lb6KZul-O4J4lPq1Fy4ya)HO86LlvnGn1id}@C%T)%Zi;~W(XvJX`} z#G1))?@?$DZ%jNg9Ms!YQ**Bxev2ypn^&r}fInuFaBJlAJc;ysK9yNa>x!;zwETva zK=CEjD)m5QiRkY2pQo~r3;v`AnpO|+^m{J3R)OME5eHs#U;TAN@*PV+>k97zTr()% zzV)Go2C(|~wjq3aX%f%lJ>3Qpv3Q25T5Eo&w@JIc@A5))K%@z$^Mkk8U9c(R5#TnV zEC@OWS|FVdb6Z>8_ByF6HLI3Lqp>A=R zQFT+YeR~NUv-=t_O1X$m({2q`Iw>@X@SkQ z+3OMd1Jw@|-274pc$V>#Yy!gx*#%o9hIqyp!EocH{KVrIG2w>;h{HiuZC{~*WtCTv z@JGrbuTrV*tp!%@iwy$GlcfvdxVVpSPt2)y*Ebwjk~ba{+gFje5lg?MoGD$Vsu%6W zci4RQEE36*{~=XY;o0ooHd=K6THMkv1IBoHv}b?oe|3N_OZ9q89qhp)Gkf974lF+{ zwPS}L@7gq5a-iJ5ThTda#%gDBu(~%w>uB_yrsAFzdZH#lYh&<+_IABub+wElZKlH z6dYqy4`;sR_`Zh3)aIp7+cUrGYyO%7BeGB9bxqPO$?vOZ$BnXYDp2yFg?j7Kr_(H zyzQwArgpQhr3ts^`#w^rFVk6)Oe8EDVgA_-t6E8)9vmV3D)Cs4+k<8@N@Q4(8p{von|AE1nh}{1J)4^xTw)^j^U?2g?vB-(@bV#JpZqo`eF4` z=l~{OyysNdD3L;>GK-UY6~Ag2+7Z{-^m^_)=i|9kF{4C2Wbrgk(j*SB{T+Avl-n|G zsQu&_GnW|*A88yb`u9lwuZ2;-S(i^mAz+%sv6p=J%p>n#YBk^i*c^F3Rs2VQrvooE z8r6E+TVC95OCF`&CKw>`B%e(Mj37zO(p*jh!vHv^`wif|DLiOm_%+REFVjROGQ|MU zuBkf!zfbncz`=NPFJjL_4+1$;+M`N;RB+R*2hgChWN|Obmc-NVFj&$ysp^%w!01mr zKmRc)UA*7_J43)->?yRjh%D5>TDx6IwN#+BK>%JPNTJ50498 zc9eRaDu5Z?V+e09Ssgl6&5L4@0(>_ef=^FC{dw(r?Kdz$kOhC934)tn*myXUZXX*$ z0nMmKn$21TV_qBB2xgKhINrkuCELe^1VPXtL8soXeSrMojnhz#0BgL7B7RV`EjNoV z;W-b2>ub`fR`lO=S9crG4`!)4NsY`5t$X|9*?4kO?+TBg0`s4Guhk&%7U!jDN~`q) z;dB8P)w*Cr(Voy14V@&SSpUMC>>wO}Ro6&ZyldPB4*QFJM}qNy2jCiR*lA|vcYIYf z@W#!PZ;sMXdfxoK_!GRwenGocT{=+UPro@!D|EL?PwdmR57gaX)_6OePaGNQW>3IbQX2k-~deG2kEK`(F`% zK+;>mJdynhJ`nJd!SY{cD1m!2KE#&@QHD@G{nQEw#6*PZCDXlz_f>eR`b5YDzxHsw z)(iwcS$zTt_`s`S|NqeJhC#Re;WRv<-Jtd!@zq+;>9%X9^#Ias*Xz{}m}$M)gg0sD zv;g*icHsS6!*1VflMbm@k9cV;CEBb8u-sJ`+zunv>PdJ~t%qK_9Cb(#d^%Zzf&{N6 zCZ``=fNEQ@b~64gy`^7E{=cU`drbIkk+uX`_J;`f_p+~x)Y~wChx1ir?I9P2kqRSS zJ!w8a8Gi%=UL29u{1yFAe=cBfgzx?^y2EJW{^|kzl9s&NYh;K~r@j6<|LPCNb5+yv z?)X)$3|>}T`-=Xnx;yEp3h-6@<#^UDn+Zyvy;sD|-ztRKVl>`ma3H7mNxZgasObB z7vDub%h3QV8)L{{ZL9k8>L0Ifla%!J+ zF^!qJK1*Gobua|*t%-nI#as6*l-qTw9=63B>mUWZ)L+2xV?%lH&Z-=WVzz7x<&(ig9r|XAI5M;qo1f8i}JPEL;Q8bOyej5*uAh(eZexLk&u6j z2l)X15hIi@XdQ)Djn95(n^6SLrw{4h51AMnmT9_2_-`03XhF73zl#CNA3VrZree$z zaNwBY8%CqmfOeL9GmPKOB+4%gywsECQSqdXNqJ!7BDJqe%@%9xpN)L2l^+{?)Nqu;KDGR88-UN8P1B*F^cMQVH zc$F1k)oL{!V5AcvwQ{Sq=YCNaaLpuD!)M*=(h$SJ*q~akv$eddDt>MdvSR5A@2V@; z=PCkuI>9{)g9Kq0qq*Y20N|@6csvNJDC-Pg2WsgL@CLjsqlIkn7Scx!0N%8 zf&*%T;Pr{{pKep-kMOI8C~6?l6h18AcuV4Nl~yY5ZdA6%UP&1E&|Q^?$4sgS%4X0- z-v{bfYotoR;-X~mFD;{NRc{wcJDK3$+d*8!$e~Eb2A)L&CEtv}Vr>;Be1&*ROuv^5 zPF>v)85b(q>rDW@L;VX?I@)Q^189k5!wb|b@$ied3};(|V*%K>C;($*PI(ZoZQ1i< zFLgE;3l(G;Yzd=A{f$CgBW46QAh56_-pXR^l1lyFmmpwpj@SshaHN+Ew z`mN!CEt3@s7{CYZui3;%aSuDzgr|*iq$4Ef0-k-J5)a{RVD-idGs5`qsUu%T`M?oy^+l25@y`a28Y`l7Z+IX%C zv3Cyx8Nh{t#oGO4bN+V^yyWgn3V2z7caccrRvzm(v(c)zyd#ya;)spD1td=dYR zCZeHw2p4z?f7N+)``X<7@e01YzYS$I`n{6htW->AMfeT38KQ;zYxl=J=0yOzUsAKh z{b!Els15vLx%(RYeYbjl91^Q#0DD<~&gI9;i*tTvn+Z%nML}Tu%kD2fDD(^o^aZPp z7qB^JB&TOIBaz_ciplSf=iaXgxD;C;b5#!K{NjR2!IGSd$1veVGzC7sh0^pYe_k^4 z<<`T6bA$XfiXX@{O*nxiWd|4W{#-qJydI`rGV4Y89m4JbEpxp7>>-{eH?)mY>4Je) z62co)Zs9?Mwc^-dfTt>ZnaLzcVqSzjmio=xg5>80pz+v_Qw0M_o=J85J`t2D0SzTl zypsSg3=DgJUNx$aXe=Hx$X~=fqNLuz&{X8Vd%Fp6zo77Yg@y*WfQN=-enab3WUqTl zU1Kka-BTgvXaNm)V}^IXu{x69Ei~G))_cWDG7ZydxCI(gm`TQ|VC{lFZ{a0a=DrwQ zWd1DEv?_SzpGhzPoaHj(ZB&IY75}}LKQ>JJo#|9iMYm$;LCB^rvn&iFuav|9^!^BH z0}t<`2}9R)B1c+~h1w`2>O{QZ96)0Y*ckk)>&jvAWI)f=pD1Q-9HAiMyt9j68fG;x zO|AqqKKwxZyTjqL5e~l|XGFzsqy8|{Np|=aBQ@MqkUNB0aKfKSn8?w?^kI}H zUh+iE%637@EX(+%hHoQ-}?89np9Db2XIU;%EWUh5xhL=lz+M8|d{?Q~NC(-& zRt5J?hG+l>Fn}jH69@Qf;?}7`W-zjJLY#=-O-s}mDy;`$gQ|xQY zcxSfx14bUpR3;dJO^GYKru8+&7$iANz#fq)56%^_hnH7s#z~dvH*HLgb9@NRsqu|Kw zv%)~P^P$%4bUGS~1=BnvB314K_7AqMoxMm19h3%|2%p~_6~rOJ$Lb_F+nN9T3_sKX z@6_9!pjpUvX_R|34oh}>Q#yR%e<=+<7=+xz{A;CT1WZ3l*0~74}yWku-?o(l{H3y9FiY8rblom3Bs`pyN_qd$8vu zf1s4f)rt2N(FqdrMcLRMJ&S;`Vvi(V-5+Xp1sj(F;~Q6Zt{T8I{NaXNfESd)<@@1k z9|o#m%+^lXG(9C^FxYi@=4(dkdQ{xQS^2o$2?~L7b|@S+z)cdmab&;Fl(;wR9@NqZ zD9R0NFwh-r_Z~e)3cw4tDL!`s?|=lvTY5`x=`FpbxAcE@+Ceh+_un1&n*6N>`cZ$E z<>g-?Z@7&lMrn?Xu+%Mi_fbA%^M}aHt$%vH?X)-=*u3Ws8DvF0uZXa$^DTIN9%@x= zN|p2r@_D?fqHTeJWxl9Cyerx7yVZ;O7R2h>9)h(hy6P_i&F@zDQ@pruYy7uiuCDz2 z{+uXZ<$sYqEw4}W$K%%phQ34^DeaWrctHWL>5n`XwCZx*I`7Y&^F{f6j1BM4-5;-B zpm#UdZ-(6GH3;C#kB)P8xiE0I#6Pd+|F4o6e!ao1;GmJmo*P(Pe~16K9KSuj`&Yge zLGN6ie+0Cm!7o;;f2?*Yma5eq&IMo=kHtAZ$1qNe1-%Gf9a!Apx8nl6dG=8Biwh@E zH(@#9Ty=I4fWCgwpF2MSFu#5dz~|?DHgTMD!Z;~)Z_D`Y4fs5K8*3E}oLx8^qd1e7 zX+W4rC`LpsDqvl_df`D)e?7(InUE==c|MIMLMDNELsa&=^_%A&KnWUn{kq5lCLX7W zNMx4A)Ps(I3emgozniOT_xmoMTnkBdiJTnr$u2H<}pCkbV+9L4}}xA*5k4%E7EY*#VejRuo>JV|Z> z!6_2hC;?*aKhEn|PN5!cV+c0={*p6>3eX%$Q5437K5+nEF_ikRi2;{fzU09m&l0?X z-Lx&o*?*Ccsf2$u9Cq;cHXCFZ!aHDkK}#RHhRCsgH}xvgZ%V+~SzHd)ikIrI(=zAA;AL9qKikS5OXx=RazS{|*#&e^9-ew1XxF ze_dU*Y$wQy`0p>HA5YBmmInMsA7b2)f0o|_mTPWV*jRbU_RHlCeenf5OfO@&0 z)qo3r6KIIHEh7-nannqRvNC-B`|&}wiuX(gMC-Xl6BJ0^%k<$POBp9w#!)@+mv=?#?m+ z-V`bVU8zXt89h=xx=fa1o8KSA(M3`UNUcz+820BGz)uS)w4nJxEpiq9 z{G9XPv?IVU>oS#s@^v8qllQ|NkyWFwePzvO^IOR2Ea)M zh^4OC#Mf-5s!-Bnjt?wSP{gcaf8%+M3^-q$UD*{ryqrW(=!{^KOP~RLmqB?bI^gv1 zA|sygYw~JLPLrVCR#DI~a_H3>*}n@Q9v1-v^VIY_QrF-;&KLvuUNKh6)B9x&TTCQ` zkugU2U{K}T8Sr|QWrE|mHNGLzgTgSllg)TR4{w2oq+a6;^~1A7rt#{RsOrNR>nbtY z0pIov*nm{QG8&Ng>#_-9rm`QGcSLUEaOr^622ivtjYP8UKj*l2!sgj;V_`i!8iDM0 zmV`WB!&A;PHsFPp?e_a4gW__@n6s?AqCu>_1Ow#-lY?*vh3&D3qXXf9Q@W17rgJ#o zwSN#O?i$YlB*BJA5lrUdl0)A~VXIRNV1TpD8xH}`)&9sHK?twg#R`H)oo>_+Axa3D z5BBLO2VFW0p`N^WJ$u}rMZY#qUaT8n1y8>1J5PPJ4_^LghlXwd)0@K#x);1j@V=%0 zztaBzIu>P(002Z`00093002B;00031002@B0RR91004NL?45gDlx6z=A5d7J2?RwY z6;T|=RKV~sfE>(}N>j|#wX$qmE4N$?9T3e!>7YP~cxsXyl`+yyGP4E+1sog`g-sk$ z9CgjaO3P7lNWbd-Ua#Nhy6@+i6NA{c)<1i}95@g2p3n8UuKT{9`x!oFyuXJ)(YLK2 z^ug^1_;4$3Jp>>2`96Lg!rvbd*yaBT{6gU=UdQ(o1l_m}Lg(mYq31*Kf}oBQGG2dK z=-IKO@Y0B3!hj9S1Rrld;Z0pfLH+tLVbT+m1pk+UgyiTa1W)|U;R6IA=B1fJ#|~YE z52pJG@nM~X*#l%kkStPIqV^QVg|!pbs^1p+FL_%C>K!k%>+3BHd3}nY>NrDqYFLnv z@#>pG-_4zcVT0m@DW#o--d+0(W5>4>HV^A4JTxd$5ZVn8f`+vdWIcU^KK&zwUPI!A zwxt^czuCiu$$cY*juU)@n4V7vK7Jj9mxn(k#0`oTULQYJczMtO!8f%S0M{O`=0QWumC^N79R`v-QI0G3VxmY z2$Od_C&cs_Ahh+z&-i!?F_8m=&Rx3-9sGTSwjDi%DNl_B4{xEZpQq3{Q4o5Le@bZE zr?220>jetf!w4HetFjYQn2RuTg?9dHiI- z9}m~NbF|QT#8ZOc*I$TxXn-(&)KkKX?M4aS-W`Pron=D&@UcQA&R>wt#Op3+0yOiGkh6J|kUlO^2_fMJIqeB2HfdUZ0@3vE3iY|oCk zc(Pab|Kfk~zxZGLFa8(*i~q&{;(zhK__g67c({I|StPsrF&;N=czSp={}Ft~>9Zc< zH+k@{cnB_EZ!sMHw7b9a$Al+)Yc)Isx6kHXey#L_?CHXrr~R++U*vHkMJAIC9y}P= zvXmP)QiAyBlRaF%(bLl{7xC+N?($$gT;pyJ*+YCHTKm5LC`9(Z?svDu#r0R*aq}Gf zs=vY?9q}046x`4dsgui1Eb`>WNJU!kU`ELPi1_z=x_^8Q|DzkR{bwQlhZ5D_`s-T$ zQcJ(v>Gjj9VD1RXzwv+fq!2vk%K$`YEGRG|_%*x7ZvxB(Mg`HiA>8$!;{U;%+*(y>^rD{6}oWFpm%{d?Ikqbn z2^4eq$0@(%Vcw7pPK(47Z`Nwfc{<`Tc<`o86G!s+W#-IHoA59P2M6o&3IYh5JTjQ6 zhQPGI#P-Q$wTfG zYNajY^hTj{`5e1#_QUMKx(St4=5g~sd5oTTS#u}_1;)tb05bD2#K@5oC;lSFNV>v@ zBPTLAk;Xi;Mq`#YG|BFk%u*Um<^oeevv7vwN{GEVhFbj4h>J|%$dK;oXCLSdg5b@ z((T)uNICJdB8}#C+JeZm7RlTZZZw#T4Nbwz(}I^H(ww8I3GYo!NAd0uO)UidbVH>0 z5|6|kRV2yhKSq;cRTKtj-G+)Z)Y3#xtJ$)#B4dL+33a79ttf_Ltt2cjT zseFS`F%~d84@Tm`^FQ(8~(y=aM?6*;>?*d2^8b8>Gr1E6u90*X!6#rD=;pX zNqNOFoh1|UCUXH04vwdg$#6BBE;72MdyB|*79nuW@38y0H{13(@$+O(@#&l!5i$}R zb!0orZgF>@PqX9Ij_F@>KwXyb^LgCL%x8^c!YF~&(NpG59V)!;WKzv z2D=M-k~ZNwF%kFa6A1~vs?=Y>#p4dM`Wu5mB_L0S5}1+~Tx8}8GZGUMXAHmn!V5EJ z0u77XiKB)OAA!G?n0PzU7PDsUk1AMa1{vPLG^i)P!n*a=DT0sHcN`sUe330ZnN(ODkJQX3R0yYcI|;BnqePc<~nnKOWt z74N+|o_$Q8lCZE_+ttjOxXj>B45b%}!J8OqK6MmbNw}&SX#ctzn}^jF>Tlgt2K8XK*VqBqVXzDBSyS)`t=nkxXe+ z{0$)XXjZ-sHWoDCH4`tzQD9j#m*Oa~n7fF5bd)}^XzmAeO^g@|_PGxbi`ex%8>RI0 zdGi?3MNO33D6gp+($ZzW4hy)X`p%K4*kZg(oOStl`t<2^O}8^<5E>E=DP$(SieGr) z_J|R9=I9D^9(xRaJaXcAMWglAU(>95rUZjZo-TM3S<1|riFgsbz#-g9`o3`jow@WX!VarNQ)^&iqV>>pZRTA&yV%C3JvkVO_m4wl6`$5F^7UW7Ayt{4#! z5g+h-ABgupi1>isc|-uuyrca7JQnF360tE58bg!p9?LYMa&z1qL#pq%adX^3Ig7B} zq5IR%o=p&`P!N~Vqes)-1i~_X`X)*-qbbec^@~^au*6ZLMv-2AnK)9GppaLOzh^Et zZg|QRc>zRa6Nuj)PU&j~#qd!a%dA=6Mi__`yFc>w4k0L@f;Yr^T(6Id1DV~WkjzNW zX6fX{a@Y@pv0Q|*eaZHt1mP%$VS^IE?niXz6o^vy?h)O$cbDQQv0zkeWEh=vyr(z$ zT2xA<0fhkmW)MxP-{ooGSjPR^THR^au7AJ!ZvfeacZ7)JtOJ+l5h9(lz`(C5MvoTB zh<8ImMvuP5ZgKC{ty_2=UwDBM+{p0>ipItF&P9M&;P$}@!1CDbO*2N!U=o?}!tfFJ zwYNT8@BQO$!ckDL8&M##@gj{#RMv;$5*OERR$OQnB(r~HGyC<7SEI}uI&^5?{R${5v7J+(YhnNdb0fBH-P(O?_Xz$m3+WEsh=e})fL%Gk0hl@IO;!WYG^ELb zTKTsnEdSnBjj&pMFIhKO&+d}Aa0JhvwPSH0!@e?UG~MzHk}&-&0dbCy#~*!^z`Vf0 zOdNlxO(B4N`^<|s2qjDP}}TxO7ygn0j0PZ;pb&mx83GofC@Y4?wz z&`iHje4!ub5*nJ7wLi|QzO=q?{79En;yE%ciW-(u78UO-fnX?VYPLtPI}s6Ew*yE7 zQK>;}6{CAi_L3SPz&A1;HA`&Du`oX1(cRZ#K~*~sl9_|cqIuLQqHe$Y;16*bM_m5B zuev(Adhz1&^76&i8_quatnI0nP>58Xf0}>%{L=__rC7N^r_*`!O4!@`y^u+xrCk5` z|NYv0FhzC z9_29%em{%Q;PVg*z>s7>CeEwO%PT7jV35lO+n*BDdoY}l^9RQ-Z|EB}v>snCUGUEK zB}=vwlN#Kq5krEpwSWKq{GNer;Sxvj^~$fm{(2?xSV{N3UWs^`;o-6J zz@R~a6zpcuppQQKXplF>dkhSqJkGczjuOGloPM@Z(P~-3UeTU|Bh3Yo!K}hY$wm2V z^sQmHZVdwo{BBVB$SdTluK*tbDF4UV!0JOm=EwExMZJW2A`~ z#{Op{Li5pkEMLB`?}D(fceckzFg7(yz=lu|jURC52Y%Hb*M|-j9m2&W2+mvC=Pks= z@>ZMn?c1~m7;xD|+02(z(}Z+}uBK@|XW&4?PK710f4{=wS;QrZm5>c?p8finufVGB@l-rMyr+fuhLD5BG+5ORbj5|ch!2k`#SMYoy51_-?Y&&#l&z}A) zetIAA6QaMUA0@b)2blKV-y$wMcC?XPX4fu&L7&)UMK)`YUY@pD6&n=?EYCW`%INaw zOV5JKGYrVrSMh%J>Xa!&W+iEcxNs^54m|hVds0aEK4LNGz4s6|IucK=>0Le2Gos4u#!yCsJn;$>PDL0tO%y$#~S@?UpTTH&EpA1Jtt21qr7@kxgho=Kc43vS3`g&vTCSdA{gq8q!@WGn?Tz zc(x`@A~b{GGXTS!8i{Bojs7Mm zjJgERRwwafI{EOSWFQwv2Dyx=?Ao`l%|6^9neC$TEFJxfTGiybW`Uc)*%c^+fw>ua+915-#c@cZ0asOC8*ER!V3@F#2%sb-KjwJ<1aX)tRr ze1GE1V4X2IdxOf)f9Gf%;IJwKTps$jg-%$HsgmHaAXvTkdaE?t_RwJ?6Z;7EpEEI~o@kM=EHQ1d-Zoif)CgydYi zbBK0efe!{QTXyOY?hah`lUpbZ%=>*#ohs@BvGm*lGHu#`2Dr4r^{!o1HnT?4YLF`} zPPs$E^2#fYTrP=Fo_S{M#@fZe0xmp#agza(15Z@1%1KjUOv2H`2)&rd5TU9tzcilY&!oNFg?**0+7 zsZ-ks%)p<1a^hkq)2B}#BGczQF`-=6h6S*6VqkoIcM%zyk~5^+A3}31uQ*~Ei}x+H zSFdh-aV&#Fo{!s&2M-?HC}KGfSbN~PDekCH68pOi%zNHQW+9{b7$O^zA1O;S>IS#Q z#WO`=HYN-noEV%Sjtg@t{X%|Rw~nxg@plKwkh`!nMr8W2OjZ^bx4*3HM;J~1T8iUq zVg6b9Yl+KokU6<9ezxoM$ela!LreSC^gqPNFeoIMb3By+PP>7JPPH4z!Myd84UB_a zhzsHr$n1ElJ?_C|$Y&7e&+h}9eblNkw`E|KFn__$o&{AE)D1T%w% zUqTX5A5-7r?S#dNi%l{$jXhtA=hOU6cJ;J{V?Xt#4G7mQso&AGhY=h`VCVfRTiyb3tKqf?uG z`?zetMx|7x$s{cQZiWR^UbazraV!#9?#35ioH})KkApn`WGb-qcw!83IpCfP!!nwl znbD7rwiija&}tX~hMa!}1Vhs>3ZtU6*$9st!REZ+!Qc{{=wSOFqCo!f=bxK{v73uz z{Qdg%o3$HV3~FU+ENx(L)$RD&Zr$hxWSC~=JN;=-&)|ZgsK}7YK;zsapAeLD0P)FA zfZ2&Vt5$&vBje6o2+P}ITqDVFE`7x6jOnIRCz6dXv9YKK42|o%ishA$ov^(4;*&4F zxN%GE#t9Q9PyWkaCim#kW7cLhvSVk+8t?Kl=G+_h9J#D_b5TF6%?r)$jMBS~-h@IewfA zrQ6!$4|IFrfdSo)f8#)gFR%m_&-kGQOCq-K*>>*GBai&!+$W@!ojX6l`$fdgfjd{N z+9`4w_Cpp;jI`pa7aJ8CJ-&6z)=aQ5t49;PK_+B0OeP^D zn7E*WNoZ~M&Qq2bkjCabXL55vqyOlm-e~fFZWbaJgd~@KJmTut0ZSYRk==s~au^gt z%6R}_1`HU`?HiWN7A}nEodgFXiz--hbo&z2%7;Grxd!si*$@ z=O_R6B;F@%*)o-L=`s0@9&bz?L%!c5SByai0v)*6v2ZYtid=4q!-==N2N4*`M+qdD zvqn_Pcjb~Scn+4EgJly3&)l>rgwKNE_lA75+q*dyo5|R?h*`Dmo}spGMRsm8^^)SapuCc^76|sQ4p3t|Lt$DQ}oz!ka8Hf zQ1C*GhGGtE7)1UuDDZ$gEDQ`|aZ9{2Y}lj2LZ~VmJ!3{98F>N{84TvGon;HZiE+Uq%Y+O(($HmQxi;Lq})`}kUzylAEU2NM=MrBtz zz$oR`UH^8~ij4}#0xo~S`xY>nJbChjX@upV1V$W2Mj{L3O{EhQ2QZIHScW}%i@7r*V9xbH8GUO z@+G;zUb=~Tq4<<(hLd56iC3GB9$gMHHOscKUZ3(93(90WFS1(>ra2ag%e8AxU~INe zSLfSMO|}osCW^9Mb9QwqkM6X~EfvD@lt_iemMxIV)M?YE9_%rV*$V=6*jVyPGMM)! ziC9KEQ@KSiZ)r}1-3|j7YGX((!NH2N3Y{*YwSgEj?b>&~uza5*6Gtqf zSZrKSBOioTdb}}>;t7_|rm*p3a0v{2Z_*_9SVS=Pkidi_B#>ehNMu%7D_~NZOeTdw zkrooH2;nnr-uA)Dmg48Hes+}0`ncU4%4qhbZ1)#sNM%)PrA&4_e`z;oFpSLi{UhcE z!Dr@27Bs}iLopFG{eOU5dcAp(DTclG?%f+udbFU4$FC=UA*8UKzQJ9cJqtP6|t z%w@o5-}&g+=zSl%QhDkr5sQrqfjM|^0%I`^1=$-tdi<3>pcxn%w_Le6aKqC)g*lSB z#i#R|bGh~2Af&PoX@R#~*BX~QO(s3KP$CQAbuvsJa=9xRS1#+zI_!p2%F4d@0!i!( zkqe>u3@$TZfGe3t9{Iio1we98gPOQ3IvNqN6&CXe`N=0#l7R+cVYea}_nv?4niH3f z{{G-1LLn{`u_((J6vimpFWP~Njfzta<6L?ioQe+S;8ZxwG!aYgMnK_Q^nqtxtwmg9 zF=NIkS27NQp>^G9l*n4Clx1===_M^VVFr5s#6<4`$b}6i*qi*n^S74r7;&km(J^rO z;>)#btGHTlS$ce_i(tS7WGI={AeqIhl}BlPQpA!PwEY*Q{Kdq=xb*Htsv+}tuNN0C z91O{YI+q;$xU6U4 zRa);Ax}OUM*3ZGLJzj-AW^K0zzImWImq(U<-+$}ex$mf(X3ve-zI{nee>5?YvG63u zZh1Ou#)XDp+;Jf=Z+8Zmp47`6BZ~nFk;^g0rBke57s+3oxV+ws%fSh-eHcIP^2p7- zinekk%VUA>jdrCXVwo{Y3>%bNROr&!GC4o%`7Ny_GAfjVk;oD^F?;dO`zYj5X`ZE} z;Dxf}`ox9wLbeaV&~OZS|K8(!_pV*KbZ@tApB?Y^jWZVl^T@VsHCwZb8jjLj@{%Qc z4jnqgx%4K-7t@$Cm!F)*W5kNgMKAzE?n2dA8(uX71^ElObm_usfb!^lA{bY>ICJ5n zF9+F3GVfwGZal!aEZzVv-lN^+Fgq1zI=4o957H^fVaWV-hE|Oqg>o9WY?_%sU_OFe zIG6u(nxT}YDeYKn{fo$j)nZ=MROX|L$pRRvm`^UP>URA2H#|PIarx#?k34d2+p?NH zMcEBRB|Cf19x0La?)|2Sqc;!YLXG8HZ%GT3*tF&Q@9*ei?_VS=07L%LvnRO=+RQdx zm}I(q%-n^9v#+{bvY2LE>}V!4m26?A0y6Xg%4F&($ze8ZSgc>{%w>iYBfw(B2uCh- zxiu<;z=%h8>2yu4%vs)O&>PA4X_*pn$%9;I8vpS}ZA)PIN(*Vhg*eP_ABKTqyy|yn zWrb!jf1xq5stN+LHoq$WWY*Gd-DpS|L1aGVT>gYOcdlLkJw-#8Y|qXHmuwQuz@5E% zk^3`e>BZH;z<>);`M?&$rhWSzeO$?a%eUnHlJoc6(dAgISeA(yZQnjsc_#+Op&0wy z-|S=k_N$Sg*{_(zXsD=eqaaEjr>N3eCtqZpqNBYRj+R@PBF>&fe1QS|T@0FFcpJprp2CiQPIBTo+;wFDV z*xtQMm%5VqhH*L9Zrh=->~|s?D3{Snr9+3d4djE$#N`Upipb@sAG*(7G(RZFBZ$TP z*^6kME%Dja^*@7~eC$g0XNHBqc3cgfa#4>}hxP}v# z;WI*XBpBGaLZ?h?Wj(A+g@P;r-3~3VMH;)sRpQXDx&}VO4zaM2iQBz9ZdP0t<*~Iq zhzs0*LDfkT%u)j5tQpSb+_r7tlAWz2EQffs+sS&E-n}pO>TNTai#y-{VQvsRfSqP; zL^K{jvq7efD4CA-_!i!8<8o|s8$L{S{yhBU5)lHJ=q}FA&*DjfLQ`XOQ@f>>nadV? z5S0z6k~csv8v++|z3{`5Uf^#pTr=+goW+N zrlsL~vbRwpTZL9dGO# zwE$f9+ORxAVdL@$xEunNumc?=p^0~^|1B)S-4J&~K4$&xA z@H_@EjLO8vTIDjFtRE(WAJ;YAJ&~nYeQiaI|s7aWXfRCM0pm$q$fqKQQ= zI~Gee1Iy=N3LzNBJm$=0>WgSx$X$@gB$nhbW4I4nEF*RZ4OvZ&B4(7_GS=?qD zA>e677%XY6Egv7OGC?rNWeQ`SH$y?Sovpqjzp~+`8xdI|OJ;QJWkG?_7?~Ft720SBxd6jJ zJioPku|+L&mjk(hfoyb)xabn5Pn`Y&S4(p)zdXkFpBVYeNPFBsq{w6`DJiXQ6(iG` zXfFoT)p^E{QCuN5E+cGMhO=s8_-)?Hid^WJ*r;`R4UxvYg1n(oQBgyOR@7INdf<`LiRIsZ%$y3XBt}74PHTViJvlS;Sc`mKVe$_woFQTZFI;TbyxF z$$P5=Zfk6=vlXL@sZL$}1=+KrYLQ zg2z;p?O&KxQ8Bc>v^1=0L31vS1sS-|@nD>d*u<<__2w!X;}-||KmVL3vhMTQ&KYjG zkYHRbMg${@hFMH3(Cp(}x^#+O5p6G&UAasJm)b47Os-{(KEs1s;?k&7oQ1plfVxhfEf{DwF5v_9pnA^8U-A=p>EVpMx6+}fvMj7*rM5bV9R0U|T z!z_VjK~)$mCTyuAmq(lnWppt1qx1SNV=H6Wx-qt7>7s2=nYheunTrUfb7#jMMxuha zd>P3sHk!bI42tG1xU*u#GZGiuFbsj2@Z^&dhzkkEp{GP1Be}p_76&pg;4*!pJ(>gY zw8gJv!u}_N$&!|4HCWT~beo0`7fs&|#+l1-M&|bI5yWNFrufJLC;1CwW@ zBaSP|Dk}1aW>K?GdU59Bl*f?B!io>U_ls?%GW4>OHc-D(hQtBK ze*nXgi$!ffnVgoUkSk`+Bwx2#%cv0}T=jy>ZF>w}4qq|uUmk_)D2hD5DMc!)?||m= zB*371aTy4w3EiIvLgv^G7OsQ|d2~$wY&3yNw0@f3`{H{B&4MPX{jCVIGFT ztXcE$!=x9M%T~m~X6UGjE}d4axa6ppC*5#iU~*|ZhPw-DG6@SE!^()Hj7<3r`KqOm zr74vTof4Q{7#NpK_N_m#ybGyt!BA0lEH;{S z(uq>pCFtcc3C5Mngb5ND&ZRb&4fwM>MqEfSF#fY=6}n(5tx|q##&RDX=_<9!q&J&P zk-;NJPIP?!?^cZ8-t^1u;7If>#ym456S^N<>I>Et6jZER*P*_m>g2+O3-gi17PxY; zW8qxLVD{A1>|wIuJwGKf8Wm%mzoYTHd;In_*mHKZu?eOv35KV!cS$a7nZ=+aLv*=B zi7fhZbo7wemmTt$i(aPk&a!sn)m#F^>?JoBWiovKEbXmi1sB?J<(_uw{q-ShvP4Ek z8X_B-WFv2k{KYx!Tf_ZgYma^*!EAc$7p4{}k=GSO_07tPDl08rSBe}4xs)!*U$`)9 zK|V5>b6e?%MdA{+rzT;=+vIt-(kyQBUFKoHp(44%4=y zzX+ytXJBc2nFTq2mrEbN@-eFc3RgTMElhUiGIgqy$a3juKB*Y1t%X!jkey8!|LUs= zzO4=l|F-ZDcgVbh?%>9aku3*D#mG$jWpHpLZMKM(k_xf^UY^`4*662I83``%eG}lM0~Kldqj7(U(dEfaF=Vn$YFTr0xSUY zV2cK0f8-uFsaEdX+1BX$b1G}rbSBg9d~7o!nnxFAFe|RJMD}Om^59`}R@AU6YtVfIlPt8t#r~h$Dv!YpR2?_)E+4%lxI|?^E5rrP zQqcimN-Iz%F9_?l*8vNUKYjY?r;c0>?b&|x==KJ-_5wW&xjq}Yl(^UpX3tEBrZ_Q!|%Q;<}r?C1#9}z`>&w5zQUQy1eV8a4#VvQrP$T0d@c;WU%g?2u3ABQ zvD|0l|8={l-jOv$s@0JV4GnBgbk=g(+7b;+)==cJin1(Zu?|p6enmya0tdNBRM;Xi zC%qghTC%;N!9ex`FmRY_A{U6}8kA#8WIws@VC?_H&71S~u^z@@XzX3IFKgCZrtW3) z=3@*B8-rPKc?EjR6_>|yE`Q^BjB}Yr71^|D=wMKYv8EDi7!(rBh7Hx#Bp6?-!SX9M z)BH`*`uPWvWmXkoL2XTgYP9+8{;0eHkjWzB&jJo|e*(kW%B7siXO37tb+8xYv7+n- zi$ST}vxm=(4Ln4ttoIeN{8e<%W-uSP?O=F#@?kPwlG(U)ewYm?KP*m=t)N0VRul_E zM2Sp1Qp~Y^0h_7Q4sMi2k!b)%!~!rn;-X*%lm5q@>_kGvHpTY{YBHG3s>p^k+PD}@ zX6^4A6_ppYdv{c5XjVmiR#^qDPg;;q>y*OwvTE!bhxqhUN4YRA{n5H)(`K&OOR{nQ z)U|8Z=wM_pS#Spoml~ z4_;1GD1NNpJrovGQC3g&SXC8+!Ukd7U~!NOxct!nP!YHovX|6kXBQQn0+@kpG-g$= z-dC!nP(vpy%KtYCF#<+w=MbYej zeVG^BpILu?7J8Seux|f2-kgdnm#uri#bBUSWP3OlR+3%Yxw98bWLG|?lI%ewvbPqs zwwb7KlR5vxZJiZEv4$J}$7uFx)G|7jJ3lIAw|XHitb?(0Vderb3M-1`1Y|Ll+VF>Q zu?h7KQkYt;RG~c7Dbj+|6f`=WK1ob%gZmn3@X%EB9mRe&V~T4uXyPt&gE~m zK}(RKgDS_2;d5iPxr=l80Lx>H^p<=sIkrm|ULzBj%czw9EUo8%-IWVl6vGBAS3dtdaY3XuHWC=TK;FU`W7;sygS4?g%H>81C-kjR+vxB4{DG)(8t?>_9xWsNj+iRjXaG2uhZ zsFeRKfpO)6N_op^irU(h&$D&Ou$WZwye{CP{A0PyZ?dRSF|l<3{A@Jr{9>>c zQk!V&-6d?*<+k^?feV3QSRT9r=jU8tFs*V4LL%b^^G{JQaF%yrF*YtpWmF#n$ck7# z6f^eEPdam%CUO}=N4=65jpYtK*R?k&2-n2(6dCM2!mLxI(c56QLf{PS-xBXvp+7Bb{}JF#z`q_nX`1e z2P`a$&7L1LTWN|+JG#Ar)?M;tG1T>6V{ja~T)P)8Vh8iE#AS^b5|Zn%77Kk`LPV!#p z%*BRdNMzK!;F791YqeSoaNefhy|a`xHK$DfaMW}rGNje5iE%@zeuYrN;`VAA-hP;4&~oN zla}0Hs2-yZh9$Dr=8`GcSihZ%BN%qHB|l`G?1cu%E)Vfras6&w#^jRiKfQ7gT1%Q5 z<2j72>$4hCxi-nv_R}y+Akhbp9mD zVqY*WRrzbXx#dE`G3@XchNXsb7(djAoqkNYJT0=QxX$O)DO%;n)?ctZ#<-x75e=r# zTZ>v5S@*a(ZdaQwu3V@}Uc)Amqp7iE?TgsV5Eqv`#=y|k6Hk!w=N>o^c=~ks>hRNN z0@+f2TGR*USEZ`tzdsj`CY3xA&Z4A~Bx^MqO`uLe-e0h;;3Hh}nCsJMB`)ha5ENdG z(Z-hU<>H{08kWOID;^#mH#}txk!fjaO)=sWg4XwmttDiGj{n;$_ip?iF#ay+EZ=qD z^6tA-Dnl*DR`8ae8cGI*bCLA&y2!;*FwgINVEHZE+=^6t~#;L^sCOIt1% z=q2`8G%J*OqfZS#TYM4SoQnkJi7{h(@C~-e)nqWg zm&ee&q)KHm$oUDI&6=D54d|RP1BzOoYIB#;(hh9!r5P0`EbZVdEQif^ zeBCEEK`(})B4n~tr${p2efQledr&SDx%44}@oaud7l*jHYo99@Zu_*NUuyYRaIvt( zN-KClCUTkV!sTFYIqaUeoK7OuB!P?`6`4+@GNoF54QlJ}*jc8e!|x3$xk;^rVC3X4 z0fD$S8$%R%N#RMb7vi#;O}l_gDY2>Q(9Mmt46s|vIod?2riM9-?P$qleuAK)$h1gx zQE^c*gYw;X-$Eo;Xo&2}x5#D01z;Y!)~9X;Sg5XtheK!S{D8$kKf+7K2G!n3173 z>CJk2hic4dT@=PM;pFsWE{Ju^U+5%zNMqgHad8mKwq?s|wu@z$^Fge48o;HYsHm=3 z@= z6d2C@h2(-bgA1h*bCSkjXu9*eB{G?>!5~*_3+07{8G3C7#G(%j)B}q-ASp@1&R|K4 z`dBHp4$VH}LRgMB!@{W$mhVX{TjS&5_fA0Lv*N^X<2s3*tfh z(B(aH>HMy1p}b}dd>@5!^oq-TmC_0(7{4Lc$1;O)l#3&mEyQKe>C>y3TEfo+pgct? zQ>DtyCauQwJ9d^bUzI7dE+eC`JR?J^&Cu#8m6`QAT>xG$@ELZR(RGdiwXm}!G?R-R z%gK}d#T1szw}R*S$b(*L$;oNjBAVkbK0-BFaZ#UbeNG)FYvEk3u!0Poh7dv*04%`1Y8gf}7MrMQM7XmFqH%-gL+ zv7B7E5IGEfFBZoV81be_Td6i!RB9UTM{7yvbvewzuwec|iR^93U|L#>c!TL>vwJSF zD`-!WODiam`O#qVkn1b1J8*H;3**9vlm{)Y4Gav>^KqC!b7QKaI-{g6C&Of}wERAm zvWEwprLrz3Gbb}MsV*r;YeJc<*99w*k|1JDfIdKz6wWdk6HPcPk~x;+#~rD3a}*0Z z{qEe^v&BDQ=W>(nU@we%;zQS)s^a?*a7Z)%L%M-*U{4}TpvT5YNGjNxHz{XU0P6zO1n7)vHLpkD~!3 zy1d-aFP1bDEpcI+^4sXS+`Gc%Fse;0%C5N=vg zmCLpCYCsM{M;V}(qYA^z#GHo;QKK=hTUUot*=YQc&SYIrRMsAE7LH=EVM%uQJN8IU zP7Z3QG^s63X${IEZv3Yxk#R75@x{NSq00|uJFj(jj%HlM<169%l*XdFbh&hiRw~gR zG3AA1F;tInE`M>$<%u4omJKTx2i8(wiE8W&wJ<2h;Jq0+85+~?GG__7SbVJ{nWQ9b zfF4v#=<@R*7E~euW;3ZJDGBK-??-U?;)@RUec$hnC4RPJB_(k|Eyi|6Y${T#Ea=jT zeSBCBJH-I36!xhY~>pGY!f#D#wcJ>Q32$64|$o6&V=}AG&Or%Q#mq{tsWa zuZE%C1=U!2HJ#!DV9Lvflt1$fomUK89M!_Wyv8f#+{GIPQ5HLWCSZu3hCTFwjXH2K zY2mS{a8;_z7)C8*6(Xw zuq>6ZER2tjm--e-GRZb56m#cpZ%DHk)Jiq6De9B`ejm|boVnNzw`h@z$GBb2T>Sn0 zFJE?8r9{okkRj#eNSgpd2fto=h74wcy&QW(nUH-#k7&>7D2ePYI`YRP7o4Uu(!qLWqqny=%U$c}xIJDVcL0?9FX_q&jl&_XPI8gW zw~IYFXf}fqAwppbFe21NYPC{nF~DN%iR_w4M&$CZhsa>ut%kMjZU8PHZ+77FF7zVh zu*;+shUG*~d9|-qRqj_`!-L|$s6;vg69`W%Ww`eIZNB$#aCqEeFc`>=ZK)L}a4;+mAoBrY%*H>3PEE;Ntq z#D(`R7cSV{WytlUlALO*wYo4PqpS7g`YSPo)iG* zmp7(btiJM$q&kg8YqhPezkggRwKQ*xF2$_T(1ESA9O;bN4584eu4XABjq3{P>pOf| z=H->&JeE3zT`uu#g+;PxDt4)GENqo>LlIMqx=5V0{Ei!p4b10~@wdOr(4~imRF2u| zWPd4#F}+;Ae&WRS%#w^D)zzwUDyN3zh+HU<{lx{0jSF8rj%o~g2`J3TK^3HLG@zd_ znG1i9j$dYlwU|^ad1~PAY>}9r%0pUXf&0c;`_W5&@uQa)Kf~)ia+wQ%2}1f}Qi+Jz z?nH&_WjmQZ4Uhp1i$13gf5(v!pTiGwE)TuEV_u7kV(@~MY+st-C*Sw?zhDD%{rZW_ z6Gw7VtIG??v~zM!IB|L7jpl+u9t%WQSzD{u2kL1*C7Q!Uza3yM)T`x4XKAwgJvWx_ ztFl@R7E7>Ip_9vvIz?WA87&L?mI5{&Mw`F>_{EoWmTD* zro|R#0H(hFM;jBbtSoogEZ@e3*~|8bi1_#jQcAo76%h+9ykuOCHkeqIOj!6}zg;lg z`?w0fCK*vpTsZiR>ve zlZIj}H}5Z(AZw-BELWMd8dPKfv;u}!HI$7<4d>SiZd?84Pi8w+S1`1z4Qz<=uxb(>X0!5<5Ze zasti1uZ5n|jGXY2q>{y#o^>q9+;E{pmK#{BKTVzW8GR!iXp$<&50@lmW|m~arSA96 zN<4z{Q$TmuWK9(c@)n3^a1NIe;y^FbABWd9W|MKxKWXl*!zK;Y!)t zZSUUItHbw(k!HYUE5}mff~DO+W-xQ-9#ujsYD1I7mzKmbk8u{vzib9Ght5bYNXd-% zE=Xbwi%S}N_wupW3;zDZgr%@@sKvKDBMAjBP1lDfZ6Geq_2S9}z8|=lZ=l$Sf=u2h z&!BlRJX54R>rFnybllHA^*VatT_bu3y%xDWDI8cbnZx+ru8y!ob5KY zn_*cWDoG}*SuiSDcw4ZSp{=VUE=&5?kYc3hzf7XCb0@e+iA-s+ptm%rilng^H-e#a zA@682hn|OI2??Muu@IIn$2b>T8iQ8E#>LO?`jEo%PS#F^kk0BOM<@@KAdR`>@|p{m z+(C;s=;8Q{G@eX-gI-R}eo1CVPG)9KhGEWqYxNnIv`THIL8VF3YBO>)0cNc^urbvd zY&)Vdier(&Ef_k(2wj0o*VRmRrEr-3{cHM5U~E*_`P{i+h|AGPmAbA{tt`r9Ex!-V zS~^wAQX<>YX5O5eH_@niNKBxWdAlfyF)R*xS@W=QXmZT=cZ;|?O=dN^eUxJX839_o zNuJ8K?$_msd-Fxz3l@1DMKy@!3jr2n%12uP;?4?jp)c7F27C(c}ynj>{eWo4aD zW^vtj-*sg}WDaBfc7tg@Z{EE0^z=FN5p!5Dt+Z*=o=l%?-=-IT|LfOLk;Ss}Sb$2W zUDlkgKHzf1hxC%O!IjHj|N7TAT(FQ}0#A1h4-8BaSN4U6=Va*RD!EdR?o_MQXzugY zeND8bg&HmoCUTWd;j7T0@i##@1px(87L%yN-3?6Eg1u~w;%XlspYOll#tUMOglXj* zo#5>gCK%3zIv7n|k+KLsK+jv(uF^C=NrrVY|B@0}`!;RnIRv1PR)A&4G0p{G7@0Ni z!tuccSF!9QiB{iTsYh04#+01MVe45M&+dBmlE`JM#D#^c!GwpO2|Pn<`dPhDl7t*j zTlbjtbQH|}9qOm)7dr5m4uD3a>Qs$#tqC?4U^eFk6y*H~9R2KMz$Gp&u0_R^*42gk z)FFHpe7|kmHrjSXytF&VsfdD+jDPk~wLzKV(-kk}5^+qK2FAYomXBXvd&q7u?TJDg z0GTHWg;4<(e!>@iKqb(uSwp4Rb=FfxcLF_MOSRvT%)&yT&&dE8lFOw_yn%sW-mr7w zXzX0{je%#9kd{lBW+;DYXoy#iO2yY;xX&Xo9#)e{WiS|2Y*0CXg_#9qGOzXh9I&jX zW5h$eTWaICaU9)u@^?Ph7wBtdz$f7&i0r*S|WE zu^E5u5OF;WpcH1(Xn|InlcD8Lm(nV`uZxsDtd$y*QkANv@#GS!$cRgTIiNsp%*zXP z+bL_xM3S#oO==Q0q2VF!<;X)`k_GfDs^ zvzV<{q6B6eP(JLC$oll5b5rlwA>wJz&QZNX!s5W?@{uEq%Ze3#R3dk>R?Gc{#GHWb zA3;jWi6$;zf6W`1snZC|UtPewCW4_c7``56NMT_P)nPO`R#>PqP=iaakR%DN?_)=X-W$v2%QD z7`}VYMGi)kO9V~-Lob@T%1R{vy5g8(P@#9m!$mI;OdpUD(b(eHvF2bdLoNhnMXVp9 zu-sxvl^15P(Mx2cAsaXr$zZ0@Iv5u+f8}7du;nn6!7_3Ja!N88lX7iFhMFCYV!FS^ z@8PRd8mzunR2Xd48k+&q1mv+Y8P%9{Qe+1#ad9-xVnf14kP#j|Lv9Ke=*Y|V7WuXlWyIE-CQczH!j*M(*SiYUO zI6!ff3z_~_T1`&Ug9cL%jIgdTvc6NZMAXX79){)&5dMen;3CLPzFs9-iztLbY0>G0RP~0AoErQ*}Q# zd8}Cs9r_NK96d^hfrTx7#6c{Cj z`|X2w$tX`nQbg2`wI`+=s7<2wC7edZU@?@>a&ihyN@n{?`F%E+CbOB(d*|ewIFd=VhqjIm zMnW#j+uyHWKYJ>RyBnCk6+_=y9v^>nxw6v7C+r{p_@)^aP9bS@@mc*HYb$NRz!VpYTv!@&v=#|Vn>HMbjm%!~y{^K7`yC{MR+ugE1oF#~# zD4Z{my%DTxvKAHBeP^S>1%t-lpT?Jw$waw0$)vrLURV&6&BtOd_^t30UH?QTB{I}x z8HFlqx=iM4Nxyk>+^esSf0msQ!3hi}^8{=8B`!U-rElN9%j44;)S60-MpL@?%?BL! zw){lebCkrAES^t;9dvo4$)vKVltp#laV~bzKrVfXI2XHI9EeE$a*ryF&RflM>uXqvmy^ip_TPKMm-tGeHt z!pnTA`YViyVXHlIa!??l@lT>b(}H{EvVVCRoTZNBQdy}f4f}`VMzG?haJ0#lIGw}} zx}cl%%C4(@iW)3RWzi`IDBpdTSxj6=FxT9rF}GY|uV0`8_Ba?cmzgm!B|e!Z)voj= zi&ou4sgunUq}U|mLdLEdiY*`!9-z}LZq%ay=(?H?P^LtNenMrnDAo5jk$I-bl-dlo zLNtR?Xa-IEXp%G;nRS|Vp|d`;letSG+uye#l8|Uv)DalRePC(#F*=Mt*?v49kK}X% zs&02N2 zIyIGTYpF^#DA}P=IT}-*_bj`^#NCxkB$8NVk+zbJC)d@5{lh^l4jsO81O+Vum%8F2 z<d5RfV~UG_<-7xzo_FISN+z0;7%U|whUc;qM~XU``X$- z5>1MOWJEMm9DwKe#X~?uqb#RyKF(asfnWObn&5U(5+w{JMH|i838^n6i*e z+VM$5S8E63jttOD$vsVSfm#{^8_(*Da(N(4hUg5bay(ONZKd*l8Vq^xO<%3HkX92` zW@t2-8QMzbG`L@Ik6?zDu0smT)D&rbhzcyGcq!kgPuiT9u%t+fCK#8L8$$Bz*>fA} z>WVD$EVQ^!dEP>6mDT6ZpJ%JdGkw1EfnFT2xPwAm=nTjgPGn}DpbkF4Sz&6!%Yuj_g*xD4g8=j~*~a6kht;rb1bO2C;jjdVhBd7hkh9#@(Qkxeo+_j%}& zUOg5n$+$O^bD5}_r=3FNav=Bg>1tr1L*@0UAd;771RT8{&s9lXNoHZX zhj=_(^8Eqi;nAd|o#5)&3`35tjb_Ya;lemdzqLh>pPMUXyJA4nJ55JOz4DW*gMSXr+8IGh=)*FZiG0uHRw~ zYeQI~PtZ&>E4X@h2EEr5CMImYF{fyLF;seybUeV|Tm zG%6JG0F8!bFEev8Ox6^}`#!2B#n(jD6q$rpqn2x^TwRTSZFN#!dQpd3rA&=G76|{smX zZ!gB&$Ymc=SaeKDrk`3(n{oU4`tI80YqeIF(*o~8xmi=`Hi?Pl6X(DGJCineodNH#~3rSI=JU<}m^cDymA>eweL>$`Ze-W!xMJyq!tH!{c_Bee zwfLs{&Y9zDpwk*bIljA^e62L=B2Fu|lxK*HZ2b7?)1AOfnl$OTrzbtVIFMDwauQ9s z-Xw2S=}?#PlfUYMP3SarBS+pC$;jL%Fd!qd$}2PB5?Yf%uGOjwOW1(W>Tr!-*Whr{ z1V=9WhxT3G5UDhqP3AfujkYo~6M*VUC=L1eWHZAT$38rqUs5Q=7BMU}+3X}epmH8% zSRtLw3>BG*>Sd%vbtR}AIf4#{is$oOALq|^Vnkw5vBmhQ%gZT)`C6OiG|jQ9wX};` zVT@L3@oh@?wWhb0`gzIzszl~_24(c5vy&!04Y`>0M5SDwnwlyvFErss-mQNXjJ#djQMPi0#{JfJLq3p&}R=nRRq11AZFL zUt%h%BLNfVn3&?i^PPP6b;^jzjA6kZoKGS8Zj+^{$=9H=T2nLlk|%~T!)%q^+fgbK zn6qc4QzEktAAO5lrIM=}<*C(;v65FYTO)ZD(1Clfv^BGNmA~-lQ=9=Gc}}H=vgskPzJ0!!WJua zMfXtBkQ~(Pyrt}*ktW2vCVql3CBy+BbOsN|1wEk;P4*vwx%nKaRKvKmdenD#ER|{) z$S##KBL=;dPo|$A$}W6gp_0Z}((wTB^Es>#J3`k!KH6U~-kXv#QZ^kfGyUleD_5RX zoK-Z^$#??wG%bmT*QkP8v>8b>oEyHHZF{MaYmzhtd9=;s|8MX5ecLvou;_^l1O&;F zMH@jB=+KPRQgrL8B0&Cy?t*E8TbJX)Dd58Ch8WP6sXzuU29D^&Zp39E+ATAI0wlu0 zOTX_(O0w$~av}vC^bE^3ZR;NIz4yHz_jvd8O?};UmthyqPt%8SVXat7k^pQO!&-E- zkvY5Ir4YYe@r-01`}!^D<;$0EGd;EO6{e*|i2^@j%CwDmA<0At1bIjYC6+ec`EM9*re7$u?UTAs1Z-9(RplYZtKY zI`9LplC_%8PSK2EF^|zDlsyu^%VZ-|8`#i%H>)b|<6Evh09Af4m6qJ)gA1iet92wj zil$-Prtk18z{xaY6DLZ zBPOdWp&2)WH9pM-&r=SnNtNZ~2q}5wf)eZzg&B0Afvo!hq*<8i0uPdbV_`$7GV#+W z7leO_W(1}q+!WT8)$9*WZ=J^$HF*huSR61 zv?8by%sWdWQUo#3$;F(dDOA!R_h{gB=vW&#i?;6-!5imM^{(xLamb2mWNQJ92 z4`D3@Nx4)~GnvHu<(Ui`j0YwdvMVQ8+@o~q2OF3bH6)h4PYbh6#1LlB&-0GBVMoDDs za_)`m7w{S>VqjByDiI6WrU{<`5LDddb%fNSRq4V7&RWJcZpR>Xf0|a76GeoFOsD#0 z4KRaT)^KYHCpn>y7rx^}hJ}(3`l%S-q<1BgM=T21@F@D7U*#-@Nf-*!mQg6TkM+TH zhE^BRQkBT!RD0B!wZB&WMp7g+7q*SJ&A^*2_&uzpEVugN{B$C@@OG?ur_4~UrU*Wi zrItccCh(`MTNxfoBbU51Wn7nHNj0F!uT(eR-;sBJ^JE(2trbSl?03rX(?!hQXoKWz zy95qF6Cwd?T8?*G+F2yL`}V?Ln33t-*s@tr94deMt!sIqo&uD4o-gW3FG@rkjmQSM+XlT-4U6I3ms%SWp%U1L3+k#3k#8Y; zJlbT;JJzBKSs?cJtGX5ePm}PNyy}I^SW^^601SIr*9GkP)EXcO;=nvQ^->utW?dgP z&=qbbfQ%*rq7$+po(~L=%fSgD7|63)##Iv@lvlCOvJX2$n9|U^&corQYn;oz$3@3! zSsMnmPK%_i@0zBiRdi0rUpn2qUmcjvKZ;f%2MKq)tp?_Bxpn3}KDsN8Kkx=Vy35P1 zZJcgk?c`!HxC^_UhYph~B_euv8yK4p3d1OPrF?zomLZCz6cwZj7o1SgwV7A>kew-g``*~7{+~IOIjXe3sJ(eeVjM_Bu*B=mP z9E-hS@ZMPUVBrp7hN~R3+|`!*Bhe(>JwuvetJ!uZ`Q6`r?L!N98(ZGHXKU~E#2joV z;C32u(v!)ECmyGNIdqmD{KJ3!=dXTXj<1ZK1)9m9p#PwKRR@#Go9&7XFAiF&UB_T zo#{+RqrU;0ku+qO4FCWG0001w4FCWE0002;Jpcdz0001ZoXwkGh$KfDz^kg~&+hHr zthco_H%rFbW~z5Gn{}_#*`2OkXKE*X$|?94!Ivl@=t~0nl7|Z<81NoW*bowo4@wL^ z`EZg14MBqeiHee76d$5s9un{mXuyC0BLsp0XL@F5Z)b9;ndzQCHC?~@zOTOe z>g(={pL$CoT@Elp9oRnxuY2Hy(SrW|**-!mOXhVEnb(&HLGQf%Hu~pZ|At74ucD8A^egBm zhll8yD_78e-+2c;^W015UvIpDo`3XF^qJll(B2ong?{tOpV3429inRwJc!LL2X-H)TY?|KmZ>DMo! zYd`!IdiwtR(L-PVHo7zXG&=bFRdm;#SJ2;IeHA_R=y%ZXpL-sC{EkEP!ppCtd#*f* ze(}T;=#>|KiT?A}Tj;4LjQs<2W=*v33qP@wj*|{Mw#|<1j&0jk$F^? z@7{NxbN9L5e#Tf;D>Z6Xtuc~k{^zgOtV(5$an>v5YtO;h@xfL{C<~8k@aOF)-t^Mt z8;RTY4xTUQXA$1a{6XPC0;)@|(Mr3zR;QusL89Ru-1#I;)x7^STyNyB03GS|6NIb; z(-eNOz|brA&fnBGT)i#dfc1S#C??8v4o6bx7p4}^He@*>7$%Fy|PL|mXG65ZSoSuu1E@Un-@jZ+zn?HnytdL2~fsUPqxC^jb zfY@}$0h{FMmTnMK<*Rfz$1lbcKIF9pb+dEvu6RfC5V`XBg8V@JlNnuxo*fYxTy`{M z5;~%DbM;8~j8PtM4{C-9U{3hiUST^8I^pdeE}33ghu-cVu2c^)bX-dbvndwpj>6Tjr89&jnyZTRy+2CsY--{{CVV;QFjd@I1u9`;-Js(kZw3VA2e`@5F~ zFeW`tDxS~5~$Y#cLLCo<3vK}Zr;Nk5`EvPbJ1`BM6a z!iBI#Bi7nQs+&St!vnH-o7`m*tJNmY+*Q#7c!g3~{%H2b_hN*$wl?OE zT%FIh=g9#W^Q&T}=PcVI3O}e1oc0zPRd}TuZBaTi0lW~`n+2Lf9;)j$K0h z`v%Xiwaw!|BHn-$UZRfg0VE5n-_fvG!bLqVh>y9m2b5O*!HC;V&nN!LvSSc#`!gd}Qevk+EEiz=ln;}ZhwxsFyml?{{!qw;=n z=Sb$|_f6($@Jzh>1+t(D*uOPpZyLE-h%)o3Pb<>ZOOrvUGZfx#eWo=M`mvyKxCU&; z%-FG9UUs0T0=(MlDZ=!?P;6#GelEZqfn>%K!42^5ZPPQ5AjRAeIS1Psr#`&W-Wh($pbo?l7VRah zra75%y-9met{NHZYFowPr&l$eG_;CO3C+{v;%%SEvQ~CIPE>NLN=3XnXX9#pYv@6} z5=iW4Z?62Jo@2@CmPtjWQ!lxm)Ik=<`Z5u$-alb(!vGZ>Clnv zV6jFS128x>V|Wb?VHU;x6X7}WRj%i@hNusA{lv&ZxH@O$NyLPXVHqp`X)sG18k(8s-&iYam%6LlYFhr(t2-&WFQ`o$egtsNj zV+0`z_UsY=^<}V0j7q;U0ki9#H;LVQtV-8nw7LHo(|T7MBI`0sE6c*|719qb7Z>nrvLR!gaX^x1+=$6oW-nPK zoG7j!WBU=hK`bf>EURBIqzcJ29qsv8jwCglsYlFA?y#y3Deg9= z_W7ikQ6enGrSLbDzFx9CiUw=|GG=MHU9Aqi=}8I!P+V|E^}w(4c85p6P&^5lqnTod zy^_&zKErM)kZt^}p3d$wQwS41GJOUsBf&wI3bx<2B-emspx;@#R{DMq6jItk@|_HS!DwY)!bnSZ^nwwKK;-MS*3`teKp)fe=v#)?F4ucBt(N#{-#t=akj>b)m`xZ&Y z;Ju~x3(U|98}%)I1&& zkpPz}kY?)HLT5oSQx&K0&L7yOoD#uZmk?JXlE`HFuwdF^*h>%BA1;><QdGENXp74$Dy_ur5y?@$qk_c7n_WBr*&HgeoLvzv4dtAhh`q+>(RFatPmm77%(RY z%+6umRW!VxGov3d7If#0=BcToAqTKYA3$DgBTX&(t4qS8qDev*R8Uoj)uHH?ZWX30 zTCn%d6DRT+egcl-jVFVN6OtRRF~RNnBx8mu8ssP_xxb7h+3qwb(sCZ{>8|6&N^N2e zWAvB}CB>>G<~SIiwpkQ@4%@K&WLz1Qh&MVwHR7H*NNxp1+suRVPtT5xF$&1DuPMCO z=mhl_@3Y|w8KLlK)SaVK=uY+oUN92RZmzb_ur`jX!5I6cOh_9RTKqv$d16>{>=MI{ z2QyW9X3H*7X=A2#*{w%VVyh6xM`X`GnhYtpynKimD1IQgC%BVNwcaW%>6aZYeT`8l zD7{Q&v&>bPz@?x}Oe`!-p=Ph;Bs`%}&m6Vl94waQi^|1%Y3C=t$Ahf0_Iv{Y*gd6U2_u!lJBa%KpDzDs>7gX_xt@Tvar!niia#8X!Jn8tWNkJ zW|cc?l8?D?_<$7liIRE?KnWUi%D34${0It7_QO9+UZuxp5K$O};Hd+1OlK`RODWq$ z_>Ime)T2%u1?^R%@p@2V3ROMKS<)+wW1}&q&`rlXh`dfS$O;HaXAZ-eEp#D`$B4=()m?|NV&&-!cvihzI;-vv9y)Hsc5W4>s$FmVo!c zhZW@8Xz|VLuD!)R=MH_+)(dEa{LV_!X}}+d*=ZZ*KO#6QuBNgmNu2GG6(+0@FHeyY zo^{i|0G=zo?6WCgvkNrElRd~o2o`$hM*dSL`Yco->iY7{>+Iy5>VazL$o|tKt2Kw~ zTdE4o>*uGp)z=dtMD{z@c{AAG=c)$#`#kyo)@}g6w|{D&Z-DKpYlv4NSs8(=)3)yb z05ss;4euK;5GgRAOxs2uatA;G03e}&|F!$cj{pEr(*ptU0sqg(=Whk}Uz+~upZ@QC z^`HA~h`;w*e=Kz%{?7Z?_V51!)ch~Dn^9srXOVf1Pj{7?OGWkw8CECb>ofEh<7I=5 zLrD&ZYvV<%X_4^fm73D=IM5E_N-2qhyw+Us|!t(Lynr`%`*oyi5F!lVd$ud zO%nDddS#R5O;+Z83e-;N4f0nRkKB%&vc#hvM_wKeo2DT#h>T4IlA89SK#EM;-b?^e zpB{jAlyvO7_c}>HgjuJi<+W!ZG8;H9W{~h zEWnN_&Z<`r!H!8HX~VMB*UQEwnltal^;be~Z}Mi==W4K0h?p0#}v&>&}R8;jZ1M}_Ydh;-0Y zX*6jJQ1_!gj{*rx_u=-J2HYu=eLrUO2c^8a?bUjs{e=NSx?ng4q<#A5$Fsysb~|r0 zyH7yH!YHxnhjJsEMD_qN`RrhAk279N;{B)a==!4GQ9bj9&bM?i{3YU;ng`!1&v?N1 zgSslXO%>)*gIz-6^6PR=owX!MO8I6|4+L!SP57u$CS!>;b$L29Zw~llyL~uF=H*Kq zP0q@-mP8&C@D3ygY4CXJKow?B{yr27);wOYxIyphOSHs;)FjKe7s>BywWuC2$*lMb zahz{iBA65o>#1flOKfrC0-VxX_N}I@#mnbT?`(Q&f!FLpyzeaB=4o$th-xKF<}>pW~n9|NuHoW_RxgW81=|Hc1~--fCEIFGiF8(}=bIoJK*5P^&Yz2ZnnOXm~e6`(c2 zWd&hJKM%dgvH@G|)}mct$LOT5Pd#-ayuJJ056;~@(TdyfVM@ztLVqEI&*)m)yh@EA zf9K*akZ~m@e0<(*#N>uuwT+r|g{Y2koxCaTN6zya3QSwRhIGs&=7X9;1 zwDSy!WGebr++=0+IdxxF@tUVN&R8i7WYaTp00jpnf zL?h!dc<1@mKL~5Ka^EyxX=mZLM!vfoliSEn{F=f>KH^epP?Re_(zc*# z1i#^-wxbjm>(vCaT(l#GdI&G4m>JIu|b7%cWeaj)UHz3buE{{V+bqZg=7V0 zMB@gNy)*>2R2Svwa`ntQyzbD=|#y1WK znvFel8o)jQJFENw~05A;kcf8JjeR1u-^?zsq@E@Q2Uhr27 z048e1|5XcoXubYZ3$7sn08qgHmlpi|-?ZSL{{Lt}I1~U7{pUJ{{@ebK7Fa<4o%gTp zf2Rd_KTd{Mv@Nq(9gawDFK-`%q<^IM9uzU^9d6cMqSMi7ww}24oPj?inYz{6YA&Co zHAFPo(`cN@9b)gUk1qubrCQ;zr;XVSk*(6S4mM?&R-s2awzM-19O7_G*Cs`rm895b zymxA0a~30amfWSJ2u!ZYe6!nP2|b83mIcwz)Umni2GYTXhvM15YT?;<@ttMU>;RPH zK{4XwMP<7v7_YVsEn!?isGD77Rp!Y{_9c9(zI}s#Yp`XE6u~>=#!KTmc)Y{V$F&Hj z1MA1c^(Dc|J~>tOZ&MeX+4jvaS(k%bwwRsr6}MRO?u6|?Wf}}_Ooj%6J~je?w-2G^Zc>n zoAy+eqoJH1%w>oc(P9t3I5sx zt~>SU{D9pQhy029b;LT7h+2Q(`^lv1308+d9)O{sfxQ6a-OJp8ohumI^%&T7 z0_S~J4lyXt5Lkjh6`Pv>G3COQeeu?LAG2~uwPjuw4^g8IJ~meJ;D2Sy{_D8?J$hN7 z1mW|`ri=@te2)u{t=z@wE$l##Y@V$9ZfGvAqcvx9i#gRA#k2z`X|-H;ultONm#(iy zg-8FCO6kad&er$O>lRr%y|&_BZgxG*0m4`cOkg0uZs$cl;0HIRHarfF{N6o2bcpmengC0IQqNlbWL$w zP8lWBuB1!#eKLlxxvdlqGgqKQ82$*t`O%k+YrF{ZomRyJe3VJstu7kJ)s0V`Lvta4 zxA+9^w%)Zc`$8$0H9=?=K42j!CqypTi5~BwzD<53r&(Dkuv1x2-4s^Q>IuW~wLx9f zCIEle4Zc9mL3;3PHcuu+P`@fSiB6OQ?4rmq5H|wOpnPzVtT3e+S%L06{(jY4I_{^5 zjJ2`r3dZcM;a$O=1nDSQK)}I08M-@JQE&VH1|Bf1s7=;39@6XM&KEH)(^uO!*NR>D z;COB1C5l^!AgkS16teWR`PeonXGd+U86CKr~w16C~zcV-$`gQi_ zuc#fBRWvoAhAw|#3O$jXwD{e?r5JcDnz=6gz)vJOy?l<#AAEr#&dy2bRWD);Pj2yi zNujTnBF%1*M`*W)he#qP7cQyYQZJVHeW|BxtdlhF?{^ye2)Gjr^_gX#nSeE>_&Fl< z6Dd$2HLdL%i)r3pyxI>at*~`3Haf&EYOF!G*j$DFXStGMI=2eRnd1%_OkQgffehS; zAKI~1AZ%-@jKG_cy&7D@c19XLGJsv>BWU~BQ#ldvkcx0uCbuog`@MBWZ>kR z>O-_300i?B1mE}TLYAUG0e`)$A;`qwZbx}mH?F~0R#&gVz{cMsDr0c-bgSxDP#%Y9 zy~G}O3);|^N<5dZRNzsZY0TSOH4e|p8pGEM&nh>@ zSJ~F#YV3FO96MVd7ae3TVt*LKMtfBGqctc5hD!lO!Y$Dh>Ng?UDxu6$|EQ z=*^QgmYZ#iMi=0f$}&5Sl2Vyav%_aK@lB_Rn=&5K#qZ&YG8-)?B^@p%i7Bsp8k)7e!LV{C8Qd3G zj%102tx-?;R#u70OWkY2B5YkZaV1Og>~+<8qANK^`1v`~?Z3zyEyRl5ksz~{BTwE{ zORiUkAak+cBpmgdp&;8cNFLjc?0$D169|ImevazU+w(bd(mL?WE4!x_OX6>=l1vc` z0&ciN)PD|eAl(eTHTqIyV|BmZMJ?4osDwQeQ7CUoY13P;6u@FZ`<0^UG!pEV&&8t4 zskE{`rRxB_qpxuL&hzB|fowH4BeS5nJ-!x>r|E#}%^^6o+fvS}c32zhjdvJ7=adSQ z2HtuiEtnNS@ZKJ-k%CymiV0N~T*+TUM0rM*i2})b@~mN34t@jykR%9h3!e-jBAGIJT0sT^X{Pha#?+In@kIzPNRXi6!IKGL)A zoT)yO_YOvzPlT5JuE#;!;7%Y$p9YC}dqLO0f{Zh>lhKWMkVI9jw?ab;d@$nYC#{Nu49=`^USRq)AY2kmeceBgePqO#2|F#db z54K-sPqu45(m3k1XWJ)58LxZgftu8vK%V-5;EBu7PdWMqCd1vRDj{%?!eBIY>zaWT zqErA#TsEz0G7h^5Q_w9h^)Sb?NJO*_3#gqUd^e{ooKscvVXj=$EH8;;JkY>6jxPb{ zK$Xw>s^9x~Bjs1Xe+uAY)I7K-uyZ0`O4%g4od#c~!Cyj53uo(B4A4Q&Zq3y+k;e)T zr;(NKJ#4}bf!T)Hx1!oH33vdThbcz^(tg2f_?Q@C@4Wzf1Krj;1@+$Mtz37yVYdnX z0)cT0KAVX8X-_59gHRF|S;$)XaJC#J(Bc&_ebe44e-~!|UC?hRg0MMh(A{xxQ@EqE zh}JV82m%76tu*wJ7VQuegBS~ofFOpTY%O`UxnxA4wNZB zY-B9WspifSSJl>1jQ1bc3HT4L;sgBkox=b6l>g#8(R5s{izohYRr0@F#b$SV2Q!L1 zCQsbsAq*~w-@Dxp0MxNV{o^37V}p_|M=!-K+mxCWwFA|M8#K-~P_~*Y>~jpEseU#4i`x zQS`29S!`O2h2?g4)SZTOwi{~PYvax8N*cM0X+3Uj(ndAqO%iS+>CR5oa-)aBdjVQT zSknhP^_#?#>=Q$*j8?fiW3=o+$kz0$)~al#ZmQ`=94u?((+@}SSJ`_9da+egUL6Y_-nI(*mE{m605R8wSw6fRYXMtab?4ivC3F&#Rz&4EKH z_N*|Vl1eHV<}zT4vOqv{^n?a3lA2#d62LVX7ox_cSn0exF!Wj=ZpQ8kw5DUsIX0M$ zT4%#2qbJrZgj*fi2t5skcHe!n6^=3-+w8G+f9y~3j$%Hi@>AhpwEE}0#yS-zBMRf) zNV7_!1xnFLISeT6w7spuFB?<_n+Mmb@BXL=+o#f``;v?osJfT0Mzraf8E8rbT~o1o zD}%p&f~sW5>Mpfp-%o!?w?1bSX?XBMzsmD9v*2MLYXPUVa9hykL3n?gG${XI7=)qd zCz>VxI=|a$&$C|2u znTqKwh%a16wBHj0-)yF7H%ewrmG1PXYoZ&TIy=dE-Egcy*S4rrj7Rn--}}+$IM>hp z&AL#M38mzX@%%eGtK(0V!1$fDIJAbSt@X*Lu?wK#0ljKHoBxO-U4iH z!Fe2dSN0KIdZx}SVIGeNKu@Qgw1AblG5{tO991o$H72r8AoXk`2}j+NZnyDLB{(?WgA^4E_#&^LL1stW~CRR;|U!DyBpVyj^cC9xJu;*}#BPv7Bj9 z6e!AW=W}PR$#RtEec%jJn4g0~5W(bcvosHZKU9Aj`sdT$d5|QqV6_v2y*5K)bAFNF z-)D+N_)4Z=eb|@~D*}zG(DzZgx|wxK2fK_OJ1?EbsAY&F2ZIMVsKu*XhFh{TagO~E z1d@@}JwPM^!#>31bLk=wuxUm|**BRxRYA{`+$-Ok&_dvj{eU&VKtQ_M2b#o5#5!6!Ga9))&(*p~z8(f(vW#%L!;1vI-6W;urk0%JR1 zH#`=tGL^DwmlKBM=jUAih+W#rI;gK=o>dle7XzZg>2uOWb^;xI+1d_tzFnLGBENCE zRI9O2^(s@Vw0VkE(}Au?^mPwNtL7P$l?VYjbSVFwN+#f*8A zgMQ2}y;V8(n%t~}{JQoeGNLR&wSA-bAax|1av7e_7B?M>Botu3trzx4xU9+8gW*Jd z3EA0M$P=P}gj!Hn?{qiM{w=b&$YSu@ci$}>{VHP}39cQ6)QR+DB-4*+XGOcl$Gur3 z=9csK4~lZ2;h(N+)SZn^_loFjEgeOi=Gqv~--2&8A~JWu8am20C;ivE-VzGo7Pqw* zX>rw0MG8TDTk*N^d~y7}`D?mir-o)>Z=+ZmaT`Qb7+dQSp)L2Sg5QmKM}o&m`dZ<+ z^}!D|y}fw9H%Y4@Uk!)&_qHBC7uy&8C5+b>n@nK9#{gw1Fr4@A|=&J*K`I8LW^CG)DmT!!t!SPz9IwA>eB$=_)x54l;N zD2IWRlWFR|dgv4mN8T6WMd2K8C2h61YEY$M1|i9+g+aZkjs9JeOa%ok4`1Qxx|T7LE^q#;nFFdnA0v=CwypUs`nR zt|Bat$zC-`<|;oxXqc{tnp$YS9Z992E5ITzgxUWLu@v_Tt?hf*k5n%xJsR_ju7ZVJiAfa@4qc6yTHHVW5G6y^B*2Q!UvKky zFTRv>hXUTqRFi`ih3LVdBB!=2&*rS>QRhx*JDL^_L}-AW!fMQIChaA0y*$-^&SapK zX-tAT$3*;YUEpd;Lt349E~pc;qBeYkAuIa+4C)nm{50-vac}AVUG6b)ng%0iO&NR_ zmhgg;J+zE(9f`ZK$>sS~B=J#6q+58&M&Lp-l5mk>?`oTXd-1L4%OBPa0Rsy?+Ns40 zw^8eYN0wBNKpVId*j$XzgvFf!D16_)v_&TPB_)^I01R0YBR;c$-9G{`}(eiy{v z3|wNDP{~qwf&l4(JXQ)@A9PbY(lvQbY-00p5|)t(Ca|WV#^*{KmdPtze*6Q}s9+iO zyD&Rq5yrd;7~XcMc9wM@fggzG^L*b?1D@&!Vj}4A!WuuPL}@s)XE^9{tMJ&@)3H8k zWg>mEwz=0^BrkR4!j#JkhG3JQ2jc!Rg0S%vVbj#KlZX=wX(tazv*?;y&4rytqjTf5 z1U;{-70_Az0I{vVu+*hnW@6@WVjKy63#>bc->(YgQ}VcC{#ao6QAzz`UbWEB7hbBa;*J#TcP3vG>sCM?L$nv<%uxdcpbwo z?%*vNc9$|C4B(*@tj#ai>YEEN^j!&|sD-eBL0N0{)x?)~Tu`BffXBehpR5`yP7a-n zwg73*$9Ir6^tK-B8p_m^$(S>U<8~2ZIU{6{1EJhJyW)*f*3z&9e(~_$yqi)+v%u5v z*SwBj&Z9vTp$Wnzaw^3Yzq}lU?D7nXS4vq*qfq7cDcCxCzP5fjDq`J{fQJ_G7f+Xx zE5f2;g9+{CKFA%HvTKImIP^HwXlfPjlyWO7f5qmd7C)h4K>LHz-7RW@KTmBS5s7&l z->}D*`fNxVI|q3{}%#g?t`IX5R6`MKCr|CVxEmQArx4NlxbdWW$paZQW; za;iva)KgAA(XED4Q639<$r3Efm@iRg=ZCgm@E%d7C(t2QlN$$Zwd=j_oO&fp)KkaJ zQBX??xKHp-Op3ZsqPCN4tz&qq?IX(fv}f{wEeU(y0ma}9uUU9II5B596!?4#DyIqz zp+#|j6d(+7gYD)uNh&5j4Utdg{*C=Qqg;cu8p4g_K@2J3MBIsVn}Sf5uo2x>i|)jK zN&Md5QA2AZkx3j(JY&F{zpKedRVdK32VpR-7~%qgkcQ!9AeW7lgOq2)TXH@qV8nn$ z|4c$@9%^qy%A)tTKoTACuJDCQ&Rhw(_*bS^KTrKtJjCK!qj{v~Z(}_z4h(p-HFhgQ>fc`?qH~^4@0GS2=K>qtK=ks46 zxc#^O59R>-6Z@NU{bi1EOW=|J${ar*%l?x&Fd+V-#sBnO&OiPCVUGGgH4`KN@EhuH z`#;P93H5j0zqbEx=9p}|U4Ctm>wjsg$`DcSVx?ag;xHUlavYx&x=LSIZ<(l=Y!R?# zGdtY0+pJQNTU{?0u@9s%Z)+e=ERk5OOJcKUbU5Tpb6RICOFyQuCZ)72ER*x@{ zEOgKvqH%0zYhDWDFi$_4;==WB0CryBc1^h(*Cq%pIqBh$m>YrxFs+2ZP3nNKp@xJc zJBp9@-Na(=k9-89F7O+IDfLg#xu-yBNKuGydqRreF*Qg^W@m~Fr4)iRR*KM4GuLnw zs&9`=RZ;j`?#ey8;w#zth%3@Png{W+Ojs)5^Ya8=qtXmmd0B?jc$vqvZpJy0zRl%G4#{qCT;~f z?bK|Ra?mB_x9UDGl4qrpn9k%qxO6)f2A1QqiP>fH0L(<=g!&6U>sao#R%TLjnm_%bm=XiNi z{P;0fp*Dr*|69%m+OUdy#SJ%(jRVzkvbCzYr8;Yj%y9s2P+VAbGt^zndz+LZE_)bayPKX%R&9-Q4W+dOwvuek1O zeJu9wwAO`JPzR0mz_3T(TgJ3y2^$RGXnLXTUqHqmJJarNFHI$Cz!9l zo9Ej0e4$Ls=Nti;nEMq+0>oooG5SE_TYc@OjJZ3i%a~i_p8>!UB%f)BU2+OBZSc0c z$u*Ru{Oc=rd2-MnR+-~pU21O-(a&q+D!|lxI>O}Tp2qVt{rO>cJ+mJl&v@Q%Jk@2g zD7#n}MmdR%BoeHr`tnl0uP~T{@V;qlG*}xSPT3)}=vI}iqKV5`IT~a3Lx%?uElqc0 zlB=>ZtNf@aBmVRfU3j#E-MKk=2nzgM*-bqADimEf*-!L-(Yb*aRbEN|!mBA^X}+Rd3_f`kgi8uD9BX2`w{ev- zqOnAuzabD)!y4sw?Sf(3ESEnRgv+|7u@UV>m{1x34|gjuyqN>7DK7%6TcQ zsu!zl*(>%af#v*G_^v5n+m$iKrKqWkvfXuS>Pk7*GO!iyv2_yeDeBw0=nQ%r^TN8& z$%*Fi?P5E!SZGVGa7PR-Ua|Qm&fzESi`Qe0ddK5>xG^EW*4;Z<(&7sv!E{(L&-4tO z{!Fww`U*wf#PA!Y)ep&R);coW`V-L<0S|~*5Xa>0GUrF}3tRG+i&-bMWalfK_{{D) z#-)uNrT469$;y`jlKV1|StTRG8qFr66tUfXdxlktp8FT#kii4G!xi$J5(gpwq)UgR z8>eoPtO6e}SGh-_sMn%2bE(uezxPUE0{Cx*wz9U-w$s|#@&2NIBj6oir7#Xy23Yy% zklakTrSQf9BInr$_=nkv{wsV_d{7gNK)6{J{$St~gkO5_sR$vU^HAT4_HBLGp}Yby z^pY;TyDkfS`jBI}7fH@ z*aZVI(#Z4T;uD50n!Kl}co)_SzjD4J9Sq(3B}iZ6W?tY6)Q;w|E>~2^DTb3g!$<=b zf<7!e>gM|)8uWl$r;Dm&QO*icbbl7M`~aMZqOG35U07=M&b-j-S~^0%;2vm?oXofq z&1rGd$*J&(WY;o?j7^DfbG>x=FMcj3C+~9*e{1UGj6FYZ?@XbTSK99y5tu=Wm3{7S z0quf`J-<&nAf6_^L>eHzLVAYs5bWevm6pIg{^A1cC;jT`TA^v7*?IQJSuBuf1hdq&da-4}HDq&_8a&)wo$E_&@wabZSY2BSPKwp7f||TtLVRa^Ix0Dym%0{^G$dH?kPM_YAJ0RW3X7Yh2{_J6cBAMNkFe{KJp^}Kd2q0AUcOX#x4 z_rv7iNaA+MD5kM2+atuZh88=0YU)zc)Tm!tn1XvWLTs1jc?+`zM=4t(>`OQ)rBAFG z?b~zYbLp-^J1v6a8$)yhEq&5n)Skw3>#F8SihNT31+}PS0v$XJwO@ z##I`ghZ=cc`%1Z;cc28<9KonTvca{%P8zbbhZsM*#B6md;g5z3523*Yz&$c+i3?Aa zs`pQ(b=?LVg0N)hLqL8w(Y`%!0n^OEYAY1BWRaGJ@j4f`k_JSVwx=hq+tE7EL)`GS zS;8bN<{Q@r3aME{ssy6*OeHL4RUA0xhxQS~eDTPJMJ*as1w^-GJV_2+P?Rq_$I5L) zAG>w1cR%)}{+7;^fOicVhA>WTuQ&KDmCr=r8oh+l!+?7JR_=aJD@tRyG2U!)NZmK}-Nrxg0^TeQ%x*U|i z=~hCYFhZ2#(awT?MmiCl&sAT(_p_K9=rcTCVU^#jy;WW1*R<1ihpdup)(E;-JcSEW zb{8G3KU6Z!AnGq<9dAgQPDJ3d9alP4;J59%=~kGqf{H(X*?KV3V2k`-Fy#SH_-8$? z-L1uvJw`jk5Na^5Kn~Zz=rYi|@YU$cBUV|Npj27MIA3HB7MAd9c_JdhW(oHfomY`@ zR}>q)(xsJ_nzA#N1>qMcCRSGIEqS@9TU@Q8Lk(63rxG-2&XH`?n?zx2MTr#`NJ3pe z9c_t^R!ZL4?u{ZLKcB*=>hZug5Be&hS>Z0#*NAR;z);jz)rbyABesZkSs-fH2Ky}5 z*E-!FA>Kr!HMzD5oZLn3a@Ja$(mdW-yZSa;8$2H|vd-|n5|BR(cyDtZtNJZ1*IV3b z-$C3%uzpwKaJ8)w3jEv+Uga6KS)F9T?CFsPdrv9P7H@nN!~h{q(6K z?2F#jTKjUT>PB6?UbW?5`5dmiVv5YHzW9vjXo&LklXlz6!NVm z5`#0t?hTQ_q)e2Fz%ee<(mQ|aT-Uo&qUmL84+!Jj_>c>`Emtibh*pQt-RS2qOq9$w zs8%J$BrDIHvghW3!lWl8622v&ox;{U9r$YAy+xyacjlFGTWubACLANt`<&c<&|Hxn z-gB3gJ&2dCnhs)I^}+XwFuA(=Kv@p|y)c*mY*lf}lFK)EznJ2glq998tf;(q9<#~O zx^#^syfU}1o~PVqvBslMD*E`;4Z zbct1_x8&6es^h|Dx$~)>M#O%syFn9x1HaRBSL=E$!oGb{|b0 zy;xxWZQ{0Sw19?&d42zo))-Ox-Re|2HKv&P!n~A%Vz;oiF}G^S5_ff3Z=|xgs`QRL zVEKuobu{(Va)EzU86B(8Y%!Ca+H>+$GGr!zbrf z#B+LPdyGq9Dv!};ey+sBDAAKKLS^F7+kSC5?6b{}^d=!!2qXAyb zNie_J6nxn`OCGZ0g+1+hLcc1{X6-*SO$h^n%im{%^NQs?9eQLWOT%!DvT{YoONcqI z@JrcY3+YfZle%^COZ~wzMbz{55}O-tmyTslc)uSoseD&|Z+8I`(02tF;twf4OMuN} z4CzD3bz)?O_GrFkf zT_y9g3RN|MmriM$@{9e?Z>TAyKmnGr6Z&%lxN}e+jIBpqw(1OeSRX$;O?@wEZJMtn zC11f0wa(An!%Kcb^LyHM)duwTG3rVgT~RvfW)EK9E12WxScw{HjUR821N3Ra4B0%T z4ytQ*u-P4P{0)DnsN$fnQc7&89GEkoI`T8eV{v+ePT3ycxjk2CmH4OuZ3|OiCaPU* zcAJlyrP+nMpgnrCC8%gI(OBv_4+R+H?F zHxq;XeYQ1>tl9mu^^SHsr|a)2DJ+4xJ?~nlJInj6@mfBP$}Cqg4OU2d7U8O+WZ!hU zaX-fR9dcC-6W|Mk_7)o`-4-4-ZoEW!&2gL{=dm?uU|^|*amP7DX!LQ7;UeMFphbXS zUci{14So6$Bm#=}8GhUb(Y~1#P!)`zOq3V}Fh42LHsGJy9@5pT*s*=*V)sDmj+TRY zv7ja;P==2Ve7Fq_939oi@aR*Ut4GUZLd0(|L{?1{J-s2YzoJMYrASX~dp9tQTVW^rPKZX3m4yP4(WxeJOwD-GulWFMc~8c&W|1 zsyLJK- zQKJHysp(Y7=+7V#)!mSdz)E}T-3{)3AOW8FQ}<|IJX27W_k9_v;moFHrvnO3&LCSS zrIk5nI9A1u$FY>S-@wx?8R$B`uB^HO4rj z5{?5`s)H0un|_zb*==co&2O!XwqZSWxL&6x+f#}!cSF)#lbeUM{>IHA6Ra&}XE5rb zSylX#d5)y zaoGtvWbR}x-~n5GNbd0J(5dD^-UFG>;!nz6vl34u@j+BUXC<?6JnTpk&fTF)vO>NJL} zQ9rSTEt$e6!#D=wK;+IydS#7K3wf{3RxC^oPo1ezv8<)3z=4Ebz=wCJnbX z2;Dke$+5}i0R--N%M3to{>2n-0t_U3LUbfnyRx?14f(!Qi9Ohex4eO< zs;D2w2JTGN&i9;$j2I|8+{U-bzrFd)cM_Jc_(6s5hy+)N(aiUj+-{XF^8TKM6-mvt zC4wYgyruHoLd;FfNnF9K`23rYw}78or{}%LdNcJ1x%-TW0R&#GR|v&=l8qE$l0=#` zlDX*nUPMVBW2k;$5Xup%2x<^kT^Mo{)7})@p7V-#ukDuz-mC4`5atkG|6Z$YA=?7B zOu8(#9JU2K*(5PMFZmGJZlgF^M>KC(x|=cX&eqrPUb^iyw%z16V1<|;Zpy=67Lt-e zjaVV)=h~AA?BdRf%1@Z@>8QMp>bZU>fy!Er}IJe2UhjjHvC*kK3@4(&|qn zxFft@3PlqWN_WZHmS4&zQ17?2hiw3RsL!Kn+wBfw@X#Z1OrhP@b%Vnr9TnV>V+`xaA*Wk7Inx5N2uBHK8;U!IG;+R(>1 zwckyWe%R;+n9$69duvmVQ5`XLId~#C{C^dFI6)7GGmQkCdIXIGl>e(>VPWVJ0&5>G z=rh&i7CS&$x zw*TZxY)Am$9PmG1v&H^5|GxQ8oeu>7EJFhT&(MFlvKjjCynk)~JFdJf@YFWh@;sEd zOV(;i+tN^WrZ!umr)x1!?{k=$Xh|_mqF#bNNweENv2E6DVi{jtRZnu3Yz$G>z*0Gs z(40WouxqrMz+S_)G#j_HqzMVPk5`En#|E#qkI!H|#JlF`vrY3~{` zs=Pp9=3p$%X>W&UW`HlfkBENBHyls(9fZH$t(To2)f7}=UNB#InJ==u#jY{l2j7Uc)b~ZgkI2`3INr1R zP{VVxt%^f*R~?SK@JOz^Ns?1zAm*+=hJH`yB1V#OFkJTjC=uez#po~inLHfo`8sb- zlt(nuWcA~5F=TQllPlgTg?Q>Ch`C@cC`n#&`i`8Z;Q4i;L{1kuON3RX)LWIKm(Uy{ ze`W25KdE^hhk+C(r^V%E56LQ7#2O*up5cwUio$#bhg+ib=?d}Tp_9{i?82vJqPhkU z``BFEy=%maM9m1l6fVbAvV#`19Y z>N-_Y^uH3R7MaY^!f?z6OZ2sBTxxcyJPM*L^*w4{7TL~fFIV#6wYK*5TXK^~YkeWOdc#7iiSv|ezoZjFa*KejSz zi)^*q6#TT%-V6GOunLaNWx`&>cCJ%%S>_rURRW&X?&2}b>~r{KwrT&?+k2(LclJ~; zR+epRqES9~8xWRS$BnAl??2cJ&mey8huB|V3*3^3M3iS5Ao;>=-Y3!-Js{fFUK4UH=yIRJw zF)plURn3wROUoy4^1gehn|$kYk!xTA(MUaBGV(K@(@r~J0jiD&v=Ym~O0>|omx5gZ zKf=nisB?%|U{#rcTVmDO$P;EU&5t7Gz51W5dv1UGqfv+l|L3~rNP*D6i_m{v_bdy6 z`VNTyHxE4Y-~4Z{|053^`j1X1QvKB@HK(eD|C>Ig|2KKy|M~Ixr}*FXDgEC(aJD~< zTz@Wu|B?rO4EA^4zqbFKKH*W_-*9hguC$m{YMauZC9rd>8YRTumDO908xXYT#|Y;OYNtSwNI6*kGS8bMct(cV zM$}Y`lPZDtWJK*CE0t*$laeqgHP=v^Hm!f+Syle6Il#)jO5T^X#>Cw!*4AfvR5Y*t zE36n;A&WF9T~i%q?>GFPx@>H(fxkGJ#f|L!6YlI`EH5N zEuh^`Gs-Pu*{E=abJ$k8Whx%FqYRi-k6lAHM5&nnjWkxs%Fl*RZVEt5e4mBj@gMF~9nd-NR>uMui%#gq+;z+ZnydsYj zSTU73?btS|69&^bRXt_0`=F$P@!0xu@4zq6fMMNOrDksSujkY93nqs51Kv+usPa;t2f;b`EoQ zQRWp6pJRqDaWkfRyK#f$-~5Blj>}Cl(x2P%5$Ne zRVB{#g7sYhM^ANNh?b?Uv*__LOGiYe^)cnl7AQwR&%tcyAiY9Xu(34MQyprokmF9G!Iy9V+A@(gl<_|z>1l?qV}UW@~Mvn%B?zcD+r`gs7tQk`*0z7(^ZVEu`WiYVvu%M`N8f^bTCa{E#;~^~rWy&C~ zH|rd8uNaUwppK67{O)l)!^q(NN)6_~&P7!m17&11q{ZWpcLx6u;H~QQIucq*aJ2%x z|3xTV*TPe#z%3LXUAS@D_RO;4wDn)!@BH6$C$^DvTx1RR{?FWr5+R{~+}!_@JCQ#I zc?1Ah{F^&r@bCUtmH%TOEX*H&V}SS9&%t*0p#N|A+HRx&>F3`6-N*VrJrm)d{{L|% zLNd&sr};Ne{2xEZ1p9a1zqbEvzP89r=E+PK&Ee%k;EyGe!(esEQ9o=aGu2e9By*=E z*a7IY#?j@R6l$RWDM`^9p#}+hrZwilLRN;h=JkOw%MJ{q9ls;;-~II!6P9Bs5>57W zf@j20U8yO{50;mrtJWT#8tzl6m>V4m91|ydJ$qKhx@Z&>LfR<7?Sh=Nr0-l<=(_m@Fy-@y;Y_1$>k}cRTMf+nL|Z!#H6YN~6Bh ze14TojQOJ5Un%+q%`gWd8a$e5b=_Y|e+IobVO$sVC;KOW0_ru3C z#A-1^tW@Kfj2oXlHp=oo>$cC^DvVbW|HV-I_|oUuP)_gDqffbcR%3cvl^Sf>|8~?R zjGM-TNc9Tn@qo_M5{QhL(0`8`w;!QCWIi#2y#rz%+)~Jq&CSLWO2xYC2-Qtbtl%N9 znE5L~uhGcI$ckc#$}IsRrZ$CXtwMP+xAJ-EQ<>wj$|jVi7SRH+8NiYRXYyX{be^i z9rR)HY^RmC3pPKQ1zJvKUJb+(i2d{8JcbwH^y5#H&IZAwItU7>h% zRodxVPUMJJ5hKlKyHD8e4gO)Bgj?R*T+*XrS6!ODQby;K=U5}8ZC@|FmPT8i+uXni zpKLmdR=rnzpDCS+qd>}UHx!WX&+D9K*l6qZ`XV~L|?|R-?4N)Vfv<@ ze=7Xx^%c#lR`;|OXvJIR-T5wH`=R=F_1^Q8u*zo8AQK*%h053EC_Qtw6$!Cvf$cRt zb4d$7bMxD)w#Z~ln#scvVxOZ(Z}ZQczx}7bJ=@G0$Udd_l9pJ@my&0m7lI=bg8XFMyDZ_9HYN+_6^BrG||qi2N9ip%&J1S5UK zo3S7&cgoBi&Qc#3G}7`>@3H)99n}cRNF1lRLy&{2YaGka2?_Il-9ReU z>6~NNuZboVfhI^Z?R+9KSxe=YUI#j~c5S)ariT>Xfl3d;8(#Y}l#dD2D(^*)uWH^j zx_IG@PtZ^{M+*Id@A{s)E76y9fz6yJ-?m`8F3`M-fWH~`kgz7=Tn8*e==R-*M1e@U zN+;i@v(M@mhU&|(O4z$wBeX54w$-k%Sgefcu9@Z(;-S1KJ92RO7fnT67};SB&QFnV zC>qKjFlSa(*uGSKEclzl;R-OSt4WtvV7J-p7Ij9aWw$MJc9|qdm1<@QQt+8?&n#F> z9VeftwCX*Cf9Hw7rr>nr4CPE^HrdhD-4X5F`v1S*Y8y?*WqabE+{f|1`i+hKkA9n` zu$RQ@@DPHKeABhj0|1=nAwK@t3I40!>=1v)qk;I3@uVW$*^oo=2GRL1gYsG^pVk8V zOjKg!=uukwe-ok@W0BNjQ>2g){IC$CnbCN%r&3zp*=G^5&oURV8`}tMn7exBp1NxH zZofKu;n{j}wFUT~YzOt{1Lo3Pa=6>VXd2;NHe~=lklTPFiUDWAv?|mk99%LkkZBM= zen0@w*YUWj*q^w<1Jnli+Ixc?w#Pf;^G)U%FX?@oks!$9L8R_sdFN91X_$BCt?H7< zG0*yq-G4z{WX@gGhh)~+VwYt{MA(tBS@Pk#1E@owDQ-M zQ$==K^@p!x8l4G-MJ8@Dzj?Pn`~osctb2t+mHJ#D3k{~r0_y;iSfntUxo zbCZD%zxg~BTS4AZHoKW%)t-K=w``$uNX4<2F%WYjjGf--4-7|PIN#e$BEX4y#S_$% zS%1|~Vg;7h?={4;wWNdJNG3-3MB~H`dl5Y$(qbC?gk}DdEhn5frVJ8sl-V=T%`vs> z$kZjtwK5XD!j^FVF>Ph%mF8>~_!EGrdGur zbCrTU<|Kr^N+>VM1{lS+*Rxz(=@Ek)_8wyHN`NF^o^vn^!rU}zdS9$L+wDw^igJ7Jho&G~YB_ae@otwBcW6_T^X+Q|Z#=Vm5U;7#FE& zir>XzTb2F% z><5iqB3+T1pU7-`=>OarZkkY&PcKvsjBh0v3?yrMu^SJn2lL0a{Nk> z>fIk!3i>=@Q{S+%mEjoci=$1I&#`IOfVABOPh2M|wSDBrwE~Vw&et8sI~M93BO=tOSN4 zdRlIY+W5B}&u*(?l^ezTQ(zT`1C^+ZQJL=76}G@;*OKI>{CU^WQEN>t`2(w--+Ir{ z%N?;%;~&oIu@3Ich;X{6WW0W>w+|BlNj0Np6Es@l;Jx=M+58mcRtd{>ppNaBe-3I{ z(c(#;V}#wS&kmB=+@5*)iJ5O(g9ZROXt{PP5bUzLJ3OY&{~|d=n7A? zBbBVQDvBTzrR-g38SjGfkVOUIhi<{RwC)wv#$m{N88~>;eNvr zUbA{XegNz2ZF~3;H#v$N%Q3QdLH+`AKpd2s`08XA)SU6TZ3NMiX4@|=e&Xn?@%=!3 zEB9G-6tJpU&@8Y-|5-{?$Yo-6!z-D#T2%RJh6p z(?*%-qN2PWGVD~gaFXhnyLVeD{na{+&hjPEjd2z4ZkrCYg`v1YI-=;8|^#)WtwoONi^Zy9txW`i3#<#q~~WHQC>}xWb{C3={!_C;s6rC?B31G6b%lbEfp;w#R4`; zZb(ZBxpyt~_>0z~TkfA0gHwZ5!Of>piPR*8uKgejCEgt4rs741*=e~YT$@|oXfCLL z{}ERs>bTe#r)op^lm9(K!p1H!A1x`L^ze{G+z$)`lg<~?pAiHwrU2#jhi5_lj+X-R zcf3T9{}``KPv@Hs0GJOb5W<OCJ0dlmdg{(A<$5*4D3 zr`Aqh_6#$RidARZ<43lMjk(5T+>Q>*(ekz?#Jq)et zcJ2d84+C7xaFg!oErucvfrE>pAreXTD47#(?COM6{oKcsNoP+yZ5)zIT*@3*A9i;Q zMX_OHcTP?!kPen*Tx!;HHO?X8d7tuKmD)Fy0|J;AY(o0f57MSDRLK~2okd6UyCKHj z)Jj^|r_RR{y%{n`A}yC^?pDhE2li8Q+J|BHiSv7AB=kW{-whq{Hp>+>Px6_lFQW%r zoL@*a5WpcCMAuUZXkXW4A1tGF4#BqOtblr)2HL#3>R=VNkmAVOK6ck3Bf?ncJ16a? z+S>ydQxyiD-l!}qU1aXkQY6i`a=-IGvK%x%++`b zX?N*89)yc2G<}w5VWPO5KNV(&bc~u=F)$wRW`sL$w9QG3zqr4ArM+l3c)4t-j1nF8 zev-BuS-#2P6;KogO%|Y9M}F~mg(^3PE}bRLB7APuIe+pP8{ZqHPN!{H9u=N9W|4R1 zy&biO=53)ikthwLG!03Hbi8~H%q-({-SUWdpR?am`#d3-mk;H1Y4;u#iB4Q^ud2H% z-CAV1b_z+S9DHx%R!TXfM#nMJ_qyoNHXKA$?r?eS3VVlbsk*Y7Tw8Q#zcNwK6B!lp zCG0`6805xeRKnn4ZMSMB7ws8R zJ-}?t(q{S?@GpI-Dqu+FxM!W8u#>c0crnRi{o&Mi1!11-Zz)gIuEHAPtP$lcXRFr> zUMP_MbVzkrJFHq=)?xfZ`7m#5eW^ccv&njcq=9<;WbjKnWo*qza_Or<(dvSu=JBwe znNg9nJjM83|DZyoso@TW$D6k6)AQ{zA58-+TIhzxOur zf4=tyMM`KAelLFyj|l++%z#3r{jsz7H(y#8{_i-7|JMJpo`(Dlu-%#PcRg)_aY5sM zJ7ctCmk7OH4uEO7=Wq6gZx{R{Z5bX;Rqx=U3C^9 zd(=xpU+(fD4<1#bWsTQIwWcihq1gKz&`DUm`$xsH$#Df(w)alAK5s__~pK1C?}A#stSfB?|>7A7v$4R7kn3-EOwl z)nFf0c7Z?BZeX;nrSHO=CFmASf7)AUGe|!q8Z|)cNV22`+1i1hm38) z8`O(ECoKtSK$TlNluX%+Df2Uo2it(WAKfMLorclnCK{Hn%Nw^*;|+ z0YrL2HM7v9+hx5QC2u*Sm3_4jjU7MIif(jC0gQ}J)~!ed7;X=7W- zCWAM2M({V>iJBH8mgI%)_fNskLWsK_3BtD`=JwA9FAv467va`^w0+n~g)(LlH9dy+ zYTrj}w5Q+8cOUKmRI-93gKNHyaucvJFGi;!d&Q=dB59s zy7=7hMQ$JKzkQIXSuZoMOuP|xv9>hW;btkLn0Jym7B|g{+zPqyw zYo#G;j61!X44vtPOXM1w^X|l8eCSj?#b_%{idL0T$>+9#dusS3Zn3^im4=1koBO97 z3cbHTk9-o=Ee_C-(asRoO~JwsG5;j*hjLtLC2?oLK93BK)QB)DVC#9~+KAV-CR~fT z8V1k;MZ-Z4CBdh)&GQndPapZ&vaE6J4vf+ZYgv(vrUQtODx>IuT)E0eVMYsnWmnmi zYH3~q-(fGdapE-JJlT;K4z?JCyDY2??R(HCv^kNHJb-*3Lc~==>yc)2Ws&@>lYYK9 z=t~+xlYwN2vbC~rdH}Vu4{UP;yoj6kcBqn02M@8_9p{fVU;_gL z#zP(+AmcBFC_*{Nft@=KO>3fPWCXS_P2$s<-KUoJ=n95 zRwk*{L(ki(SCaEOWT+E z#y!SO*jIaFz=)1bt5WU-d>m&?sB-*XW>*QHiMx7dlmT?cand0a{@m_R@Ubv>tGtTi z%5F8l&HN#(RFmC98??h+i@= zRm#m&f15GeSuDKtH*sw2T>>*aS>3tq@6sSgRs5vhn_sL}AX0glbuX-3PFWYk6T#J9?J0nb_7#bDYW4 zwJpg^)ZVUC!6z+}CHk#PoJo`3<;vQ`T{U;v;oD(VBuxZFB;FHhxzPK1e8to8Ct4KY zb7FfrddnsVr7&O>|DG_RLp_!S@JRnN@D5F5MPs%%z+MVrzvUhhW&YbMSgi;ppBqdO zB=6jN&PTy0%TsSR=FlkE8^&JRHi?$#Df+SgRFyXN%&`GkJzc%*L>`u>T|HgIA%DvZ zKb*4oVJ>@oCYQf!^oL<)9kmp`IQ zwrQsDpD-?3ZOpu)LbtsoarHrDetaCc-&lZHo+p5sSzO# z6^|eoQ)_q!vrS4#VxLE}2)iI03UFT`BN-tXolEwYmY2{zSvWjSV&>@I-u2&YJF|$0 z9~rbF@;+kD5q$A3_6n;)!r=(?(d*cw^z_{TnEu~81p8Jlj?4Ioo*L+}>GZ#qFHDAM zH9ImqHYssu4P-Ld{<<-ri8A87WFeKSF5MPmYq;BceZC#4#nXd46gdqLU<4=s#E#CD zZ4tt>nj8cY%Q*3I>3yoj{z!4KyZ=y#L$I~QcJQxGWgUV4E-)>sna>0Tha?~xeS`Gf zz;8c*fzM4qEm|*nC7&`D&+>;}bgihBJXU|umZ;kaBsm>2Qbu3DDCNc%Tk3J=Fr;;wcXs@BuM1P$Tzuzz2Ys_cBe zU0f(zs!WgYLagJkR3FMwZFKAq_yUVBrzmZEBVRUq8Le<6_lTn!+m% z`)U~d6?k@rL_YS83|DOl+=DZAA(nF7kLTHRHhwSB;dLB5Q;lyw${wm?ZHPkY8%CA$ z3v#Q|O6{{pSsP^UQ$d-vUhV~-_S>}Pb(=uXlemuXg_L`>PB$hMz@S+y4&T5ZP=RW0 zIspSV>erht=2NDtgXUL}T~}YG0v7~VN9-rzTYX3!1i#vw{;f;{l7Sq$A#aZD-pUUW z0@73c_i8y!K*oYeLT+}eMYCA6raA-6=pvBI@^pJ+1x(MhwmKEeJ{9m=fEuw0`Y{dC zH=3}w+&G=Ct}b|GD4&FEyC8%F2iawIiaXaFe^)gO)?p|c zfAG&`y5G9m%TOqq;Am*y9E7x@D30k~q<;Ulw+2B#faSGj2BPdf+1`SXfj$<0=kVl7 zHgIs|i{>3aQSq4GPv&ystjrgW^#RV7urmR%B^8bcJ&ceAT`{@Zhv$tau0yKK#u%g2 z1T;*;{3$|g`YV4|fmZ#l>hCB83cjK71T2FSzk+st2YOqgQR#XZgq;ZcLQ#I{uM=!T z0Zz)sIKpnZp~lR^+4cOHrDoD&6pm(+KY@~>Q=jh6D8yn?IDw*?8^$DO6iPL-(qAd~ zqK~)AWG-XlJJl>e1!opCl+#Sra7Hn?cv-66>Hx{=xT)V7#AvvE zTwzw>tjNi6x^1;{rjWYY@+wJ~VfFI0Sc{``@v;ftR9U*1!Kx0RwmSy4_A6^)&Z(H- zT1*w)Bnrh%TGnbTvFb2KZBwj$*LT>)`{(?=|H#e$=giZ8$WHuUru#4ail*a2SF=#% z-;?_H{5}^KarrQb+cEhtJ0!{oq8`1!3>yIic+-Y9{bT#>UxtPJmtEigk3GLAe^`bV`hhe$?@T-fJgtOx4fdH>q}w+ySO z`0(9bgQ9u;$)1|#02x*{^l^SjSYIuRVY^>Yy9f@Cmb}R^>^t`9rk2s=>dkm-tHru& zTkbkzD0{u+5oZ-lyQ$s9#zI@GMoaryO8;3|+r$wEtE*d^Uu3hbWXYJ++u0%y4*6E1 zTZ=j2*x8nrb(c|HU8!S$-TI%1!lV*Zb4d|+)loDIHegH~XHhJkv%Gh9j~f0oxa3v{ zUVvoX0~wW8*JD{dxv&une#SrV24y|$T9o+K5QE7ZiG>tWi zxawOd1`+-wM4O;;GKbPav!FWRp#`L&qf`~0S)+0?<3W8)f&Y}2&_ItlEB6m`D|n!_ zN27@%`29rweGXhN5IV~wcBm{f2^!bIdZ_lR!_fYs;ieY7ud3nSQ%VxJvB*D0G(Xn+C0V`2i!aSllhGX-93rhoI-V1#ZJkC-sM%kQjxh# zN&5mf9M@7C5yNB8Ivm|o_+J+*5Mqd)H~Z@B3!l2cq}WY{llph>8V(As<+xGV0NtGN=b8>QPtsr{H$^9LNrfrDoPghlkme4@ho2CYvA)D zYcyUF(+@)U{iSP!R{WdY!E{OWT`apI5>pSM`ojozB_ClI6!OvC(-^<78#-~Ca{*r5 zgXjvL7}h0O#Cs{BH&NF_R9Q_y#@1QVAA-#v5}LwO_WmuDpG)1|X8k+t>NIV8aKgK= za3pc9`|#d|nP>CrotFG={X>fO;5y&cq4|5t#T+EN6t^DDgEDZ{C+Wtb6aMy z8|GHq0jI4tCWMy_<=dC|oB5gbh2{q>#;uF@mvnL3GVpC(r~J(iD9T7*yx7;BhYJ0L zk4MESSsRl{b@7H$)0rgPY+Uv4;`Uq13}ZddzY&f{X}K?GYO_llr%n2$QG4B%sdo5I z*7=O*{H1JGb5r4$-PZU*Vu zBT-*!#Eq>{2Ye;Js;kDr-gUc%LP9Z>rRkSRm2DM?Y2xI${o=DZ%}B5rA<((Fv2 zR&&2Ny5Gzjy!PxOlUJG!Z#8(St8uYh(wb;l1HG~mBh<3+1k}xL*7}&5 zyh0)?Qu%@ULC+_4pA}aDfppIotF&2#H!IuL&w8*cSnC7n<9%H z4=~>E%4t+aD{!c!V#M376%++?h=ALfVP=7QHz8Gar)sbzcu{DF z-^X*GcOHd1;1#x5T#e;^A-+$1+`kgwhSWlj1~>HJyJaZ)3+^YI`dBcPm^>;7U$&;U zDAujNODXGt3chOs+!r=q52nEHrgfhU_t5f*3L!ctSM&(7cW$eE{{eZNaPkh%D03RR z5B#m)`5fTKvJRanloBP!pK}<6F110h-nx>Dqud0WqZ8<8_~l&raIrX(>lP}uRSLZ_ z{QO}%2YDU^*9BC0D|h?ix=zZXZrJq)q({NL_4uR4zAGk)B_vq8J0JaB0|XKw-%`=L zYC{H4?iNN(;>ms|@%vQe2(|@MrND`i^w)jpMt$WbJnw4tp?LP$Br#wr#vATU$k5%N z#0Q8Lvi;282>v|UzS8b-%*^R=>`pd|q2wc~_Udr{ zBCDb`N0kT4aRF?c(ki2Y@#@Fzr`}ttxj`(|%o}D{V102_;B86b&dxDRuy@P#RKi=w z?^yOEshxr!G%wV2j3>Hr5{pN^9erxmQ`-?_4ckIl4cVN2`n5F{1G zU3*Rv9VZc_P$_YNPAc=NQ8FLQn95(E7ebNRTmdo%X%k~L63$fgFRb@kpH*2W)==U} zIF1w=&eS2|p5%e#(Am5UH^=jeSJWHq&YM3`e5HZ)%6QaBR!$!wF2E$S@ZetQAS~4v zcn3EM570y9(=fMJV55w}f%0#*;9VsxMP>1>vbqI5UuT`DJ~tln!k8pa4$^`_IzZasH&wkPp?dE|r&m{O?YH6N;q4EpKy5Vc}(w3TsjOCUEGrGJ*Dg-E`@v#@!x zHnCSL)_24?gb*W#dpirx@Nnur>E&t4)7mvS6v&k3S9wbz@sn*01Zs?PzKdUuvTI-Q zq7l6~c4m3fZ)j!Q?O_42xN7xmdrp3kxAO9ZsBQj9Y~rlt{K@u=dECFX`-(d9YVF)G zZ;xiEMkKQJasrLxEwcaJ>)7a3gYb5U{x;0gCVHGHkPCbVq3t>`ezOa?mbxi6P`@*f z3t~r(|BkcEqj6#H#Fd!d3K1*GpRYFY{;a9oAdnQwEQum=yes<;|<&m8dBuLCLLF1jLf1dVo8YzE7PYJRfTi zA(8Ap{v&pn9ts3?m7*>xXLJV}6~YFy@ct_1Ms+rV8y_;H1$~N>Kno22o6nQDax(AY zD4y~V%nKkfsMErl6W9RPBhD5S^3!5!`G*@vPpoRmYs%;O>9i1j-1s`;FW4-dACIJu zht4Ww;oWYwYIpjR|Ub^6i|=!JtanD&OwDyJ5F$OmRO-vD5ZD9L zj<=H-d|``h+7SLXKx6#y&U@+J3oq~&;aD=M_Dmglks9B-nFL7h+xXSDEBz-fq{lu7 zFTb&01Derx!$U@fy}q4B%UhtmBXwJRMYQI@9rxL2eAD(pM?ueriG^7Jn*cipe)RRq z)_TDB5Sa;1rV_}?N1ptB{56dEQao4_c+My9X9UxOVZR4oOsfJT2qPm(5hcp=_R|ZT z_7OrWTHL`GT@>+e;m-=z`qKfIj|5%NdhV)mp-dT0Xwx_@3%8yJn1h#+<6th=>tK=p zbEeX3j{it(Te@q};xP>d`l{$cmAUq|uC*huJAIYgCM=BT(;k|?#S`QUou4l90j~gS zmU$+RgN1*6mx9KG6S^G5_iR4`VL>sh8pYo)`bm=O4!WhVXaZ zzqbF~nTLX~;+(?f`;R&-jor-+O_vf{GP4pZ7tw<>_tTlv0}z4SlyFz}m$>VuD9}nr(wC7j z=^l~xn%N4&8;OxF5v=r1-z$(Vj;!N+9+BFvf{>d*a2%fs0?RKE1m{|kLuaP=#b^*D zU}ix?+5r7TpdZe80bx82=X7Lo^NW6-6B)e&X}LRk<==-Dj_nS9Ztd1da6_psVwh${ z#wvhL<#QqkYh6_@BdcA?idcrXB_@~rc)aa^1PV@Jm{3el$gZ#AUE@{(ADsYoZl3j3 zd^gU)(GvQxYk(WS82xf{KnHntQ`9Zu9ga!SJw%e20>a8`_^!d8jU1+2R*!6i<<95O z?SKg;smOo<4wMmpEVDw{ph-uWe<7PZOFJtgwz@o$vx?uIe8x{xQ>83M4|!|bt})tY zEm=IlqN_7^)FZkq`8dv-CKCk4t<0~so)7A3avSRt59Uh-*c61AjAfa~LY!uub2K^C z_--O1EcSs5F)H?%$@PxewQBmsTaH*D&D`a2KFCll#k)^vGQ1Eo@l-%;g2$0U;*H5T zFEX5LjkstK(Mf3Xi*?SSIpPShl^CwxksOp@3@fb=GA&%!yqf-$QDf|B3YL`!NzWml z{2(q%HTD-$9aWg#+l>HalV-uQ2s}ltrWLCbQfff zMdC;ZO79y2S6$TxMOO!*1^reVGBFU1HsoDyDGZ|HDnFuh2O&q@)+;1(cvL)7AAM&tlFAHptN|IT zFaBkFwv%=-*QTVzb(_db%BQrxMf#_3n|4BHbcr__uqNC#`HxjeYncFUN_w%Mw|A@K zZrtUi_vq~Nzs+`YNZnV{;mH}dx>VC=Pi<`Y8E;$)2uPd>tTyJ`v9Jn0-3tHk^m%xv z%BcLiaUdXV3QSh;Xo;`A-AJy|Bi5F-|6seZrEbZ3>xWTbOZL5T(vke<;`E1t1WT+Y zSR5~6q9v+M`kdG2ki36CO(u_v-}kE&h|9CBY`52^%PX0@s#a%bb8QF2<9->3^Du{- z&Nt&>^JrJSX750qErM( zk7Mht(V30a^uATv#`G4zWH`MP#U+Q5?}=>IW~MW2U0X3HMdO9J#;@~<0`uBci__D_ z2I`3N)rC3c6;_l7b?Ty%UZ4Sq&?Pw2btO{YvYdHRrI)$)9!{x-qM~wY<_^(}lF~x6 zmFA3u~6jVzyY#(3cjSfvsMb(CgGyOBFmi#-1`25UCyOX~#BxwZ)`5Ea&Fo*#J}HJXIeY*aO0>gS)iWX4QUvYk`B=yKIwJr?Lg@Pf(1il zJ#dku^Mx`1A@DB3^*D%QEKE^SdMZrvIYxn(0B5Zs+?kb_(&l0#z1x_213oC^J|Sc0 zMhjb}>k3Y#$vF;e;n|DHIc(XUupNxydI2`N$+d|3syT?Tn&}PUN;g4M_xOH$1J~c5 zKSUjsXVQsoZZ}oMyv0htDmSo}<6}o{c=s}BBv7}+Q8$0TT>q=h>0o40sKp^@1UJip zo&KXyH`MTv%~3B%cns;dD**k-1aIaxavF$7=LxTMz; zDcw$1i|JzT9G#zMm`oWIH^O1$-O+stSbzm4vdr^TX*~0*GP5`#d6G7#K>4sfm4oZ1 zz)&>)0uF(D(-11A0-9onkMw@lF z%@I@NI!R=SQrvf5_s=3vI{8ESN(q7cc|0YWxUX*meTssQ-}2p|INQeU9?|w8v(0T$ zQMcXolyt%}mc-e&k4oy)$yB+ae$KUjm}@Ot$ z16jvkXyBrlis)lxB=b14{%x|-#l*j`3P1|La{X5LdS&IPqA3^18|Kl(;l(4qR`|}z z*h?WsK_JDiQI*3$*sAe=MzJoX`%`ZJZ2gs5O;Z<4k3xu58LM&pwaC(ww4J!Y#a*E* zr4+on_>fSkHkW|H%CtpRzEVx=oskyzK3wPLO@D%S`z-y(n;UprjT#A;y9g-aK(NkB zShZ|Y+#%{OU>VK@6ICsH)3rQz>%G0;&P`wW#my&n z?b&C1E|)@^KTi z6osL^FO2?MNiGjs4;Koz>mr=^hcNUfWUoX521R2yY|SumSvh!ddzcIFG3>`N&cre- zj_;ZZ+EW>NAo}ILyy1OWiw--HTw)U8zE2Xt7^2Y_9*xT9i0&O^OYOk$zKWnG5|tiJ zuGMY-WqrnCT3hZrrDxFWxQ!9UHj+e~rC!cxAzs{~fcFbnK)%w$rg~ z+qP{d9ox2T+qP}ndb_9l&fK}bnR)N?oV`z-^X#fR|D0N%RkhZ4F_&3LE$PhCXB15R zn0maSd85>!hRaJ-|zhCbXUz`w!h$lA`@6_@|Y=%B$Y#e{^#|IFx} zsE{_?e>HlT{{l3{zi9NJ{9(?5(33MPy4-!u?-p8k{3h5zOx{a?Ak|IFyZ;Qy5y zy!We3@=vBzJIO+d20f8JDCm`z(F+do*#->8U)kTH-o3xsYK zYtTzbIMCKj>rI3*NewMd_BH9BV4^e-ZDfLR7_(NApv7vWDz7=87GF3q?N@BHqoYum zUuT@Ar?Vmr+28MPJ%`z`i=Ys}E=(OeO}jkUUsaRdp1*7zOtqnbXkaNoo-l!z`tFmD z4=ryWMjVLpJ-bDg(z7T}lI4KPX1{E_kquQKx4Py&JM;U z^abbkbevJ5ZeO8)QZ7ZnU;>Yh9?+a@6qB`ipVJ4qWfjvGLxX(G{6x*&{2Ws<}fkXCz93eZRl;_dS$JS^h#bfnpqxa#TfR z!n&#;nzZz&8OsA6(yK}QiKGIdM#^IL8Y}Gm*i}}v^Qw$xrR8|4hvkd6;_)6c>^xV< z)@5pb9RG)#qAO@=y@X{0DIUhV#O|cov3xRD^g3q!LR^7t>3gQ`xWjS^Y?O6L4>y&3 z$r-B@^n0VuB}%~~D+W+(5j8LmkyEiFR}AX(8zk9kp+rihUPo+SRl zWR5^rvbw(YFY9#=_*eX{+gQD$rYicLIjXTZdC`|s62P{bS4R$hGVLc$lw@Pp90kvuH5 zi8OOaGqgJq40-=f*w0D~yjRId;l17__G6^oLJfXKOiBe*vjOWf-oi{{a~x|jOHv%g zRHLzU8H*A~_So)%=h4=zd(-a44-tg*>CTpBorZ(K3NEx_YR-?xDo(eZzQd&dGg$QYl%7%)Z zwBw1=(whf3-lFy~h8XlZzQZWQNkR)&F9u@Z18@zcILA#Z8NRqlsSEe&KoxC2GD`VD zOIPQu8-&{q@!7KKniJGB{hNw2T!keCXe8x;Vnd_YuCnqLQOkNqL&siiLeCqba0L~G z(g3I&5pgjwxNrE*jokH6K+|T=eYTdZ4z33b+D~FIRJ5liS~hpefHsE?S>^YoX^c$ zbKBWn8k)l?_avzZf=AWIhHQydqdoI9JxF4d}D!tJQ1U zE-#-gV}l84B!1%K@9TSvg*ozgGd-r*jwTuPQ>oX#K_`-%VMJvjtrIG|F5bdCn<^;9 z4JPkC#59p3Y*7n3hP0JMa{+*sx_lE$jKn-scem*zG8j`9wL+it2=?4~MYneqy~z#x z6TCMY`b%g-%6o?2wpq)vRSww`xWX_~4N)y!Z{f#+zN^~n} zo9pXymQZ+5p$?aI3j$6`z&gmGe*_{-)jbHoR7xzkSZ~KS4SMnfl<+rsT{qZtR-UQe z<+~E0=Z$TQ31q&z7?R4FYvOAS`D=~N@-Sw zCQTAkV!UhC3T(v`?S<$rA&H8GmNJ2GC*?`pa^KOri5;xBBXCE?&Wy&7e;u2ZAG;)4>ap{`*`+t=KQ&qZ-MypV&;PbdNnZc}+J0T`f8!&5+a(a#KlA?S`#;7f zaM06rJhB!X-=;FfojQS%d0g6_Q#e_(IzU>r4Y_m#Ps6~+sdu-e>6g?h+Z;84G_a7oe(*d@Z?9m@Vz zCqu>o^?UIC?jm@jvwnX&vAZA69$J&vYS>b6_&otmEb3fR10~$7u~c5S5K@w#NRicn z>|{bz(RFb6KG|`7K#9Ugey#<*d=1lhMso=fu56Ed(m6kAcskzcIHuv4xv9c_1m1-S z7fGA1*qk3~)Bu{9PPkQjLQmgwS@+4L>{o}mP=VsqH;a#))$&)Ad3KF``8fU8NqQJN zo)gg)|;BRJsBDRFW!CykTUs)~onM|Z0?Adl5C5oJ(d zw9?~t-(sWT5G2(tQN@O#qzh6e0%mx@=<|V&XPDujyWns_YNct13q<5?)fKJsc+Z}j z7%a}YaQDeq%l-Xl!kW%O9y{ONAbt7g4?>PFOB^TNm76fCx>=7cKFgpbHbE*Ulo-@>DCa<{()A70pQqBU zmt70oPH^n#-Cxd<1+xJ8jQs@5z%XT$A0LMu}YW^Q4z($7JWdQ-iy}}DOVnS z&%gfQccyZdq;b@$8y zhnk*ffBkZxhej_#AEG^K2S1yfm zdh6r*;iK$^D4fg3;lP9hX0U-UMZ0=b8~5(X9CF=P`7HKr>VJK zV3a5Rn0@HU#kW4g;v*YGVQPxrl98smXeO+RB+!P8&{V%@fAzo?9~)IfR@5-B0;&f~ zp{TOf6ZtJ{(iZt=og7(8)TLuRdzqz`E`MZQSWcpW*}emM1ZxaJmE=n|LnAa%{*IDT zaFKhxPUcMM%XMF8S{ z`S6=SZb^TQ3y=usM=VuolG0#p-_uB2ByZ+EM+XS9^t#dr5i9+S5_}6HgKUV!&(1q3 zCMQ)r6W`7S=UqkhWpIuzwTTQ7DA>vxP1W4ZduOp5g(oHAR?EGlYokUaVrAzK(Im%l z+Oj~nwM?M3#VtmY@M6^WdaL&CS)^$X6Z)c)#Ju5=X7F1qVNqCBxb@9aSHf^ z$Y%R^cv@!l6(8gEMg{|;Ua`)vMK?$-$4zVwIzl3Bqf0hO)j@7{ws{5>55=TT5EK#_ zGHU{1bpc%4k@u7@ZJxQ#HYic?XAbyb1$1snGI63Pv&MM>_`Ff|`zsXpm+#*mFwV6U z-+nlC8^4t38LhZPWTKFvz|aIa7{y*@B6mW57s#BSCP(O(+OKGcDLV61&;m)aVNZIh zX?k$zge9_;4RpRV;ljG~;i4ON+LZd-9_;IpTR~P~i<`isA&A3D9vM+u8-29mNNa6O zYbm6vCJUaXJ=}NWB5$KtC|n(3bTTwx+ryk1&e(OareJu{;22S&&DJ25bJ;Coy_M7b zn0#k$vhXiTIxS2|s)9>lK%lz) zo>ep14|UKrcr0h&!X0O5-1ybiCpu-~P9R}B?I2sD%dZ?o;-z9=-=e1m!1UX@OX`~= zXr$Y&idRs3!picO?-FY{mFD*i?i-Z*Q6jG&v?%tvkN9x)3~K0S@fgr@-8)$8$b8K# z>uD8soh%bri)n`w_QV{?W5DS$tUBwZ=lTJ5@j)sGCM$jI!DK6G+(z|J@qTF#X_KNB6I0xKM8+JWb}x_aYda9i<+55f`y{IiO0^%9Z(yoG$vLK||^~{<7INN?mg-pZGcJ zRP_x9FahfEf>#_?d%SImlbfZ>6u8!UjeCO|2Mx1}X+mg27{?hW3MUJv3AYW-c*Y4& za!+I}m>J3Y1;9a3pb9Nr2d>u%Utt=08p9oGivhslD6+4L&6<*X5wM!ykmkn@<#7G` z*I0gnX-EcMiGMW2A&LF&;UVjIExxAm<4r@<@xQ}!m7*(S$%B%NH*G6`>f$>~ZFc&< zY3w+y=)5mIggCl!klElN+3z^OTxcCvxFOwR=L^2HhDWrlOqPZOe&9@snN=(zIMM2m zLSby0^)k!v3V)h?k0W(2RER&peK3_D8EBk)*Ec-bwZ?3snsqGg6ypIekI#{~JzJ<{ z{OtU9^dF<1M{{=N0_U;2+dD3A^S-$4J2hx%8v4Epc;KNu7J7wb8= z{$b1`5$o~)ri=yZ=aA~&wLth=t9YnJs{w>4|3kCU8+lI!Z^=hMsijWLL*qz#(Tt7E0c z*)+-ID;lyl*HcsWBvNc0O!cXU>?*P~`^yX1VcWZIhuHTNQXIUVf~Px~K9B>h*x#*& z;7~_5Mc7fn)D6L_%1BoiMWdeZjKr$HmyFwe)KGiKP%VXwno3BkJOtn)hoeCoTOz6b z=mA=O4KF(=BIi2KH5OP_^{THZJ%{bi^k7i1^5Gd|AZ@?@nGKLP(hqwjCYT8N@U|xn zf41?}tidB!bOkJ&*dUzGk6yMdG+V@p841}Vz2fJ4B32E;aiaM?qer_Ntzbhk(>&|S zPYxP)bILm62RCyUEQ7jvm=P3c{>?c%gq3)P2mkD-wv4tn>2_J7yGT=IYyuJKc}Ci8 z#Pzrvs~!G#1Inh#F_L$?Erx*0E0MO{gtNfW<8*ffXvc0V{)^C7DttAnW~M2&noF?A z6!cB|&^5VrqIbD%hH%k@4zUNY$}yPwm%a^dMTt?)r>X$IuNURclNY}3GL(=zxQ2+@ zj|y^onFeM%T+EVpV!ZBriy+sL9t!OA%OPdJE6@o?AKYFLN1YatgYcT^M_%?0gQ57b zj)&h{hcZzZn9GKLT>EKZ@T1e{ruO3a1-dIg+n|NFCm7pgj|PDea0$ffZfYdXGB?{0_C~|UiU|&r?d)uCd&(i2r7*Y{4#$k4n}{!RlMuqQY&=`t|}4&v{bv{GinO&-V2JER2gqCB~lil;uA z452kXVZEku4K6wWmVidggBY&FU}W#Zd-iE+pz^U@_C9cHH0>+zJ?DwJs3UKLq;Qow z(~pT|6?p|BFNG~WE1E|7<8}Z_SBiRiw(3znl1#R9>Do1(NZ>Zik}J72dfc#|7JjY! zwDEuB$yhUaJeqGb5lQ6BsJc||Zx=>O$)vyM~jbF$19D(u}|A+DXvC%N$Wf=%*Wl6}ZXghd6PuqFlaW-Kg3*CLwE@7hujsiadKS+(lmRVUs z05|}A|9Rn^RMgZ}jWf~2Hv#wBW$LpCFH=Dry_q>=ms|)#f!@x+3p0R%z%PJDnaGKZ^Dq-%?g- zzOH!ZbsYJZTl5QZr_v32)dm4WaQif>pl5QuvYx2~a!s5K$IWW(@?g}@e?v1P3Q61f zYyAGdYEcpwh&fX8%<)gA_0j-1OzFQyus%JyXD#friGK z_N_PuRa;lyh;?dAGimHPiYL^E#~6wp7>$|vnx5tegN}}b<{LM#zpelRP;n-(0cI5q zjWajlt~aYx757=dkpYNYwXo~t`A0@47gx=e^<8xN%IVC*lX@__Tr$hPWTwq!a*yop z*pZ>qF?RKH8(ZOIFr~Vc>jU=&EXQdYK3f4<{{^Q<)8d)n=J-KDee-g(tPLpJLSXsJ znVPzrj@@L4XLY4p=f+c;)#FJL3U>)3&k{uQO9OJhR`HruD4a}6P4Y&%L2;GfPtSRTeFC-xO>_4GKU*U2vv?<`KU z@o3Q3#iM$ZpA*V;lUKeDffoyni@0M9^m^5lv}+75@rjJP{2#&xz;L3GNs>$7uPXIo z`ruGrMRZ?2nI9CHKh=|ZZHjq&-r82M4lUldVJFmBXYUtnjpUhKoIfq!JL7B;>Um|Z zCq^4lH#*Z?LoaPrh96TdV~7hdrI@wYw5H8FTJDzxtUAOBC*92K3>H}!UAkE+-Kmf! z-AYJ3E<5*&hnyyX#hr0CTuZm)7C3LcHeO$pmm`FvHr^(k-R_mVR=Str4pKAJo_MFv zJ`+Qpiq79{h!#voSxjflfdt6j=Q?SLtha%Y=+eRys zIycQ!i!U}AM)5w!C4&bORLLVk(#LAXYE;OWN*5K_M@{3;m5LQi2OAAc&o9;7Ijq-5 zUYajZQBYefOwZRoJ#2_7k2&vO9Tv+Ty-G+JwU?*d^rkQC3Eh|)Lim&4$x5w7wxOT$ zPG9$(vvOZPrP4rr~lKSWI^a#E#xKS)Oi8e-yVHTo{m_ zin#ecSh=X9a;*Zn(`^Au~n06f*9b&rGx-zvQ&irREf3g&wRk zpAMaHv_5`<1GMgU9|HX0v)_Mj?!Rk?!2i2;AZR;xnfyMh8v3(#oSpq%I}CoW98`Z~ z@bm!y^bNps>|y?lW%f5uN$X$ol`wxX6DrmpR>PfrcWDrFE$!cgQfBOBq=TyI+ z|HnC1-LJMd+Mo7+Xmz9hnfFiM|B2Nys0&syu6v0GX*VwJ+t$lR=>=>Cf)ojZaWDTjQ&PV2X#EeVLE85o5ZTFci*6XHI!$&Ml_e9T|tH)R3&;8*k81eHhvbp_+sPc{DWkH?ork8XwU#)i}u3^S7-tv|_riJ6Bbn3_z#6?UrRE z+4{qF*)8o}*l2Sgyw}I+7{K6h3zS0`aUhI2@pi0s2>>Z?Z2{oaB|%;6ZJZk6Lz)bC zl4EZVfNAke&uFv6z-)pD2g`VtFA{*D4cY1NHW6xNgGbm+8s$cqD=H|?%mvE3Kys24 zG7NksUz3d;R~fEk3}B+@KskKg8JRmbu>mvN`&l+ZbIo#x+dW^1+M3DLnk)$BX#J>* z-SR^4jCR4g8KqI>n}XFo*4=@ecp_YxWhY8lUAI{hr*2PXSQWAyj5KBNyUoY^kyBLlkUr9q36D1waLO0WJ(_pVE`RUNWXsXo+Q1`M*u#vN`X0G;^evdGeOi(_E# z;$MDVW0Sl}`2Z^GTfB0MNeu;>v-S3RDiug<4tcC}u5pqME18=Y5*HekdAE2d5Fh2d z-Mze+V)MTP5PD{aeyn3*V0#b}vcEHef>jadoYc3xOAvw;YVo2i+276HzN|=CF!}LR z$M(+2%1)c&Zx-Zb%}Gs8$?9F6y2DQ&m##LNZW?Ro1x{e2OqUw=*IMdWkgxu5Qa+kh zOVr#Ou!5o7uGpX;x^0-3L<c*O`DoHQbjpi8H5>gN|(Hcp=9meMvMgE zaL)b__Z@`EM)oj@w}ebnFR7K5Ry%Nm^ovR&Sg2PxQvQ~oagBG$-PfWJX@$%W+%%^$ z+f-&^3wRZ6dvmfj)o#fVlJ9&d@+cAqT~*-$W+7z`9}kq9mI5y;G`u~ec*5TsLgPDh z$<_sit{^LYVL&_atw`JPGfBJ4v#&qLWlm9x@3_Q2{E<48+r0f#(D5V#5>nK0n3Qut#kC<+~(<3dY%XWMKExR6Y|`n=B4refvb4 zwDgY-4Eom(v`1GdQm60~&Z`Xs3|~QFcp=0EW*{|m4cybThCSFpmWPxe@*EY^2$YVs zBn=;N*^8rJCVd*5p<(j{BVR+MDrDORB)lPtzKHI94zKhFlk*DlV7yNk&yB>$B}L1x&!wC$da$s+?mV zk4Cu;4V<+-)6GP6bh-IeGT!s=r#q~cm7NW`+VbIUq;Dy=rQKT7s<&b3#fBoV3_s}- z9J4vi?sf%LrEdr|{oa`3brgcUX|#s_jp7 zg_3C8r{Bz}MGzvY=_1n+jR~=53~;IN_;;BV^v&5e@7x&%YT7MC-*bc)^hV z0HK+5f$V)ZKthlQMe_=to5o?N{2InQ_1PqF{-l%lu%F|k`%o@%KEgkm^YH6c@{^bo z%c&6-hcn$?PqIVoeDzdl(~iXXxFVYIfYEWkmW^(O*+HG2c3Doj3L)=tgBwiFVX>}b zBD1~Yn5@4In={ls9JJPa@4(ADYww85)H(ghd3sR{mfc~vS8P(rlzorg_{3;HL`ViE zA3hOCZ##x{j86%V^(LFejHF#4t|o^1vq(g&a~zV?>4+C{M$IZ4B5Mg(YD!ew(Vo95 zWJx~>Cjr;rIn!A?s2?I>RkW+wGADcD?Q5__ebsT%fY5fHp27CMRq%yrcGSR54@PKD zq(w&5nl$GD1v;2g4*2NMHxYz{IQ`_l6O}{iV;_9N+ zHQpmmI?`4(D!b?nH&y1CI`BV6R*&J03=}S+J~%rEXdHDr^KFJ*A6Y?fdc18qLM%qc znt){pl=Lh3RAe}WDuJhVL>sw|Ok7?WiB%tbELMa1$w5+Sa~MM}G14r8o=8|JJJ>NP zWN$ihK^)m1v^k5+Rta&bZ}oa!o?NaPQRe8NA6mbzqqGc^gj-| z=q3od?tF-nd)O**@6*Sn4wUM(LnWICxGS7)(xA+QKI04|dE9SmIR~hw|53#gD3nB$ z0ZB0U(4G2azAOES5UP_GdVXI$a!f`|&RMCf%OU*^o+W4C?r@iu-a;Ai@C|W-WNUn{ zQq(My-P0`molgUh^)q}`u!Yy*-BY`9M)yHqIN=c8DmL>usA4}+JAiA#N%4;iHgg26i7`m(s9g@r20fnDfQvnPkF1s z5f~bMzTt;dyCs8|6Sl`{tQkn?;-Xz{Z`&F`TD*s~Q)BDU@`~l~=;IRdXa!HW2x(bu z#z@irp$P63H0yO+RG$E7$ZnX>8?PXnTYzQ*Rk?64 z)AW*|hZK<R!sH5^pG0GKBJ*Z3om$ z!xzVo8#c?So~{)FTHd9dTxl&oJYF;Sv&6!2w<16C6^?iLTzXU@0PY68_p~z*DIP$_ z4+AD-MBT1RI6j2oJmq3Hm%Moa7Hi->^srALE}!%w z-lYo_DO|XBv_6pwZy$8irL(20uP>R>_Hb^rHC%aThi)wMNrvUwngE$dI^>!Om({XR zrGnZ3F2I!vP+n{er^d8W*nGfYXjLJh_WDC~hiUFF581o`}PrYJ=}P?eN~9{^i+4mB%bq-pxYF}LuZ(7<#D*5K9V zfj5=2&0-|XWAvZ7RimKdAt?uceK3COlP8glS+idlCQ=r@y331pT4WR2_2@f`ytmRk zFI<1{3@21*h)7dHIqwxp*Fa&nS!VEyDAn4jYi4c#AQzSdH0wzt0ZK*#82Mr`$aEIo z)cloC(>t`ZG_h{V-$tSRNe1E4=~D(MsLdP?Xrt`}-fPkA;O8!^7h(}H?7Z4q0iG)7 zTlP#Jg6f?fBlb~Fjy|wH361oUOe}I+)&5C<#&@~{a4K!v-#0h(F}PjkoCR$+=n$r! zNNJhZek>g!ESdLyoUPnAl26|VfV4bK7!vhAQI2Cdc5(ZK7HIhGLUYNi~O6n^&vK2FQFlaa7rg z=|_-U5EHF>NZ-Nm&wnT0FbYN6S-boH$q6z@CQWuRdH&~k!=^q+g|A=!j0gU=7Rc+r z1&-uJ{CgOlt+QrAedZu7*k5I-^*$#Hp2hJJj+d=OgQNI`-2l(9NY& z;l*=D@zTRIza5pHf|(pQ(Tk~XYXQL5E=xtY%Ke0n&I>z0|1ybhci+RfSi&Dks_q96kWvFYfLP>Mribm9lV{)C&mk^z+yZPL_p-5b>Sc4;P8~%6> zafEXkYuA)Oq_5uOBH1I}9fwKQuCeoNI5}MvLvtLxu>f~3aWZ$wP)ims{922VIL0b_ zK_<3kQbKu6stY$f7|Ns8LnM7dd)ta`pa;s_$2fRlLANKFyR2>PT^yE8BaNX{AD#fIZa9tg)XJWN*%=(iSDdCcc zZ+9lTRNjQ#3oQ$po6FPsWj8a;Xd9+E7r3fd5xGi=VIcdjvmX6d-pgH{h;Pphly4`i z(KhMxL5u>v#~lH&`uyZUu`%xLMKkQ60>NBjo9tkB5?5{FUO|yi2T)|v9eY^FXXcz< z?~OGPonnnAI$5ic@?bc>_-eS~u`CSf({;wc#yH!WyDA%Zv}idTrOL$98h7mq&W$z6 zoz$>M)ad=CGap`(!Z>_3Zpr+pWSO2a2k5G_&)Q@=9iE*FutMu-Mi*&L zENW_|cwzavu>x(nv6s9f+3S*wP{93Yz@Y02Ry(@r$JDS5gHkjZjilb7{gZ(2wh zdf`VGvtFPua_O1G%1ONZB~H_s`sO;j^JACt*+pGD%m7U-vBt#Pe(UU$o(w%!kI!bL zsy4|QR3>P-ywb*d#~KqwRA}D-P~rrYXNcaEs+Rg&(wcFjhrxJCblUvvZgSmXgyL$b+TP^aseXRmnF)>+C?51*b=x~ zI{reW-O?3Y8RD8MmVM?6Bk}|zs>&x=x7$>6tx)|Qy+bo24VtB$E10PCzGb%q_Cg{> zM%0lHBDZQZk)r)`*gYuE{(Fn#L zI9!MgJ5&?`0zfo7npE2eK2!U0Hmm^hy&;cq_r*C4ls`j{`cXB&-E+tTR`EJ=epa5J z!>fHh;kEXN%%M?2zPxgMmHvc+-R9?P&oqF0&9M+)$qO2*m4Hj;ooHzX4n16fhr6k{ z|C~iQ8jRQ7@cH_NDO%{yL`tt?BD*tv7Z)6} zLAML`b@t_Pt-Op+bL&hA`usCV>_P+j>fl0p$+YbnS?lva>+=EYWqA6mQJ&G@9QqD| z?Nvf%^O!U?owOf(%#MBHx6g)0x)L!~=P{|TmOVy{t8Qr!`r;qVPNB6fCTX+xIljYv zs)gk2P5Q4^k9=dXhdYnqa3=Qv9C8sZ4sgclj;m{I+1c6gqBUEh-a{V=wW|d4FE)Cr zye#;`>)bdlBe5Ow^5Hi<)yNbb5sCr`ty?6-cBsAc7yiT}WMVTo#yY<5PTZcEy^72c zNbFC}z@r}kr!K+}+so-C#4|Q#Q3LWUUN3%zPX2FZP~-}FWSOr*b3yO4_wfVnjD=%x zi;FaSR)yN(hB`A`c_=Yk9N}_(m};u?3AvJdrqJ?$Be_ek#O6= zt;cXVQWCGXn*jSA46I7e*>uXuHJEP;nqFdXv>u3OAg14ADDy={J~*tjB~EdpLu^hV zDd5$_$=w-tXDYWgct#Jy9tK-ELcpH|efKH#Sr)A&8zw;epcoa{}a;9`XS`!Ek z_xggQ^=r*rXSL|=cLOf+7&>M@EvG^z<9PtU(B zXp?u3>6mc4R{B@bEBE5*AeMTJQ4Bz6mGvlfTxylvgW2gI@H}DbMa*zTwZfd-HU;sc ztD@ae-$e!oww+VTQ0U~A%yi%k?4EQXzs*$!RlO0))o3OLzI&I_LO8>U56zS~qSAYa&ZW3e8|GUJ$EFe`=g=(8-?g{r z_du}L*_xEMa#)1>8W^LuiM`2cm`2Kp-<+wF*Vz%S0&7I7qFaJ6#Q7bbdw)9*?6SY1 zUZ}!qc>EIe!zaF1FtC{z4#vDc>i&8~SrE9%_GdBQi{Zu*d8DbZy1m>K_oHBV%-Ar3 zBinq_UfGwS*UZHj23rQUD94}Rbs56=;DiHc;PUR!SJ&>6aRFv$-nAZ4Qm`j!oI@D( z`~XXLd*FR)Jc`C* z5#7VIxbl8J$(0cYdrIyAjpVD-R(lc9pAw@;#(u_l14FJ^a?|%bE`)Y8CDj?e1P;N) z*kIlRYl~};u=j&a^EhX@W~~*m^@G{)ux3paF`R%w0nH(cLiK|+^Jr$(NSn`LDu8EX zbxM2ogH!U{6tR}T^!T}EbxB(zVIhN>_Vu6nM!onsX6=z|UKFv2!bS7+N|V78cSNh4!vq{LOMM4)B) zNUR{8nOsP&a<1h&QfWr_Xp=td<443~)f7QF9-I@)mrCZ_ zK??c@|M*@7qir@5@gzLhmJ^9{OaCy~CNKK=(+4>4VTkwIXyFvDvYzN3_aT*;%Lg3( zQd!X4dg4t;<9tuE{Y`GLQJ$Sos_@&a7=SZfZ;y-3)g={mHTieyA*);c?YFAh1Qgqz zF_EMggx=n2Y8o+1!nOq5Q{lvN3R?B5PvgF3AkC}99>N<)FImh)3}<;dbIo`7`xpNj z|Bh|y9%YXWb#wAWY%DR^Vm8o3sM;P?7Mqa$0rEsNSaod{8}I!AV1#{0#S)B2?{3}V zM%Zw>{b?B)+8oTbP5e&WajLv^u2|l25WramHnE2|jaLbBRtZt3m+=4x0|lnTe!3ik zy{SYMdBe*JH80kWT4*1>S->vDo^jCA>_c@jSuM6UzGzX$! z|IGWR@BbJ#j(jhwc*{}P8}Cy0oT9Dd+G4nmbj-*SNiQj%Ye893kFH_geG$Biu zIOtO6kc(DZm~7*`owRbBnC5JWVc6!xlv*&e&p4|XP<{BrtbX4P2fc6GM#yExVPV7Y zV1J{-W$#c*W0Oz^m;B`V{xDAfP-T`v07nzvq~Vl?K$Sy-gP=^jU=H$ zywW04dUcLndvR5)P$Mi01X!l^_}WM*0U0v!1=|nya9UKEzD}Wx@k`7sqfRhBMmLo@ z<+YSaaoel{02|b`mkgF*{z6HwD43RqBYOmy_(9MK4&MQUIOkhZ?HgdT{!Bj zwyd@+VL%@4oNP*ei(TWE$Lh%cOu>+`^|&B~qQwO5m)l{-NNqYuo#y0K$z2LL)vBsl zOx~9zc<|0ap>bE>KN=!f;C|L-{h7!E&R^L<_oG+rCSl~cj$Evc`U~Mxk(nW_-9o^vp;^@n&p}2)ba2_j1Hy%U1LB^%@sw*od=RkQ2=SdwoN4WoM=E6h8$fZua_5I{`YP!LrLsgcf#7sT2ype@?S2*RTPS!eNe2?Fj@ZG0dRY-=Vn^XM3&tUINlIl1L>OEL&k zUrAtmQ0~5V)b>zL8!2pdL9|S@iZxk>dw8Mq5qvrZXQtpkkrd@n`HKCl+!p-#K}HkD zz`vUd)-`eel`+&~-v0yUB{0a@Y|kpYzxxa7*GntyT!3}=j|P24n{2)=UED1Z#7{1Z z8lJhj&R8|3noV3U;{$EOjKBvU>c+d-a1i<*4QnZq={ zM%iVy+Jy0q5H%r>1oojLHnT|csLf~nlca{qU=8u-=r?)YG@VZF$*FgM1@vF7NExDw0oxE zmvzI{ZeQl`v%ev})*~V+ik;w*@2BmAZ?A8bbL`>;Avj%T*O1xA938lIUB*77PXTwLu}NQKVMomfNIGL1q>9l)h^UFXEwj@S(%$@> zpp9Yo-v35b8Y(FPF>ptS(16Z=-c;J|Df2?wJW@uUJvUyZGzryQ$3zQ4Q5eTL9`|*Se;_b0X zegDd9(^-3|3WFV)Yc6pDc}FFc9o2UzQ0$8d_vk}#J)%X}Scv#NNn-gV|H@L<*bvng z5l6q9X8L6DWuK|Eps!7Jc1)StcDK@4)1O?LGh@=vOZ}g!jv?Cn9XILgBn2EK1+3bS zgkE904R7?3Q@FkN7Y!I3`^C?nEJ=PBhlm~Cm63@oKn)Nc!+jMbSSU-E9KaknVpWW0-c|pp7t;Tu|sdAGlH|g4f{O^=W*8Y z)CKl4CX1hh=9dO_;?-i{!F{j*>iLouf?~W}bvJn-z2`1rcCKf%@@DYWyyFR*^L6%g2K5|IG9{RxLSsTPD8F%#7K^)Pvz! z(f!P$Beqqh-i)1uplzwjAeMZ z%tjF3BnfdYn&A6xmBwwMOs!NZpttuRGTmT`@)`}y_0(R~xQ3rHh7qMU73%oO7tDgH zz1k(-vq_~@I4Q5@)XdTO)L~zc@KYC>@J6&cw;;Z-WzNx6;NnWSF8i|i%Ln?({H(o< zKG*b?O%iHflYiF@8rm0#GnifAQEh89EEMpxuG=LXKVbi^J7w4;j0AA&u4-+wC6q8| zMX+t3W^MHc^v*GDS94fQVD7FbW!!0>> zbzpr;A0OwDKTrou%I~g5R{$|vJ-8NXAX z+t1aX;Y~k}`-CKaNTzX3X{j}X<*;{zK54Q$zi&P7JGV@~uRa<-;xM{H(1AWMwFMd+GfA2hVZ={NY*tznu3^Jd3RDOkz7!vp#?TK}8Vs08@~E#v1yY|Je2~d5}22xN>Lr56>X-w>2Dt7?>gPwzpkUd@m9Zi_BZ3={NFtLwd1noJUNq|$WksjJG`KY#kfFq1#M6A zA>ATEwq{`Fwor|~7qU3Qq9r&w7p;)W5Pfd7#H_mzJc*k2kY+{A#iPXaz8!PYz-#1QY&_{tI%ax0!$sCp{(`> zQicuVrN*R~pvD~0#&X2#$O1~FfH$DG86IRNsV-N!u>+&;xS>?JwnI0*HlU4ux2e^} zZm{Lps71xftUAP|FeE!7q-Z3@>s$xuLZEvvCW`MK8LYHX%mOVYGxVM~!LqGBp>$C` z^IcK!xa4&Q-W;@S@RdWwf~{tMuTRKFeg@n!HY9FeFs3rU>eh%G@Bo6bj(iUC!2St1 z#tHdI44#XIygx=;MBbM)1k(@d)B~t#KS@FAr%$OnRvGIX8hktq;?fYF858pD=Z`eh z4)#e=M*cWi+ER!(#PC3@|BDq#(IxiDxc3jGj= zZ4&$Ppx*@b3#*|3;|u9c8RiTT#PX8Bom>HZrVXthUwSu_V%4m&g9oZJqNi^hnq8r| zj>hMkA5yh8xk4dm= zo1?Y-T#4p9E)e*+;}SGq6e9YjoD@4oVA8L+Q+`xA3)Ot=e{+cHa@|o#%Raw*cRE;? z%tbUf(ZNq&+f=~VVY}u2!MsZGg859N0iePac)fa(H{tyDXe8fLg}~sPsb>9ty=cNF zftb}!%G*f1sK0R?y^?Vdb^@Y8P; zI90xNvT~J`@_}ZSApZnTt9#=M==3os&l2$9RV=}!0uVr|B=7~Iu#xut8?!L%JHZP; zpSOBvQ=k|f)Yn)qkZ8OyiDUJ=P8 z-FGQX)}){29ua+9jP?mg-B&4dWAH7%eg#z6UJ6m+GWvLZqwY!sAJKqtxmoeJCXx`FE0@`K$0U4U_kO0Mk<17tnlb0`Ghn20^ziY=cINr=4vvf zyt$i|tGDjFIsJYix~1-qO3?!bKKgn(DmBayL9S2&NN1y_@lT={i3->Rn{u z!och;DX}DLWA^K3YWGf&s)&$ydT43E%xMn1-Xs5scdDYIY;1mZ&V*^J`M=gTp%?q44_bK z?(ADjl&7jiD}lD>&wE2bCHY$Vk%=~+D4C(I_oLDb2redQKG%I2wy2A%nydtv3ABR7 z()8pL==#wzxQ7omPMdSz76nWzg@jdf<&3vvG?g!`t0Vu3u z`?mRKIa*kuHBW`-r57DL>^9Mi$w({A^mNw_gZA_=9X_R_`(&?H&NhuR^~Aj3V~=4c zm-VpD<{j0=@=pIizB0i-Q_Rrn{Hjt@9%1s~tGZ}BjnExNHpbU<>Z*aIA|6Tgk2#nM z1z$y-le|m-9)_)c7Rlcnzuim_(YRT+tzW!p?y>F`Hrx#JHDTqEWrqwjB(xnCBBxlz zT#%h9pS-jqBDubT5$25Ni^VNMv*1&);rLIo8=A-(V;ktkkq|;{DSiHQz!#2a`>BDX zwd=418io!|im2izrGWYJdC9b&oM)t~LZEz~>J6V{xo<#@2)Gh0?1La@8-I?`1Bb0R zx9E8@E9(X0_s5Qn=S3|x#q_Qqa1*hmJ?jDBdCuAKGO+MDJtr&mWT*DH{&P`VbZVz) zOFIl9&qioP-*UN8FK0M`@UnT3WbSiE5r6#!pVJmUnuFcfokZbC?cmxckS*<3kcWl{ zFJC-^11)Y$cvP1dcCO%S zwJ56W#|2LjktK?(B2zVkQ-iqSc57@;s50QN@svLsnIWU`J_}iX%05k^n?dZUia$=( zjM{i^nQ>XSDAG~h!Sbc{+HJJYl~R13oHr1o0Z-r+vkW~yyd`6PL447LMbtA-WB8%j zBZ`tUAKd&dcmhP;d^+(EdwM9GcU&Y>AmYekl0xkwv4U_Dff49PV$6pUV}fZi>y2YN70#Hg!;V}T zEr%_;V0y@A-TUCzyn)8i{9Ml)M-TI#yCIa!WLcjqoO_@qG#a3|`^AIN5Oxv~qIK_` z%AXvbq!7;NeN>Q0k)&8b=8nBChiaLXj$R?v;6YypUW}gp(4t3m=1CLsejvtk^fip^A}F7$9iab%_nfkIoY30Ae@pfMp&zXqv93DP*88p zvPt8IH7jZqur9;9p~CNj944NO9CS*GCr6XXedJc;+ZY*GnXOzDS=~$OGJRh+-9{Wk)hGToX8a8qZ@es%e80YPRFeSmVvFan*mE3 z3k99=p*LP?i{$5BqMQtHqKi)c;WG~P>btzLYYu1F=sgCWoLLK&ZD_TqmlrSjOK%=3 zAm!B8o;=w1FMUuNm#p~sh(zGUjasX|#a+;qgOVO{oBDAQ@Q zDa!{ZNR9GkPL+tBXV|$Or+q@)Rs?j>%sa2GSiey4L(wu!rFA{6Re11%6+bU!@`T3m z*jPz<&?$+|a4uY9q)Jw!r$(`9gijR>j2LpHBc%Z)b%{@)yNLY00lV0Ukqq`2n%ah#&dMqM8!>OjUVDhU8M; z6{$(MZJ;;m_)(XUs2}L3WL@mVxpSn!uD2mUAZ%0+2<4t+olR_*ZEYP=G_>t=`BD88 z@~&XyF4c===4DHl9)i~mGQ*)!mXk}0$FdbGHW3lLck{pg3fo|2NrvJ3Kr01ko>{5Z}{1iymw z?43^Fba#*ip@ed;j%}*ha5Ca6^;+Al-YVM%+Ll3V_!UeLnZgrs&BY#mkUkf@t=>MY zZ8wBSuC~R)j0;+}9SBr>dK~gd&mOEA;S%a&^ZF}pXM}GDk`4uAk>je_ceR>38}c%1 z2yECvbv;6CIaFO?eaQ#*5D_6<(HHZ(q>1~%OG>|P8BuYvEk0`vp0xR$G^4n;+EU6C zRkFE=JL_Q&sRH2^C2`j)Ljnb%nu8?3q%qn?MDf9Cx+CfsILV~`zO(>}<~4u;?JF0f7)6n(pz3GU+lv7EEHY1>34 zP`#kxi@EcP!)u(*;!g-~&&moz%`V%ma+=1>>bD2M%ZtM{WWLyk?^b^m*& zABh6rVYhc)mZLs*-oZ7+v)G>l6E;XLbkPVQE65j3PY`Zuu16nJNQ#CXfKLpu)R2%( zUCh;q%b2>72VbPq6oLVZUu%B4t{Z4gakY)Z>aO2mq2Iw+VX#(45&%E&ru0?co*`kk zpR|;)2k|9ag{^pq!(^NhUoW3mD>%IcEZPCgJ2jE@T3#KfbH^)3qMl_I&f(&YC&#Od zlKI6?PTTX2z-agc>|5lVz=ClyD#$46D;5rb_;OU8P3gQ^-9hzX9XV-CTd5Qxrb$zb z&QyYk@v8^R-AGmP`zB6-Bp-or`ewd-^OM7)fKfiRXoeZN=3R>{aLI^n-l)~W=Rq;q z&jgiNEfsPH0{Pc9jgtABY+`Ds7*+&7WtcZfNPE8CD>*=~!_mhNdOYFFo=olg$&8Yh zpV{eZT$g(ZTz-9h_h{go8>H!nlZ#4ORWBF!aZTkeqqBgl1ME`YLj$&(Tq~ z3dX-3e!~MTpIGuiG10fS_xYmGh@+EIGtr}JbWAKTXuKi)6sD`ErX%H{c9lpN{o`L9 z+Nr4azLw2N1*-}kPJzrqrYL}{-i65LTS>2Zy@|)auS>M`#ty(L+7i;FLc^z;a=ftz4@zC4P(y}gpi z>ROaWC}El%SD`$8W0du@_t~f=@|H{rcM(fR<6Z~`Ye0AdXM(`T`0-$!eFIv1dypAk zUXdz7$2w9zrW_&3lvOo_rzN%lEw7FezSOo~rH*w^woM{F!$5PsH>qVlgK6C3BQP_* zLb<8o5Wc~b4Mv|Coq7D1_|FAqTphdzQMQb(kH0rxTuwtYj6mFAz>y$vT}m!^e7CWk z3#;@L4(H;zLiuSGTN3!Wp$mFqG5~AX3)K7T4PX^bJxrNxjm&Lh2jRO|F(qc8zo57m z8)VSKVryvi!~`k%ld{cl$Ky17R_^iFXm;2z;@(2+h6T&2Kkry94&xv*2q%`Ip3L@| zeYS2=78KP-j?@NUO*2sk*S7^XG~kpz9AyONdYGI*yyGC_E(3d+=d7uX@Squ@3wb+? z|7OIY5AR!P@Pt^Cmq*9kr;B%|FtMHIA)MDR9G1omBAc(*_K<#dg)f<(JKw4$wj5YG zDIxyc6reKS$7eXL+*#KCsaxNXH}eaay6^iL@-pCywun#HZOjG;+ExW4SY@9zNFS zRPH8ju9Q-nSaw!aKA#Q#2)w^m;5+8(O8xhV(}tUsShQgEDNH0 zUZf)3?_rOqY%~1O69sxoMQrBNHz>qAo%QwbrK- zvdp8|;_}sJzCYtZzl4g6%(j*%5Bp`^s(=Z<3Pyh-To> zFRj)I(_ZAU=Wd$*H_s)O0i9zl`55FCk)MOBW6sa*w8t{>6422NpaL%-`e$Esr>FY= zY>$l0egB)jo+UoBCg_ji6plPUoPLAe*~=Q`j2p&gk=G|c+^WiLBpp*kYlz5g!FKc% zT>^mt3+XJBL(dXXh$YiLxMT;mdjgi)Q&_R!33qS}m$)NBzQ9`o6xan?RZT0T)+Nyn z=x!|2Z!cbj0HzcoJd1T>216D)j(L})>SpqsM85Hq>o9sNC=uspx8@VsxM_4)!$W}X zGyxUk*KXMwTH4)iOb{Fqo!pU>S0RJek~0^3h6GzPhbZ+bP^&zoO#&E{kQuuMvGz#t z*Z1&Oao4~wCnlokm}O(Zwx7~f3_Ti~3%E zVeG7xWM`u$X~n;^0p44eo|dWlJh23n=h-A4tQ(9fi-}n^n+sw`{IQdQ2iOCF7A=># ze|-4sKSbdA_a4>R$(ZG5_p(#?x&3j2XiR`TR{<0VMD*L8e+?Ovp^bxuA+wRKgW9CK zCbAx8$7g$b@|2Jv_QYt3{)&+3*8frEq7siDsb&F{*? z#np9uV&Z|m{!2IvY6AmVBZJIh^tK>f)GUEe&URdD&*AEsIFNt;%^z!N)y>5D+K? z1v4RFkR6Uz#gK{kB_t#u!%;}6+1V3|ifCgA`MSn)A4bH+Zq8O4_w@8QT%9`_85{FC zu0hf$zF40uR?QUlea>M%;&8h6WNmGY*ZqL-^XJc$l)xiJSDwr|jiN?I<5N$|}{UblRWiVrOUX9~z=$V2Ik=vvG2A z>K`7aVquB9y7GaChi~+|<_`@G#l*q_MjXj*x#b<8thCI`n?P?Co1DXe{sQXU)#`oL z=zk-OLM*uYp*vjA>+93EaU{pOLTH_a&>i)1St9V*jUHmO8d=7K+(L8c69)RYSHE&KPKM;=*NS}dOkX{N&Q7_vA{}9`=Q0%Uba)wqm&;p!HM$Xs z`Kk75WaGpVn){0x5fvK7FK84<8=Y&E6h(L!_YT|RTD;uo$t~-Iz(IQi*fHSz**x7E zCg(3gZ-+q8W};l2IxZ^1 zh0Q5g*Tdyj2z(Hyn!G$P16xJi?CdJaW2O>AYd^$F6+r|gqQ@Jey7KdDZRA7M7AQjI zLYz?yRn|;QCyAF@2vGk-AxcusPCEfeh>S z{pyLnzP+7UjlqFSQmGme0=;& zLZW%CojBsf&;nSr_SV+cj=V8V4bSxsWO+$a*Rry*;o)KGKBHot&Lr<8%QJ z4rW*-))h+N(wT8t^ENkXl5CNxl}oNh;&fd~AFbu0df1IG_565ODuVM!(##g+M>Y@} zxiY>ttijVRNEX&eA^{hDv`^T9VBjCwJV2Rry(TzLHg6ALJ6_@Bp`tCVU>OZ&WCqfx z6Ed(RhNoFei+m3+ye6qzTztRm#Tu63qKjjs5fc`?QrHt>0(to=Bah9=<~s4v&)W5X z8ljp%LOA}(BPymRdPTDQ^-~+=M1_|a9?<>fK{5jxNJ(3vVa~P-oU&@-Fl$4;+ERv6 zIg&LJ)`^mXL(UISpr|!z)pwp%#LNZ-zJ%hHcykbuKf*OpyO?{FoX*M9(l5ZDB~R_! zTpp5$b*L$V{w5-$Tm`do_%mrOuaHK}dtqrTB>5SH3Pjkpk5%DmH;j6)1&91u!GS*5 zP5dtFey6;+Wr=={)TaTn zYvjyqV$|%QchuPxqk@7r7C;2S(cONNiD)Bj6s?2^4UUK?uk^hgn5Nw!H*rB^P~X8n zi_n^Z^^q{3){1>}!9?^&?TJSTp+ba5tU&Y>ee?8HVjw0dv^*PY?K9Y-R#eaY?VE~^ z(LuyRdftkUXH)7-6U_F_lLr^`7qC*fpEr{_ofiJ;y zpjctSt5H!AAgWV}Axh;Y7lO!05OkxFKPM z^=R^Z!^R4Z;R=q*e$|d7pED#cPYMaiDB3g7IWW-GHPAaU(%0GD3%u{OcX)V^hO%Rj zrvL3Q6Dc(*Eh9NS{XjPhGZ{5G86`PAID1F}UQu{xN>WOSYDij!Mu^GL4JeothE?}7 zI|n@*D;zsJ0{eH7E>aX1VFn6ZR#7ktjIkJ-J;F?#MNug2K)#TK^z?{OymhN=8z!X} zfs*lR(&J+Zk9b)Vbc>aGiX7L(kxdI@U?hW?{gl`g=&jb)(J|8ElU3AIXT~Pk*|<0w zs_LBF99^Byj=sVp!yzHWJ&l%Cka;9G+CN0kOvl7fSyX0aXK8DF_-XGsr{}<=<%IcA z=4*@3iTQ)6m6}af6Prxh4Yn)Q&NHvNAI1_3_^quM%cWK7w7OmQ4Qr#22>E^aI(Ll2 zqVIe4^6pGeBjXU`9;rVYdrB}SY)utCehnNSbPWwQ zJOdt=(^K9@I*p%63u_$5V8-)uqI8VtsZrEKf?A+Y@f?Y*$p_6H;>fOCqXNUz(QrM7 zf)Gy;^*1uy-`U<6T#?>XwI5~8Hdk&P`(6+3HJBf^gx8X{dmQRq@(Mljby{ww81>n_&LWLTMwcV@qgh_N9CE|PItahvuxa!ABmyy*HEr#m`JLmajZ3Ya zH^K8=Pd*b}Y$QC=%jcP?j?~hEspaqdKGh%RYL=;-`a@U1+n<$_sI)H~Or5={dAr^0 zusPg3N_ZwwxxUJwomr#zgep*DJFSOKyZs}v2xQtM?p4u!3AEW@n}I5{d85grnhUk~Yyo;j*#Hk0^mD9R$ys7?!!9Y4gvpx&~@0KWQ(Am1fu z?o(rze^`Iif~hRFYx&5RYonVRY6!-g-ssKt@vDa`S7&B7!IC$4!sjoGCZby|-+p|! z@g=t@&Q8N;G;v_5cWu{%UcYlTyGu!FY1Sut_oc4QU5$n<+Hi6Kkp@^e+Uhs?vS3{Vu-=`(BpaAo}==3m<4Z^2ru* zGzoKk@bPQ2Xh_H_DmsSli=c<6yDW?lJeg=ad-lwWT zSGIAU)@6D)rj*QD{-rmHE$*Gh3BZ@+7)W)4K?X1ZU-d`>7Wo=C+jp_=oC9MojsqLC zV4A*~>PTN@TlO}-Cmz98Ae~KAO99b}XN870r*smkVH+NoJ%F>Oq7(YwnQr#CGab@B zbLnF0>~il=hvHzwJ=-WezyK_Aiohaw|0w?BRwGwS8tcsi~2&j^5FRQ`F zrkLQtL$WcoM4wSQzF*O=&84I)cP@NuZ&=qjrlw(v_>yt^?WXC8jc%Ns_UMBrgS_L9 zw+-JNj)!m7f)O!2>H%{a;(H8)77b>2jyTG)xZoQO`vejTPK{sPM0|)ZpU0?DPaEQ` zHuT1hR^6zmPJdPDE5$pe5STV06--mDvXVnK7E#ZKL|n+VxU?t|@X$&}Su~1PI?eiN z5~*p*Iwp5AE24EOSL3z;8cZbvWaLp6(*{8gFYbFhT{bS+FG~C})iw2rXIv#1rFeeS z0)=(Q-_7#lmn0|8M26p5R+1p|2#J{`v`J-7j@Wj0OG|1&dr3skA|_m zt*yPCzL}+ssWY>KP3U85`*~K(Yee*$57UFx?8=yZ+>azO=9RzA8c1M1O4@`^@5x7t z!00WgD>*-G_M{QzqWW&I;(Q>~ChS()lt7plsiU1fGGnpHB^!-Lmf}io_diFzB%xh;BR;P!Yb#sc?`sli9?kK1kF__E-*6os zstDsL*JX88-`4TqwvAK9PLV`0uVy4%uE?|t_vorZfYH1JyU14$_wDe!3DQN@=ojO) z5q<%)H4lTXWzeMBBOUfdP4K>8_PwQ`vyzM+RSO}3OmufFG>y@_d5sBWRQYt*^s^Dg z%h*9iFn#on8*QF+%`~2m%F_Z14_;Rretj=IJzCl$oZhQftBB3KpM)*WjXGg;`n;T1 z&|&k4HcjPibh@T3DkaLNL#cLTRlURf63LYoB`0sTFg~s1L|vHqz6n|(q6defl@QS1 zPf{s+8t6V_G9(fqlBO#=L0-H--}Z<)M|YXIN;f)YVBnS&=wr7Jc|3I72;taZ(u!t+ zd+tY?h&qe*c6V+4=_P3E6vCuo31e*JFn-yJThAfcRR!`3esk+cGLqaVKF&mKY6cah z-$0^aRz0;qHXTvr*SRi6c*^DC7KCK0ns4B%g2Z#n_#dQ%F;&K8Twcn(qobk;UJIo? zr{#8Zd=qhX3G-9g=4`~c`}YY1z<~L@3{;ZemCe@B+Vplh>)Sh++8O_t)QW?4-K403 zJc&1k8^)AH3&hR`Z2ksxk_oUj855VYyG&nJ5@V%-eifvjK0+7 zJlJSkkd#MuITB_pjBM}O-Z4S>eO>U*jW-%f#`goEjM}y-6*GqgA2hIi@| zI|rl&158))|0=z|Tx5R;%;ahEn-2 zig>?HQGfO7VBSeqHj#ZzDEAo#!{{w^b_CIk6NzN!Yplsyf??_p2BNjSmvzs?vXT<0 z4r*#^$8?r63Oqj`aE($ieK6E2qRH~g>@iOHV%0L|e^O8Ho_N62XRxg2Z*KLDXjn>U zWRS87N<_AeOAnE$ps!%neOB-73%7G{~R3QP53luA*PHM}n zF#{;SbU+*vJ%G76eAkZ3Xvdx zq3JvRRH#{)Zh+9oQYqr!oW6`7XG6F^!@v}v0n_`2hqL}s`)OaIomq(ez zAF?XE(K-%|+F@vrUR>Bj*(z|h=_TOoWS;JP5*O<7k=kB1O_dtZf6W{-4&teOR;7DJ ztX<^MZTUnHCbQuLHM0-bJRiLdJCKOme`p|_wmB}BQI!+QELF9Ly0p`YDLWMXj0DO> zMgpx6eB8)e7mA>0GY}1h!@W#Ng0G@sK5uuv48+qX!Yb4D<@Mvs2?^4y%^rwE49z)l zN?~Y7A!XZAw3}E3KTf9z> zL4`BfvH*v~{7M&3rrlZ`}%rd6`{NMhP+4h|GH#xgsBD5x~?8Fg#v zv|GHmi7K!qUaY>V33mHzxFJ8)nigq?vj-kR{}d&v$(>j8g9L-%dz@G0IKm@mErapS zmV_T24|m8iyi@`fNnRg{4!G(0z_ey6za5XBuo;R^C1|?=|7k>C+lq0Mb0)^30&6`9 z+OLkNA6qIQ25>tcfSFLPVe33Eh59|({ECDbJ}Yn@x?R3KWERSJ&M?SUN>rOC&C6sP z^e7~6Coh@vvC z-hDA<2@3t*(Rd+QG1sRc><8A0i^ou4u0XMoXH}MNXA1!wC zi?8eRu?t0LrwA8-kkZa1*W*0*V;aF z4&M#~qXedD*GL_swAV?Xq?g=KgWIBnbnb{U zVjiaT7LgW|Vy~P&$V00aAo3WSZ>>q0Kj0>qL!D}Qz~2x&Cm>xMuWY!b=oZ$Drx8$$ zRLd}lR_DFnR;|p-`;ehVxohBXu_#c%d@HmM6t~~1{E#%f8e4B(A5{5ZG^{z5)cGQg zkWE^g=#2$G9eMau=n9P2Z(0vtbxl^x#%QsBBTpYIx(SYgTXbWl3tW*<@9bOOi<@Dx zA*pL_vWy>IU{vf%g?GHDSh6#$Sl9^@tqk0BsxBuM*L7o(LW-J9Iy4X;A$KR;9~kQ0 z^7d4PVmQRRq%b%)%tF`{W~?@MTcizn+@2H*H8Td>h3gg;KPqIL+K|i5P~^*!%l&5 zjn9uJ^Fp@n+q&Pm0*QPUUGzcN$BUHM5alIi>QdS%g*JT~ z#bl2UUF35L8$0U#w%=H@wj1DZ`Y4aeYgMDkUT{GeWRnYFeHDMiFjqXVTqG^3XZ4Yl z5{M-6o_@i!xtU{6JdXdG7oDi_UTPC&U*^Ly4JD$Me&mxh&uU_IqTYC)j-@!5qvEB< z%#lNC@8CTl!>9|JOSqEsUuT~=8y6|AiYI%EeO`{}qGahLRhYP-W~Q>FFOf_1-FZUW zxGFD4(ey%&Be!~P*xo7U7&rBF&%^MpjNMmjU z^UXPMV-DB>v2ROi+(cC4;7pR@uBBe6%<+949;T+3mtijt-zNgbFtzY%j} z3R~ebRH%UD;a02=EO;;@(RtxSG~o&d?8(P5@)^rZXf!2uxYi1-k|; z_&KtlpSj27Ht%}7x;F{LwyBqOG6)XTzs>2bnl3%^9s@&n z3$IH@ZsGUZOK2|r;^+YC<}4zME^^JzoGOLo71-&oYkD$p>Xc`X`LW@^VD*#-dw40C z+2|0X@hU`aLL3nh-r)@*v+u)NS1ubMCPsfw`nX}EonY&x_o02)937`GlcL|PUS%y3 zNXa`ltRs+pUzSs1ut&v1^!fV7x%4h9DP;d^SQ7T$PE1J-3>*`5mtwb2Cc#}W)SBi7 z{5=b(fW7@uz(AybeG=D@QBY;MbJnUcOGrxHCntNN%^j-r4c7(0uOSA3kpCjOBhLqZ z`iJ};?H!A^P5*WKj|=oaKL8#|kR;sSwD;S)rSUyStdaokkOu1Qowwz#JxhQ_QcPUt zzj2Fcv&_vydBPe5Y_aGFK%m=m{cX9UUbsj7e=-ZKO@EbJ7M=oP`_b@yUdgSNxzp{& zYsP^aY=NW1ZI0b-xofQyAo)8^Y-D4?Y-wk9M|>xo-aoh??#OT3D+V%C{w9``6JrAg z{&qk zMt&&#{gJ%o8b(i{S_0{~ycq$aa#`3t-D{|4^2InHeC@QZxE{${ss(_!w)t?_vX`0oB@_;*p_#C39i z!$vsH1WfBBpb)>VM2^2vnm8LW|0StA<-tnnb*e(GYo58>=$Xk+t>Qrg=tb1w&v!g&Fr*aoC| z8_B;dccM7@1NE&Wj7^>HYxYSA8F$Hc1l}Z&3UCAf{R;9Dn43T4dB?&nh_$KbeGoyw zb&IKLcgPHgf)x`(mxKyE#J_i;=ChyQhd$+wyT2+-3hh#y&8 zcSxkbh2`xZarA!#0DfobPmed;Lfx@MmI>nPf7eg>D`ik(%%lvKZfvb zzWgcI^(S%kvtNk+%6z@w_@5F?f6{BD|0n(5hWM`iKjkp~r02}|o&J7C<9$By9Kyg5jySz{7C2fX-)r>(04~k3S4%6qx_HbzWcrS zQ}WGEsEAkhdI2!;w>ki+IQK#RlyGqia;H!8xxaz{;=PtmhGh+E^8T=Em*hd1Yb>wk)--ICt*p#68!Ut(+basCuC`iVnc_8SYo z1(5C|{V5*s6Dh9ZH>CfJ4%`R(lY9Ip*l^{41N%#Ze>ltUKScbtFxZ+9Sf^XN|}&RY<`@&i?)=_iPi9Mq4q9w)H>2mnruzQEr=p#KNj CnY=^* diff --git a/l4/pkg/libstdc++-headers/include/bits/gthr-posix.h b/l4/pkg/libstdc++-headers/include/bits/gthr-posix.h deleted file mode 100644 index 4c4fdb294..000000000 --- a/l4/pkg/libstdc++-headers/include/bits/gthr-posix.h +++ /dev/null @@ -1,897 +0,0 @@ -/* Threads compatibility routines for libgcc2 and libobjc. */ -/* Compile this one with gcc. */ -/* Copyright (C) 1997, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007 - Free Software Foundation, Inc. - -This file is part of GCC. - -GCC 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, or (at your option) any later -version. - -GCC 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 GCC; see the file COPYING. If not, write to the Free -Software Foundation, 51 Franklin Street, Fifth Floor, Boston, MA -02110-1301, USA. */ - -/* As a special exception, if you link this library with other files, - some of which are compiled with GCC, to produce an executable, - this library does not by itself cause the resulting executable - to be covered by the GNU General Public License. - This exception does not however invalidate any other reasons why - the executable file might be covered by the GNU General Public License. */ - -#ifndef GCC_GTHR_POSIX_H -#define GCC_GTHR_POSIX_H - -/* POSIX threads specific definitions. - Easy, since the interface is just one-to-one mapping. */ - -#define __GTHREADS 1 -#define __GTHREADS_CXX0X 1 - -/* Some implementations of require this to be defined. */ -#if !defined(_REENTRANT) && defined(__osf__) -#define _REENTRANT 1 -#endif - -#ifndef _GNU_SOURCE -# define _GNU_SOURCE 1 -#endif - -#include -#include - -typedef pthread_t __gthread_t; -typedef pthread_key_t __gthread_key_t; -typedef pthread_once_t __gthread_once_t; -typedef pthread_mutex_t __gthread_mutex_t; -typedef pthread_mutex_t __gthread_recursive_mutex_t; -typedef pthread_cond_t __gthread_cond_t; -typedef struct timespec __gthread_time_t; - -/* POSIX like conditional variables are supported. Please look at comments - in gthr.h for details. */ -#define __GTHREAD_HAS_COND 1 - -#define __GTHREAD_MUTEX_INIT PTHREAD_MUTEX_INITIALIZER -#define __GTHREAD_ONCE_INIT PTHREAD_ONCE_INIT -#if defined(PTHREAD_RECURSIVE_MUTEX_INITIALIZER) -#define __GTHREAD_RECURSIVE_MUTEX_INIT PTHREAD_RECURSIVE_MUTEX_INITIALIZER -#elif defined(PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP) -#define __GTHREAD_RECURSIVE_MUTEX_INIT PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP -#else -#define __GTHREAD_RECURSIVE_MUTEX_INIT_FUNCTION __gthread_recursive_mutex_init_function -#endif -#define __GTHREAD_COND_INIT PTHREAD_COND_INITIALIZER -#define __GTHREAD_TIME_INIT {0,0} - -#ifdef _GTHREAD_USE_MUTEX_INIT_FUNC -# undef __GTHREAD_MUTEX_INIT -# define __GTHREAD_MUTEX_INIT_FUNCTION __gthread_mutex_init_function -#endif -#ifdef _GTHREAD_USE_RECURSIVE_MUTEX_INIT_FUNC -# undef __GTHREAD_RECURSIVE_MUTEX_INIT -# undef __GTHREAD_RECURSIVE_MUTEX_INIT_FUNCTION -# define __GTHREAD_RECURSIVE_MUTEX_INIT_FUNCTION __gthread_recursive_mutex_init_function -#endif -#ifdef _GTHREAD_USE_COND_INIT_FUNC -# undef __GTHREAD_COND_INIT -# define __GTHREAD_COND_INIT_FUNCTION __gthread_cond_init_function -#endif - -#if __GXX_WEAK__ && GTHREAD_USE_WEAK -# ifndef __gthrw_pragma -# define __gthrw_pragma(pragma) -# endif -# define __gthrw2(name,name2,type) \ - static __typeof(type) name __attribute__ ((__weakref__(#name2))); \ - __gthrw_pragma(weak type) -# define __gthrw_(name) __gthrw_ ## name -#else -# define __gthrw2(name,name2,type) -# define __gthrw_(name) name -#endif - -/* Typically, __gthrw_foo is a weak reference to symbol foo. */ -#define __gthrw(name) __gthrw2(__gthrw_ ## name,name,name) - -/* On Tru64, /usr/include/pthread.h uses #pragma extern_prefix "__" to - map a subset of the POSIX pthread API to mangled versions of their - names. */ -#if defined(__osf__) && defined(_PTHREAD_USE_MANGLED_NAMES_) -#define __gthrw3(name) __gthrw2(__gthrw_ ## name, __ ## name, name) -__gthrw3(pthread_once) -__gthrw3(pthread_getspecific) -__gthrw3(pthread_setspecific) - -__gthrw3(pthread_create) -__gthrw3(pthread_join) -__gthrw3(pthread_detach) -__gthrw3(pthread_equal) -__gthrw3(pthread_self) -__gthrw3(pthread_cancel) -__gthrw3(sched_yield) - -__gthrw3(pthread_mutex_lock) -__gthrw3(pthread_mutex_trylock) -#if _GTHREAD_USE_MUTEX_TIMEDLOCK -__gthrw3(pthread_mutex_timedlock) -#endif -__gthrw3(pthread_mutex_unlock) -__gthrw3(pthread_mutex_init) -__gthrw3(pthread_mutex_destroy) - -__gthrw3(pthread_cond_init) -__gthrw3(pthread_cond_broadcast) -__gthrw3(pthread_cond_signal) -__gthrw3(pthread_cond_wait) -__gthrw3(pthread_cond_timedwait) -__gthrw3(pthread_cond_destroy) -#else -__gthrw(pthread_once) -__gthrw(pthread_getspecific) -__gthrw(pthread_setspecific) - -__gthrw(pthread_create) -__gthrw(pthread_join) -__gthrw(pthread_equal) -__gthrw(pthread_self) -__gthrw(pthread_detach) -#ifndef __BIONIC__ -__gthrw(pthread_cancel) -#endif -__gthrw(sched_yield) - -__gthrw(pthread_mutex_lock) -__gthrw(pthread_mutex_trylock) -#if _GTHREAD_USE_MUTEX_TIMEDLOCK -__gthrw(pthread_mutex_timedlock) -#endif -__gthrw(pthread_mutex_unlock) -__gthrw(pthread_mutex_init) -__gthrw(pthread_mutex_destroy) - -__gthrw(pthread_cond_init) -__gthrw(pthread_cond_broadcast) -__gthrw(pthread_cond_signal) -__gthrw(pthread_cond_wait) -__gthrw(pthread_cond_timedwait) -__gthrw(pthread_cond_destroy) -#endif - -__gthrw(pthread_key_create) -__gthrw(pthread_key_delete) -__gthrw(pthread_mutexattr_init) -__gthrw(pthread_mutexattr_settype) -__gthrw(pthread_mutexattr_destroy) - - -#if defined(_LIBOBJC) || defined(_LIBOBJC_WEAK) -/* Objective-C. */ -#if defined(__osf__) && defined(_PTHREAD_USE_MANGLED_NAMES_) -__gthrw3(pthread_exit) -#else -__gthrw(pthread_exit) -#endif /* __osf__ && _PTHREAD_USE_MANGLED_NAMES_ */ -#ifdef _POSIX_PRIORITY_SCHEDULING -#ifdef _POSIX_THREAD_PRIORITY_SCHEDULING -__gthrw(sched_get_priority_max) -__gthrw(sched_get_priority_min) -#endif /* _POSIX_THREAD_PRIORITY_SCHEDULING */ -#endif /* _POSIX_PRIORITY_SCHEDULING */ -__gthrw(pthread_attr_destroy) -__gthrw(pthread_attr_init) -__gthrw(pthread_attr_setdetachstate) -#ifdef _POSIX_THREAD_PRIORITY_SCHEDULING -__gthrw(pthread_getschedparam) -__gthrw(pthread_setschedparam) -#endif /* _POSIX_THREAD_PRIORITY_SCHEDULING */ -#endif /* _LIBOBJC || _LIBOBJC_WEAK */ - -#if __GXX_WEAK__ && GTHREAD_USE_WEAK - -/* On Solaris 2.6 up to 9, the libc exposes a POSIX threads interface even if - -pthreads is not specified. The functions are dummies and most return an - error value. However pthread_once returns 0 without invoking the routine - it is passed so we cannot pretend that the interface is active if -pthreads - is not specified. On Solaris 2.5.1, the interface is not exposed at all so - we need to play the usual game with weak symbols. On Solaris 10 and up, a - working interface is always exposed. On FreeBSD 6 and later, libc also - exposes a dummy POSIX threads interface, similar to what Solaris 2.6 up - to 9 does. FreeBSD >= 700014 even provides a pthread_cancel stub in libc, - which means the alternate __gthread_active_p below cannot be used there. */ - -#if defined(__FreeBSD__) || (defined(__sun) && defined(__svr4__)) - -static volatile int __gthread_active = -1; - -static void -__gthread_trigger (void) -{ - __gthread_active = 1; -} - -static inline int -__gthread_active_p (void) -{ - static pthread_mutex_t __gthread_active_mutex = PTHREAD_MUTEX_INITIALIZER; - static pthread_once_t __gthread_active_once = PTHREAD_ONCE_INIT; - - /* Avoid reading __gthread_active twice on the main code path. */ - int __gthread_active_latest_value = __gthread_active; - - /* This test is not protected to avoid taking a lock on the main code - path so every update of __gthread_active in a threaded program must - be atomic with regard to the result of the test. */ - if (__builtin_expect (__gthread_active_latest_value < 0, 0)) - { - if (__gthrw_(pthread_once)) - { - /* If this really is a threaded program, then we must ensure that - __gthread_active has been set to 1 before exiting this block. */ - __gthrw_(pthread_mutex_lock) (&__gthread_active_mutex); - __gthrw_(pthread_once) (&__gthread_active_once, __gthread_trigger); - __gthrw_(pthread_mutex_unlock) (&__gthread_active_mutex); - } - - /* Make sure we'll never enter this block again. */ - if (__gthread_active < 0) - __gthread_active = 0; - - __gthread_active_latest_value = __gthread_active; - } - - return __gthread_active_latest_value != 0; -} - -#else /* neither FreeBSD nor Solaris */ - -static inline int -__gthread_active_p (void) -{ - static void *const __gthread_active_ptr - = __extension__ (void *) &__gthrw_(pthread_cancel); - return __gthread_active_ptr != 0; -} - -#endif /* FreeBSD or Solaris */ - -#else /* not __GXX_WEAK__ */ - -/* Similar to Solaris, HP-UX 11 for PA-RISC provides stubs for pthread - calls in shared flavors of the HP-UX C library. Most of the stubs - have no functionality. The details are described in the "libc cumulative - patch" for each subversion of HP-UX 11. There are two special interfaces - provided for checking whether an application is linked to a pthread - library or not. However, these interfaces aren't available in early - libc versions. We also can't use pthread_once as some libc versions - call the init function. So, we use pthread_create to check whether it - is possible to create a thread or not. The stub implementation returns - the error number ENOSYS. */ - -#if defined(__hppa__) && defined(__hpux__) - -static volatile int __gthread_active = -1; - -static inline int -__gthread_active_p (void) -{ - /* Avoid reading __gthread_active twice on the main code path. */ - int __gthread_active_latest_value = __gthread_active; - size_t __s; - - if (__builtin_expect (__gthread_active_latest_value < 0, 0)) - { - pthread_default_stacksize_np (0, &__s); - __gthread_active = __s ? 1 : 0; - __gthread_active_latest_value = __gthread_active; - } - - return __gthread_active_latest_value != 0; -} - -#else /* not hppa-hpux */ - -static inline int -__gthread_active_p (void) -{ - return 1; -} - -#endif /* hppa-hpux */ - -#endif /* __GXX_WEAK__ */ - -#ifdef _LIBOBJC - -/* This is the config.h file in libobjc/ */ -#include - -#ifdef HAVE_SCHED_H -# include -#endif - -/* Key structure for maintaining thread specific storage */ -static pthread_key_t _objc_thread_storage; -static pthread_attr_t _objc_thread_attribs; - -/* Thread local storage for a single thread */ -static void *thread_local_storage = NULL; - -/* Backend initialization functions */ - -/* Initialize the threads subsystem. */ -static inline int -__gthread_objc_init_thread_system (void) -{ - if (__gthread_active_p ()) - { - /* Initialize the thread storage key. */ - if (__gthrw_(pthread_key_create) (&_objc_thread_storage, NULL) == 0) - { - /* The normal default detach state for threads is - * PTHREAD_CREATE_JOINABLE which causes threads to not die - * when you think they should. */ - if (__gthrw_(pthread_attr_init) (&_objc_thread_attribs) == 0 - && __gthrw_(pthread_attr_setdetachstate) (&_objc_thread_attribs, - PTHREAD_CREATE_DETACHED) == 0) - return 0; - } - } - - return -1; -} - -/* Close the threads subsystem. */ -static inline int -__gthread_objc_close_thread_system (void) -{ - if (__gthread_active_p () - && __gthrw_(pthread_key_delete) (_objc_thread_storage) == 0 - && __gthrw_(pthread_attr_destroy) (&_objc_thread_attribs) == 0) - return 0; - - return -1; -} - -/* Backend thread functions */ - -/* Create a new thread of execution. */ -static inline objc_thread_t -__gthread_objc_thread_detach (void (*func)(void *), void *arg) -{ - objc_thread_t thread_id; - pthread_t new_thread_handle; - - if (!__gthread_active_p ()) - return NULL; - - if (!(__gthrw_(pthread_create) (&new_thread_handle, &_objc_thread_attribs, - (void *) func, arg))) - thread_id = (objc_thread_t) new_thread_handle; - else - thread_id = NULL; - - return thread_id; -} - -/* Set the current thread's priority. */ -static inline int -__gthread_objc_thread_set_priority (int priority) -{ - if (!__gthread_active_p ()) - return -1; - else - { -#ifdef _POSIX_PRIORITY_SCHEDULING -#ifdef _POSIX_THREAD_PRIORITY_SCHEDULING - pthread_t thread_id = __gthrw_(pthread_self) (); - int policy; - struct sched_param params; - int priority_min, priority_max; - - if (__gthrw_(pthread_getschedparam) (thread_id, &policy, ¶ms) == 0) - { - if ((priority_max = __gthrw_(sched_get_priority_max) (policy)) == -1) - return -1; - - if ((priority_min = __gthrw_(sched_get_priority_min) (policy)) == -1) - return -1; - - if (priority > priority_max) - priority = priority_max; - else if (priority < priority_min) - priority = priority_min; - params.sched_priority = priority; - - /* - * The solaris 7 and several other man pages incorrectly state that - * this should be a pointer to policy but pthread.h is universally - * at odds with this. - */ - if (__gthrw_(pthread_setschedparam) (thread_id, policy, ¶ms) == 0) - return 0; - } -#endif /* _POSIX_THREAD_PRIORITY_SCHEDULING */ -#endif /* _POSIX_PRIORITY_SCHEDULING */ - return -1; - } -} - -/* Return the current thread's priority. */ -static inline int -__gthread_objc_thread_get_priority (void) -{ -#ifdef _POSIX_PRIORITY_SCHEDULING -#ifdef _POSIX_THREAD_PRIORITY_SCHEDULING - if (__gthread_active_p ()) - { - int policy; - struct sched_param params; - - if (__gthrw_(pthread_getschedparam) (__gthrw_(pthread_self) (), &policy, ¶ms) == 0) - return params.sched_priority; - else - return -1; - } - else -#endif /* _POSIX_THREAD_PRIORITY_SCHEDULING */ -#endif /* _POSIX_PRIORITY_SCHEDULING */ - return OBJC_THREAD_INTERACTIVE_PRIORITY; -} - -/* Yield our process time to another thread. */ -static inline void -__gthread_objc_thread_yield (void) -{ - if (__gthread_active_p ()) - __gthrw_(sched_yield) (); -} - -/* Terminate the current thread. */ -static inline int -__gthread_objc_thread_exit (void) -{ - if (__gthread_active_p ()) - /* exit the thread */ - __gthrw_(pthread_exit) (&__objc_thread_exit_status); - - /* Failed if we reached here */ - return -1; -} - -/* Returns an integer value which uniquely describes a thread. */ -static inline objc_thread_t -__gthread_objc_thread_id (void) -{ - if (__gthread_active_p ()) - return (objc_thread_t) __gthrw_(pthread_self) (); - else - return (objc_thread_t) 1; -} - -/* Sets the thread's local storage pointer. */ -static inline int -__gthread_objc_thread_set_data (void *value) -{ - if (__gthread_active_p ()) - return __gthrw_(pthread_setspecific) (_objc_thread_storage, value); - else - { - thread_local_storage = value; - return 0; - } -} - -/* Returns the thread's local storage pointer. */ -static inline void * -__gthread_objc_thread_get_data (void) -{ - if (__gthread_active_p ()) - return __gthrw_(pthread_getspecific) (_objc_thread_storage); - else - return thread_local_storage; -} - -/* Backend mutex functions */ - -/* Allocate a mutex. */ -static inline int -__gthread_objc_mutex_allocate (objc_mutex_t mutex) -{ - if (__gthread_active_p ()) - { - mutex->backend = objc_malloc (sizeof (pthread_mutex_t)); - - if (__gthrw_(pthread_mutex_init) ((pthread_mutex_t *) mutex->backend, NULL)) - { - objc_free (mutex->backend); - mutex->backend = NULL; - return -1; - } - } - - return 0; -} - -/* Deallocate a mutex. */ -static inline int -__gthread_objc_mutex_deallocate (objc_mutex_t mutex) -{ - if (__gthread_active_p ()) - { - int count; - - /* - * Posix Threads specifically require that the thread be unlocked - * for __gthrw_(pthread_mutex_destroy) to work. - */ - - do - { - count = __gthrw_(pthread_mutex_unlock) ((pthread_mutex_t *) mutex->backend); - if (count < 0) - return -1; - } - while (count); - - if (__gthrw_(pthread_mutex_destroy) ((pthread_mutex_t *) mutex->backend)) - return -1; - - objc_free (mutex->backend); - mutex->backend = NULL; - } - return 0; -} - -/* Grab a lock on a mutex. */ -static inline int -__gthread_objc_mutex_lock (objc_mutex_t mutex) -{ - if (__gthread_active_p () - && __gthrw_(pthread_mutex_lock) ((pthread_mutex_t *) mutex->backend) != 0) - { - return -1; - } - - return 0; -} - -/* Try to grab a lock on a mutex. */ -static inline int -__gthread_objc_mutex_trylock (objc_mutex_t mutex) -{ - if (__gthread_active_p () - && __gthrw_(pthread_mutex_trylock) ((pthread_mutex_t *) mutex->backend) != 0) - { - return -1; - } - - return 0; -} - -/* Unlock the mutex */ -static inline int -__gthread_objc_mutex_unlock (objc_mutex_t mutex) -{ - if (__gthread_active_p () - && __gthrw_(pthread_mutex_unlock) ((pthread_mutex_t *) mutex->backend) != 0) - { - return -1; - } - - return 0; -} - -/* Backend condition mutex functions */ - -/* Allocate a condition. */ -static inline int -__gthread_objc_condition_allocate (objc_condition_t condition) -{ - if (__gthread_active_p ()) - { - condition->backend = objc_malloc (sizeof (pthread_cond_t)); - - if (__gthrw_(pthread_cond_init) ((pthread_cond_t *) condition->backend, NULL)) - { - objc_free (condition->backend); - condition->backend = NULL; - return -1; - } - } - - return 0; -} - -/* Deallocate a condition. */ -static inline int -__gthread_objc_condition_deallocate (objc_condition_t condition) -{ - if (__gthread_active_p ()) - { - if (__gthrw_(pthread_cond_destroy) ((pthread_cond_t *) condition->backend)) - return -1; - - objc_free (condition->backend); - condition->backend = NULL; - } - return 0; -} - -/* Wait on the condition */ -static inline int -__gthread_objc_condition_wait (objc_condition_t condition, objc_mutex_t mutex) -{ - if (__gthread_active_p ()) - return __gthrw_(pthread_cond_wait) ((pthread_cond_t *) condition->backend, - (pthread_mutex_t *) mutex->backend); - else - return 0; -} - -/* Wake up all threads waiting on this condition. */ -static inline int -__gthread_objc_condition_broadcast (objc_condition_t condition) -{ - if (__gthread_active_p ()) - return __gthrw_(pthread_cond_broadcast) ((pthread_cond_t *) condition->backend); - else - return 0; -} - -/* Wake up one thread waiting on this condition. */ -static inline int -__gthread_objc_condition_signal (objc_condition_t condition) -{ - if (__gthread_active_p ()) - return __gthrw_(pthread_cond_signal) ((pthread_cond_t *) condition->backend); - else - return 0; -} - -#else /* _LIBOBJC */ - -static inline int -__gthread_create (__gthread_t *__threadid, void *(*__func) (void*), - void *__args) -{ - return __gthrw_(pthread_create) (__threadid, NULL, __func, __args); -} - -static inline int -__gthread_join (__gthread_t __threadid, void **__value_ptr) -{ - return __gthrw_(pthread_join) (__threadid, __value_ptr); -} - -static inline int -__gthread_detach (__gthread_t __threadid) -{ - return __gthrw_(pthread_detach) (__threadid); -} - -static inline int -__gthread_equal (__gthread_t __t1, __gthread_t __t2) -{ - return __gthrw_(pthread_equal) (__t1, __t2); -} - -static inline __gthread_t -__gthread_self (void) -{ - return __gthrw_(pthread_self) (); -} - -static inline int -__gthread_yield (void) -{ - return __gthrw_(sched_yield) (); -} - -static inline int -__gthread_once (__gthread_once_t *__once, void (*__func) (void)) -{ - if (__gthread_active_p ()) - return __gthrw_(pthread_once) (__once, __func); - else - return -1; -} - -static inline int -__gthread_key_create (__gthread_key_t *__key, void (*__dtor) (void *)) -{ - return __gthrw_(pthread_key_create) (__key, __dtor); -} - -static inline int -__gthread_key_delete (__gthread_key_t __key) -{ - return __gthrw_(pthread_key_delete) (__key); -} - -static inline void * -__gthread_getspecific (__gthread_key_t __key) -{ - return __gthrw_(pthread_getspecific) (__key); -} - -static inline int -__gthread_setspecific (__gthread_key_t __key, const void *__ptr) -{ - return __gthrw_(pthread_setspecific) (__key, __ptr); -} - -#ifdef _GTHREAD_USE_MUTEX_INIT_FUNC -static inline void -__gthread_mutex_init_function (__gthread_mutex_t *__mutex) -{ - if (__gthread_active_p ()) - __gthrw_(pthread_mutex_init) (__mutex, NULL); -} -#endif - -static inline int -__gthread_mutex_destroy (__gthread_mutex_t *__mutex) -{ - if (__gthread_active_p ()) - return __gthrw_(pthread_mutex_destroy) (__mutex); - else - return 0; -} - -static inline int -__gthread_mutex_lock (__gthread_mutex_t *__mutex) -{ - if (__gthread_active_p ()) - return __gthrw_(pthread_mutex_lock) (__mutex); - else - return 0; -} - -static inline int -__gthread_mutex_trylock (__gthread_mutex_t *__mutex) -{ - if (__gthread_active_p ()) - return __gthrw_(pthread_mutex_trylock) (__mutex); - else - return 0; -} - -#if _GTHREAD_USE_MUTEX_TIMEDLOCK -static inline int -__gthread_mutex_timedlock (__gthread_mutex_t *__mutex, - const __gthread_time_t *__abs_timeout) -{ - if (__gthread_active_p ()) - return __gthrw_(pthread_mutex_timedlock) (__mutex, __abs_timeout); - else - return 0; -} -#endif - -static inline int -__gthread_mutex_unlock (__gthread_mutex_t *__mutex) -{ - if (__gthread_active_p ()) - return __gthrw_(pthread_mutex_unlock) (__mutex); - else - return 0; -} - -#if !defined( PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP) \ - || defined(_GTHREAD_USE_RECURSIVE_MUTEX_INIT_FUNC) -static inline int -__gthread_recursive_mutex_init_function (__gthread_recursive_mutex_t *__mutex) -{ - if (__gthread_active_p ()) - { - pthread_mutexattr_t __attr; - int __r; - - __r = __gthrw_(pthread_mutexattr_init) (&__attr); - if (!__r) - __r = __gthrw_(pthread_mutexattr_settype) (&__attr, - PTHREAD_MUTEX_RECURSIVE); - if (!__r) - __r = __gthrw_(pthread_mutex_init) (__mutex, &__attr); - if (!__r) - __r = __gthrw_(pthread_mutexattr_destroy) (&__attr); - return __r; - } - return 0; -} -#endif - -static inline int -__gthread_recursive_mutex_lock (__gthread_recursive_mutex_t *__mutex) -{ - return __gthread_mutex_lock (__mutex); -} - -static inline int -__gthread_recursive_mutex_trylock (__gthread_recursive_mutex_t *__mutex) -{ - return __gthread_mutex_trylock (__mutex); -} - -#if _GTHREAD_USE_MUTEX_TIMEDLOCK -static inline int -__gthread_recursive_mutex_timedlock (__gthread_recursive_mutex_t *__mutex, - const __gthread_time_t *__abs_timeout) -{ - return __gthread_mutex_timedlock (__mutex, __abs_timeout); -} -#endif - -static inline int -__gthread_recursive_mutex_unlock (__gthread_recursive_mutex_t *__mutex) -{ - return __gthread_mutex_unlock (__mutex); -} - -#ifdef _GTHREAD_USE_COND_INIT_FUNC -static inline void -__gthread_cond_init_function (__gthread_cond_t *__cond) -{ - if (__gthread_active_p ()) - __gthrw_(pthread_cond_init) (__cond, NULL); -} -#endif - -static inline int -__gthread_cond_broadcast (__gthread_cond_t *__cond) -{ - return __gthrw_(pthread_cond_broadcast) (__cond); -} - -static inline int -__gthread_cond_signal (__gthread_cond_t *__cond) -{ - return __gthrw_(pthread_cond_signal) (__cond); -} - -static inline int -__gthread_cond_wait (__gthread_cond_t *__cond, __gthread_mutex_t *__mutex) -{ - return __gthrw_(pthread_cond_wait) (__cond, __mutex); -} - -static inline int -__gthread_cond_timedwait (__gthread_cond_t *__cond, __gthread_mutex_t *__mutex, - const __gthread_time_t *__abs_timeout) -{ - return __gthrw_(pthread_cond_timedwait) (__cond, __mutex, __abs_timeout); -} - -static inline int -__gthread_cond_wait_recursive (__gthread_cond_t *__cond, - __gthread_recursive_mutex_t *__mutex) -{ - return __gthread_cond_wait (__cond, __mutex); -} - -static inline int -__gthread_cond_timedwait_recursive (__gthread_cond_t *__cond, - __gthread_recursive_mutex_t *__mutex, - const __gthread_time_t *__abs_timeout) -{ - return __gthread_cond_timedwait (__cond, __mutex, __abs_timeout); -} - -static inline int -__gthread_cond_destroy (__gthread_cond_t* __cond) -{ - return __gthrw_(pthread_cond_destroy) (__cond); -} - -#endif /* _LIBOBJC */ - -#endif /* ! GCC_GTHR_POSIX_H */ diff --git a/l4/pkg/libstdc++-headers/include/bits/gthr-single.h b/l4/pkg/libstdc++-headers/include/bits/gthr-single.h deleted file mode 100644 index 14718bd32..000000000 --- a/l4/pkg/libstdc++-headers/include/bits/gthr-single.h +++ /dev/null @@ -1,294 +0,0 @@ -/* Threads compatibility routines for libgcc2 and libobjc. */ -/* Compile this one with gcc. */ -/* Copyright (C) 1997, 1999, 2000, 2004 Free Software Foundation, Inc. - -This file is part of GCC. - -GCC 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, or (at your option) any later -version. - -GCC 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 GCC; see the file COPYING. If not, write to the Free -Software Foundation, 51 Franklin Street, Fifth Floor, Boston, MA -02110-1301, USA. */ - -/* As a special exception, if you link this library with other files, - some of which are compiled with GCC, to produce an executable, - this library does not by itself cause the resulting executable - to be covered by the GNU General Public License. - This exception does not however invalidate any other reasons why - the executable file might be covered by the GNU General Public License. */ - -#ifndef GCC_GTHR_SINGLE_H -#define GCC_GTHR_SINGLE_H - -/* Just provide compatibility for mutex handling. */ - -typedef int __gthread_key_t; -typedef int __gthread_once_t; -typedef int __gthread_mutex_t; -typedef int __gthread_recursive_mutex_t; - -#define __GTHREAD_ONCE_INIT 0 -#define __GTHREAD_MUTEX_INIT 0 -#define __GTHREAD_RECURSIVE_MUTEX_INIT 0 - -#define UNUSED __attribute__((unused)) - -#ifdef _LIBOBJC - -/* Thread local storage for a single thread */ -static void *thread_local_storage = NULL; - -/* Backend initialization functions */ - -/* Initialize the threads subsystem. */ -static inline int -__gthread_objc_init_thread_system (void) -{ - /* No thread support available */ - return -1; -} - -/* Close the threads subsystem. */ -static inline int -__gthread_objc_close_thread_system (void) -{ - /* No thread support available */ - return -1; -} - -/* Backend thread functions */ - -/* Create a new thread of execution. */ -static inline objc_thread_t -__gthread_objc_thread_detach (void (* func)(void *), void * arg UNUSED) -{ - /* No thread support available */ - return NULL; -} - -/* Set the current thread's priority. */ -static inline int -__gthread_objc_thread_set_priority (int priority UNUSED) -{ - /* No thread support available */ - return -1; -} - -/* Return the current thread's priority. */ -static inline int -__gthread_objc_thread_get_priority (void) -{ - return OBJC_THREAD_INTERACTIVE_PRIORITY; -} - -/* Yield our process time to another thread. */ -static inline void -__gthread_objc_thread_yield (void) -{ - return; -} - -/* Terminate the current thread. */ -static inline int -__gthread_objc_thread_exit (void) -{ - /* No thread support available */ - /* Should we really exit the program */ - /* exit (&__objc_thread_exit_status); */ - return -1; -} - -/* Returns an integer value which uniquely describes a thread. */ -static inline objc_thread_t -__gthread_objc_thread_id (void) -{ - /* No thread support, use 1. */ - return (objc_thread_t) 1; -} - -/* Sets the thread's local storage pointer. */ -static inline int -__gthread_objc_thread_set_data (void *value) -{ - thread_local_storage = value; - return 0; -} - -/* Returns the thread's local storage pointer. */ -static inline void * -__gthread_objc_thread_get_data (void) -{ - return thread_local_storage; -} - -/* Backend mutex functions */ - -/* Allocate a mutex. */ -static inline int -__gthread_objc_mutex_allocate (objc_mutex_t mutex UNUSED) -{ - return 0; -} - -/* Deallocate a mutex. */ -static inline int -__gthread_objc_mutex_deallocate (objc_mutex_t mutex UNUSED) -{ - return 0; -} - -/* Grab a lock on a mutex. */ -static inline int -__gthread_objc_mutex_lock (objc_mutex_t mutex UNUSED) -{ - /* There can only be one thread, so we always get the lock */ - return 0; -} - -/* Try to grab a lock on a mutex. */ -static inline int -__gthread_objc_mutex_trylock (objc_mutex_t mutex UNUSED) -{ - /* There can only be one thread, so we always get the lock */ - return 0; -} - -/* Unlock the mutex */ -static inline int -__gthread_objc_mutex_unlock (objc_mutex_t mutex UNUSED) -{ - return 0; -} - -/* Backend condition mutex functions */ - -/* Allocate a condition. */ -static inline int -__gthread_objc_condition_allocate (objc_condition_t condition UNUSED) -{ - return 0; -} - -/* Deallocate a condition. */ -static inline int -__gthread_objc_condition_deallocate (objc_condition_t condition UNUSED) -{ - return 0; -} - -/* Wait on the condition */ -static inline int -__gthread_objc_condition_wait (objc_condition_t condition UNUSED, - objc_mutex_t mutex UNUSED) -{ - return 0; -} - -/* Wake up all threads waiting on this condition. */ -static inline int -__gthread_objc_condition_broadcast (objc_condition_t condition UNUSED) -{ - return 0; -} - -/* Wake up one thread waiting on this condition. */ -static inline int -__gthread_objc_condition_signal (objc_condition_t condition UNUSED) -{ - return 0; -} - -#else /* _LIBOBJC */ - -static inline int -__gthread_active_p (void) -{ - return 0; -} - -static inline int -__gthread_once (__gthread_once_t *__once UNUSED, void (*__func) (void) UNUSED) -{ - return 0; -} - -static inline int UNUSED -__gthread_key_create (__gthread_key_t *__key UNUSED, void (*__func) (void *) UNUSED) -{ - return 0; -} - -static int UNUSED -__gthread_key_delete (__gthread_key_t __key UNUSED) -{ - return 0; -} - -static inline void * -__gthread_getspecific (__gthread_key_t __key UNUSED) -{ - return 0; -} - -static inline int -__gthread_setspecific (__gthread_key_t __key UNUSED, const void *__v UNUSED) -{ - return 0; -} - -static inline int -__gthread_mutex_destroy (__gthread_mutex_t *__mutex UNUSED) -{ - return 0; -} - -static inline int -__gthread_mutex_lock (__gthread_mutex_t *__mutex UNUSED) -{ - return 0; -} - -static inline int -__gthread_mutex_trylock (__gthread_mutex_t *__mutex UNUSED) -{ - return 0; -} - -static inline int -__gthread_mutex_unlock (__gthread_mutex_t *__mutex UNUSED) -{ - return 0; -} - -static inline int -__gthread_recursive_mutex_lock (__gthread_recursive_mutex_t *__mutex) -{ - return __gthread_mutex_lock (__mutex); -} - -static inline int -__gthread_recursive_mutex_trylock (__gthread_recursive_mutex_t *__mutex) -{ - return __gthread_mutex_trylock (__mutex); -} - -static inline int -__gthread_recursive_mutex_unlock (__gthread_recursive_mutex_t *__mutex) -{ - return __gthread_mutex_unlock (__mutex); -} - -#endif /* _LIBOBJC */ - -#undef UNUSED - -#endif /* ! GCC_GTHR_SINGLE_H */ diff --git a/l4/pkg/libstdc++-headers/include/bits/gthr.h b/l4/pkg/libstdc++-headers/include/bits/gthr.h deleted file mode 100644 index 7368c255d..000000000 --- a/l4/pkg/libstdc++-headers/include/bits/gthr.h +++ /dev/null @@ -1,176 +0,0 @@ -/* Threads compatibility routines for libgcc2. */ -/* Compile this one with gcc. */ -/* Copyright (C) 1997, 1998, 2004 Free Software Foundation, Inc. - -This file is part of GCC. - -GCC 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, or (at your option) any later -version. - -GCC 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 GCC; see the file COPYING. If not, write to the Free -Software Foundation, 51 Franklin Street, Fifth Floor, Boston, MA -02110-1301, USA. */ - -/* As a special exception, if you link this library with other files, - some of which are compiled with GCC, to produce an executable, - this library does not by itself cause the resulting executable - to be covered by the GNU General Public License. - This exception does not however invalidate any other reasons why - the executable file might be covered by the GNU General Public License. */ - -#ifndef GCC_GTHR_H -#define GCC_GTHR_H - -#ifndef HIDE_EXPORTS -#pragma GCC visibility push(default) -#endif - -/* If this file is compiled with threads support, it must - #define __GTHREADS 1 - to indicate that threads support is present. Also it has define - function - int __gthread_active_p () - that returns 1 if thread system is active, 0 if not. - - The threads interface must define the following types: - __gthread_key_t - __gthread_once_t - __gthread_mutex_t - __gthread_recursive_mutex_t - - The threads interface must define the following macros: - - __GTHREAD_ONCE_INIT - to initialize __gthread_once_t - __GTHREAD_MUTEX_INIT - to initialize __gthread_mutex_t to get a fast - non-recursive mutex. - __GTHREAD_MUTEX_INIT_FUNCTION - some systems can't initialize a mutex without a - function call. On such systems, define this to a - function which looks like this: - void __GTHREAD_MUTEX_INIT_FUNCTION (__gthread_mutex_t *) - Don't define __GTHREAD_MUTEX_INIT in this case - __GTHREAD_RECURSIVE_MUTEX_INIT - __GTHREAD_RECURSIVE_MUTEX_INIT_FUNCTION - as above, but for a recursive mutex. - - The threads interface must define the following static functions: - - int __gthread_once (__gthread_once_t *once, void (*func) ()) - - int __gthread_key_create (__gthread_key_t *keyp, void (*dtor) (void *)) - int __gthread_key_delete (__gthread_key_t key) - - void *__gthread_getspecific (__gthread_key_t key) - int __gthread_setspecific (__gthread_key_t key, const void *ptr) - - int __gthread_mutex_destroy (__gthread_mutex_t *mutex); - - int __gthread_mutex_lock (__gthread_mutex_t *mutex); - int __gthread_mutex_trylock (__gthread_mutex_t *mutex); - int __gthread_mutex_unlock (__gthread_mutex_t *mutex); - - int __gthread_recursive_mutex_lock (__gthread_recursive_mutex_t *mutex); - int __gthread_recursive_mutex_trylock (__gthread_recursive_mutex_t *mutex); - int __gthread_recursive_mutex_unlock (__gthread_recursive_mutex_t *mutex); - - The following are supported in POSIX threads only. They are required to - fix a deadlock in static initialization inside libsupc++. The header file - gthr-posix.h defines a symbol __GTHREAD_HAS_COND to signify that these extra - features are supported. - - Types: - __gthread_cond_t - - Macros: - __GTHREAD_COND_INIT - __GTHREAD_COND_INIT_FUNCTION - - Interface: - int __gthread_cond_broadcast (__gthread_cond_t *cond); - int __gthread_cond_wait (__gthread_cond_t *cond, __gthread_mutex_t *mutex); - int __gthread_cond_wait_recursive (__gthread_cond_t *cond, - __gthread_recursive_mutex_t *mutex); - - All functions returning int should return zero on success or the error - number. If the operation is not supported, -1 is returned. - - If the following are also defined, you should - #define __GTHREADS_CXX0X 1 - to enable the c++0x thread library. - - Types: - __gthread_t - __gthread_time_t - - Interface: - int __gthread_create (__gthread_t *thread, void *(*func) (void*), - void *args); - int __gthread_join (__gthread_t thread, void **value_ptr); - int __gthread_detach (__gthread_t thread); - int __gthread_equal (__gthread_t t1, __gthread_t t2); - __gthread_t __gthread_self (void); - int __gthread_yield (void); - - int __gthread_mutex_timedlock (__gthread_mutex_t *m, - const __gthread_time_t *abs_timeout); - int __gthread_recursive_mutex_timedlock (__gthread_recursive_mutex_t *m, - const __gthread_time_t *abs_time); - - int __gthread_cond_signal (__gthread_cond_t *cond); - int __gthread_cond_timedwait (__gthread_cond_t *cond, - __gthread_mutex_t *mutex, - const __gthread_time_t *abs_timeout); - int __gthread_cond_timedwait_recursive (__gthread_cond_t *cond, - __gthread_recursive_mutex_t *mutex, - const __gthread_time_t *abs_time) - -*/ -#if __GXX_WEAK__ -/* The pe-coff weak support isn't fully compatible to ELF's weak. - For static libraries it might would work, but as we need to deal - with shared versions too, we disable it for mingw-targets. */ -#ifndef _GLIBCXX_GTHREAD_USE_WEAK -#define _GLIBCXX_GTHREAD_USE_WEAK 1 -#endif - -#ifndef GTHREAD_USE_WEAK -#define GTHREAD_USE_WEAK 1 -#endif -#endif - -/* Check first for thread specific defines. */ -#if defined (_GLIBCXX___tpf_GLIBCXX___) -#include -#elif _GLIBCXX__PTHREADS -#include -#elif _GLIBCXX__PTHREADS95 -#include -#elif _GLIBCXX__DCE_THREADS -#include -#elif _GLIBCXX__SOLARIS_THREADS -#include - -/* Include GTHREAD_FILE if one is defined. */ -#elif defined(_GLIBCXX_HAVE_GTHR_DEFAULT) -#include - -/* Fallback to single thread definitions. */ -#else -#include -#endif - -#ifndef HIDE_EXPORTS -#pragma GCC visibility pop -#endif - -#endif /* ! GCC_GTHR_H */ diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/Makefile.am b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/Makefile.am deleted file mode 100644 index d53ae229b..000000000 --- a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/Makefile.am +++ /dev/null @@ -1,235 +0,0 @@ -## Makefile for the doc subdirectory of the GNU C++ Standard library. -## -## Copyright (C) 2008, 2009 Free Software Foundation, Inc. -## -## This file is part of the libstdc++ version 3 distribution. -## Process this file with automake to produce Makefile.in. - -## This file is part of the GNU ISO C++ Library. 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 3, 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 General Public License for more details. - -## You should have received a copy of the GNU General Public License along -## with this library; see the file COPYING3. If not see -## . - -include $(top_srcdir)/fragment.am - - -# Doxygen configuration -# Assumes doxygen, graphviz (with dot) installed -doc_doxygen_script=${top_srcdir}/scripts/run_doxygen -doc-html-doxygen: - -(srcdir=`cd ${top_srcdir}; ${PWD_COMMAND}`; \ - builddir=`cd ..; ${PWD_COMMAND}`; \ - ${SHELL} ${doc_doxygen_script} \ - --host_alias=${host_alias} --mode=html $${srcdir} $${builddir}) - -doc-man-doxygen: - -(srcdir=`cd ${top_srcdir}; ${PWD_COMMAND}`; \ - builddir=`cd ..; ${PWD_COMMAND}`; \ - ${SHELL} ${doc_doxygen_script} \ - --host_alias=${host_alias} --mode=man $${srcdir} $${builddir}) - -doc-xml-doxygen: - -(srcdir=`cd ${top_srcdir}; ${PWD_COMMAND}`; \ - builddir=`cd ..; ${PWD_COMMAND}`; \ - ${SHELL} ${doc_doxygen_script} \ - --host_alias=${host_alias} --mode=xml $${srcdir} $${builddir}) - -doxygen_xmldir = ${glibcxx_builddir}/doc/doxygen/xml -doc-xml-doxygen-single: doc-xml-doxygen - @echo "Generating doxygen xml single file..." - $(XSLTPROC) ${doxygen_xmldir}/combine.xslt ${doxygen_xmldir}/spine.xml > ${doxygen_xmldir}/all.xml; - - -# Performance doc and graph configuration. -# Assumes pychart, beautiful soup installed. -# Generates the plots and graphs for performance testing. -doc_performance_script=${top_srcdir}/scripts/make_graphs.py -doc-html-performance: - -@(chmod + ${doc_performance_script}; \ - ${doc_performance_script} ${top_srcdir} \ - ${glibcxx_builddir}/testsuite \ - ${top_srcdir}/testsuite/data/make_graph_htmls.xml \ - ${top_srcdir}/testsuite/data/make_graph_test_infos.xml local g++) - - -# Docbook configuration. -# Assumes -# libxslt -# docbook-style-xsl -# emacs-nxml-mode -# xmlto passivetex -xml_srcdir = ${glibcxx_srcdir}/doc/xml -xml_sources = \ - ${xml_srcdir}/spine.xml \ - ${xml_srcdir}/authors.xml \ - ${xml_srcdir}/manual/abi.xml \ - ${xml_srcdir}/manual/algorithms.xml \ - ${xml_srcdir}/manual/allocator.xml \ - ${xml_srcdir}/manual/auto_ptr.xml \ - ${xml_srcdir}/manual/backwards_compatibility.xml \ - ${xml_srcdir}/manual/bitmap_allocator.xml \ - ${xml_srcdir}/manual/build_hacking.xml \ - ${xml_srcdir}/manual/codecvt.xml \ - ${xml_srcdir}/manual/concurrency.xml \ - ${xml_srcdir}/manual/configure.xml \ - ${xml_srcdir}/manual/containers.xml \ - ${xml_srcdir}/manual/ctype.xml \ - ${xml_srcdir}/manual/debug_mode.xml \ - ${xml_srcdir}/manual/debug.xml \ - ${xml_srcdir}/manual/diagnostics.xml \ - ${xml_srcdir}/manual/evolution.xml \ - ${xml_srcdir}/manual/extensions.xml \ - ${xml_srcdir}/manual/internals.xml \ - ${xml_srcdir}/manual/intro.xml \ - ${xml_srcdir}/manual/io.xml \ - ${xml_srcdir}/manual/iterators.xml \ - ${xml_srcdir}/manual/locale.xml \ - ${xml_srcdir}/manual/localization.xml \ - ${xml_srcdir}/manual/messages.xml \ - ${xml_srcdir}/manual/mt_allocator.xml \ - ${xml_srcdir}/manual/numerics.xml \ - ${xml_srcdir}/manual/parallel_mode.xml \ - ${xml_srcdir}/manual/prerequisites.xml \ - ${xml_srcdir}/manual/internals.xml \ - ${xml_srcdir}/manual/shared_ptr.xml \ - ${xml_srcdir}/manual/spine.xml \ - ${xml_srcdir}/manual/status_cxx1998.xml \ - ${xml_srcdir}/manual/status_cxx200x.xml \ - ${xml_srcdir}/manual/status_cxxtr1.xml \ - ${xml_srcdir}/manual/strings.xml \ - ${xml_srcdir}/manual/support.xml \ - ${xml_srcdir}/manual/test.xml \ - ${xml_srcdir}/manual/using.xml \ - ${xml_srcdir}/manual/utilities.xml \ - ${xml_srcdir}/manual/appendix_free.xml \ - ${xml_srcdir}/manual/appendix_contributing.xml \ - ${xml_srcdir}/manual/appendix_porting.xml \ - ${xml_srcdir}/api.xml \ - ${xml_srcdir}/faq.xml - -xml_sources_extra = \ - ${xml_srcdir}/gnu/fdl-1.2.xml \ - ${xml_srcdir}/gnu/gpl-2.0.xml - -xml_noinst = \ - ${xml_srcdir}/book.txml \ - ${xml_srcdir}/chapter.txml \ - ${xml_srcdir}/class.txml - - -XSLTPROC = xsltproc -XSLTPROC_FLAGS = --nonet --xinclude -XSL_STYLE_DIR = /usr/share/sgml/docbook/xsl-stylesheets -XSL_FO_STYLE = $(XSL_STYLE_DIR)/fo/docbook.xsl -XSL_HTML_STYLE = $(XSL_STYLE_DIR)/xhtml/chunk.xsl -#XSL_HTML_SINGLE_STYLE = $(XSL_STYLE_DIR)/xhtml/onechunk.xsl -XSL_HTML_SINGLE_STYLE = $(XSL_STYLE_DIR)/xhtml/docbook.xsl - -${glibcxx_builddir}/doc/html: - mkdir ${glibcxx_builddir}/doc/html - -${glibcxx_builddir}/doc/pdf: - mkdir ${glibcxx_builddir}/doc/pdf - -${glibcxx_builddir}/doc/fo: - mkdir ${glibcxx_builddir}/doc/fo - -${glibcxx_builddir}/doc/xml: - mkdir ${glibcxx_builddir}/doc/xml - -# Validate existing XML structure. -XMLLINT = xmllint -#LINT_FLAGS = --debug --nonet --xinclude --nsclean --postvalid --nowarning -#LINT_FLAGS = --noblanks --noout --xinclude --postvalid --noent -LINT_FLAGS = --postvalid --debug --xinclude --noent --noblanks --nonet --noout -VALID_FLAGS = --dtdvalid http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd -XMLLINT_FLAGS = $(LINT_FLAGS) $(VALID_FLAGS) -doc-xml-validate: $(xml_sources) - @echo "Generating XML validation log..." - $(XMLLINT) $(XMLLINT_FLAGS) ${top_srcdir}/doc/xml/spine.xml - -doc-xml-single: $(xml_sources) ${glibcxx_builddir}/doc/xml - @echo "Generating XML single..." - $(XMLLINT) --xinclude --noent --noblanks \ - -o ${glibcxx_builddir}/doc/xml/spine-single.xml \ - ${top_srcdir}/doc/xml/spine.xml - -# HTML, index plus chapters -doc-html: $(xml_sources) ${glibcxx_builddir}/doc/html - @echo "Generating html files..." - $(XSLTPROC) $(XSLTPROC_FLAGS) -o ${glibcxx_builddir}/doc/html/ \ - $(XSL_HTML_STYLE) ${top_srcdir}/doc/xml/spine.xml - -# HTML, all one page -doc-html-single: $(xml_sources) ${glibcxx_builddir}/doc/html - @echo "Generating html single file..." - $(XSLTPROC) $(XSLTPROC_FLAGS) -o ${glibcxx_builddir}/doc/html/ \ - $(XSL_HTML_SINGLE_STYLE) ${top_srcdir}/doc/xml/spine.xml - -# FO -doc-fo: $(xml_sources) ${glibcxx_builddir}/doc/fo - @echo "Generating FO files..." - $(XSLTPROC) $(XSLTPROC_FLAGS) -o ${glibcxx_builddir}/doc/fo/spine.fo \ - $(XSL_FO_STYLE) ${top_srcdir}/doc/xml/spine.xml - -# PDF -# Points to current best xml to PDF generation process. -doc-pdf: doc-pdf-prince - -# PDF 1 -# fop -FOP = fop -FOP_FLAGS = -d -r -doc-pdf-fop-xml: $(xml_sources) ${glibcxx_builddir}/doc/pdf - @echo "Generating pdf fop files from xml..." - $(FOP) $(FOP_FLAGS) -xml ${top_srcdir}/doc/xml/spine.xml \ - -xsl $(XSL_FO_STYLE) -pdf ${glibcxx_builddir}/doc/pdf/spine.pdf - -doc-pdf-fop-fo: $(xml_sources) ${glibcxx_builddir}/doc/pdf doc-fo - @echo "Generating pdf fop files from fo..." - $(FOP) $(FOP_FLAGS) -fo ${glibcxx_builddir}/doc/fo/spine.fo \ - -pdf ${glibcxx_builddir}/doc/pdf/spine.pdf - -# PDF 2 -# xmlto -XML2PDF = xmlto -XML2PDF_FLAGS = -v pdf --skip-validation -o pdf -doc-pdf-xmlto: $(xml_sources) ${glibcxx_builddir}/doc/pdf - @echo "Generating pdf xmlto files..." - $(XML2PDF) $(XML2PDF_FLAGS) ${top_srcdir}/doc/xml/spine.xml - -# PDF 3 -# xmlroff -XMLROFF = xmlroff -XMLROFF_FLAGS = --format=pdf --backend=cairo --warn=1 --debug=1 --continue -doc-pdf-xmlroff: $(xml_sources) doc-fo - @echo "Generating pdf xmlroff files..." - $(XMLROFF) $(XMLROFF_FLAGS) ${glibcxx_builddir}/doc/fo/spine.fo - -# PDF 4 -# prince -PRINCE = prince -PRINCE_FLAGS = --log prince.log -o pdf/spine.pdf -doc-pdf-prince: $(xml_sources) ${glibcxx_builddir}/doc/pdf - @echo "Generating pdf prince files..." - $(PRINCE) $(PRINCE_FLAGS) ${top_srcdir}/doc/xml/spine.xml - - -.PHONY: doc-doxygen-html doc-doxygen-man doc-performance - -# By adding these files here, automake will remove them for 'make clean' -CLEANFILES = *.log - -# To remove directories. -clean-local: - rm -rf man html pdf fo doxygen xml diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/Makefile.in b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/Makefile.in deleted file mode 100644 index 321075058..000000000 --- a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/Makefile.in +++ /dev/null @@ -1,661 +0,0 @@ -# Makefile.in generated by automake 1.9.6 from Makefile.am. -# @configure_input@ - -# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, -# 2003, 2004, 2005 Free Software Foundation, Inc. -# This Makefile.in is free software; the Free Software Foundation -# gives unlimited permission to copy and/or distribute it, -# with or without modifications, as long as this notice is preserved. - -# This program is distributed in the hope that it will be useful, -# but WITHOUT ANY WARRANTY, to the extent permitted by law; without -# even the implied warranty of MERCHANTABILITY or FITNESS FOR A -# PARTICULAR PURPOSE. - -@SET_MAKE@ -srcdir = @srcdir@ -top_srcdir = @top_srcdir@ -VPATH = @srcdir@ -pkgdatadir = $(datadir)/@PACKAGE@ -pkglibdir = $(libdir)/@PACKAGE@ -pkgincludedir = $(includedir)/@PACKAGE@ -top_builddir = .. -am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd -INSTALL = @INSTALL@ -install_sh_DATA = $(install_sh) -c -m 644 -install_sh_PROGRAM = $(install_sh) -c -install_sh_SCRIPT = $(install_sh) -c -INSTALL_HEADER = $(INSTALL_DATA) -transform = $(program_transform_name) -NORMAL_INSTALL = : -PRE_INSTALL = : -POST_INSTALL = : -NORMAL_UNINSTALL = : -PRE_UNINSTALL = : -POST_UNINSTALL = : -build_triplet = @build@ -host_triplet = @host@ -target_triplet = @target@ -DIST_COMMON = $(srcdir)/Makefile.am $(srcdir)/Makefile.in \ - $(top_srcdir)/fragment.am -subdir = doc -ACLOCAL_M4 = $(top_srcdir)/aclocal.m4 -am__aclocal_m4_deps = $(top_srcdir)/../config/enable.m4 \ - $(top_srcdir)/../config/futex.m4 \ - $(top_srcdir)/../config/iconv.m4 \ - $(top_srcdir)/../config/lead-dot.m4 \ - $(top_srcdir)/../config/lib-ld.m4 \ - $(top_srcdir)/../config/lib-link.m4 \ - $(top_srcdir)/../config/lib-prefix.m4 \ - $(top_srcdir)/../config/multi.m4 \ - $(top_srcdir)/../config/no-executables.m4 \ - $(top_srcdir)/../config/override.m4 \ - $(top_srcdir)/../config/proginstall.m4 \ - $(top_srcdir)/../config/stdint.m4 \ - $(top_srcdir)/../config/unwind_ipinfo.m4 \ - $(top_srcdir)/../libtool.m4 $(top_srcdir)/../ltoptions.m4 \ - $(top_srcdir)/../ltsugar.m4 $(top_srcdir)/../ltversion.m4 \ - $(top_srcdir)/../lt~obsolete.m4 $(top_srcdir)/crossconfig.m4 \ - $(top_srcdir)/linkage.m4 $(top_srcdir)/acinclude.m4 \ - $(top_srcdir)/../config/tls.m4 $(top_srcdir)/configure.ac -am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \ - $(ACLOCAL_M4) -CONFIG_HEADER = $(top_builddir)/config.h -CONFIG_CLEAN_FILES = -depcomp = -am__depfiles_maybe = -SOURCES = -DIST_SOURCES = -DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST) -ABI_TWEAKS_SRCDIR = @ABI_TWEAKS_SRCDIR@ -ACLOCAL = @ACLOCAL@ -ALLOCATOR_H = @ALLOCATOR_H@ -ALLOCATOR_NAME = @ALLOCATOR_NAME@ -AMTAR = @AMTAR@ -AR = @AR@ -AS = @AS@ -ATOMICITY_SRCDIR = @ATOMICITY_SRCDIR@ -ATOMIC_FLAGS = @ATOMIC_FLAGS@ -ATOMIC_WORD_SRCDIR = @ATOMIC_WORD_SRCDIR@ -AUTOCONF = @AUTOCONF@ -AUTOHEADER = @AUTOHEADER@ -AUTOMAKE = @AUTOMAKE@ -AWK = @AWK@ -BASIC_FILE_CC = @BASIC_FILE_CC@ -BASIC_FILE_H = @BASIC_FILE_H@ -CC = @CC@ -CCODECVT_CC = @CCODECVT_CC@ -CCOLLATE_CC = @CCOLLATE_CC@ -CCTYPE_CC = @CCTYPE_CC@ -CFLAGS = @CFLAGS@ -CLOCALE_CC = @CLOCALE_CC@ -CLOCALE_H = @CLOCALE_H@ -CLOCALE_INTERNAL_H = @CLOCALE_INTERNAL_H@ -CMESSAGES_CC = @CMESSAGES_CC@ -CMESSAGES_H = @CMESSAGES_H@ -CMONEY_CC = @CMONEY_CC@ -CNUMERIC_CC = @CNUMERIC_CC@ -CPP = @CPP@ -CPPFLAGS = @CPPFLAGS@ -CPU_DEFINES_SRCDIR = @CPU_DEFINES_SRCDIR@ -CSTDIO_H = @CSTDIO_H@ -CTIME_CC = @CTIME_CC@ -CTIME_H = @CTIME_H@ -CXX = @CXX@ -CXXCPP = @CXXCPP@ -CXXFLAGS = @CXXFLAGS@ -CYGPATH_W = @CYGPATH_W@ -C_INCLUDE_DIR = @C_INCLUDE_DIR@ -DEBUG_FLAGS = @DEBUG_FLAGS@ -DEFS = @DEFS@ -DSYMUTIL = @DSYMUTIL@ -DUMPBIN = @DUMPBIN@ -ECHO_C = @ECHO_C@ -ECHO_N = @ECHO_N@ -ECHO_T = @ECHO_T@ -EGREP = @EGREP@ -ENABLE_PARALLEL_FALSE = @ENABLE_PARALLEL_FALSE@ -ENABLE_PARALLEL_TRUE = @ENABLE_PARALLEL_TRUE@ -ENABLE_SYMVERS_DARWIN_FALSE = @ENABLE_SYMVERS_DARWIN_FALSE@ -ENABLE_SYMVERS_DARWIN_TRUE = @ENABLE_SYMVERS_DARWIN_TRUE@ -ENABLE_SYMVERS_FALSE = @ENABLE_SYMVERS_FALSE@ -ENABLE_SYMVERS_GNU_FALSE = @ENABLE_SYMVERS_GNU_FALSE@ -ENABLE_SYMVERS_GNU_NAMESPACE_FALSE = @ENABLE_SYMVERS_GNU_NAMESPACE_FALSE@ -ENABLE_SYMVERS_GNU_NAMESPACE_TRUE = @ENABLE_SYMVERS_GNU_NAMESPACE_TRUE@ -ENABLE_SYMVERS_GNU_TRUE = @ENABLE_SYMVERS_GNU_TRUE@ -ENABLE_SYMVERS_TRUE = @ENABLE_SYMVERS_TRUE@ -ENABLE_VISIBILITY_FALSE = @ENABLE_VISIBILITY_FALSE@ -ENABLE_VISIBILITY_TRUE = @ENABLE_VISIBILITY_TRUE@ -ERROR_CONSTANTS_SRCDIR = @ERROR_CONSTANTS_SRCDIR@ -EXEEXT = @EXEEXT@ -EXTRA_CXX_FLAGS = @EXTRA_CXX_FLAGS@ -FGREP = @FGREP@ -GLIBCXX_BUILD_DEBUG_FALSE = @GLIBCXX_BUILD_DEBUG_FALSE@ -GLIBCXX_BUILD_DEBUG_TRUE = @GLIBCXX_BUILD_DEBUG_TRUE@ -GLIBCXX_BUILD_PCH_FALSE = @GLIBCXX_BUILD_PCH_FALSE@ -GLIBCXX_BUILD_PCH_TRUE = @GLIBCXX_BUILD_PCH_TRUE@ -GLIBCXX_C_HEADERS_COMPATIBILITY_FALSE = @GLIBCXX_C_HEADERS_COMPATIBILITY_FALSE@ -GLIBCXX_C_HEADERS_COMPATIBILITY_TRUE = @GLIBCXX_C_HEADERS_COMPATIBILITY_TRUE@ -GLIBCXX_C_HEADERS_C_FALSE = @GLIBCXX_C_HEADERS_C_FALSE@ -GLIBCXX_C_HEADERS_C_GLOBAL_FALSE = @GLIBCXX_C_HEADERS_C_GLOBAL_FALSE@ -GLIBCXX_C_HEADERS_C_GLOBAL_TRUE = @GLIBCXX_C_HEADERS_C_GLOBAL_TRUE@ -GLIBCXX_C_HEADERS_C_STD_FALSE = @GLIBCXX_C_HEADERS_C_STD_FALSE@ -GLIBCXX_C_HEADERS_C_STD_TRUE = @GLIBCXX_C_HEADERS_C_STD_TRUE@ -GLIBCXX_C_HEADERS_C_TRUE = @GLIBCXX_C_HEADERS_C_TRUE@ -GLIBCXX_C_HEADERS_EXTRA_FALSE = @GLIBCXX_C_HEADERS_EXTRA_FALSE@ -GLIBCXX_C_HEADERS_EXTRA_TRUE = @GLIBCXX_C_HEADERS_EXTRA_TRUE@ -GLIBCXX_HOSTED_FALSE = @GLIBCXX_HOSTED_FALSE@ -GLIBCXX_HOSTED_TRUE = @GLIBCXX_HOSTED_TRUE@ -GLIBCXX_INCLUDES = @GLIBCXX_INCLUDES@ -GLIBCXX_LDBL_COMPAT_FALSE = @GLIBCXX_LDBL_COMPAT_FALSE@ -GLIBCXX_LDBL_COMPAT_TRUE = @GLIBCXX_LDBL_COMPAT_TRUE@ -GLIBCXX_LIBS = @GLIBCXX_LIBS@ -GREP = @GREP@ -INSTALL_DATA = @INSTALL_DATA@ -INSTALL_PROGRAM = @INSTALL_PROGRAM@ -INSTALL_SCRIPT = @INSTALL_SCRIPT@ -INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@ -LD = @LD@ -LDFLAGS = @LDFLAGS@ -LIBICONV = @LIBICONV@ -LIBOBJS = @LIBOBJS@ -LIBS = @LIBS@ -LIBSUPCXX_PICFLAGS = @LIBSUPCXX_PICFLAGS@ -LIBTOOL = @LIBTOOL@ -LIPO = @LIPO@ -LN_S = @LN_S@ -LTLIBICONV = @LTLIBICONV@ -LTLIBOBJS = @LTLIBOBJS@ -MAINT = @MAINT@ -MAINTAINER_MODE_FALSE = @MAINTAINER_MODE_FALSE@ -MAINTAINER_MODE_TRUE = @MAINTAINER_MODE_TRUE@ -MAKEINFO = @MAKEINFO@ -NM = @NM@ -NMEDIT = @NMEDIT@ -OBJDUMP = @OBJDUMP@ -OBJEXT = @OBJEXT@ -OPTIMIZE_CXXFLAGS = @OPTIMIZE_CXXFLAGS@ -OPT_LDFLAGS = @OPT_LDFLAGS@ -OS_INC_SRCDIR = @OS_INC_SRCDIR@ -OTOOL = @OTOOL@ -OTOOL64 = @OTOOL64@ -PACKAGE = @PACKAGE@ -PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@ -PACKAGE_NAME = @PACKAGE_NAME@ -PACKAGE_STRING = @PACKAGE_STRING@ -PACKAGE_TARNAME = @PACKAGE_TARNAME@ -PACKAGE_VERSION = @PACKAGE_VERSION@ -PATH_SEPARATOR = @PATH_SEPARATOR@ -RANLIB = @RANLIB@ -SECTION_FLAGS = @SECTION_FLAGS@ -SECTION_LDFLAGS = @SECTION_LDFLAGS@ -SED = @SED@ -SET_MAKE = @SET_MAKE@ -SHELL = @SHELL@ -STRIP = @STRIP@ -SYMVER_FILE = @SYMVER_FILE@ -TOPLEVEL_INCLUDES = @TOPLEVEL_INCLUDES@ -USE_NLS = @USE_NLS@ -VERSION = @VERSION@ -WARN_FLAGS = @WARN_FLAGS@ -WERROR = @WERROR@ -ac_ct_AR = @ac_ct_AR@ -ac_ct_AS = @ac_ct_AS@ -ac_ct_CC = @ac_ct_CC@ -ac_ct_CXX = @ac_ct_CXX@ -ac_ct_DSYMUTIL = @ac_ct_DSYMUTIL@ -ac_ct_DUMPBIN = @ac_ct_DUMPBIN@ -ac_ct_LIPO = @ac_ct_LIPO@ -ac_ct_NMEDIT = @ac_ct_NMEDIT@ -ac_ct_OBJDUMP = @ac_ct_OBJDUMP@ -ac_ct_OTOOL = @ac_ct_OTOOL@ -ac_ct_OTOOL64 = @ac_ct_OTOOL64@ -ac_ct_RANLIB = @ac_ct_RANLIB@ -ac_ct_STRIP = @ac_ct_STRIP@ -am__leading_dot = @am__leading_dot@ -am__tar = @am__tar@ -am__untar = @am__untar@ -baseline_dir = @baseline_dir@ -bindir = @bindir@ -build = @build@ -build_alias = @build_alias@ -build_cpu = @build_cpu@ -build_os = @build_os@ -build_vendor = @build_vendor@ -check_msgfmt = @check_msgfmt@ -datadir = @datadir@ -enable_shared = @enable_shared@ -enable_static = @enable_static@ -exec_prefix = @exec_prefix@ -glibcxx_MOFILES = @glibcxx_MOFILES@ -glibcxx_PCHFLAGS = @glibcxx_PCHFLAGS@ -glibcxx_POFILES = @glibcxx_POFILES@ -glibcxx_builddir = @glibcxx_builddir@ -glibcxx_localedir = @glibcxx_localedir@ -glibcxx_prefixdir = @glibcxx_prefixdir@ -glibcxx_srcdir = @glibcxx_srcdir@ -glibcxx_thread_h = @glibcxx_thread_h@ -glibcxx_toolexecdir = @glibcxx_toolexecdir@ -glibcxx_toolexeclibdir = @glibcxx_toolexeclibdir@ -gxx_include_dir = @gxx_include_dir@ -host = @host@ -host_alias = @host_alias@ -host_cpu = @host_cpu@ -host_os = @host_os@ -host_vendor = @host_vendor@ -includedir = @includedir@ -infodir = @infodir@ -install_sh = @install_sh@ -libdir = @libdir@ -libexecdir = @libexecdir@ -libtool_VERSION = @libtool_VERSION@ -localstatedir = @localstatedir@ -lt_ECHO = @lt_ECHO@ -mandir = @mandir@ -mkdir_p = @mkdir_p@ -multi_basedir = @multi_basedir@ -oldincludedir = @oldincludedir@ -port_specific_symbol_files = @port_specific_symbol_files@ -prefix = @prefix@ -program_transform_name = @program_transform_name@ -sbindir = @sbindir@ -sharedstatedir = @sharedstatedir@ -sysconfdir = @sysconfdir@ -target = @target@ -target_alias = @target_alias@ -target_cpu = @target_cpu@ -target_os = @target_os@ -target_vendor = @target_vendor@ -toplevel_srcdir = @toplevel_srcdir@ - -# May be used by various substitution variables. -gcc_version := $(shell cat $(top_srcdir)/../gcc/BASE-VER) -MAINT_CHARSET = latin1 -mkinstalldirs = $(SHELL) $(toplevel_srcdir)/mkinstalldirs -PWD_COMMAND = $${PWDCMD-pwd} -STAMP = echo timestamp > -toolexecdir = $(glibcxx_toolexecdir) -toolexeclibdir = $(glibcxx_toolexeclibdir) - -# These bits are all figured out from configure. Look in acinclude.m4 -# or configure.ac to see how they are set. See GLIBCXX_EXPORT_FLAGS. -CONFIG_CXXFLAGS = \ - $(SECTION_FLAGS) $(EXTRA_CXX_FLAGS) - -WARN_CXXFLAGS = \ - $(WARN_FLAGS) $(WERROR) -fdiagnostics-show-location=once - - -# -I/-D flags to pass when compiling. -AM_CPPFLAGS = $(GLIBCXX_INCLUDES) - -# Doxygen configuration -# Assumes doxygen, graphviz (with dot) installed -doc_doxygen_script = ${top_srcdir}/scripts/run_doxygen -doxygen_xmldir = ${glibcxx_builddir}/doc/doxygen/xml - -# Performance doc and graph configuration. -# Assumes pychart, beautiful soup installed. -# Generates the plots and graphs for performance testing. -doc_performance_script = ${top_srcdir}/scripts/make_graphs.py - -# Docbook configuration. -# Assumes -# libxslt -# docbook-style-xsl -# emacs-nxml-mode -# xmlto passivetex -xml_srcdir = ${glibcxx_srcdir}/doc/xml -xml_sources = \ - ${xml_srcdir}/spine.xml \ - ${xml_srcdir}/authors.xml \ - ${xml_srcdir}/manual/abi.xml \ - ${xml_srcdir}/manual/algorithms.xml \ - ${xml_srcdir}/manual/allocator.xml \ - ${xml_srcdir}/manual/auto_ptr.xml \ - ${xml_srcdir}/manual/backwards_compatibility.xml \ - ${xml_srcdir}/manual/bitmap_allocator.xml \ - ${xml_srcdir}/manual/build_hacking.xml \ - ${xml_srcdir}/manual/codecvt.xml \ - ${xml_srcdir}/manual/concurrency.xml \ - ${xml_srcdir}/manual/configure.xml \ - ${xml_srcdir}/manual/containers.xml \ - ${xml_srcdir}/manual/ctype.xml \ - ${xml_srcdir}/manual/debug_mode.xml \ - ${xml_srcdir}/manual/debug.xml \ - ${xml_srcdir}/manual/diagnostics.xml \ - ${xml_srcdir}/manual/evolution.xml \ - ${xml_srcdir}/manual/extensions.xml \ - ${xml_srcdir}/manual/internals.xml \ - ${xml_srcdir}/manual/intro.xml \ - ${xml_srcdir}/manual/io.xml \ - ${xml_srcdir}/manual/iterators.xml \ - ${xml_srcdir}/manual/locale.xml \ - ${xml_srcdir}/manual/localization.xml \ - ${xml_srcdir}/manual/messages.xml \ - ${xml_srcdir}/manual/mt_allocator.xml \ - ${xml_srcdir}/manual/numerics.xml \ - ${xml_srcdir}/manual/parallel_mode.xml \ - ${xml_srcdir}/manual/prerequisites.xml \ - ${xml_srcdir}/manual/internals.xml \ - ${xml_srcdir}/manual/shared_ptr.xml \ - ${xml_srcdir}/manual/spine.xml \ - ${xml_srcdir}/manual/status_cxx1998.xml \ - ${xml_srcdir}/manual/status_cxx200x.xml \ - ${xml_srcdir}/manual/status_cxxtr1.xml \ - ${xml_srcdir}/manual/strings.xml \ - ${xml_srcdir}/manual/support.xml \ - ${xml_srcdir}/manual/test.xml \ - ${xml_srcdir}/manual/using.xml \ - ${xml_srcdir}/manual/utilities.xml \ - ${xml_srcdir}/manual/appendix_free.xml \ - ${xml_srcdir}/manual/appendix_contributing.xml \ - ${xml_srcdir}/manual/appendix_porting.xml \ - ${xml_srcdir}/api.xml \ - ${xml_srcdir}/faq.xml - -xml_sources_extra = \ - ${xml_srcdir}/gnu/fdl-1.2.xml \ - ${xml_srcdir}/gnu/gpl-2.0.xml - -xml_noinst = \ - ${xml_srcdir}/book.txml \ - ${xml_srcdir}/chapter.txml \ - ${xml_srcdir}/class.txml - -XSLTPROC = xsltproc -XSLTPROC_FLAGS = --nonet --xinclude -XSL_STYLE_DIR = /usr/share/sgml/docbook/xsl-stylesheets -XSL_FO_STYLE = $(XSL_STYLE_DIR)/fo/docbook.xsl -XSL_HTML_STYLE = $(XSL_STYLE_DIR)/xhtml/chunk.xsl -#XSL_HTML_SINGLE_STYLE = $(XSL_STYLE_DIR)/xhtml/onechunk.xsl -XSL_HTML_SINGLE_STYLE = $(XSL_STYLE_DIR)/xhtml/docbook.xsl - -# Validate existing XML structure. -XMLLINT = xmllint -#LINT_FLAGS = --debug --nonet --xinclude --nsclean --postvalid --nowarning -#LINT_FLAGS = --noblanks --noout --xinclude --postvalid --noent -LINT_FLAGS = --postvalid --debug --xinclude --noent --noblanks --nonet --noout -VALID_FLAGS = --dtdvalid http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd -XMLLINT_FLAGS = $(LINT_FLAGS) $(VALID_FLAGS) - -# PDF 1 -# fop -FOP = fop -FOP_FLAGS = -d -r - -# PDF 2 -# xmlto -XML2PDF = xmlto -XML2PDF_FLAGS = -v pdf --skip-validation -o pdf - -# PDF 3 -# xmlroff -XMLROFF = xmlroff -XMLROFF_FLAGS = --format=pdf --backend=cairo --warn=1 --debug=1 --continue - -# PDF 4 -# prince -PRINCE = prince -PRINCE_FLAGS = --log prince.log -o pdf/spine.pdf - -# By adding these files here, automake will remove them for 'make clean' -CLEANFILES = *.log -all: all-am - -.SUFFIXES: -$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(top_srcdir)/fragment.am $(am__configure_deps) - @for dep in $?; do \ - case '$(am__configure_deps)' in \ - *$$dep*) \ - cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh \ - && exit 0; \ - exit 1;; \ - esac; \ - done; \ - echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign --ignore-deps doc/Makefile'; \ - cd $(top_srcdir) && \ - $(AUTOMAKE) --foreign --ignore-deps doc/Makefile -.PRECIOUS: Makefile -Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status - @case '$?' in \ - *config.status*) \ - cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \ - *) \ - echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \ - cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \ - esac; - -$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES) - cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh - -$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps) - cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh -$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps) - cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh - -mostlyclean-libtool: - -rm -f *.lo - -clean-libtool: - -rm -rf .libs _libs - -distclean-libtool: - -rm -f libtool -uninstall-info-am: -tags: TAGS -TAGS: - -ctags: CTAGS -CTAGS: - - -distdir: $(DISTFILES) - $(mkdir_p) $(distdir)/.. - @srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`; \ - topsrcdirstrip=`echo "$(top_srcdir)" | sed 's|.|.|g'`; \ - list='$(DISTFILES)'; for file in $$list; do \ - case $$file in \ - $(srcdir)/*) file=`echo "$$file" | sed "s|^$$srcdirstrip/||"`;; \ - $(top_srcdir)/*) file=`echo "$$file" | sed "s|^$$topsrcdirstrip/|$(top_builddir)/|"`;; \ - esac; \ - if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \ - dir=`echo "$$file" | sed -e 's,/[^/]*$$,,'`; \ - if test "$$dir" != "$$file" && test "$$dir" != "."; then \ - dir="/$$dir"; \ - $(mkdir_p) "$(distdir)$$dir"; \ - else \ - dir=''; \ - fi; \ - if test -d $$d/$$file; then \ - if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \ - cp -pR $(srcdir)/$$file $(distdir)$$dir || exit 1; \ - fi; \ - cp -pR $$d/$$file $(distdir)$$dir || exit 1; \ - else \ - test -f $(distdir)/$$file \ - || cp -p $$d/$$file $(distdir)/$$file \ - || exit 1; \ - fi; \ - done -check-am: all-am -check: check-am -all-am: Makefile -installdirs: -install: install-am -install-exec: install-exec-am -install-data: install-data-am -uninstall: uninstall-am - -install-am: all-am - @$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am - -installcheck: installcheck-am -install-strip: - $(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \ - install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \ - `test -z '$(STRIP)' || \ - echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install -mostlyclean-generic: - -clean-generic: - -test -z "$(CLEANFILES)" || rm -f $(CLEANFILES) - -distclean-generic: - -test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES) - -maintainer-clean-generic: - @echo "This command is intended for maintainers to use" - @echo "it deletes files that may require special tools to rebuild." -clean: clean-am - -clean-am: clean-generic clean-libtool clean-local mostlyclean-am - -distclean: distclean-am - -rm -f Makefile -distclean-am: clean-am distclean-generic distclean-libtool - -dvi: dvi-am - -dvi-am: - -html: html-am - -info: info-am - -info-am: - -install-data-am: - -install-exec-am: - -install-info: install-info-am - -install-man: - -installcheck-am: - -maintainer-clean: maintainer-clean-am - -rm -f Makefile -maintainer-clean-am: distclean-am maintainer-clean-generic - -mostlyclean: mostlyclean-am - -mostlyclean-am: mostlyclean-generic mostlyclean-libtool - -pdf: pdf-am - -pdf-am: - -ps: ps-am - -ps-am: - -uninstall-am: uninstall-info-am - -.PHONY: all all-am check check-am clean clean-generic clean-libtool \ - clean-local distclean distclean-generic distclean-libtool \ - distdir dvi dvi-am html html-am info info-am install \ - install-am install-data install-data-am install-exec \ - install-exec-am install-info install-info-am install-man \ - install-strip installcheck installcheck-am installdirs \ - maintainer-clean maintainer-clean-generic mostlyclean \ - mostlyclean-generic mostlyclean-libtool pdf pdf-am ps ps-am \ - uninstall uninstall-am uninstall-info-am - -doc-html-doxygen: - -(srcdir=`cd ${top_srcdir}; ${PWD_COMMAND}`; \ - builddir=`cd ..; ${PWD_COMMAND}`; \ - ${SHELL} ${doc_doxygen_script} \ - --host_alias=${host_alias} --mode=html $${srcdir} $${builddir}) - -doc-man-doxygen: - -(srcdir=`cd ${top_srcdir}; ${PWD_COMMAND}`; \ - builddir=`cd ..; ${PWD_COMMAND}`; \ - ${SHELL} ${doc_doxygen_script} \ - --host_alias=${host_alias} --mode=man $${srcdir} $${builddir}) - -doc-xml-doxygen: - -(srcdir=`cd ${top_srcdir}; ${PWD_COMMAND}`; \ - builddir=`cd ..; ${PWD_COMMAND}`; \ - ${SHELL} ${doc_doxygen_script} \ - --host_alias=${host_alias} --mode=xml $${srcdir} $${builddir}) -doc-xml-doxygen-single: doc-xml-doxygen - @echo "Generating doxygen xml single file..." - $(XSLTPROC) ${doxygen_xmldir}/combine.xslt ${doxygen_xmldir}/spine.xml > ${doxygen_xmldir}/all.xml; -doc-html-performance: - -@(chmod + ${doc_performance_script}; \ - ${doc_performance_script} ${top_srcdir} \ - ${glibcxx_builddir}/testsuite \ - ${top_srcdir}/testsuite/data/make_graph_htmls.xml \ - ${top_srcdir}/testsuite/data/make_graph_test_infos.xml local g++) - -${glibcxx_builddir}/doc/html: - mkdir ${glibcxx_builddir}/doc/html - -${glibcxx_builddir}/doc/pdf: - mkdir ${glibcxx_builddir}/doc/pdf - -${glibcxx_builddir}/doc/fo: - mkdir ${glibcxx_builddir}/doc/fo - -${glibcxx_builddir}/doc/xml: - mkdir ${glibcxx_builddir}/doc/xml -doc-xml-validate: $(xml_sources) - @echo "Generating XML validation log..." - $(XMLLINT) $(XMLLINT_FLAGS) ${top_srcdir}/doc/xml/spine.xml - -doc-xml-single: $(xml_sources) ${glibcxx_builddir}/doc/xml - @echo "Generating XML single..." - $(XMLLINT) --xinclude --noent --noblanks \ - -o ${glibcxx_builddir}/doc/xml/spine-single.xml \ - ${top_srcdir}/doc/xml/spine.xml - -# HTML, index plus chapters -doc-html: $(xml_sources) ${glibcxx_builddir}/doc/html - @echo "Generating html files..." - $(XSLTPROC) $(XSLTPROC_FLAGS) -o ${glibcxx_builddir}/doc/html/ \ - $(XSL_HTML_STYLE) ${top_srcdir}/doc/xml/spine.xml - -# HTML, all one page -doc-html-single: $(xml_sources) ${glibcxx_builddir}/doc/html - @echo "Generating html single file..." - $(XSLTPROC) $(XSLTPROC_FLAGS) -o ${glibcxx_builddir}/doc/html/ \ - $(XSL_HTML_SINGLE_STYLE) ${top_srcdir}/doc/xml/spine.xml - -# FO -doc-fo: $(xml_sources) ${glibcxx_builddir}/doc/fo - @echo "Generating FO files..." - $(XSLTPROC) $(XSLTPROC_FLAGS) -o ${glibcxx_builddir}/doc/fo/spine.fo \ - $(XSL_FO_STYLE) ${top_srcdir}/doc/xml/spine.xml - -# PDF -# Points to current best xml to PDF generation process. -doc-pdf: doc-pdf-prince -doc-pdf-fop-xml: $(xml_sources) ${glibcxx_builddir}/doc/pdf - @echo "Generating pdf fop files from xml..." - $(FOP) $(FOP_FLAGS) -xml ${top_srcdir}/doc/xml/spine.xml \ - -xsl $(XSL_FO_STYLE) -pdf ${glibcxx_builddir}/doc/pdf/spine.pdf - -doc-pdf-fop-fo: $(xml_sources) ${glibcxx_builddir}/doc/pdf doc-fo - @echo "Generating pdf fop files from fo..." - $(FOP) $(FOP_FLAGS) -fo ${glibcxx_builddir}/doc/fo/spine.fo \ - -pdf ${glibcxx_builddir}/doc/pdf/spine.pdf -doc-pdf-xmlto: $(xml_sources) ${glibcxx_builddir}/doc/pdf - @echo "Generating pdf xmlto files..." - $(XML2PDF) $(XML2PDF_FLAGS) ${top_srcdir}/doc/xml/spine.xml -doc-pdf-xmlroff: $(xml_sources) doc-fo - @echo "Generating pdf xmlroff files..." - $(XMLROFF) $(XMLROFF_FLAGS) ${glibcxx_builddir}/doc/fo/spine.fo -doc-pdf-prince: $(xml_sources) ${glibcxx_builddir}/doc/pdf - @echo "Generating pdf prince files..." - $(PRINCE) $(PRINCE_FLAGS) ${top_srcdir}/doc/xml/spine.xml - -.PHONY: doc-doxygen-html doc-doxygen-man doc-performance - -# To remove directories. -clean-local: - rm -rf man html pdf fo doxygen xml -# Tell versions [3.59,3.63) of GNU make to not export all variables. -# Otherwise a system limit (for SysV at least) may be exceeded. -.NOEXPORT: diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/doxygen/Intro.3 b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/doxygen/Intro.3 deleted file mode 100644 index 35fdb1384..000000000 --- a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/doxygen/Intro.3 +++ /dev/null @@ -1,132 +0,0 @@ -.\" t -.\" This man page is released under the GPL as part of libstdc++. -.TH C++Intro 3 "20 May 2004" "GNU libstdc++" "Standard C++ Library" -.SH NAME -C++Intro \- Introduction to the GNU libstdc++ man pages -.SH DESCRIPTION -This man page serves as a brief introduction to the GNU implementation of -the Standard C++ Library. For a better introduction and more complete -documentation, see the -.B libstdc++ -homepage listed at the end. -.P -All standard library entities are declared within -.I namespace std -and have manual entries beginning with "std::". For example, to see -documentation of the template class -.I std::vector -one would use "man std::vector". Some entities do not have a separate man -page; for those see the main listing in "man Namespace_std". -.P -All the man pages are automatically generated by Doxygen. For more -information on this tool, see the HTML counterpart to these man pages. -.P -Some man pages do not correspond to individual classes or functions. Rather -they describe categories of the Standard Library. (For a more thorough -introduction to the various categories, consult a text such as Josuttis' -or Austern's.) These category pages are: -.P -.\" These are separated by ONE TAB. Nothing else. I don't like it either. -.TS -lB l. -C++Intro This page. -Namespace_std A listing of the contents of std::. -Namespace___gnu_cxx A listing of the contents of __gnu_cxx::. -Containers An introduction to container classes. -Sequences Linear containers. -Assoc_containers Key-based containers. -Iterator_types Programatically distinguishing iterators/pointers. -Intro_functors An introduction to function objects, or functors. -Arithmetic_functors Functors for basic math. -Binder_functors Functors which "remember" an argument. -Comparison_functors Functors wrapping built-in comparisons. -Func_ptr_functors Functors for use with pointers to functions. -Logical_functors Functors wrapping the Boolean operations. -Member_ptr_functor Functors for use with pointers to members. -Negation_functors Functors which negate their contents. -SGIextensions A list of the extensions from the SGI STL subset. - -.TE -.P -The HTML documentation typically goes into much more depth. -.SH FILES -Lots! -.SS Standard Headers -These headers will be found automatically, unless you instruct the compiler -otherwise. -.TS -lB lB lB lB. - - - - - - -646 - - - - - -.TE -.SS Backwards-Compatibility Headers -For GCC 3.0 these headers will be found automatically, unless you instruct -the compiler otherwise. You should not depend on this, instead you should -read FAQ 5.4 and use a -.B backward/ -prefix. -.TS -lB lB lB lB. - -.TE -.SS Extension Headers -These headers will only be found automatically if you include the leading -.B ext/ -in the name. Otherwise you need to read FAQ 5.4. -.\" Easy way to generate these columns of headers is to use GNU ls(1): -.\" ls -w 40 file1 file2... | sed 's=[a-z_][a-z_]*==g' -.TS -lB lB. - - - - - - - - -.TE -.SS Libraries -.TP -.I libstdc++.a -The library implementation in static archive form. If you did not configure -libstdc++ to use shared libraries, this will always be used. Otherwise -it will only be used if the user requests it. -.TP -.I libsupc++.a -This library contains C++ language support routines. Usually you will never -need to know about it, but it can be useful. See FAQ 2.5. -.TP -.I libstdc++.so[.N] -The library implementation in shared object form. This will be used in -preference to the static archive form by default. N will be a number equal -to or greater than 3. If N is in the 2.x series, then you are looking at -the old libstdc++-v2 library, which we do not maintain. -.TP -.I libstdc++.la -.TP -.I libsupc++.la -These are Libtool library files, and should only be used when working with -that tool. -.SH CONFORMING TO -Almost conforming to -.BI "International Standard ISO/IEC 14882:1998(E), " "Programming Languages --- C++" -(aka the C++ standard), in addition to corrections proposed by the Library -Working Group, -.SM JTC1/SC22/WG21. -.SH SEE ALSO -.UR -http://gcc.gnu.org/libstdc++/ -.UE -for the Frequently Asked Questions, online documentation, and much, much more! -.\" vim:ts=8:noet: diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/doxygen/TODO b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/doxygen/TODO deleted file mode 100644 index d50c65d8b..000000000 --- a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/doxygen/TODO +++ /dev/null @@ -1,70 +0,0 @@ - -The approach I've been using for a given header is to recursively do each -of the "bits" headers which make up the standard header. So, e.g., while -there are four headers making up , three of them were already -documented in the course of doing other headers. - -"Untouched" means I've deliberately skipped it for various reasons, or -haven't gotten to it yet. It /will/ be done (by somebody, eventually.) - -If you document an area and need to skip (for whatever reason) a non-trivial -entity (i.e., one that should be documented), go ahead and add the comment -markup, and use the homegrown @doctodo tag. See include/bits/stl_iterator.h -for examples of this. Doing so will at least cause doxygen to consider the -entitiy as documented and include it in the output. It will also add the -entity to the generated TODO page. - - - Area Still needs to be doxygen-documented ------------------------------------------------------------ - -c17 FINISHED (Nothing in Clause 17 "exists" in terms of code.) -c18 FINISHED, Note A -c19 Note A -c20 Note A -c21 Public functions basic_string done, Note B -c22 Most still to do; see docs/html/22_locale/* -c23 See doxygroups.cc and Note B. Notes on what invalidates - iterators need to be added. -c24 stl_iterator.h (__normal_iterator, other small TODO bits) - stream iterators -c25 stl_algo.h (lots of stuff) -c26 , , stl_numeric.h[26.4], Note A -c27 ios_base callbacks and local storage - basic_ios::copyfmt() - std_streambuf.h's __copy_streambufs() - " " _M_* protected memfns (data has been done) - fstream and sstream protected members - -backward/* Not scanned by doxygen. Should it be? Doubtful. - -ext/* Some of the SGI algorithm/functional extensions. - All of rope/hashing/slist need docs. - -__gnu_cxx Tricky. Right now ext/* are in this namespace. - ------------------------------------------------------------ - -NOTES: - -A) So far I have not tried to document any of the headers. So entities -such as atexit() are undocumented throughout the library. Since we usually -do not have the C code (to which the doxygen comments would be attached), -this would need to be done in entirely separate files, a la doxygroups.cc. - -B) Huge chunks of containers and strings are described in common "Tables" -in the standard. These are pseudo-duplicated in tables.html. We can -use doxygen hooks like @pre and @see to reference the tables. Then the -individual classes do like the standard does, and only document members for -which additional info is available. - - -STYLE: -stl_deque.h, stl_pair.h, and stl_algobase.h have good examples of what I've -been using for class, namespace-scope, and function documentation, respectively. -These should serve as starting points. /Please/ maintain the inter-word and -inter-sentence spacing, as this might be generated and/or scanned in the -future. - - -vim:ts=4:et: diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/doxygen/doxygroups.cc b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/doxygen/doxygroups.cc deleted file mode 100644 index d11fb3bd2..000000000 --- a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/doxygen/doxygroups.cc +++ /dev/null @@ -1,158 +0,0 @@ -/* - Copyright (C) 2001, 2002, 2005, 2008, 2009 Free Software Foundation, Inc. - See license.html for license. - - This just provides documentation for stuff that doesn't need to be in the - source headers themselves. It is a ".cc" file for the sole cheesy reason - that it triggers many different text editors into doing Nice Things when - typing comments. However, it is mentioned nowhere except the *cfg.in files. - - Some actual code (declarations) is exposed here, but no compiler ever - sees it. The decls must be visible to doxygen, and sometimes their real - declarations are not visible, or not visible in a way we want. - - Pieces separated by '// //' lines will usually not be presented to the - user on the same page. -*/ - -// // // // // // // // // // // // // // // // // // // // // // // // -/** @namespace std - * @brief ISO C++ entities toplevel namespace is std. -*/ -/** @namespace std::__detail - * @brief Implementation details not part of the namespace std interface. -*/ -/** @namespace std::tr1 - * @brief ISO C++ TR1 entities toplevel namespace is std::tr1. -*/ -/** @namespace std::tr1::__detail - * @brief Implementation details not part of the namespace std::tr1 interface. -*/ -/** @namespace __gnu_cxx - * @brief GNU extensions for public use. -*/ -/** @namespace __gnu_cxx::__detail - * @brief Implementation details not part of the namespace __gnu_cxx - * interface. -*/ -/** @namespace __gnu_internal - * @brief GNU implemenation details, not for public use or - * export. Used only when anonymous namespaces cannot be substituted. -*/ -// // // // // // // // // // // // // // // // // // // // // // // // - -/** - * @defgroup extensions Extensions - * - * Components generally useful that are not part of any standard. - */ - -/** @defgroup SGIextensions SGI STL extensions - * @ingroup extensions -Because libstdc++ based its implementation of the STL subsections of -the library on the SGI 3.3 implementation, we inherited their extensions -as well. - -They are additionally documented in the - -online documentation, a copy of which is also shipped with the -library source code (in .../docs/html/documentation.html). You can also -read the documentation on SGI's -site, which is still running even though the code is not maintained. - -NB that the following notes are pulled from various -comments all over the place, so they may seem stilted. -
    -*/ - -/** @defgroup containers Containers -Containers are collections of objects. - -A container may hold any type which meets certain requirements, but the type -of contained object is chosen at compile time, and all objects in a given -container must be of the same type. (Polymorphism is possible by declaring a -container of pointers to a base class and then populating it with pointers to -instances of derived classes. Variant value types such as the @c any class -from Boost can also be used. - -All contained types must be @c Assignable and @c CopyConstructible. -Specific containers may place additional requirements on the types of -their contained objects. - -Containers manage memory allocation and deallocation themselves when -storing your objects. The objects are destroyed when the container is -itself destroyed. Note that if you are storing pointers in a container, -@c delete is @e not automatically called on the pointers before destroying them. - -All containers must meet certain requirements, summarized in -tables. - -The standard containers are further refined into -@link sequences Sequences@endlink and -@link associative_containers Associative Containers@endlink. -@link unordered_associative_containers Unordered Associative Containers@endlink. -*/ - -/** @defgroup sequences Sequences - * @ingroup containers -Sequences arrange a collection of objects into a strictly linear order. - -The differences between sequences are usually due to one or both of the -following: - - memory management - - algorithmic complexity - -As an example of the first case, @c vector is required to use a contiguous -memory layout, while other sequences such as @c deque are not. - -The prime reason for choosing one sequence over another should be based on -the second category of differences, algorithmic complexity. For example, if -you need to perform many inserts and removals from the middle of a sequence, -@c list would be ideal. But if you need to perform constant-time access to -random elements of the sequence, then @c list should not be used. - -All sequences must meet certain requirements, summarized in -tables. -*/ - -/** @defgroup associative_containers Associative Containers - * @ingroup containers -Associative containers allow fast retrieval of data based on keys. - -Each container type is parameterized on a @c Key type, and an ordering -relation used to sort the elements of the container. - -All associative containers must meet certain requirements, summarized in -tables. -*/ - -/** @defgroup unordered_associative_containers Unordered Associative Containers - * @ingroup containers -Unordered associative containers allow fast retrieval of data based on keys. - -Each container type is parameterized on a @c Key type, a @c Hash type -providing a hashing functor, and an ordering relation used to sort the -elements of the container. - -All unordered associative containers must meet certain requirements, -summarized in tables. */ - -/** - * @defgroup diagnostics Diagnostics - * - * Components for error handling, reporting, and diagnostic operations. - */ - -/** - * @defgroup concurrency Concurrency - * - * Components for concurrent operations, including threads, mutexes, - * and condition variables. - */ - -/** - * @defgroup pointer_abstractions Pointer Abstractions - * @ingroup memory - * - * Components for memory allocation, deallocation, and management. - */ diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/doxygen/mainpage.html b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/doxygen/mainpage.html deleted file mode 100644 index aa650bafe..000000000 --- a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/doxygen/mainpage.html +++ /dev/null @@ -1,108 +0,0 @@ - - - -libstdc++ Source: Main Index - - - - - -

    libstdc++ Source Documentation

    - -

    Documentation Overview

    - -

    Generated on @DATE@.

    - -

    There are two types of documentation for libstdc++. One is the - distribution documentation, which can be read online - here - or offline from the file doc/html/index.html in the library source - directory. -

    - -

    The other type is the source documentation, of which this is the first page. -

    - -

    Here are entry points to all the pages generated by Doxygen: -

    -

    - -

    If you are using Doxygen for your own projects, you can use - a tag file for the appropriate version and - an entry such as -

    - TAGFILES = "libstdc++.tag = - http://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen" -
    - Be sure to adjust the URL for the right version. If you download a - local copy of the source documentation for faster viewing, you can use - the doxytag/installdox programs (part of Doxygen) to adjust the links - for you. -

    - -

    Generating the documentation

    -

    These HTML pages are automatically generated, along with the man - pages. See the section "Documentation Style" - in doc/xml/manual/appendix_contributing.xml in the - source tree for how to create (and write) the doxygen markup. - This style guide can also be viewed on the web. - -

    License, Copyright, and Other Lawyerly Verbosity

    -

    The libstdc++ documentation is released under - - these terms. -

    -

    Part of the generated documentation involved comments and notes from - SGI, who says we gotta say this: -

    - Permission to use, copy, modify, distribute and sell this software and its - documentation for any purpose is hereby granted without fee, provided - that the below copyright notice appears in all copies and that both - the copyright notice and this permission notice appear in supporting - documentation. Silicon Graphics makes no representations about the - suitability of this software for any purpose. It is provided "as is" - without express or implied warranty. -

    - Copyright © 1994 - Hewlett-Packard Company -
    -

    -

    Part of the generated documentation is quoted from the ISO C++ Standard, - which is Copyright © 1998 by Information Technology Industry Council. -

    - - - diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/doxygen/stdheader.cc b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/doxygen/stdheader.cc deleted file mode 100644 index 8bcb1a059..000000000 --- a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/doxygen/stdheader.cc +++ /dev/null @@ -1,171 +0,0 @@ -// This is a slow larval-stage kludge to help massage the generated man -// pages. It's used like this: -const char* const usage = -"\nTakes on stdin, whitespace-separated words of the form\n" -"\n" -" [bits/]stl_foo.h\n" -" [bits/]std_foo.h\n" -"\n" -"and writes on stdout the nearest matching standard header name.\n" -"\n" -"Takes no command-line arguments.\n" -"\n"; - -#include -#include -#include -#include - -typedef std::map Map; - -Map headers; - -void init_map() -{ - // Enter the glamourous world of data entry!! Maintain these! - headers["algo.h"] = "algorithm"; - headers["algobase.h"] = "algorithm"; - headers["algorithm.h"] = "algorithm"; - headers["heap.h"] = "algorithm"; - headers["bitset.h"] = "bitset"; - headers["complex.h"] = "complex"; - //headers["construct.h"] stl_construct.h entirely internal - headers["deque.h"] = "deque"; - headers["deque.tcc"] = "deque"; - headers["fstream.h"] = "fstream"; - headers["fstream.tcc"] = "fstream"; - headers["function.h"] = "functional"; - headers["functional.h"] = "functional"; - headers["iomanip.h"] = "iomanip"; - headers["basic_ios.h"] = "ios"; - headers["basic_ios.tcc"] = "ios"; - headers["ios.h"] = "ios"; - headers["iosfwd.h"] = "iosfwd"; - headers["iostream.h"] = "iostream"; - headers["istream.h"] = "istream"; - headers["istream.tcc"] = "istream"; - headers["iterator.h"] = "iterator"; - headers["iterator_base_funcs.h"] = "iterator"; - headers["iterator_base_types.h"] = "iterator"; - headers["stream_iterator.h"] = "iterator"; - headers["streambuf_iterator.h"] = "iterator"; - headers["limits.h"] = "limits"; - headers["list.h"] = "list"; - headers["list.tcc"] = "list"; - headers["codecvt.h"] = "locale"; - headers["locale.h"] = "locale"; - headers["localefwd.h"] = "locale"; - headers["locale_classes.h"] = "locale"; - headers["locale_facets.h"] = "locale"; - headers["locale_facets.tcc"] = "locale"; - headers["map.h"] = "map"; - headers["multimap.h"] = "map"; - headers["memory.h"] = "memory"; - headers["allocator.h"] = "memory"; - headers["raw_storage_iter.h"] = "memory"; - headers["tempbuf.h"] = "memory"; - headers["uninitialized.h"] = "memory"; - headers["numeric.h"] = "numeric"; - headers["ostream.h"] = "ostream"; - headers["ostream.tcc"] = "ostream"; - headers["queue.h"] = "queue"; - headers["set.h"] = "set"; - headers["multiset.h"] = "set"; - headers["sstream.h"] = "sstream"; - headers["sstream.tcc"] = "sstream"; - headers["stack.h"] = "stack"; - headers["functexcept.h"] = "stdexcept"; - headers["stdexcept.h"] = "stdexcept"; - headers["streambuf.h"] = "streambuf"; - headers["streambuf.tcc"] = "streambuf"; - headers["string.h"] = "string"; - headers["char_traits.h"] = "string"; - headers["postypes.h"] = "string"; - headers["basic_string.h"] = "string"; - headers["basic_string.tcc"] = "string"; - headers["tree.h"] = "backward/tree.h"; - headers["pair.h"] = "utility"; - headers["utility.h"] = "utility"; - headers["relops.h"] = "utility"; - headers["gslice.h"] = "valarray"; - headers["gslice_array.h"] = "valarray"; - headers["indirect_array.h"] = "valarray"; - headers["mask_array.h"] = "valarray"; - headers["slice_array.h"] = "valarray"; - headers["valarray.h"] = "valarray"; - headers["valarray_after.h"] = "valarray"; - headers["valarray_before.h"] = "valarray"; - headers["valarray_array.h"] = "valarray"; - headers["valarray_array.tcc"] = "valarray"; - headers["valarray_meta.h"] = "valarray"; - headers["bvector.h"] = "vector"; - headers["vector.h"] = "vector"; - headers["vector.tcc"] = "vector"; - - //headers["concurrence.h"] who knows - //headers["atomicity.h"] who knows - - // C wrappers -- probably was an easier way to do these, but oh well - headers["cassert.h"] = "cassert"; - headers["cctype.h"] = "cctype"; - headers["cerrno.h"] = "cerrno"; - headers["cfloat.h"] = "cfloat"; - headers["climits.h"] = "climits"; - headers["clocale.h"] = "clocale"; - headers["cmath.h"] = "cmath"; - headers["csetjmp.h"] = "csetjmp"; - headers["csignal.h"] = "csignal"; - headers["cstdarg.h"] = "cstdarg"; - headers["cstddef.h"] = "cstddef"; - headers["cstdio.h"] = "cstdio"; - headers["cstdlib.h"] = "cstdlib"; - headers["cstring.h"] = "cstring"; - headers["ctime.h"] = "ctime"; - headers["cwchar.h"] = "cwchar"; - headers["cwctype.h"] = "cwctype"; -} - - -void do_word (std::string const& longheader) -{ - std::string::size_type start = 0; - - // if it doesn't contain a "." then it's already a std header - if (longheader.find(".") == std::string::npos) - { - std::cout << longheader << '\n'; - return; - } - - if (longheader.substr(start,5) == "bits/") start += 5; - if ((longheader.substr(start,4) == "stl_") || - (longheader.substr(start,4) == "std_")) - { - start += 4; - } - - // come on, gdb, find `p' already... - const char* p = longheader.substr(start).c_str(); - Map::iterator word = headers.find(p); - if (word != headers.end()) - std::cout << word->second << '\n'; - else std::cout << "MAYBE_AN_ERROR_MESSAGE_HERE\n"; -} - - -int main (int argc, char**) -{ - if (argc > 1) - { - std::cerr << usage; - std::exit(0); - } - - init_map(); - - std::string w; - while (std::cin >> w) - do_word (w); -} - - diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/doxygen/tables.html b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/doxygen/tables.html deleted file mode 100644 index def011e74..000000000 --- a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/doxygen/tables.html +++ /dev/null @@ -1,644 +0,0 @@ - - - -Tables - - - - -

    Tables

    - -

    Most of the requirements on containers are presented in the ISO standard - in the form of tables. In order to avoid massive duplication of effort - while documenting all the classes, we follow the standard's lead and - present the base information here. Individual classes will only document - their departures from these tables (removed functions, additional functions, - changes, etc). -

    - -

    We will not try to duplicate all of the surrounding text (footnotes, - explanations, etc.) from the standard, because that would also entail a - duplication of effort. Some of the surrounding text has been paraphrased - here for clarity. If you are uncertain about the meaning or interpretation - of these notes, consult a good textbook, and/or purchase your own copy of - the standard (it's cheap, see our FAQ). -

    - -

    The table numbers are the same as those used in the standard. Tables can - be jumped to using their number, e.g., "tables.html#67". Only - Tables 65 through 69 are presented. Some of the active Defect Reports - are also noted or incorporated. -

    - -
    - -

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

    Table 65 --- Container Requirements

    -Anything calling itself a container must meet these minimum requirements. -
    expressionresult typeoperational semanticsnotes, pre-/post-conditions, assertionscomplexity
    X::value_typeT T is Assignablecompile time
    X::referencelvalue of T  compile time
    X::const_referenceconst lvalue of T  compile time
    X::iteratoriterator type pointing to T Any iterator category except output iterator. - Convertible to X::const_iterator.compile time
    X::const_iteratoriterator type pointing to const T Any iterator category except output iterator.compile time
    X::difference_typesigned integral type identical to the difference type of X::iterator and X::const_iteratorcompile time
    X::size_typeunsigned integral type size_type can represent any non-negative value of difference_typecompile time
    X u;  post: u.size() == 0constant
    X();  X().size == 0constant
    X(a);  a == X(a)linear
    X u(a);
    X u = a;    		  post: u == a. Equivalent to: X u; u = a;linear
    (&a)->~X();void dtor is applied to every element of a; all the memory is deallocatedlinear
    a.begin()iterator; const_iterator for constant a  constant
    a.end()iterator; const_iterator for constant a  constant
    a == bconvertible to bool == is an equivalence relation. a.size()==b.size() && - equal(a.begin(),a.end(),b.begin())linear
    a != bconvertible to bool equivalent to !(a==b)linear
    a.swap(b)void swap(a,b)may or may not have constant complexity
    r = aX& r == alinear
    a.size()size_typea.end() - a.begin() may or may not have constant complexity
    a.max_size()size_typesize() of the largest possible container may or may not have constant complexity
    a.empty()convertible to boola.size() == 0 constant
    a < bconvertible to boollexographical_compare( a.begin, a.end(), b.begin(), b.end())pre: < is defined for T and is a total ordering relationlinear
    a > bconvertible to boolb < a linear
    a <= bconvertible to bool!(a > b) linear
    a >= bconvertible to bool!(a < b) linear

     - - -

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

    Table 66 --- Reversible Container Requirements

    -If a container's iterator is bidirectional or random-access, then the -container also meets these requirements. -Deque, list, vector, map, multimap, set, and multiset are such containers. -
    expressionresult typenotes, pre-/post-conditions, assertionscomplexity
    X::reverse_iteratoriterator type pointing to Treverse_iterator<iterator>compile time
    X::const_reverse_iteratoriterator type pointing to const Treverse_iterator<const_iterator>compile time
    a.rbegin()reverse_iterator; const_reverse_iterator for constant areverse_iterator(end())constant
    a.rend()reverse_iterator; const_reverse_iterator for constant areverse_iterator(begin())constant

     - - -

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

    Table 67 --- Sequence Requirements

    -These are in addition to the requirements of containers. -Deque, list, and vector are such containers. -
    expressionresult typenotes, pre-/post-conditions, assertions
    X(n,t)
    X a(n,t)    		 constructs a sequence with n copies of t
    post: size() == n
    X(i,j)
    X a(i,j)    		 constructs a sequence equal to the range [i,j)
    - post: size() == distance(i,j)
    a.insert(p,t)iterator (points to the inserted copy of t)inserts a copy of t before p
    a.insert(p,n,t)voidinserts n copies of t before p
    a.insert(p,i,j)voidinserts copies of elements in [i,j) before p
    - pre: i, j are not iterators into a
    a.erase(q)iterator (points to the element following q (prior to erasure))erases the element pointed to by q
    a.erase(q1,q1)iterator (points to the element pointed to by q2 (prior to erasure))erases the elements in the range [q1,q2)
    a.clear()voiderase(begin(),end())
    post: size() == 0

     - - -

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

    Table 68 --- Optional Sequence Operations

    -These operations are only included in containers when the operation can be -done in constant time. -
    expressionresult typeoperational semanticscontainer
    a.front()reference; const_reference for constant a*a.begin()vector, list, deque
    a.back()reference; const_reference for constant a*--a.end()vector, list, deque
    a.push_front(x)voida.insert(a.begin(),x)list, deque
    a.push_back(x)voida.insert(a.end(),x)vector, list, deque
    a.pop_front()voida.erase(a.begin())list, deque
    a.pop_back()voida.erase(--a.end())vector, list, deque
    a[n]reference; const_reference for constant a*(a.begin() + n)vector, deque
    a.at(n)reference; const_reference for constant a*(a.begin() + n)
    throws out_of_range if n>=a.size()    		vector, deque

     - - -

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

    Table 69 --- Associative Container Requirements

    -These are in addition to the requirements of containers. -Map, multimap, set, and multiset are such containers. An associative -container supports unique keys (and is written as -a_uniq instead of a) if it may contain at most -one element for each key. Otherwise it supports equivalent keys -(and is written a_eq). Examples of the former are set and map, -examples of the latter are multiset and multimap. -
    expressionresult typenotes, pre-/post-conditions, assertionscomplexity
    X::key_typeKeyKey is Assignablecompile time
    X::key_compareComparedefaults to less<key_type>compile time
    X::value_comparea binary predicate typesame as key_compare for set and multiset; an ordering relation on - pairs induced by the first component (Key) for map and multimapcompile time
    X(c)
    X a(c)    		 constructs an empty container which uses c as a comparison objectconstant
    X()
    X a    		 constructs an empty container using Compare() as a comparison objectconstant
    X(i,j,c)
    X a(i,j,c)    		 constructs an empty container and inserts elements from the range [i,j) - into it; uses c as a comparison objectNlogN in general where N is distance(i,j); linear if [i,j) is - sorted with value_comp()
    X(i,j)
    X a(i,j)    		 same as previous, but uses Compare() as a comparison objectsame as previous
    a.key_comp()X::key_comparereturns the comparison object out of which a was constructedconstant
    a.value_comp()X::value_comparereturns an object constructed out of the comparison objectconstant
    a_uniq.insert(t)pair<iterator,bool>"Inserts t if and only if there is no element in the container with - key equivalent to the key of t. The bool component of the returned pair - is true -iff- the insertion took place, and the iterator component of - the pair points to the element with key equivalent to the key of - t." logarithmic
    a_eq.insert(t)iteratorinserts t, returns the iterator pointing to the inserted elementlogarithmic
    a.insert(p,t)iteratorpossibly inserts t (depending on whether a_uniq or a_eq); returns iterator - pointing to the element with key equivalent to the key of t; iterator p - is a hint pointing to where the insert should start to searchlogarithmic in general, amortized constant if t is inserted right - after p
    - [but see DR 233 and our - specific notes]
    a.insert(i,j)voidpre: i, j are not iterators into a. possibly inserts each element from - the range [i,j) (depending on whether a_uniq or a_eq)Nlog(size()+N) where N is distance(i,j) in general
    a.erase(k)size_typeerases all elements with key equivalent to k; returns number of erased - elementslog(size()) + count(k)
    a.erase(q)voiderases the element pointed to by qamortized constant
    a.erase(q1,q2)voiderases all the elements in the range [q1,q2)log(size()) + distance(q1,q2)
    a.clear()voiderases everything; post: size() == 0linear
    a.find(k)iterator; const_iterator for constant areturns iterator pointing to element with key equivalent to k, or - a.end() if no such element foundlogarithmic
    a.count(k)size_typereturns number of elements with key equivalent to klog(size()) + count(k)
    a.lower_bound(k)iterator; const_iterator for constant areturns iterator pointing to the first element with key not less than klogarithmic
    a.upper_bound(k)iterator; const_iterator for constant areturns iterator pointing to the first element with key greater than klogarithmic
    a.equal_range(k)pair<iterator,iterator>; - pair<const_iterator, const_iterator> for constant aequivalent to make_pair(a.lower_bound(k), a.upper_bound(k))logarithmic

     - - -
    -

    -See mainpage.html for copying conditions. -See the libstdc++ homepage -for more information. -

    - - - - - diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/doxygen/user.cfg.in b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/doxygen/user.cfg.in deleted file mode 100644 index aceb67098..000000000 --- a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/doxygen/user.cfg.in +++ /dev/null @@ -1,1711 +0,0 @@ -# Doxyfile 1.5.8 - -# This file describes the settings to be used by the documentation system -# doxygen (www.doxygen.org) for a project -# -# All text after a hash (#) is considered a comment and will be ignored -# The format is: -# TAG = value [value, ...] -# For lists items can also be appended using: -# TAG += value [value, ...] -# Values that contain spaces should be placed between quotes (" ") - -#--------------------------------------------------------------------------- -# Project related configuration options -#--------------------------------------------------------------------------- - -# This tag specifies the encoding used for all characters in the config file -# that follow. The default is UTF-8 which is also the encoding used for all -# text before the first occurrence of this tag. Doxygen uses libiconv (or the -# iconv built into libc) for the transcoding. See -# http://www.gnu.org/software/libiconv for the list of possible encodings. - -DOXYFILE_ENCODING = UTF-8 - -# The PROJECT_NAME tag is a single word (or a sequence of words surrounded -# by quotes) that should identify the project. - -PROJECT_NAME = libstdc++ - -# The PROJECT_NUMBER tag can be used to enter a project or revision number. -# This could be handy for archiving the generated documentation or -# if some version control system is used. - -PROJECT_NUMBER = - -# The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute) -# base path where the generated documentation will be put. -# If a relative path is entered, it will be relative to the location -# where doxygen was started. If left blank the current directory will be used. - -OUTPUT_DIRECTORY = @outdir@ - -# If the CREATE_SUBDIRS tag is set to YES, then doxygen will create -# 4096 sub-directories (in 2 levels) under the output directory of each output -# format and will distribute the generated files over these directories. -# Enabling this option can be useful when feeding doxygen a huge amount of -# source files, where putting all generated files in the same directory would -# otherwise cause performance problems for the file system. - -CREATE_SUBDIRS = NO - -# The OUTPUT_LANGUAGE tag is used to specify the language in which all -# documentation generated by doxygen is written. Doxygen will use this -# information to generate all constant output in the proper language. -# The default language is English, other supported languages are: -# Afrikaans, Arabic, Brazilian, Catalan, Chinese, Chinese-Traditional, -# Croatian, Czech, Danish, Dutch, Farsi, Finnish, French, German, Greek, -# Hungarian, Italian, Japanese, Japanese-en (Japanese with English messages), -# Korean, Korean-en, Lithuanian, Norwegian, Macedonian, Persian, Polish, -# Portuguese, Romanian, Russian, Serbian, Serbian-Cyrilic, Slovak, Slovene, -# Spanish, Swedish, and Ukrainian. - -OUTPUT_LANGUAGE = English - -# If the BRIEF_MEMBER_DESC tag is set to YES (the default) Doxygen will -# include brief member descriptions after the members that are listed in -# the file and class documentation (similar to JavaDoc). -# Set to NO to disable this. - -BRIEF_MEMBER_DESC = NO - -# If the REPEAT_BRIEF tag is set to YES (the default) Doxygen will -# prepend the brief description of a member or function before the -# detailed description. Note: if both HIDE_UNDOC_MEMBERS and -# BRIEF_MEMBER_DESC are set to NO, the brief descriptions will be -# completely suppressed. - -REPEAT_BRIEF = YES - -# This tag implements a quasi-intelligent brief description abbreviator -# that is used to form the text in various listings. Each string -# in this list, if found as the leading text of the brief description, will be -# stripped from the text and the result after processing the whole list, is -# used as the annotated text. Otherwise, the brief description is used as-is. -# If left blank, the following values are used ("$name" is automatically -# replaced with the name of the entity): "The $name class" "The $name widget" -# "The $name file" "is" "provides" "specifies" "contains" -# "represents" "a" "an" "the" - -ABBREVIATE_BRIEF = - -# If the ALWAYS_DETAILED_SEC and REPEAT_BRIEF tags are both set to YES then -# Doxygen will generate a detailed section even if there is only a brief -# description. - -ALWAYS_DETAILED_SEC = YES - -# If the INLINE_INHERITED_MEMB tag is set to YES, doxygen will show all -# inherited members of a class in the documentation of that class as if those -# members were ordinary class members. Constructors, destructors and assignment -# operators of the base classes will not be shown. - -INLINE_INHERITED_MEMB = YES - -# If the FULL_PATH_NAMES tag is set to YES then Doxygen will prepend the full -# path before files name in the file list and in the header files. If set -# to NO the shortest path that makes the file name unique will be used. - -FULL_PATH_NAMES = NO - -# If the FULL_PATH_NAMES tag is set to YES then the STRIP_FROM_PATH tag -# can be used to strip a user-defined part of the path. Stripping is -# only done if one of the specified strings matches the left-hand part of -# the path. The tag can be used to show relative paths in the file list. -# If left blank the directory from which doxygen is run is used as the -# path to strip. - -STRIP_FROM_PATH = - -# The STRIP_FROM_INC_PATH tag can be used to strip a user-defined part of -# the path mentioned in the documentation of a class, which tells -# the reader which header file to include in order to use a class. -# If left blank only the name of the header file containing the class -# definition is used. Otherwise one should specify the include paths that -# are normally passed to the compiler using the -I flag. - -STRIP_FROM_INC_PATH = - -# If the SHORT_NAMES tag is set to YES, doxygen will generate much shorter -# (but less readable) file names. This can be useful is your file systems -# doesn't support long names like on DOS, Mac, or CD-ROM. - -SHORT_NAMES = YES - -# If the JAVADOC_AUTOBRIEF tag is set to YES then Doxygen -# will interpret the first line (until the first dot) of a JavaDoc-style -# comment as the brief description. If set to NO, the JavaDoc -# comments will behave just like regular Qt-style comments -# (thus requiring an explicit @brief command for a brief description.) - -JAVADOC_AUTOBRIEF = NO - -# If the QT_AUTOBRIEF tag is set to YES then Doxygen will -# interpret the first line (until the first dot) of a Qt-style -# comment as the brief description. If set to NO, the comments -# will behave just like regular Qt-style comments (thus requiring -# an explicit \brief command for a brief description.) - -QT_AUTOBRIEF = NO - -# The MULTILINE_CPP_IS_BRIEF tag can be set to YES to make Doxygen -# treat a multi-line C++ special comment block (i.e. a block of //! or /// -# comments) as a brief description. This used to be the default behaviour. -# The new default is to treat a multi-line C++ comment block as a detailed -# description. Set this tag to YES if you prefer the old behaviour instead. - -MULTILINE_CPP_IS_BRIEF = YES - -# If the INHERIT_DOCS tag is set to YES (the default) then an undocumented -# member inherits the documentation from any documented member that it -# re-implements. - -INHERIT_DOCS = YES - -# If the SEPARATE_MEMBER_PAGES tag is set to YES, then doxygen will produce -# a new page for each member. If set to NO, the documentation of a member will -# be part of the file/class/namespace that contains it. - -SEPARATE_MEMBER_PAGES = NO - -# The TAB_SIZE tag can be used to set the number of spaces in a tab. -# Doxygen uses this value to replace tabs by spaces in code fragments. - -TAB_SIZE = 4 - -# This tag can be used to specify a number of aliases that acts -# as commands in the documentation. An alias has the form "name=value". -# For example adding "sideeffect=\par Side Effects:\n" will allow you to -# put the command \sideeffect (or @sideeffect) in the documentation, which -# will result in a user-defined paragraph with heading "Side Effects:". -# You can put \n's in the value part of an alias to insert newlines. - -ALIASES = "doctodo=@todo\nDoc me! See doc/doxygen/TODO and http://gcc.gnu.org/ml/libstdc++/2002-02/msg00003.html for more. " \ - "isiosfwd=One of the @link ios I/O @endlink " - -# Set the OPTIMIZE_OUTPUT_FOR_C tag to YES if your project consists of -# C sources only. Doxygen will then generate output that is more -# tailored for C. For instance, some of the names that are used will -# be different. The list of all members will be omitted, etc. - -OPTIMIZE_OUTPUT_FOR_C = NO - -# Set the OPTIMIZE_OUTPUT_JAVA tag to YES if your project consists of Java -# sources only. Doxygen will then generate output that is more tailored for -# Java. For instance, namespaces will be presented as packages, qualified -# scopes will look different, etc. - -OPTIMIZE_OUTPUT_JAVA = NO - -# Set the OPTIMIZE_FOR_FORTRAN tag to YES if your project consists of Fortran -# sources only. Doxygen will then generate output that is more tailored for -# Fortran. - -OPTIMIZE_FOR_FORTRAN = NO - -# Set the OPTIMIZE_OUTPUT_VHDL tag to YES if your project consists of VHDL -# sources. Doxygen will then generate output that is tailored for -# VHDL. - -OPTIMIZE_OUTPUT_VHDL = NO - -# Doxygen selects the parser to use depending on the extension of the -# files it parses. With this tag you can assign which parser to use -# for a given extension. Doxygen has a built-in mapping, but you can -# override or extend it using this tag. The format is ext=language, -# where ext is a file extension, and language is one of the parsers -# supported by doxygen: IDL, Java, Javascript, C#, C, C++, D, PHP, -# Objective-C, Python, Fortran, VHDL, C, C++. For instance to make -# doxygen treat .inc files as Fortran files (default is PHP), and .f -# files as C (default is Fortran), use: inc=Fortran f=C - -EXTENSION_MAPPING = - -# If you use STL classes (i.e. std::string, std::vector, etc.) but do not want -# to include (a tag file for) the STL sources as input, then you should -# set this tag to YES in order to let doxygen match functions declarations and -# definitions whose arguments contain STL classes (e.g. func(std::string); v.s. -# func(std::string) {}). This also make the inheritance and collaboration -# diagrams that involve STL classes more complete and accurate. - -BUILTIN_STL_SUPPORT = NO - -# If you use Microsoft's C++/CLI language, you should set this option to YES to -# enable parsing support. - -CPP_CLI_SUPPORT = NO - -# Set the SIP_SUPPORT tag to YES if your project consists of sip -# sources only. Doxygen will parse them like normal C++ but will -# assume all classes use public instead of private inheritance when no -# explicit protection keyword is present. - -SIP_SUPPORT = NO - -# For Microsoft's IDL there are propget and propput attributes to -# indicate getter and setter methods for a property. Setting this -# option to YES (the default) will make doxygen to replace the get and -# set methods by a property in the documentation. This will only work -# if the methods are indeed getting or setting a simple type. If this -# is not the case, or you want to show the methods anyway, you should -# set this option to NO. - -IDL_PROPERTY_SUPPORT = YES - -# If member grouping is used in the documentation and the DISTRIBUTE_GROUP_DOC -# tag is set to YES, then doxygen will reuse the documentation of the first -# member in the group (if any) for the other members of the group. By default -# all members of a group must be documented explicitly. - -DISTRIBUTE_GROUP_DOC = YES - -# Set the SUBGROUPING tag to YES (the default) to allow class member groups of -# the same type (for instance a group of public functions) to be put as a -# subgroup of that type (e.g. under the Public Functions section). Set it to -# NO to prevent subgrouping. Alternatively, this can be done per class using -# the \nosubgrouping command. - -SUBGROUPING = YES - -# When TYPEDEF_HIDES_STRUCT is enabled, a typedef of a struct, union, -# or enum is documented as struct, union, or enum with the name of the -# typedef. So typedef struct TypeS {} TypeT, will appear in the -# documentation as a struct with name TypeT. When disabled the typedef -# will appear as a member of a file, namespace, or class. And the -# struct will be named TypeS. This can typically be useful for C code -# in case the coding convention dictates that all compound types are -# typedef'ed and only the typedef is referenced, never the tag name. - -TYPEDEF_HIDES_STRUCT = NO - -# The SYMBOL_CACHE_SIZE determines the size of the internal cache use -# to determine which symbols to keep in memory and which to flush to -# disk. When the cache is full, less often used symbols will be -# written to disk. For small to medium size projects (<1000 input -# files) the default value is probably good enough. For larger -# projects a too small cache size can cause doxygen to be busy -# swapping symbols to and from disk most of the time causing a -# significant performance penality. If the system has enough physical -# memory increasing the cache will improve the performance by keeping -# more symbols in memory. Note that the value works on a logarithmic -# scale so increasing the size by one will rougly double the memory -# usage. The cache size is given by this formula: -# 2^(16+SYMBOL_CACHE_SIZE). The valid range is 0..9, the default is 0, -# corresponding to a cache size of 2^16 = 65536 symbols - -SYMBOL_CACHE_SIZE = 0 - -#--------------------------------------------------------------------------- -# Build related configuration options -#--------------------------------------------------------------------------- - -# If the EXTRACT_ALL tag is set to YES doxygen will assume all entities in -# documentation are documented, even if no documentation was available. -# Private class members and static file members will be hidden unless -# the EXTRACT_PRIVATE and EXTRACT_STATIC tags are set to YES - -EXTRACT_ALL = NO - -# If the EXTRACT_PRIVATE tag is set to YES all private members of a class -# will be included in the documentation. - -EXTRACT_PRIVATE = NO - -# If the EXTRACT_STATIC tag is set to YES all static members of a file -# will be included in the documentation. - -EXTRACT_STATIC = YES - -# If the EXTRACT_LOCAL_CLASSES tag is set to YES classes (and structs) -# defined locally in source files will be included in the documentation. -# If set to NO only classes defined in header files are included. - -EXTRACT_LOCAL_CLASSES = YES - -# This flag is only useful for Objective-C code. When set to YES local -# methods, which are defined in the implementation section but not in -# the interface are included in the documentation. -# If set to NO (the default) only methods in the interface are included. - -EXTRACT_LOCAL_METHODS = YES - -# If this flag is set to YES, the members of anonymous namespaces will be -# extracted and appear in the documentation as a namespace called -# 'anonymous_namespace{file}', where file will be replaced with the base -# name of the file that contains the anonymous namespace. By default -# anonymous namespace are hidden. - -EXTRACT_ANON_NSPACES = NO - -# If the HIDE_UNDOC_MEMBERS tag is set to YES, Doxygen will hide all -# undocumented members of documented classes, files or namespaces. -# If set to NO (the default) these members will be included in the -# various overviews, but no documentation section is generated. -# This option has no effect if EXTRACT_ALL is enabled. - -HIDE_UNDOC_MEMBERS = NO - -# If the HIDE_UNDOC_CLASSES tag is set to YES, Doxygen will hide all -# undocumented classes that are normally visible in the class hierarchy. -# If set to NO (the default) these classes will be included in the various -# overviews. This option has no effect if EXTRACT_ALL is enabled. - -HIDE_UNDOC_CLASSES = YES - -# If the HIDE_FRIEND_COMPOUNDS tag is set to YES, Doxygen will hide all -# friend (class|struct|union) declarations. -# If set to NO (the default) these declarations will be included in the -# documentation. - -HIDE_FRIEND_COMPOUNDS = NO - -# If the HIDE_IN_BODY_DOCS tag is set to YES, Doxygen will hide any -# documentation blocks found inside the body of a function. -# If set to NO (the default) these blocks will be appended to the -# function's detailed documentation block. - -HIDE_IN_BODY_DOCS = NO - -# The INTERNAL_DOCS tag determines if documentation -# that is typed after a \internal command is included. If the tag is set -# to NO (the default) then the documentation will be excluded. -# Set it to YES to include the internal documentation. - -INTERNAL_DOCS = NO - -# If the CASE_SENSE_NAMES tag is set to NO then Doxygen will only generate -# file names in lower-case letters. If set to YES upper-case letters are also -# allowed. This is useful if you have classes or files whose names only differ -# in case and if your file system supports case sensitive file names. Windows -# and Mac users are advised to set this option to NO. - -CASE_SENSE_NAMES = NO - -# If the HIDE_SCOPE_NAMES tag is set to NO (the default) then Doxygen -# will show members with their full class and namespace scopes in the -# documentation. If set to YES the scope will be hidden. - -HIDE_SCOPE_NAMES = NO - -# If the SHOW_INCLUDE_FILES tag is set to YES (the default) then Doxygen -# will put a list of the files that are included by a file in the documentation -# of that file. - -SHOW_INCLUDE_FILES = NO - -# If the INLINE_INFO tag is set to YES (the default) then a tag [inline] -# is inserted in the documentation for inline members. - -INLINE_INFO = YES - -# If the SORT_MEMBER_DOCS tag is set to YES (the default) then doxygen -# will sort the (detailed) documentation of file and class members -# alphabetically by member name. If set to NO the members will appear in -# declaration order. - -SORT_MEMBER_DOCS = YES - -# If the SORT_BRIEF_DOCS tag is set to YES then doxygen will sort the -# brief documentation of file, namespace and class members alphabetically -# by member name. If set to NO (the default) the members will appear in -# declaration order. - -SORT_BRIEF_DOCS = YES - -# If the SORT_GROUP_NAMES tag is set to YES then doxygen will sort the -# hierarchy of group names into alphabetical order. If set to NO (the default) -# the group names will appear in their defined order. - -SORT_GROUP_NAMES = YES - -# If the SORT_BY_SCOPE_NAME tag is set to YES, the class list will be -# sorted by fully-qualified names, including namespaces. If set to -# NO (the default), the class list will be sorted only by class name, -# not including the namespace part. -# Note: This option is not very useful if HIDE_SCOPE_NAMES is set to YES. -# Note: This option applies only to the class list, not to the -# alphabetical list. - -SORT_BY_SCOPE_NAME = YES - -# The GENERATE_TODOLIST tag can be used to enable (YES) or -# disable (NO) the todo list. This list is created by putting \todo -# commands in the documentation. - -GENERATE_TODOLIST = YES - -# The GENERATE_TESTLIST tag can be used to enable (YES) or -# disable (NO) the test list. This list is created by putting \test -# commands in the documentation. - -GENERATE_TESTLIST = NO - -# The GENERATE_BUGLIST tag can be used to enable (YES) or -# disable (NO) the bug list. This list is created by putting \bug -# commands in the documentation. - -GENERATE_BUGLIST = YES - -# The GENERATE_DEPRECATEDLIST tag can be used to enable (YES) or -# disable (NO) the deprecated list. This list is created by putting -# \deprecated commands in the documentation. - -GENERATE_DEPRECATEDLIST= YES - -# The ENABLED_SECTIONS tag can be used to enable conditional -# documentation sections, marked by \if sectionname ... \endif. - -ENABLED_SECTIONS = @enabled_sections@ - -# The MAX_INITIALIZER_LINES tag determines the maximum number of lines -# the initial value of a variable or define consists of for it to appear in -# the documentation. If the initializer consists of more lines than specified -# here it will be hidden. Use a value of 0 to hide initializers completely. -# The appearance of the initializer of individual variables and defines in the -# documentation can be controlled using \showinitializer or \hideinitializer -# command in the documentation regardless of this setting. - -MAX_INITIALIZER_LINES = 0 - -# Set the SHOW_USED_FILES tag to NO to disable the list of files generated -# at the bottom of the documentation of classes and structs. If set to YES the -# list will mention the files that were used to generate the documentation. - -SHOW_USED_FILES = YES - -# If the sources in your project are distributed over multiple -# directories then setting the SHOW_DIRECTORIES tag to YES will show -# the directory hierarchy in the documentation. The default is NO. - -SHOW_DIRECTORIES = YES - -# Set the SHOW_FILES tag to NO to disable the generation of the Files page. -# This will remove the Files entry from the Quick Index and from the -# Folder Tree View (if specified). The default is YES. - -SHOW_FILES = YES - -# Set the SHOW_NAMESPACES tag to NO to disable the generation of the -# Namespaces page. -# This will remove the Namespaces entry from the Quick Index -# and from the Folder Tree View (if specified). The default is YES. - -SHOW_NAMESPACES = YES - -# The FILE_VERSION_FILTER tag can be used to specify a program or -# script that doxygen should invoke to get the current version for -# each file (typically from the version control system). Doxygen will -# invoke the program by executing (via popen()) the command -# , where is the value of the -# FILE_VERSION_FILTER tag, and is the name of an input -# file provided by doxygen. Whatever the program writes to standard -# output is used as the file version. See the manual for examples. - -FILE_VERSION_FILTER = - -# The LAYOUT_FILE tag can be used to specify a layout file which will -# be parsed by doxygen. The layout file controls the global structure -# of the generated output files in an output format independent -# way. The create the layout file that represents doxygen's defaults, -# run doxygen with the -l option. You can optionally specify a file -# name after the option, if omitted DoxygenLayout.xml will be used as -# the name of the layout file. - -LAYOUT_FILE = - -#--------------------------------------------------------------------------- -# configuration options related to warning and progress messages -#--------------------------------------------------------------------------- - -# The QUIET tag can be used to turn on/off the messages that are generated -# by doxygen. Possible values are YES and NO. If left blank NO is used. - -QUIET = NO - -# The WARNINGS tag can be used to turn on/off the warning messages that are -# generated by doxygen. Possible values are YES and NO. If left blank -# NO is used. - -WARNINGS = YES - -# If WARN_IF_UNDOCUMENTED is set to YES, then doxygen will generate warnings -# for undocumented members. If EXTRACT_ALL is set to YES then this flag will -# automatically be disabled. - -WARN_IF_UNDOCUMENTED = NO - -# If WARN_IF_DOC_ERROR is set to YES, doxygen will generate warnings for -# potential errors in the documentation, such as not documenting some -# parameters in a documented function, or documenting parameters that -# don't exist or using markup commands wrongly. - -WARN_IF_DOC_ERROR = YES - -# This WARN_NO_PARAMDOC option can be abled to get warnings for -# functions that are documented, but have no documentation for their parameters -# or return value. If set to NO (the default) doxygen will only warn about -# wrong or incomplete parameter documentation, but not about the absence of -# documentation. - -WARN_NO_PARAMDOC = NO - -# The WARN_FORMAT tag determines the format of the warning messages that -# doxygen can produce. The string should contain the $file, $line, and $text -# tags, which will be replaced by the file and line number from which the -# warning originated and the warning text. Optionally the format may contain -# $version, which will be replaced by the version of the file (if it could -# be obtained via FILE_VERSION_FILTER) - -WARN_FORMAT = "$file:$line: $text " - -# The WARN_LOGFILE tag can be used to specify a file to which warning -# and error messages should be written. If left blank the output is written -# to stderr. - -WARN_LOGFILE = - -#--------------------------------------------------------------------------- -# configuration options related to the input files -#--------------------------------------------------------------------------- - -# The INPUT tag can be used to specify the files and/or directories -# that contain documented source files. You may enter file names like -# "myfile.cpp" or directories like "/usr/src/myproject". Separate the -# files or directories with spaces. - -INPUT = @srcdir@/doc/doxygen/doxygroups.cc \ - @srcdir@/libsupc++/cxxabi.h \ - @srcdir@/libsupc++/cxxabi-forced.h \ - @srcdir@/libsupc++/exception \ - @srcdir@/libsupc++/exception_ptr.h \ - @srcdir@/libsupc++/initializer_list \ - @srcdir@/libsupc++/new \ - @srcdir@/libsupc++/typeinfo \ - include/algorithm \ - include/array \ - include/bitset \ - include/chrono \ - include/complex \ - include/condition_variable \ - include/deque \ - include/fstream \ - include/functional \ - include/iomanip \ - include/ios \ - include/iosfwd \ - include/iostream \ - include/istream \ - include/iterator \ - include/limits \ - include/list \ - include/locale \ - include/map \ - include/memory \ - include/mutex \ - include/numeric \ - include/ostream \ - include/queue \ - include/random \ - include/ratio \ - include/regex \ - include/set \ - include/sstream \ - include/stack \ - include/stdexcept \ - include/streambuf \ - include/string \ - include/system_error \ - include/thread \ - include/tuple \ - include/type_traits \ - include/unordered_map \ - include/unordered_set \ - include/utility \ - include/valarray \ - include/vector \ - include/cassert \ - include/ccomplex \ - include/cctype \ - include/cerrno \ - include/cfenv \ - include/cfloat \ - include/cinttypes \ - include/ciso646 \ - include/climits \ - include/clocale \ - include/cmath \ - include/csetjmp \ - include/csignal \ - include/cstdarg \ - include/cstdatomic \ - include/cstdbool \ - include/cstddef \ - include/cstdint \ - include/cstdio \ - include/cstdlib \ - include/cstring \ - include/ctgmath \ - include/ctime \ - include/cwchar \ - include/cwctype \ - include/backward/hash_map \ - include/backward/hash_set \ - include/backward/strstream \ - include/debug/bitset \ - include/debug/deque \ - include/debug/list \ - include/debug/map \ - include/debug/set \ - include/debug/string \ - include/debug/unordered_map \ - include/debug/unordered_set \ - include/debug/vector \ - include/ext/algorithm \ - include/ext/functional \ - include/ext/iterator \ - include/ext/memory \ - include/ext/numeric \ - include/ext/rb_tree \ - include/ext/rope \ - include/ext/slist \ - include/parallel/algorithm \ - include/parallel/numeric \ - include/tr1/array \ - include/tr1/ccomplex \ - include/tr1/cctype \ - include/tr1/cfenv \ - include/tr1/cfloat \ - include/tr1/cinttypes \ - include/tr1/climits \ - include/tr1/cmath \ - include/tr1/complex \ - include/tr1/cstdarg \ - include/tr1/cstdbool \ - include/tr1/cstdint \ - include/tr1/cstdio \ - include/tr1/cstdlib \ - include/tr1/ctgmath \ - include/tr1/ctime \ - include/tr1/cwchar \ - include/tr1/cwctype \ - include/tr1/functional \ - include/tr1/memory \ - include/tr1/random \ - include/tr1/regex \ - include/tr1/tuple \ - include/tr1/type_traits \ - include/tr1/unordered_map \ - include/tr1/unordered_set \ - include/tr1_impl/array \ - include/tr1_impl/cctype \ - include/tr1_impl/cfenv \ - include/tr1_impl/cinttypes \ - include/tr1_impl/cmath \ - include/tr1_impl/complex \ - include/tr1_impl/cstdint \ - include/tr1_impl/cstdio \ - include/tr1_impl/cstdlib \ - include/tr1_impl/cwchar \ - include/tr1_impl/cwctype \ - include/tr1_impl/functional \ - include/tr1_impl/hashtable \ - include/tr1_impl/random \ - include/tr1_impl/regex \ - include/tr1_impl/type_traits \ - include/tr1_impl/unordered_map \ - include/tr1_impl/unordered_set \ - include/tr1_impl/utility \ - include/tr1_impl \ - include/tr1 \ - include/ \ - include/@host_alias@/bits \ - include/backward \ - include/bits \ - include/bits/shared_ptr.h \ - include/debug \ - include/parallel \ - include/ext \ - include/ext/pb_ds \ - include/ext/pb_ds/detail - -# This tag can be used to specify the character encoding of the source files -# that doxygen parses. Internally doxygen uses the UTF-8 encoding, which is -# also the default input encoding. Doxygen uses libiconv (or the iconv built -# into libc) for the transcoding. See http://www.gnu.org/software/libiconv for -# the list of possible encodings. - -INPUT_ENCODING = UTF-8 - -# If the value of the INPUT tag contains directories, you can use the -# FILE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp -# and *.h) to filter out the source-files in the directories. If left -# blank the following patterns are tested: -# *.c *.cc *.cxx *.cpp *.c++ *.java *.ii *.ixx *.ipp *.i++ *.inl *.h *.hh *.hxx -# *.hpp *.h++ *.idl *.odl *.cs *.php *.php3 *.inc *.m *.mm *.py *.f90 - -FILE_PATTERNS = *.h \ - *.hpp \ - *.tcc - -# The RECURSIVE tag can be used to turn specify whether or not subdirectories -# should be searched for input files as well. Possible values are YES and NO. -# If left blank NO is used. - -RECURSIVE = NO - -# The EXCLUDE tag can be used to specify files and/or directories that should -# excluded from the INPUT source files. This way you can easily exclude a -# subdirectory from a directory tree whose root is specified with the INPUT tag. - -EXCLUDE = Makefile - -# The EXCLUDE_SYMLINKS tag can be used select whether or not files or -# directories that are symbolic links (a Unix filesystem feature) are excluded -# from the input. - -EXCLUDE_SYMLINKS = NO - -# If the value of the INPUT tag contains directories, you can use the -# EXCLUDE_PATTERNS tag to specify one or more wildcard patterns to exclude -# certain files from those directories. Note that the wildcards are matched -# against the file with absolute path, so to exclude all test directories -# for example use the pattern */test/* - -EXCLUDE_PATTERNS = stamp-* \ - *stdc++.h* \ - *stdtr1c++.h* \ - *extc++.h* \ - */.svn/* - -# The EXCLUDE_SYMBOLS tag can be used to specify one or more symbol names -# (namespaces, classes, functions, etc.) that should be excluded from the -# output. The symbol name can be a fully qualified name, a word, or if the -# wildcard * is used, a substring. Examples: ANamespace, AClass, -# AClass::ANamespace, ANamespace::*Test - -EXCLUDE_SYMBOLS = - -# The EXAMPLE_PATH tag can be used to specify one or more files or -# directories that contain example code fragments that are included (see -# the \include command). - -EXAMPLE_PATH = - -# If the value of the EXAMPLE_PATH tag contains directories, you can use the -# EXAMPLE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp -# and *.h) to filter out the source-files in the directories. If left -# blank all files are included. - -EXAMPLE_PATTERNS = - -# If the EXAMPLE_RECURSIVE tag is set to YES then subdirectories will be -# searched for input files to be used with the \include or \dontinclude -# commands irrespective of the value of the RECURSIVE tag. -# Possible values are YES and NO. If left blank NO is used. - -EXAMPLE_RECURSIVE = NO - -# The IMAGE_PATH tag can be used to specify one or more files or -# directories that contain image that are included in the documentation (see -# the \image command). - -IMAGE_PATH = - -# The INPUT_FILTER tag can be used to specify a program that doxygen should -# invoke to filter for each input file. Doxygen will invoke the filter program -# by executing (via popen()) the command , where -# is the value of the INPUT_FILTER tag, and is the name of an -# input file. Doxygen will then use the output that the filter program writes -# to standard output. -# If FILTER_PATTERNS is specified, this tag will be -# ignored. - -INPUT_FILTER = - -# The FILTER_PATTERNS tag can be used to specify filters on a per file pattern -# basis. -# Doxygen will compare the file name with each pattern and apply the -# filter if there is a match. -# The filters are a list of the form: -# pattern=filter (like *.cpp=my_cpp_filter). See INPUT_FILTER for further -# info on how filters are used. If FILTER_PATTERNS is empty, INPUT_FILTER -# is applied to all files. - -FILTER_PATTERNS = - -# If the FILTER_SOURCE_FILES tag is set to YES, the input filter (if set using -# INPUT_FILTER) will be used to filter the input files when producing source -# files to browse (i.e. when SOURCE_BROWSER is set to YES). - -FILTER_SOURCE_FILES = NO - -#--------------------------------------------------------------------------- -# configuration options related to source browsing -#--------------------------------------------------------------------------- - -# If the SOURCE_BROWSER tag is set to YES then a list of source files -# will be generated. Documented entities will be cross-referenced with -# these sources. Note: To get rid of all source code in the generated -# output, make sure also VERBATIM_HEADERS is set to NO. - -SOURCE_BROWSER = YES - -# Setting the INLINE_SOURCES tag to YES will include the body -# of functions and classes directly in the documentation. - -INLINE_SOURCES = NO - -# Setting the STRIP_CODE_COMMENTS tag to YES (the default) will instruct -# doxygen to hide any special comment blocks from generated source code -# fragments. Normal C and C++ comments will always remain visible. - -STRIP_CODE_COMMENTS = NO - -# If the REFERENCED_BY_RELATION tag is set to YES -# then for each documented function all documented -# functions referencing it will be listed. - -REFERENCED_BY_RELATION = YES - -# If the REFERENCES_RELATION tag is set to YES -# then for each documented function all documented entities -# called/used by that function will be listed. - -REFERENCES_RELATION = YES - -# If the REFERENCES_LINK_SOURCE tag is set to YES (the default) -# and SOURCE_BROWSER tag is set to YES, then the hyperlinks from -# functions in REFERENCES_RELATION and REFERENCED_BY_RELATION lists will -# link to the source code. -# Otherwise they will link to the documentation. - -REFERENCES_LINK_SOURCE = YES - -# If the USE_HTAGS tag is set to YES then the references to source code -# will point to the HTML generated by the htags(1) tool instead of doxygen -# built-in source browser. The htags tool is part of GNU's global source -# tagging system (see http://www.gnu.org/software/global/global.html). You -# will need version 4.8.6 or higher. - -USE_HTAGS = NO - -# If the VERBATIM_HEADERS tag is set to YES (the default) then Doxygen -# will generate a verbatim copy of the header file for each class for -# which an include is specified. Set to NO to disable this. - -VERBATIM_HEADERS = NO - -#--------------------------------------------------------------------------- -# configuration options related to the alphabetical class index -#--------------------------------------------------------------------------- - -# If the ALPHABETICAL_INDEX tag is set to YES, an alphabetical index -# of all compounds will be generated. Enable this if the project -# contains a lot of classes, structs, unions or interfaces. - -ALPHABETICAL_INDEX = YES - -# If the alphabetical index is enabled (see ALPHABETICAL_INDEX) then -# the COLS_IN_ALPHA_INDEX tag can be used to specify the number of columns -# in which this list will be split (can be a number in the range [1..20]) - -COLS_IN_ALPHA_INDEX = 2 - -# In case all classes in a project start with a common prefix, all -# classes will be put under the same header in the alphabetical index. -# The IGNORE_PREFIX tag can be used to specify one or more prefixes that -# should be ignored while generating the index headers. - -IGNORE_PREFIX = - -#--------------------------------------------------------------------------- -# configuration options related to the HTML output -#--------------------------------------------------------------------------- - -# If the GENERATE_HTML tag is set to YES (the default) Doxygen will -# generate HTML output. - -GENERATE_HTML = @do_html@ - -# The HTML_OUTPUT tag is used to specify where the HTML docs will be put. -# If a relative path is entered the value of OUTPUT_DIRECTORY will be -# put in front of it. If left blank `html' will be used as the default path. - -HTML_OUTPUT = html - -# The HTML_FILE_EXTENSION tag can be used to specify the file extension for -# each generated HTML page (for example: .htm,.php,.asp). If it is left blank -# doxygen will generate files with .html extension. - -HTML_FILE_EXTENSION = .html - -# The HTML_HEADER tag can be used to specify a personal HTML header for -# each generated HTML page. If it is left blank doxygen will generate a -# standard header. - -HTML_HEADER = - -# The HTML_FOOTER tag can be used to specify a personal HTML footer for -# each generated HTML page. If it is left blank doxygen will generate a -# standard footer. - -HTML_FOOTER = - -# The HTML_STYLESHEET tag can be used to specify a user-defined cascading -# style sheet that is used by each HTML page. It can be used to -# fine-tune the look of the HTML output. If the tag is left blank doxygen -# will generate a default style sheet. Note that doxygen will try to copy -# the style sheet file to the HTML output directory, so don't put your own -# stylesheet in the HTML output directory as well, or it will be erased! - -HTML_STYLESHEET = - -# If the HTML_ALIGN_MEMBERS tag is set to YES, the members of classes, -# files or namespaces will be aligned in HTML using tables. If set to -# NO a bullet list will be used. - -HTML_ALIGN_MEMBERS = NO - -# If the HTML_DYNAMIC_SECTIONS tag is set to YES then the generated HTML -# documentation will contain sections that can be hidden and shown after the -# page has loaded. For this to work a browser that supports -# JavaScript and DHTML is required (for instance Mozilla 1.0+, Firefox -# Netscape 6.0+, Internet explorer 5.0+, Konqueror, or Safari). - -HTML_DYNAMIC_SECTIONS = NO - -# If the GENERATE_DOCSET tag is set to YES, additional index files -# will be generated that can be used as input for Apple's Xcode 3 -# integrated development environment, introduced with OSX 10.5 -# (Leopard). To create a documentation set, doxygen will generate a -# Makefile in the HTML output directory. Running make will produce the -# docset in that directory and running "make install" will install the -# docset in ~/Library/Developer/Shared/Documentation/DocSets so that -# Xcode will find it at startup. See -# http://developer.apple.com/tools/creatingdocsetswithdoxygen.html for -# more information. - -GENERATE_DOCSET = NO - -# When GENERATE_DOCSET tag is set to YES, this tag determines the name -# of the feed. A documentation feed provides an umbrella under which -# multiple documentation sets from a single provider (such as a -# company or product suite) can be grouped. - -DOCSET_FEEDNAME = "Doxygen generated docs" - -# When GENERATE_DOCSET tag is set to YES, this tag specifies a string that -# should uniquely identify the documentation set bundle. This should be a -# reverse domain-name style string, e.g. com.mycompany.MyDocSet. Doxygen -# will append .docset to the name. - -DOCSET_BUNDLE_ID = org.doxygen.Project - -# If the GENERATE_HTMLHELP tag is set to YES, additional index files -# will be generated that can be used as input for tools like the -# Microsoft HTML help workshop to generate a compiled HTML help file (.chm) -# of the generated HTML documentation. - -GENERATE_HTMLHELP = NO - -# If the GENERATE_HTMLHELP tag is set to YES, the CHM_FILE tag can -# be used to specify the file name of the resulting .chm file. You -# can add a path in front of the file if the result should not be -# written to the html output directory. - -CHM_FILE = - -# If the GENERATE_HTMLHELP tag is set to YES, the HHC_LOCATION tag can -# be used to specify the location (absolute path including file name) of -# the HTML help compiler (hhc.exe). If non-empty doxygen will try to run -# the HTML help compiler on the generated index.hhp. - -HHC_LOCATION = - -# If the GENERATE_HTMLHELP tag is set to YES, the GENERATE_CHI flag -# controls if a separate .chi index file is generated (YES) or that -# it should be included in the master .chm file (NO). - -GENERATE_CHI = NO - -# If the GENERATE_HTMLHELP tag is set to YES, the CHM_INDEX_ENCODING -# is used to encode HtmlHelp index (hhk), content (hhc) and project file -# content. - -CHM_INDEX_ENCODING = - -# If the GENERATE_HTMLHELP tag is set to YES, the BINARY_TOC flag -# controls whether a binary table of contents is generated (YES) or a -# normal table of contents (NO) in the .chm file. - -BINARY_TOC = NO - -# The TOC_EXPAND flag can be set to YES to add extra items for group members -# to the contents of the HTML help documentation and to the tree view. - -TOC_EXPAND = NO - -# If the GENERATE_QHP tag is set to YES and both QHP_NAMESPACE and -# QHP_VIRTUAL_FOLDER are set, an additional index file will be -# generated that can be used as input for Qt's qhelpgenerator to -# generate a Qt Compressed Help (.qch) of the generated HTML -# documentation. - -GENERATE_QHP = NO - -# If the QHG_LOCATION tag is specified, the QCH_FILE tag can -# be used to specify the file name of the resulting .qch file. -# The path specified is relative to the HTML output folder. - -QCH_FILE = - -# The QHP_NAMESPACE tag specifies the namespace to use when generating -# Qt Help Project output. For more information please see -# http://doc.trolltech.com/qthelpproject.html#namespace - -QHP_NAMESPACE = org.doxygen.Project - -# The QHP_VIRTUAL_FOLDER tag specifies the namespace to use when generating -# Qt Help Project output. For more information please see -# http://doc.trolltech.com/qthelpproject.html#virtual-folders - -QHP_VIRTUAL_FOLDER = doc - -# If QHP_CUST_FILTER_NAME is set, it specifies the name of a custom -# filter to add. For more information please see -# http://doc.trolltech.com/qthelpproject.html#custom-filters - -QHP_CUST_FILTER_NAME = - -# The QHP_CUST_FILT_ATTRS tag specifies the list of the attributes of -# the custom filter to add.For more information please see Qt -# Help Project / Custom Filters. - -QHP_CUST_FILTER_ATTRS = - -# The QHP_SECT_FILTER_ATTRS tag specifies the list of the attributes -# this project's filter section matches. Qt -# Help Project / Filter Attributes. - -QHP_SECT_FILTER_ATTRS = - -# If the GENERATE_QHP tag is set to YES, the QHG_LOCATION tag can -# be used to specify the location of Qt's qhelpgenerator. -# If non-empty doxygen will try to run qhelpgenerator on the generated -# .qhp file. - -QHG_LOCATION = - -# The DISABLE_INDEX tag can be used to turn on/off the condensed index at -# top of each HTML page. The value NO (the default) enables the index and -# the value YES disables it. - -DISABLE_INDEX = YES - -# This tag can be used to set the number of enum values (range [1..20]) -# that doxygen will group on one line in the generated HTML documentation. - -ENUM_VALUES_PER_LINE = 4 - -# The GENERATE_TREEVIEW tag is used to specify whether a tree-like index -# structure should be generated to display hierarchical information. -# If the tag value is set to FRAME, a side panel will be generated -# containing a tree-like index structure (just like the one that -# is generated for HTML Help). For this to work a browser that supports -# JavaScript, DHTML, CSS and frames is required (for instance Mozilla 1.0+, -# Netscape 6.0+, Internet explorer 5.0+, or Konqueror). Windows users are -# probably better off using the HTML help feature. Other possible values -# for this tag are: HIERARCHIES, which will generate the Groups, Directories, -# and Class Hierarchy pages using a tree view instead of an ordered list; -# ALL, which combines the behavior of FRAME and HIERARCHIES; and NONE, which -# disables this behavior completely. For backwards compatibility with previous -# releases of Doxygen, the values YES and NO are equivalent to FRAME and NONE -# respectively. - -GENERATE_TREEVIEW = YES - -# If the treeview is enabled (see GENERATE_TREEVIEW) then this tag can be -# used to set the initial width (in pixels) of the frame in which the tree -# is shown. - -TREEVIEW_WIDTH = 250 - -# Use this tag to change the font size of Latex formulas included -# as images in the HTML documentation. The default is 10. Note that -# when you change the font size after a successful doxygen run you need -# to manually remove any form_*.png images from the HTML output directory -# to force them to be regenerated. - -FORMULA_FONTSIZE = 10 - -#--------------------------------------------------------------------------- -# configuration options related to the LaTeX output -#--------------------------------------------------------------------------- - -# If the GENERATE_LATEX tag is set to YES (the default) Doxygen will -# generate Latex output. - -GENERATE_LATEX = NO - -# The LATEX_OUTPUT tag is used to specify where the LaTeX docs will be put. -# If a relative path is entered the value of OUTPUT_DIRECTORY will be -# put in front of it. If left blank `latex' will be used as the default path. - -LATEX_OUTPUT = latex - -# The LATEX_CMD_NAME tag can be used to specify the LaTeX command name to be -# invoked. If left blank `latex' will be used as the default command name. - -LATEX_CMD_NAME = latex - -# The MAKEINDEX_CMD_NAME tag can be used to specify the command name to -# generate index for LaTeX. If left blank `makeindex' will be used as the -# default command name. - -MAKEINDEX_CMD_NAME = makeindex - -# If the COMPACT_LATEX tag is set to YES Doxygen generates more compact -# LaTeX documents. This may be useful for small projects and may help to -# save some trees in general. - -COMPACT_LATEX = NO - -# The PAPER_TYPE tag can be used to set the paper type that is used -# by the printer. Possible values are: a4, a4wide, letter, legal and -# executive. If left blank a4wide will be used. - -PAPER_TYPE = letter - -# The EXTRA_PACKAGES tag can be to specify one or more names of LaTeX -# packages that should be included in the LaTeX output. - -EXTRA_PACKAGES = amsmath - -# The LATEX_HEADER tag can be used to specify a personal LaTeX header for -# the generated latex document. The header should contain everything until -# the first chapter. If it is left blank doxygen will generate a -# standard header. Notice: only use this tag if you know what you are doing! - -LATEX_HEADER = - -# If the PDF_HYPERLINKS tag is set to YES, the LaTeX that is generated -# is prepared for conversion to pdf (using ps2pdf). The pdf file will -# contain links (just like the HTML output) instead of page references -# This makes the output suitable for online browsing using a pdf viewer. - -PDF_HYPERLINKS = NO - -# If the USE_PDFLATEX tag is set to YES, pdflatex will be used instead of -# plain latex in the generated Makefile. Set this option to YES to get a -# higher quality PDF documentation. - -USE_PDFLATEX = NO - -# If the LATEX_BATCHMODE tag is set to YES, doxygen will add the \\batchmode. -# command to the generated LaTeX files. This will instruct LaTeX to keep -# running if errors occur, instead of asking the user for help. -# This option is also used when generating formulas in HTML. - -LATEX_BATCHMODE = NO - -# If LATEX_HIDE_INDICES is set to YES then doxygen will not -# include the index chapters (such as File Index, Compound Index, etc.) -# in the output. - -LATEX_HIDE_INDICES = NO - -#--------------------------------------------------------------------------- -# configuration options related to the RTF output -#--------------------------------------------------------------------------- - -# If the GENERATE_RTF tag is set to YES Doxygen will generate RTF output -# The RTF output is optimized for Word 97 and may not look very pretty with -# other RTF readers or editors. - -GENERATE_RTF = NO - -# The RTF_OUTPUT tag is used to specify where the RTF docs will be put. -# If a relative path is entered the value of OUTPUT_DIRECTORY will be -# put in front of it. If left blank `rtf' will be used as the default path. - -RTF_OUTPUT = rtf - -# If the COMPACT_RTF tag is set to YES Doxygen generates more compact -# RTF documents. This may be useful for small projects and may help to -# save some trees in general. - -COMPACT_RTF = NO - -# If the RTF_HYPERLINKS tag is set to YES, the RTF that is generated -# will contain hyperlink fields. The RTF file will -# contain links (just like the HTML output) instead of page references. -# This makes the output suitable for online browsing using WORD or other -# programs which support those fields. -# Note: wordpad (write) and others do not support links. - -RTF_HYPERLINKS = NO - -# Load stylesheet definitions from file. Syntax is similar to doxygen's -# config file, i.e. a series of assignments. You only have to provide -# replacements, missing definitions are set to their default value. - -RTF_STYLESHEET_FILE = - -# Set optional variables used in the generation of an rtf document. -# Syntax is similar to doxygen's config file. - -RTF_EXTENSIONS_FILE = - -#--------------------------------------------------------------------------- -# configuration options related to the man page output -#--------------------------------------------------------------------------- - -# If the GENERATE_MAN tag is set to YES (the default) Doxygen will -# generate man pages - -GENERATE_MAN = @do_man@ - -# The MAN_OUTPUT tag is used to specify where the man pages will be put. -# If a relative path is entered the value of OUTPUT_DIRECTORY will be -# put in front of it. If left blank `man' will be used as the default path. - -MAN_OUTPUT = man - -# The MAN_EXTENSION tag determines the extension that is added to -# the generated man pages (default is the subroutine's section .3) - -MAN_EXTENSION = .3 - -# If the MAN_LINKS tag is set to YES and Doxygen generates man output, -# then it will generate one additional man file for each entity -# documented in the real man page(s). These additional files -# only source the real man page, but without them the man command -# would be unable to find the correct page. The default is NO. - -MAN_LINKS = NO - -#--------------------------------------------------------------------------- -# configuration options related to the XML output -#--------------------------------------------------------------------------- - -# If the GENERATE_XML tag is set to YES Doxygen will -# generate an XML file that captures the structure of -# the code including all documentation. - -GENERATE_XML = @do_xml@ - -# The XML_OUTPUT tag is used to specify where the XML pages will be put. -# If a relative path is entered the value of OUTPUT_DIRECTORY will be -# put in front of it. If left blank `xml' will be used as the default path. - -XML_OUTPUT = xml - -# The XML_SCHEMA tag can be used to specify an XML schema, -# which can be used by a validating XML parser to check the -# syntax of the XML files. - -XML_SCHEMA = - -# The XML_DTD tag can be used to specify an XML DTD, -# which can be used by a validating XML parser to check the -# syntax of the XML files. - -XML_DTD = - -# If the XML_PROGRAMLISTING tag is set to YES Doxygen will -# dump the program listings (including syntax highlighting -# and cross-referencing information) to the XML output. Note that -# enabling this will significantly increase the size of the XML output. - -XML_PROGRAMLISTING = YES - -#--------------------------------------------------------------------------- -# configuration options for the AutoGen Definitions output -#--------------------------------------------------------------------------- - -# If the GENERATE_AUTOGEN_DEF tag is set to YES Doxygen will -# generate an AutoGen Definitions (see autogen.sf.net) file -# that captures the structure of the code including all -# documentation. Note that this feature is still experimental -# and incomplete at the moment. - -GENERATE_AUTOGEN_DEF = NO - -#--------------------------------------------------------------------------- -# configuration options related to the Perl module output -#--------------------------------------------------------------------------- - -# If the GENERATE_PERLMOD tag is set to YES Doxygen will -# generate a Perl module file that captures the structure of -# the code including all documentation. Note that this -# feature is still experimental and incomplete at the -# moment. - -GENERATE_PERLMOD = NO - -# If the PERLMOD_LATEX tag is set to YES Doxygen will generate -# the necessary Makefile rules, Perl scripts and LaTeX code to be able -# to generate PDF and DVI output from the Perl module output. - -PERLMOD_LATEX = NO - -# If the PERLMOD_PRETTY tag is set to YES the Perl module output will be -# nicely formatted so it can be parsed by a human reader. -# This is useful -# if you want to understand what is going on. -# On the other hand, if this -# tag is set to NO the size of the Perl module output will be much smaller -# and Perl will parse it just the same. - -PERLMOD_PRETTY = YES - -# The names of the make variables in the generated doxyrules.make file -# are prefixed with the string contained in PERLMOD_MAKEVAR_PREFIX. -# This is useful so different doxyrules.make files included by the same -# Makefile don't overwrite each other's variables. - -PERLMOD_MAKEVAR_PREFIX = - -#--------------------------------------------------------------------------- -# Configuration options related to the preprocessor -#--------------------------------------------------------------------------- - -# If the ENABLE_PREPROCESSING tag is set to YES (the default) Doxygen will -# evaluate all C-preprocessor directives found in the sources and include -# files. - -ENABLE_PREPROCESSING = YES - -# If the MACRO_EXPANSION tag is set to YES Doxygen will expand all macro -# names in the source code. If set to NO (the default) only conditional -# compilation will be performed. Macro expansion can be done in a controlled -# way by setting EXPAND_ONLY_PREDEF to YES. - -MACRO_EXPANSION = YES - -# If the EXPAND_ONLY_PREDEF and MACRO_EXPANSION tags are both set to YES -# then the macro expansion is limited to the macros specified with the -# PREDEFINED and EXPAND_AS_DEFINED tags. - -EXPAND_ONLY_PREDEF = NO - -# If the SEARCH_INCLUDES tag is set to YES (the default) the includes files -# in the INCLUDE_PATH (see below) will be search if a #include is found. - -SEARCH_INCLUDES = YES - -# The INCLUDE_PATH tag can be used to specify one or more directories that -# contain include files that are not input files but should be processed by -# the preprocessor. - -INCLUDE_PATH = - -# You can use the INCLUDE_FILE_PATTERNS tag to specify one or more wildcard -# patterns (like *.h and *.hpp) to filter out the header-files in the -# directories. If left blank, the patterns specified with FILE_PATTERNS will -# be used. - -INCLUDE_FILE_PATTERNS = - -# The PREDEFINED tag can be used to specify one or more macro names that -# are defined before the preprocessor is started (similar to the -D option of -# gcc). The argument of the tag is a list of macros of the form: name -# or name=definition (no spaces). If the definition and the = are -# omitted =1 is assumed. To prevent a macro definition from being -# undefined via #undef or recursively expanded use the := operator -# instead of the = operator. - -PREDEFINED = __cplusplus \ - __GTHREADS \ - _GLIBCXX_HAS_GTHREADS \ - __GXX_EXPERIMENTAL_CXX0X__ \ - _GLIBCXX_INCLUDE_AS_CXX0X \ - "_GLIBCXX_STD_P= " \ - "_GLIBCXX_STD_D= " \ - _GLIBCXX_STD=std \ - "_GLIBCXX_TR1= " \ - "_GLIBCXX_BEGIN_NAMESPACE_TR1= " \ - "_GLIBCXX_END_NAMESPACE_TR1= " \ - "_GLIBCXX_BEGIN_NAMESPACE(name)=namespace name { " \ - "_GLIBCXX_BEGIN_NESTED_NAMESPACE(name, unused)=namespace name { " \ - _GLIBCXX_END_NAMESPACE=} \ - _GLIBCXX_END_NESTED_NAMESPACE=} \ - "_GLIBCXX_TEMPLATE_ARGS=... " \ - _GLIBCXX_DEPRECATED \ - _GLIBCXX_USE_WCHAR_T \ - _GLIBCXX_USE_LONG_LONG \ - _GLIBCXX_USE_C99_STDINT_TR1 \ - _GLIBCXX_USE_SCHED_YIELD \ - _GLIBCXX_USE_NANOSLEEP \ - __glibcxx_function_requires=// \ - __glibcxx_class_requires=// \ - __glibcxx_class_requires2=// \ - __glibcxx_class_requires3=// \ - __glibcxx_class_requires4=// - -# If the MACRO_EXPANSION and EXPAND_ONLY_PREDEF tags are set to YES -# then this tag can be used to specify a list of macro names that -# should be expanded. The macro definition that is found in the -# sources will be used. Use the PREDEFINED tag if you want to use a -# different macro definition. - -EXPAND_AS_DEFINED = - -# If the SKIP_FUNCTION_MACROS tag is set to YES (the default) then -# doxygen's preprocessor will remove all function-like macros that are alone -# on a line, have an all uppercase name, and do not end with a semicolon. Such -# function macros are typically used for boiler-plate code, and will confuse -# the parser if not removed. - -SKIP_FUNCTION_MACROS = YES - -#--------------------------------------------------------------------------- -# Configuration::additions related to external references -#--------------------------------------------------------------------------- - -# The TAGFILES option can be used to specify one or more tagfiles. -# Optionally an initial location of the external documentation -# can be added for each tagfile. The format of a tag file without -# this location is as follows: -# -# TAGFILES = file1 file2 ... -# Adding location for the tag files is done as follows: -# -# TAGFILES = file1=loc1 "file2 = loc2" ... -# where "loc1" and "loc2" can be relative or absolute paths or -# URLs. If a location is present for each tag, the installdox tool -# does not have to be run to correct the links. -# Note that each tag file must have a unique name -# (where the name does NOT include the path) -# If a tag file is not located in the directory in which doxygen -# is run, you must also specify the path to the tagfile here. - -TAGFILES = - -# When a file name is specified after GENERATE_TAGFILE, doxygen will create -# a tag file that is based on the input files it reads. - -GENERATE_TAGFILE = @generate_tagfile@ - -# If the ALLEXTERNALS tag is set to YES all external classes will be listed -# in the class index. If set to NO only the inherited external classes -# will be listed. - -ALLEXTERNALS = YES - -# If the EXTERNAL_GROUPS tag is set to YES all external groups will be listed -# in the modules index. If set to NO, only the current project's groups will -# be listed. - -EXTERNAL_GROUPS = YES - -# The PERL_PATH should be the absolute path and name of the perl script -# interpreter (i.e. the result of `which perl'). - -PERL_PATH = /usr/bin/perl - -#--------------------------------------------------------------------------- -# Configuration options related to the dot tool -#--------------------------------------------------------------------------- - -# If the CLASS_DIAGRAMS tag is set to YES (the default) Doxygen will -# generate a inheritance diagram (in HTML, RTF and LaTeX) for classes with base -# or super classes. Setting the tag to NO turns the diagrams off. Note that -# this option is superseded by the HAVE_DOT option below. This is only a -# fallback. It is recommended to install and use dot, since it yields more -# powerful graphs. - -CLASS_DIAGRAMS = YES - -# You can define message sequence charts within doxygen comments using the \msc -# command. Doxygen will then run the mscgen tool (see -# http://www.mcternan.me.uk/mscgen/) to produce the chart and insert it in the -# documentation. The MSCGEN_PATH tag allows you to specify the directory where -# the mscgen tool resides. If left empty the tool is assumed to be found in the -# default search path. - -MSCGEN_PATH = - -# If set to YES, the inheritance and collaboration graphs will hide -# inheritance and usage relations if the target is undocumented -# or is not a class. - -HIDE_UNDOC_RELATIONS = NO - -# If you set the HAVE_DOT tag to YES then doxygen will assume the dot tool is -# available from the path. This tool is part of Graphviz, a graph visualization -# toolkit from AT&T and Lucent Bell Labs. The other options in this section -# have no effect if this option is set to NO (the default) - -HAVE_DOT = YES - -# By default doxygen will write a font called FreeSans.ttf to the -# output directory and reference it in all dot files that doxygen -# generates. This font does not include all possible unicode -# characters however, so when you need these (or just want a -# differently looking font) you can specify the font name using -# DOT_FONTNAME. You need need to make sure dot is able to find the -# font, which can be done by putting it in a standard location or by -# setting the DOTFONTPATH environment variable or by setting -# DOT_FONTPATH to the directory containing the font. - -DOT_FONTNAME = FreeSans - -# The DOT_FONTSIZE tag can be used to set the size of the font of dot graphs. -# The default size is 10pt. - -DOT_FONTSIZE = 10 - -# By default doxygen will tell dot to use the output directory to look for the -# FreeSans.ttf font (which doxygen will put there itself). If you specify a -# different font using DOT_FONTNAME you can set the path where dot -# can find it using this tag. - -DOT_FONTPATH = - -# If the CLASS_GRAPH and HAVE_DOT tags are set to YES then doxygen -# will generate a graph for each documented class showing the direct and -# indirect inheritance relations. Setting this tag to YES will force the -# the CLASS_DIAGRAMS tag to NO. - -CLASS_GRAPH = YES - -# If the COLLABORATION_GRAPH and HAVE_DOT tags are set to YES then doxygen -# will generate a graph for each documented class showing the direct and -# indirect implementation dependencies (inheritance, containment, and -# class references variables) of the class with other documented classes. - -COLLABORATION_GRAPH = NO - -# If the GROUP_GRAPHS and HAVE_DOT tags are set to YES then doxygen -# will generate a graph for groups, showing the direct groups dependencies - -GROUP_GRAPHS = YES - -# If the UML_LOOK tag is set to YES doxygen will generate inheritance and -# collaboration diagrams in a style similar to the OMG's Unified Modeling -# Language. - -UML_LOOK = NO - -# If set to YES, the inheritance and collaboration graphs will show the -# relations between templates and their instances. - -TEMPLATE_RELATIONS = YES - -# If the ENABLE_PREPROCESSING, SEARCH_INCLUDES, INCLUDE_GRAPH, and HAVE_DOT -# tags are set to YES then doxygen will generate a graph for each documented -# file showing the direct and indirect include dependencies of the file with -# other documented files. - -INCLUDE_GRAPH = NO - -# If the ENABLE_PREPROCESSING, SEARCH_INCLUDES, INCLUDED_BY_GRAPH, and -# HAVE_DOT tags are set to YES then doxygen will generate a graph for each -# documented header file showing the documented files that directly or -# indirectly include this file. - -INCLUDED_BY_GRAPH = NO - -# If the CALL_GRAPH and HAVE_DOT options are set to YES then -# doxygen will generate a call dependency graph for every global function -# or class method. Note that enabling this option will significantly increase -# the time of a run. So in most cases it will be better to enable call graphs -# for selected functions only using the \callgraph command. - -CALL_GRAPH = NO - -# If the CALLER_GRAPH and HAVE_DOT tags are set to YES then -# doxygen will generate a caller dependency graph for every global function -# or class method. Note that enabling this option will significantly increase -# the time of a run. So in most cases it will be better to enable caller -# graphs for selected functions only using the \callergraph command. - -CALLER_GRAPH = NO - -# If the GRAPHICAL_HIERARCHY and HAVE_DOT tags are set to YES then doxygen -# will graphical hierarchy of all classes instead of a textual one. - -GRAPHICAL_HIERARCHY = YES - -# If the DIRECTORY_GRAPH, SHOW_DIRECTORIES and HAVE_DOT tags are set to YES -# then doxygen will show the dependencies a directory has on other directories -# in a graphical way. The dependency relations are determined by the #include -# relations between the files in the directories. - -DIRECTORY_GRAPH = YES - -# The DOT_IMAGE_FORMAT tag can be used to set the image format of the images -# generated by dot. Possible values are png, jpg, or gif -# If left blank png will be used. - -DOT_IMAGE_FORMAT = png - -# The tag DOT_PATH can be used to specify the path where the dot tool can be -# found. If left blank, it is assumed the dot tool can be found in the path. - -DOT_PATH = - -# The DOTFILE_DIRS tag can be used to specify one or more directories that -# contain dot files that are included in the documentation (see the -# \dotfile command). - -DOTFILE_DIRS = - -# The DOT_GRAPH_MAX_NODES tag can be used to set the maximum number of -# nodes that will be shown in the graph. If the number of nodes in a graph -# becomes larger than this value, doxygen will truncate the graph, which is -# visualized by representing a node as a red box. Note that doxygen if the -# number of direct children of the root node in a graph is already larger than -# DOT_GRAPH_MAX_NODES then the graph will not be shown at all. Also note -# that the size of a graph can be further restricted by MAX_DOT_GRAPH_DEPTH. - -DOT_GRAPH_MAX_NODES = 50 - -# The MAX_DOT_GRAPH_DEPTH tag can be used to set the maximum depth of the -# graphs generated by dot. A depth value of 3 means that only nodes reachable -# from the root by following a path via at most 3 edges will be shown. Nodes -# that lay further from the root node will be omitted. Note that setting this -# option to 1 or 2 may greatly reduce the computation time needed for large -# code bases. Also note that the size of a graph can be further restricted by -# DOT_GRAPH_MAX_NODES. Using a depth of 0 means no depth restriction. - -MAX_DOT_GRAPH_DEPTH = 0 - -# Set the DOT_TRANSPARENT tag to YES to generate images with a transparent -# background. This is disabled by default, because dot on Windows does not -# seem to support this out of the box. Warning: Depending on the platform used, -# enabling this option may lead to badly anti-aliased labels on the edges of -# a graph (i.e. they become hard to read). - -DOT_TRANSPARENT = NO - -# Set the DOT_MULTI_TARGETS tag to YES allow dot to generate multiple output -# files in one run (i.e. multiple -o and -T options on the command line). This -# makes dot run faster, but since only newer versions of dot (>1.8.10) -# support this, this feature is disabled by default. - -DOT_MULTI_TARGETS = YES - -# If the GENERATE_LEGEND tag is set to YES (the default) Doxygen will -# generate a legend page explaining the meaning of the various boxes and -# arrows in the dot generated graphs. - -GENERATE_LEGEND = NO - -# If the DOT_CLEANUP tag is set to YES (the default) Doxygen will -# remove the intermediate dot files that are used to generate -# the various graphs. - -DOT_CLEANUP = YES - -#--------------------------------------------------------------------------- -# Options related to the search engine -#--------------------------------------------------------------------------- - -# The SEARCHENGINE tag specifies whether or not a search engine should be -# used. If set to NO the values of all tags below this one will be ignored. - -SEARCHENGINE = NO diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/README b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/README deleted file mode 100644 index ea5dcfcdd..000000000 --- a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/README +++ /dev/null @@ -1,3 +0,0 @@ -The HTML documentation in this folder is generated from the XML sources. - -To change or edit, please edit the XML sources in the ../xml directory. diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/api.html b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/api.html deleted file mode 100644 index af2598365..000000000 --- a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/api.html +++ /dev/null @@ -1,54 +0,0 @@ - - -API and Source Level Documentation
    API and Source Level Documentation
    Prev  Next

    API and Source Level Documentation

    Copyright © - 2008 - - FSF - -

    -The GNU C++ library sources have been specially formatted so that with the -proper invocation of another tool (Doxygen), a set of HTML pages -are generated from the sources files themselves. The resultant -documentation is referred to as Source Level Documentation, and is -useful for examining the signatures of public member functions for -the library classes, finding out what is in a particular include -file, looking at inheritance diagrams, etc. -

    -The source-level documentation for the most recent releases can be -viewed online: -

    -This generated HTML collection, as above, is also available for download in the libstdc++ snapshots directory at - <URL:ftp://gcc.gnu.org/pub/gcc/libstdc++/doxygen/>. - You will almost certainly need to use one of the - mirror sites to download - the tarball. After unpacking, simply load libstdc++-html-*/index.html - into a browser. -

    -Documentation for older releases is available for download only, not -online viewing. -

    -In addition, an initial set of man pages are also available in the -same place as the HTML collections. Start with C++Intro(3). -

    Prev Up Next
     Home 
    diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/bk02.html b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/bk02.html deleted file mode 100644 index e765d9eae..000000000 --- a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/bk02.html +++ /dev/null @@ -1,3 +0,0 @@ - - -
    Prev   Next

    Table of Contents

    API and Source Level Documentation
    Prev   Next
    Backwards Compatibility Home API and Source Level Documentation
    diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/bk03.html b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/bk03.html deleted file mode 100644 index 1d08fc98e..000000000 --- a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/bk03.html +++ /dev/null @@ -1,3 +0,0 @@ - - -
    Prev   Next

    Table of Contents

    Frequently Asked Questions
    Prev   Next
    API and Source Level Documentation Home Frequently Asked Questions
    diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/lwg-active.html b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/lwg-active.html deleted file mode 100644 index 94b57c0a6..000000000 --- a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/lwg-active.html +++ /dev/null @@ -1,19718 +0,0 @@ - - - - - -C++ Standard Library Active Issues List - - - - - - - - - - - - - - - - - - - -
    Doc. no.N2727=08-0237
    Date:2008-08-24
    Project:Programming Language C++
    Reply to:Howard Hinnant <howard.hinnant@gmail.com>
    -

    C++ Standard Library Active Issues List (Revision R59)

    - -

    Reference ISO/IEC IS 14882:1998(E)

    -

    Also see:

    - -

    The purpose of this document is to record the status of issues - which have come before the Library Working Group (LWG) of the ANSI - (J16) and ISO (WG21) C++ Standards Committee. Issues represent - potential defects in the ISO/IEC IS 14882:1998(E) document. Issues - are not to be used to request new features.

    - -

    This document contains only library issues which are actively being - considered by the Library Working Group. That is, issues which have a - status of New, Open, - Ready, and Review. See - Library Defect Reports List for issues considered defects and - Library Closed Issues List for issues considered closed.

    - -

    The issues in these lists are not necessarily formal ISO Defect - Reports (DR's). While some issues will eventually be elevated to - official Defect Report status, other issues will be disposed of in - other ways. See Issue Status.

    - -

    This document is in an experimental format designed for both - viewing via a world-wide web browser and hard-copy printing. It - is available as an HTML file for browsing or PDF file for - printing.

    - -

    Prior to Revision 14, library issues lists existed in two slightly - different versions; a Committee Version and a Public - Version. Beginning with Revision 14 the two versions were combined - into a single version.

    - -

    This document includes [bracketed italicized notes] as a - reminder to the LWG of current progress on issues. Such notes are - strictly unofficial and should be read with caution as they may be - incomplete or incorrect. Be aware that LWG support for a particular - resolution can quickly change if new viewpoints or killer examples are - presented in subsequent discussions.

    - -

    For the most current official version of this document see - http://www.open-std.org/jtc1/sc22/wg21/. - Requests for further information about this document should include - the document number above, reference ISO/IEC 14882:1998(E), and be - submitted to Information Technology Industry Council (ITI), 1250 Eye - Street NW, Washington, DC 20005.

    - -

    Public information as to how to obtain a copy of the C++ Standard, - join the standards committee, submit an issue, or comment on an issue - can be found in the comp.std.c++ FAQ. - Public discussion of C++ Standard related issues occurs on news:comp.std.c++. -

    - -

    For committee members, files available on the committee's private - web site include the HTML version of the Standard itself. HTML - hyperlinks from this issues list to those files will only work for - committee members who have downloaded them into the same disk - directory as the issues list files.

    - -

    Revision History

    -
      -
    • R59: -2008-08-22 pre-San Francisco mailing. -
        -
      • Summary:
          -
        • 192 open issues, up by 9.
          • -
        • 686 closed issues, up by 0.
          • -
        • 878 issues total, up by 9.
          • -
        • -
      • Details:
        • -
      -
      • -
    • R58: -2008-07-28 mid-term mailing. -
        -
      • Summary:
          -
        • 183 open issues, up by 12.
          • -
        • 686 closed issues, down by 4.
          • -
        • 869 issues total, up by 8.
          • -
        • -
      • Details:
          -
        • Added the following New issues: 862, 863, 864, 865, 866, 867, 868, 869.
          • -
        • Changed the following issues from Pending NAD Editorial to NAD Editorial: 393, 557, 592, 754, 757.
          • -
        • Changed the following issues from Pending WP to Open: 644.
          • -
        • Changed the following issues from WP to Ready: 387, 629.
          • -
        • Changed the following issues from Pending NAD Editorial to Review: 709.
          • -
        • -
      -
      • -
    • R57: -2008-06-27 post-Sophia Antipolis mailing. - -
      • -
    • R56: -2008-05-16 pre-Sophia Antipolis mailing. - -
      • -
    • R55: -2008-03-14 post-Bellevue mailing. - -
      • -
    • R54: -2008-02-01 pre-Bellevue mailing. -
        -
      • Summary:
          -
        • 206 open issues, up by 23.
          • -
        • 581 closed issues, up by 0.
          • -
        • 787 issues total, up by 23.
          • -
        • -
      • Details:
          -
        • Added the following New issues: 765, 766, 767, 768, 769, 770, 771, 772, 773, 774, 775, 776, 777, 778, 779, 780, 781, 782, 783, 784, 785, 786, 787.
          • -
        • Changed the following issues from NAD Future to Dup: 105, 348.
          • -
        • Changed the following issues from NAD Future to NAD Editorial: 353.
          • -
        • Changed the following issues from New to NAD Editorial: 697.
          • -
        • Changed the following issues from NAD Future to Open: 388.
          • -
        • Changed the following issues from Open to Tentatively Ready: 527.
          • -
        • -
      -
      • -
    • R53: -2007-12-09 mid-term mailing. -
        -
      • Summary:
          -
        • 183 open issues, up by 11.
          • -
        • 581 closed issues, down by 1.
          • -
        • 764 issues total, up by 10.
          • -
        • -
      • Details:
        • -
      -
      • -
    • R52: -2007-10-19 post-Kona mailing. - -
      • -
    • R51: -2007-09-09 pre-Kona mailing. - -
      • -
    • R50: -2007-08-05 post-Toronto mailing. -
        -
      • Summary:
          -
        • 153 open issues, down by 5.
          • -
        • 555 closed issues, up by 17.
          • -
        • 708 issues total, up by 12.
          • -
        • -
      • Details:
          -
        • Added the following New issues: 697, 698, 699, 700, 701, 702, 703, 704, 705, 706, 707, 708.
          • -
        • Changed the following issues from New to NAD: 583, 584, 662.
          • -
        • Changed the following issues from Open to NAD: 528.
          • -
        • Changed the following issues from New to NAD Editorial: 637, 647, 658, 690.
          • -
        • Changed the following issues from Open to NAD Editorial: 525.
          • -
        • Changed the following issues from Pending NAD Editorial to NAD Editorial: 553, 571, 591, 633, 636, 641, 642, 648, 649, 656.
          • -
        • Changed the following issues from New to Open: 579, 631, 680.
          • -
        • Changed the following issues from Pending WP to Open: 258.
          • -
        • Changed the following issues from Ready to Pending WP: 644.
          • -
        • Changed the following issues from New to Ready: 577, 660.
          • -
        • Changed the following issues from Open to Ready: 488.
          • -
        • Changed the following issues from Open to Review: 518.
          • -
        • Changed the following issues from Ready to TRDec: 604.
          • -
        • Changed the following issues from DR to WP: 453.
          • -
        • Changed the following issues from Ready to WP: 531, 551, 566, 628, 640, 643, 646.
          • -
        • -
      -
      • -
    • R49: -2007-06-23 pre-Toronto mailing. -
        -
      • Summary:
          -
        • 158 open issues, up by 13.
          • -
        • 538 closed issues, up by 7.
          • -
        • 696 issues total, up by 20.
          • -
        • -
      • Details:
          -
        • Added the following New issues: 677, 678, 679, 680, 681, 682, 684, 685, 686, 687, 688, 689, 690, 691, 692, 693, 694, 695, 696.
          • -
        • Added the following Pending NAD Editorial issues: 683.
          • -
        • Changed the following issues from New to NAD Editorial: 587.
          • -
        • Changed the following issues from Open to NAD Editorial: 590.
          • -
        • Changed the following issues from New to Pending NAD Editorial: 636, 642, 648, 649.
          • -
        • -
      -
      • -
    • R48: -2007-05-06 post-Oxford mailing. - -
      • -
    • R47: -2007-03-09 pre-Oxford mailing. - -
      • -
    • R46: -2007-01-12 mid-term mailing. -
        -
      • Summary:
          -
        • 141 open issues, up by 11.
          • -
        • 478 closed issues, down by 1.
          • -
        • 619 issues total, up by 10.
          • -
        • -
      • Details:
        • -
      -
      • -
    • R45: -2006-11-03 post-Portland mailing. - -
      • -
    • R44: -2006-09-08 pre-Portland mailing. -
        -
      • Summary:
          -
        • 130 open issues, up by 6.
          • -
        • 462 closed issues, down by 1.
          • -
        • 592 issues total, up by 5.
          • -
        • -
      • Details:
        • -
      -
      • -
    • R43: -2006-06-23 mid-term mailing. -
        -
      • Summary:
          -
        • 124 open issues, up by 14.
          • -
        • 463 closed issues, down by 1.
          • -
        • 587 issues total, up by 13.
          • -
        • -
      • Details:
        • -
      -
      • -
    • R42: -2006-04-21 post-Berlin mailing. - -
      • -
    • R41: -2006-02-24 pre-Berlin mailing. -
        -
      • Summary:
          -
        • 126 open issues, up by 31.
          • -
        • 440 closed issues, up by 0.
          • -
        • 566 issues total, up by 31.
          • -
        • -
      • Details:
          -
        • Added new issues 536-566.
          • -
        • Moved 342 from Ready to Open.
          • -
        • Reopened 309.
          • -
        • -
      -
      • -
    • R40: -2005-12-16 mid-term mailing. -
        -
      • Summary:
          -
        • 95 open issues.
          • -
        • 440 closed issues.
          • -
        • 535 issues total.
          • -
        • -
      • Details:
        • -
      -
      • -
    • R39: -2005-10-14 post-Mont Tremblant mailing. -Added new issues 526-528. -Moved issues 280, 461, 464, 465, 467, 468, 474, 496 from Ready to WP as per the vote from Mont Tremblant. -Moved issues 247, 294, 342, 362, 369, 371, 376, 384, 475, 478, 495, 497 from Review to Ready. -Moved issues 498, 504, 506, 509, 510, 511, 512, 513, 514 from New to Open. -Moved issues 505, 507, 508, 519 from New to Ready. -Moved issue 500 from New to NAD. -Moved issue 518 from New to Review. -
      • -
    • R38: -2005-07-03 pre-Mont Tremblant mailing. -Merged open TR1 issues in 504-522. -Added new issues 523-523 -
      • -
    • R37: -2005-06 mid-term mailing. -Added new issues 498-503. -
      • -
    • R36: -2005-04 post-Lillehammer mailing. All issues in "ready" status except -for 454 were moved to "DR" status, and all issues -previously in "DR" status were moved to "WP". -
      • -
    • R35: -2005-03 pre-Lillehammer mailing. -
      • -
    • R34: -2005-01 mid-term mailing. Added new issues 488-494. -
      • -
    • R33: -2004-11 post-Redmond mailing. Reflects actions taken in Redmond. -
      • -
    • R32: -2004-09 pre-Redmond mailing: reflects new proposed resolutions and -new issues received after the 2004-07 mailing. Added -new issues 479-481. -
      • -
    • R31: -2004-07 mid-term mailing: reflects new proposed resolutions and -new issues received after the post-Sydney mailing. Added -new issues 463-478. -
      • -
    • R30: -Post-Sydney mailing: reflects decisions made at the Sydney meeting. -Voted all "Ready" issues from R29 into the working paper. -Added new issues 460-462. -
      • -
    • R29: -Pre-Sydney mailing. Added new issues 441-457. -
      • -
    • R28: -Post-Kona mailing: reflects decisions made at the Kona meeting. -Added new issues 432-440. -
      • -
    • R27: -Pre-Kona mailing. Added new issues 404-431. -
      • -
    • R26: -Post-Oxford mailing: reflects decisions made at the Oxford meeting. -All issues in Ready status were voted into DR status. All issues in -DR status were voted into WP status. -
      • -
    • R25: -Pre-Oxford mailing. Added new issues 390-402. -
      • -
    • R24: -Post-Santa Cruz mailing: reflects decisions made at the Santa Cruz -meeting. All Ready issues from R23 with the exception of 253, which has been given a new proposed resolution, were -moved to DR status. Added new issues 383-389. (Issues 387-389 were discussed -at the meeting.) Made progress on issues 225, 226, 229: 225 and 229 have been moved to Ready status, and the only remaining -concerns with 226 involve wording. -
      • -
    • R23: -Pre-Santa Cruz mailing. Added new issues 367-382. -Moved issues in the TC to TC status. -
      • -
    • R22: -Post-Curaçao mailing. Added new issues 362-366. -
      • -
    • R21: -Pre-Curaçao mailing. Added new issues 351-361. -
      • -
    • R20: -Post-Redmond mailing; reflects actions taken in Redmond. Added -new issues 336-350, of which issues -347-350 were added since Redmond, hence -not discussed at the meeting. - -All Ready issues were moved to DR status, with the exception of issues -284, 241, and 267. - -Noteworthy issues discussed at Redmond include -120 202, 226, 233, -270, 253, 254, 323. -
      • -
    • R19: -Pre-Redmond mailing. Added new issues -323-335. -
      • -
    • R18: -Post-Copenhagen mailing; reflects actions taken in Copenhagen. -Added new issues 312-317, and discussed -new issues 271-314. - -Changed status of issues -103 118 136 153 -165 171 183 184 -185 186 214 221 -234 237 243 248 -251 252 256 260 -261 262 263 265 -268 -to DR. - -Changed status of issues -49 109 117 182 -228 230 232 235 -238 241 242 250 -259 264 266 267 -271 272 273 275 -281 284 285 286 -288 292 295 297 -298 301 303 306 -307 308 312 -to Ready. - -Closed issues -111 277 279 287 -289 293 302 313 -314 -as NAD. - -
      • -
    • R17: -Pre-Copenhagen mailing. Converted issues list to XML. Added proposed -resolutions for issues 49, 76, 91, 235, 250, 267. -Added new issues 278-311. -
      • -
    • R16: -post-Toronto mailing; reflects actions taken in Toronto. Added new -issues 265-277. Changed status of issues -3, 8, 9, 19, -26, 31, 61, -63, 86, 108, -112, 114, 115, -122, 127, 129, -134, 137, 142, -144, 146, 147, -159, 164, 170, -181, 199, 208, -209, 210, 211, -212, 217, 220, -222, 223, 224, -227 to "DR". Reopened issue 23. Reopened -issue 187. Changed issues 2 and -4 to NAD. Fixed a typo in issue 17. Fixed -issue 70: signature should be changed both places it -appears. Fixed issue 160: previous version didn't fix -the bug in enough places. -
      • -
    • R15: -pre-Toronto mailing. Added issues -233-264. Some small HTML formatting -changes so that we pass Weblint tests. -
      • -
    • R14: -post-Tokyo II mailing; reflects committee actions taken in -Tokyo. Added issues 228 to 232. (00-0019R1/N1242) -
      • -
    • R13: -pre-Tokyo II updated: Added issues 212 to 227. -
      • -
    • R12: -pre-Tokyo II mailing: Added issues 199 to -211. Added "and paragraph 5" to the proposed resolution -of issue 29. Add further rationale to issue -178. -
      • -
    • R11: -post-Kona mailing: Updated to reflect LWG and full committee actions -in Kona (99-0048/N1224). Note changed resolution of issues -4 and 38. Added issues 196 -to 198. Closed issues list split into "defects" and -"closed" documents. Changed the proposed resolution of issue -4 to NAD, and changed the wording of proposed resolution -of issue 38. -
      • -
    • R10: -pre-Kona updated. Added proposed resolutions 83, -86, 91, 92, -109. Added issues 190 to -195. (99-0033/D1209, 14 Oct 99) -
      • -
    • R9: -pre-Kona mailing. Added issues 140 to -189. Issues list split into separate "active" and -"closed" documents. (99-0030/N1206, 25 Aug 99) -
      • -
    • R8: -post-Dublin mailing. Updated to reflect LWG and full committee actions -in Dublin. (99-0016/N1193, 21 Apr 99) -
      • -
    • R7: -pre-Dublin updated: Added issues 130, 131, -132, 133, 134, -135, 136, 137, -138, 139 (31 Mar 99) -
      • -
    • R6: -pre-Dublin mailing. Added issues 127, 128, -and 129. (99-0007/N1194, 22 Feb 99) -
      • -
    • R5: -update issues 103, 112; added issues -114 to 126. Format revisions to prepare -for making list public. (30 Dec 98) -
      • -
    • R4: -post-Santa Cruz II updated: Issues 110, -111, 112, 113 added, several -issues corrected. (22 Oct 98) -
      • -
    • R3: -post-Santa Cruz II: Issues 94 to 109 -added, many issues updated to reflect LWG consensus (12 Oct 98) -
      • -
    • R2: -pre-Santa Cruz II: Issues 73 to 93 added, -issue 17 updated. (29 Sep 98) -
      • -
    • R1: -Correction to issue 55 resolution, 60 code -format, 64 title. (17 Sep 98) -
      • -
    - -

    Issue Status

    - -

    New - The issue has not yet been - reviewed by the LWG. Any Proposed Resolution is purely a - suggestion from the issue submitter, and should not be construed as - the view of LWG.

    - -

    Open - The LWG has discussed the issue - but is not yet ready to move the issue forward. There are several - possible reasons for open status:

    -
      -
    • Consensus may have not yet have been reached as to how to deal - with the issue.
      • -
    • Informal consensus may have been reached, but the LWG awaits - exact Proposed Resolution wording for review.
      • -
    • The LWG wishes to consult additional technical experts before - proceeding.
      • -
    • The issue may require further study.
      • -
    - -

    A Proposed Resolution for an open issue is still not be - construed as the view of LWG. Comments on the current state of - discussions are often given at the end of open issues in an italic - font. Such comments are for information only and should not be given - undue importance.

    - -

    Dup - The LWG has reached consensus that - the issue is a duplicate of another issue, and will not be further - dealt with. A Rationale identifies the duplicated issue's - issue number.

    - -

    NAD - The LWG has reached consensus that - the issue is not a defect in the Standard.

    - -

    NAD Editorial - The LWG has reached consensus that - the issue can either be handled editorially, or is handled by a paper (usually - linked to in the rationale).

    - -

    NAD Future - In addition to the regular - status, the LWG believes that this issue should be revisited at the - next revision of the standard.

    - -

    Review - Exact wording of a - Proposed Resolution is now available for review on an issue - for which the LWG previously reached informal consensus.

    - -

    Tentatively Ready - The issue has - been reviewed online, but not in a meeting, and some support has been formed - for the proposed resolution. Tentatively Ready issues may be moved to Ready - and forwarded to full committee within the same meeting. Unlike Ready issues - they will be reviewed in subcommittee prior to forwarding to full committee.

    - -

    Ready - The LWG has reached consensus - that the issue is a defect in the Standard, the Proposed - Resolution is correct, and the issue is ready to forward to the - full committee for further action as a Defect Report (DR).

    - -

    DR - (Defect Report) - The full J16 - committee has voted to forward the issue to the Project Editor to be - processed as a Potential Defect Report. The Project Editor reviews - the issue, and then forwards it to the WG21 Convenor, who returns it - to the full committee for final disposition. This issues list - accords the status of DR to all these Defect Reports regardless of - where they are in that process.

    - -

    TC - (Technical Corrigenda) - The full - WG21 committee has voted to accept the Defect Report's Proposed - Resolution as a Technical Corrigenda. Action on this issue is thus - complete and no further action is possible under ISO rules.

    - -

    TRDec - (Decimal TR defect) - The - LWG has voted to accept the Defect Report's Proposed - Resolution into the Decimal TR. Action on this issue is thus - complete and no further action is expected.

    - -

    WP - (Working Paper) - The proposed - resolution has not been accepted as a Technical Corrigendum, but - the full WG21 committee has voted to apply the Defect Report's Proposed - Resolution to the working paper.

    - -

    Pending - This is a status qualifier. When prepended to - a status this indicates the issue has been - processed by the committee, and a decision has been made to move the issue to - the associated unqualified status. However for logistical reasons the indicated - outcome of the issue has not yet appeared in the latest working paper. - -

    Issues are always given the status of New when - they first appear on the issues list. They may progress to - Open or Review while the LWG - is actively working on them. When the LWG has reached consensus on - the disposition of an issue, the status will then change to - Dup, NAD, or - Ready as appropriate. Once the full J16 committee votes to - forward Ready issues to the Project Editor, they are given the - status of Defect Report ( DR). These in turn may - become the basis for Technical Corrigenda (TC), - or are closed without action other than a Record of Response - (RR ). The intent of this LWG process is that - only issues which are truly defects in the Standard move to the - formal ISO DR status. -

    - - -

    Active Issues

    -
    -

    23. Num_get overflow result

    -

    Section: 22.2.2.1.2 [facet.num.get.virtuals] Status: Review - Submitter: Nathan Myers Date: 1998-08-06

    -

    View other active issues in [facet.num.get.virtuals].

    -

    View all other issues in [facet.num.get.virtuals].

    -

    View all issues with Review status.

    -

    Discussion:

    -

    The current description of numeric input does not account for the -possibility of overflow. This is an implicit result of changing the -description to rely on the definition of scanf() (which fails to -report overflow), and conflicts with the documented behavior of -traditional and current implementations.

    - -

    Users expect, when reading a character sequence that results in a -value unrepresentable in the specified type, to have an error -reported. The standard as written does not permit this.

    - -

    Further comments from Dietmar:

    - -

    -I don't feel comfortable with the proposed resolution to issue 23: It -kind of simplifies the issue to much. Here is what is going on: -

    - -

    -Currently, the behavior of numeric overflow is rather counter intuitive -and hard to trace, so I will describe it briefly: -

    - -
      -
    • - According to 22.2.2.1.2 [facet.num.get.virtuals] - paragraph 11 failbit is set if scanf() would - return an input error; otherwise a value is converted to the rules - of scanf. -
      • -
    • - scanf() is defined in terms of fscanf(). -
      • -
    • - fscanf() returns an input failure if during conversion no - character matching the conversion specification could be extracted - before reaching EOF. This is the only reason for fscanf() - to fail due to an input error and clearly does not apply to the case - of overflow. -
      • -
    • - Thus, the conversion is performed according to the rules of - fscanf() which basically says that strtod, - strtol(), etc. are to be used for the conversion. -
      • -
    • - The strtod(), strtol(), etc. functions consume as - many matching characters as there are and on overflow continue to - consume matching characters but also return a value identical to - the maximum (or minimum for signed types if there was a leading minus) - value of the corresponding type and set errno to ERANGE. -
      • -
    • - Thus, according to the current wording in the standard, overflows - can be detected! All what is to be done is to check errno - after reading an element and, of course, clearing errno - before trying a conversion. With the current wording, it can be - detected whether the overflow was due to a positive or negative - number for signed types. -
      • -
    - -

    Further discussion from Redmond:

    - -

    The basic problem is that we've defined our behavior, -including our error-reporting behavior, in terms of C90. However, -C90's method of reporting overflow in scanf is not technically an -"input error". The strto_* functions are more precise.

    - -

    There was general consensus that failbit should be set -upon overflow. We considered three options based on this:

    -
      -
    1. Set failbit upon conversion error (including overflow), and - don't store any value.
      2. -
    2. Set failbit upon conversion error, and also set errno to - indicated the precise nature of the error.
      3. -
    3. Set failbit upon conversion error. If the error was due to - overflow, store +-numeric_limits<T>::max() as an - overflow indication.
      4. -
    - -

    Straw poll: (1) 5; (2) 0; (3) 8.

    - - -

    Discussed at Lillehammer. General outline of what we want the - solution to look like: we want to say that overflow is an error, and - provide a way to distinguish overflow from other kinds of errors. - Choose candidate field the same way scanf does, but don't describe - the rest of the process in terms of format. If a finite input field - is too large (positive or negative) to be represented as a finite - value, then set failbit and assign the nearest representable value. - Bill will provide wording.

    - -

    -Discussed at Toronto: -N2327 -is in alignment with the direction we wanted to go with in Lillehammer. Bill -to work on. -

    - - - -

    Proposed resolution:

    - -

    -Change 22.2.2.1.2 [facet.num.get.virtuals], end of p3: -

    - -
    -

    -Stage 3: The result of stage 2 processing can be one of -The sequence of chars accumulated in stage 2 (the field) is -converted to a numeric value by the rules of one of the functions declared -in the header <cstdlib>: -

    -
      -
    • -A sequence of chars has been accumulated in stage 2 that is -converted (according to the rules of scanf) to a value of the -type of val. This value is stored in val and ios_base::goodbit is -stored in err. -For a signed integer value, the function strtoll. -
      • -
    • -The sequence of chars accumulated in stage 2 would have caused -scanf to report an input failure. ios_base::failbit is -assigned to err. -For an unsigned integer value, the function strtoull. -
      • -
    • -For a floating-point value, the function strtold. -
      • -
    -

    -The numeric value to be stored can be one of: -

    -
      -
    • zero, if the conversion function fails to convert the entire field. -ios_base::failbit is assigned to err.
      • -
    • the most positive representable value, if the field represents a value -too large positive to be represented in val. ios_base::failbit is assigned -to err.
      • -
    • the most negative representable value (zero for unsigned integer), if -the field represents a value too large negative to be represented in val. -ios_base::failbit is assigned to err.
      • -
    • the converted value, otherwise.
      • -
    - -

    -The resultant numeric value is stored in val. -

    -
    - -

    -Change 22.2.2.1.2 [facet.num.get.virtuals], p6-p7: -

    - -
    -
    iter_type do_get(iter_type in, iter_type end, ios_base& str, 
-                 ios_base::iostate& err, bool& val) const;
-
    -
    -

    --6- Effects: If -(str.flags()&ios_base::boolalpha)==0 then input -proceeds as it would for a long except that if a value is being -stored into val, the value is determined according to the -following: If the value to be stored is 0 then false is stored. -If the value is 1 then true is stored. Otherwise -err|=ios_base::failbit is performed and no value true is -stored. and ios_base::failbit is assigned to err. -

    -

    --7- Otherwise target sequences are determined "as if" by calling the -members falsename() and truename() of the facet -obtained by use_facet<numpunct<charT> ->(str.getloc()). Successive characters in the range -[in,end) (see 23.1.1) are obtained and matched -against corresponding positions in the target sequences only as -necessary to identify a unique match. The input iterator in is -compared to end only when necessary to obtain a character. If and -only if a target sequence is uniquely matched, val is set to the -corresponding value. Otherwise false is stored and ios_base::failbit -is assigned to err. -

    -
    -
    - - - - - -
    -

    96. Vector<bool> is not a container

    -

    Section: 23.2.6 [vector] Status: Open - Submitter: AFNOR Date: 1998-10-07

    -

    View all other issues in [vector].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    vector<bool> is not a container as its reference and -pointer types are not references and pointers.

    - -

    Also it forces everyone to have a space optimization instead of a -speed one.

    - -

    See also: 99-0008 == N1185 Vector<bool> is -Nonconforming, Forces Optimization Choice.

    - -

    [In Santa Cruz the LWG felt that this was Not A Defect.]

    - - -

    [In Dublin many present felt that failure to meet Container -requirements was a defect. There was disagreement as to whether -or not the optimization requirements constituted a defect.]

    - - -

    [The LWG looked at the following resolutions in some detail: -
    -     * Not A Defect.
    -     * Add a note explaining that vector<bool> does not meet -Container requirements.
    -     * Remove vector<bool>.
    -     * Add a new category of container requirements which -vector<bool> would meet.
    -     * Rename vector<bool>.
    -
    -No alternative had strong, wide-spread, support and every alternative -had at least one "over my dead body" response.
    -
    -There was also mention of a transition scheme something like (1) add -vector_bool and deprecate vector<bool> in the next standard. (2) -Remove vector<bool> in the following standard.]

    - - -

    [Modifying container requirements to permit returning proxies -(thus allowing container requirements conforming vector<bool>) -was also discussed.]

    - - -

    [It was also noted that there is a partial but ugly workaround in -that vector<bool> may be further specialized with a customer -allocator.]

    - - -

    [Kona: Herb Sutter presented his paper J16/99-0035==WG21/N1211, -vector<bool>: More Problems, Better Solutions. Much discussion -of a two step approach: a) deprecate, b) provide replacement under a -new name. LWG straw vote on that: 1-favor, 11-could live with, 2-over -my dead body. This resolution was mentioned in the LWG report to the -full committee, where several additional committee members indicated -over-my-dead-body positions.]

    - - -

    Discussed at Lillehammer. General agreement that we should - deprecate vector<bool> and introduce this functionality under - a different name, e.g. bit_vector. This might make it possible to - remove the vector<bool> specialization in the standard that comes - after C++0x. There was also a suggestion that - in C++0x we could additional say that it's implementation defined - whether vector<bool> refers to the specialization or to the - primary template, but there wasn't general agreement that this was a - good idea.

    - -

    We need a paper for the new bit_vector class.

    - - - - -

    Proposed resolution:

    -

    -We now have: -N2050 -and -N2160. -

    - -

    [ -Batavia: The LWG feels we need something closer to SGI's bitvector to ease migration -from vector<bool>. Although some of the funcitonality from -N2050 -could well be used in such a template. The concern is easing the API migration for those -users who want to continue using a bit-packed container. Alan and Beman to work. -]

    - - - - - - -
    -

    128. Need open_mode() function for file stream, string streams, file buffers, and string  buffers

    -

    Section: 27.7 [string.streams], 27.8 [file.streams] Status: Open - Submitter: Angelika Langer Date: 1999-02-22

    -

    View all other issues in [string.streams].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    The following question came from Thorsten Herlemann:

    - -
    -

    You can set a mode when constructing or opening a file-stream or - filebuf, e.g. ios::in, ios::out, ios::binary, ... But how can I get - that mode later on, e.g. in my own operator << or operator - >> or when I want to check whether a file-stream or - file-buffer object passed as parameter is opened for input or output - or binary? Is there no possibility? Is this a design-error in the - standard C++ library?

    -
    - -

    It is indeed impossible to find out what a stream's or stream -buffer's open mode is, and without that knowledge you don't know -how certain operations behave. Just think of the append mode.

    - -

    Both streams and stream buffers should have a mode() function that returns the -current open mode setting.

    - -

    [ -post Bellevue: Alisdair requested to re-Open. -]

    - - - - -

    Proposed resolution:

    -

    For stream buffers, add a function to the base class as a non-virtual function -qualified as const to 27.5.2 [streambuf]:

    - -

        openmode mode() const;

    - -

        Returns the current open mode.

    - -

    With streams, I'm not sure what to suggest. In principle, the mode -could already be returned by ios_base, but the mode is only -initialized for file and string stream objects, unless I'm overlooking -anything. For this reason it should be added to the most derived -stream classes. Alternatively, it could be added to basic_ios -and would be default initialized in basic_ios<>::init().

    - - -

    Rationale:

    -

    This might be an interesting extension for some future, but it is -not a defect in the current standard. The Proposed Resolution is -retained for future reference.

    - - - - - -
    -

    180. Container member iterator arguments constness has unintended consequences

    -

    Section: 21.3 [basic.string] Status: Ready - Submitter: Dave Abrahams Date: 1999-07-01

    -

    View other active issues in [basic.string].

    -

    View all other issues in [basic.string].

    -

    View all issues with Ready status.

    -

    Discussion:

    -

    It is the constness of the container which should control whether -it can be modified through a member function such as erase(), not the -constness of the iterators. The iterators only serve to give -positioning information.

    - -

    Here's a simple and typical example problem which is currently very -difficult or impossible to solve without the change proposed -below.

    - -

    Wrap a standard container C in a class W which allows clients to -find and read (but not modify) a subrange of (C.begin(), C.end()]. The -only modification clients are allowed to make to elements in this -subrange is to erase them from C through the use of a member function -of W.

    - -

    [ -post Bellevue, Alisdair adds: -]

    - - -
    -

    -This issue was implemented by -N2350 -for everything but basic_string. -

    - -

    -Note that the specific example in this issue (basic_string) is the one place -we forgot to amend in -N2350, -so we might open this issue for that -single container? -

    -
    - -

    [ -Sophia Antipolis: -]

    - - -
    -

    -This was a fix that was intended for all standard library containers, -and has been done for other containers, but string was missed. -

    -

    -The wording updated. -

    -

    -We did not make the change in replace, because this change would affect -the implementation because the string may be written into. This is an -issue that should be taken up by concepts. -

    -

    -We note that the supplied wording addresses the initializer list provided in -N2679. -

    -
    - - - -

    Proposed resolution:

    -

    -Update the following signature in the basic_string class template definition in -21.3 [basic.string], p5: -

    -
    namespace std {
-  template<class charT, class traits = char_traits<charT>,
-    class Allocator = allocator<charT> >
-  class basic_string {
-
-    ...
-
-    iterator insert(const_iterator p, charT c);
-    void insert(const_iterator p, size_type n, charT c);
-    template<class InputIterator>
-      void insert(const_iterator p, InputIterator first, InputIterator last);
-    void insert(const_iterator p, initializer_list<charT>);
-
-    ...
-
-    iterator erase(const_iterator const_position);
-    iterator erase(const_iterator first, const_iterator last);
-
-    ...
-
-  };
-}
-
    - -

    -Update the following signatures in 21.3.6.4 [string::insert]: -

    - -
    iterator insert(const_iterator p, charT c);
-void insert(const_iterator p, size_type n, charT c);
-template<class InputIterator>
-  void insert(const_iterator p, InputIterator first, InputIterator last);
-void insert(const_iterator p, initializer_list<charT>);
-
    - -

    -Update the following signatures in 21.3.6.5 [string::erase]: -

    - -
    iterator erase(const_iterator const_position);
-iterator erase(const_iterator first, const_iterator last);
-
    - - - -

    Rationale:

    -

    The issue was discussed at length. It was generally agreed that 1) -There is no major technical argument against the change (although -there is a minor argument that some obscure programs may break), and -2) Such a change would not break const correctness. The concerns about -making the change were 1) it is user detectable (although only in -boundary cases), 2) it changes a large number of signatures, and 3) it -seems more of a design issue that an out-and-out defect.

    - -

    The LWG believes that this issue should be considered as part of a -general review of const issues for the next revision of the -standard. Also see issue 200.

    - - - - -
    -

    190. min() and max() functions should be std::binary_functions

    -

    Section: 25.3.7 [alg.min.max] Status: Open - Submitter: Mark Rintoul Date: 1999-08-26

    -

    View all other issues in [alg.min.max].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    Both std::min and std::max are defined as template functions. This -is very different than the definition of std::plus (and similar -structs) which are defined as function objects which inherit -std::binary_function.
    -
    - This lack of inheritance leaves std::min and std::max somewhat useless in standard library algorithms which require -a function object that inherits std::binary_function.

    - -

    [ -post Bellevue: Alisdair requested to re-Open. -]

    - - - - -

    Rationale:

    -

    Although perhaps an unfortunate design decision, the omission is not a defect -in the current standard.  A future standard may wish to consider additional -function objects.

    - - - - -
    -

    255. Why do basic_streambuf<>::pbump() and gbump() take an int?

    -

    Section: 27.5.2 [streambuf] Status: Open - Submitter: Martin Sebor Date: 2000-08-12

    -

    View all other issues in [streambuf].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -The basic_streambuf members gbump() and pbump() are specified to take an -int argument. This requirement prevents the functions from effectively -manipulating buffers larger than std::numeric_limits<int>::max() -characters. It also makes the common use case for these functions -somewhat difficult as many compilers will issue a warning when an -argument of type larger than int (such as ptrdiff_t on LLP64 -architectures) is passed to either of the function. Since it's often the -result of the subtraction of two pointers that is passed to the -functions, a cast is necessary to silence such warnings. Finally, the -usage of a native type in the functions signatures is inconsistent with -other member functions (such as sgetn() and sputn()) that manipulate the -underlying character buffer. Those functions take a streamsize argument. -

    - - -

    Proposed resolution:

    -

    -Change the signatures of these functions in the synopsis of template -class basic_streambuf (27.5.2) and in their descriptions (27.5.2.3.1, p4 -and 27.5.2.3.2, p4) to take a streamsize argument. -

    - -

    -Although this change has the potential of changing the ABI of the -library, the change will affect only platforms where int is different -than the definition of streamsize. However, since both functions are -typically inline (they are on all known implementations), even on such -platforms the change will not affect any user code unless it explicitly -relies on the existing type of the functions (e.g., by taking their -address). Such a possibility is IMO quite remote. -

    - -

    -Alternate Suggestion from Howard Hinnant, c++std-lib-7780: -

    - -

    -This is something of a nit, but I'm wondering if streamoff wouldn't be a -better choice than streamsize. The argument to pbump and gbump MUST be -signed. But the standard has this to say about streamsize -(27.4.1/2/Footnote): -

    - -

    - [Footnote: streamsize is used in most places where ISO C would use - size_t. Most of the uses of streamsize could use size_t, except for - the strstreambuf constructors, which require negative values. It - should probably be the signed type corresponding to size_t (which is - what Posix.2 calls ssize_t). --- end footnote] -

    - -

    -This seems a little weak for the argument to pbump and gbump. Should we -ever really get rid of strstream, this footnote might go with it, along -with the reason to make streamsize signed. -

    - - -

    Rationale:

    -

    The LWG believes this change is too big for now. We may wish to -reconsider this for a future revision of the standard. One -possibility is overloading pbump, rather than changing the -signature.

    -

    [ -[2006-05-04: Reopened at the request of Chris (Krzysztof ?elechowski)] -]

    - - - - - -
    -

    290. Requirements to for_each and its function object

    -

    Section: 25.1.4 [alg.foreach] Status: Open - Submitter: Angelika Langer Date: 2001-01-03

    -

    View all other issues in [alg.foreach].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    The specification of the for_each algorithm does not have a -"Requires" section, which means that there are no -restrictions imposed on the function object whatsoever. In essence it -means that I can provide any function object with arbitrary side -effects and I can still expect a predictable result. In particular I -can expect that the function object is applied exactly last - first -times, which is promised in the "Complexity" section. -

    - -

    I don't see how any implementation can give such a guarantee -without imposing requirements on the function object. -

    - -

    Just as an example: consider a function object that removes -elements from the input sequence. In that case, what does the -complexity guarantee (applies f exactly last - first times) mean? -

    - -

    One can argue that this is obviously a nonsensical application and -a theoretical case, which unfortunately it isn't. I have seen -programmers shooting themselves in the foot this way, and they did not -understand that there are restrictions even if the description of the -algorithm does not say so. -

    -

    [Lillehammer: This is more general than for_each. We don't want - the function object in transform invalidiating iterators - either. There should be a note somewhere in clause 17 (17, not 25) - saying that user code operating on a range may not invalidate - iterators unless otherwise specified. Bill will provide wording.]

    - - - -

    Proposed resolution:

    - - - - - - -
    -

    299. Incorrect return types for iterator dereference

    -

    Section: 24.1.4 [bidirectional.iterators], 24.1.5 [random.access.iterators] Status: Open - Submitter: John Potter Date: 2001-01-22

    -

    View all other issues in [bidirectional.iterators].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -In section 24.1.4 [bidirectional.iterators], -Table 75 gives the return type of *r-- as convertible to T. This is -not consistent with Table 74 which gives the return type of *r++ as -T&. *r++ = t is valid while *r-- = t is invalid. -

    - -

    -In section 24.1.5 [random.access.iterators], -Table 76 gives the return type of a[n] as convertible to T. This is -not consistent with the semantics of *(a + n) which returns T& by -Table 74. *(a + n) = t is valid while a[n] = t is invalid. -

    - -

    -Discussion from the Copenhagen meeting: the first part is -uncontroversial. The second part, operator[] for Random Access -Iterators, requires more thought. There are reasonable arguments on -both sides. Return by value from operator[] enables some potentially -useful iterators, e.g. a random access "iota iterator" (a.k.a -"counting iterator" or "int iterator"). There isn't any obvious way -to do this with return-by-reference, since the reference would be to a -temporary. On the other hand, reverse_iterator takes an -arbitrary Random Access Iterator as template argument, and its -operator[] returns by reference. If we decided that the return type -in Table 76 was correct, we would have to change -reverse_iterator. This change would probably affect user -code. -

    - -

    -History: the contradiction between reverse_iterator and the -Random Access Iterator requirements has been present from an early -stage. In both the STL proposal adopted by the committee -(N0527==94-0140) and the STL technical report (HPL-95-11 (R.1), by -Stepanov and Lee), the Random Access Iterator requirements say that -operator[]'s return value is "convertible to T". In N0527 -reverse_iterator's operator[] returns by value, but in HPL-95-11 -(R.1), and in the STL implementation that HP released to the public, -reverse_iterator's operator[] returns by reference. In 1995, the -standard was amended to reflect the contents of HPL-95-11 (R.1). The -original intent for operator[] is unclear. -

    - -

    -In the long term it may be desirable to add more fine-grained -iterator requirements, so that access method and traversal strategy -can be decoupled. (See "Improved Iterator Categories and -Requirements", N1297 = 01-0011, by Jeremy Siek.) Any decisions -about issue 299 should keep this possibility in mind. -

    - -

    Further discussion: I propose a compromise between John Potter's -resolution, which requires T& as the return type of -a[n], and the current wording, which requires convertible to -T. The compromise is to keep the convertible to T -for the return type of the expression a[n], but to also add -a[n] = t as a valid expression. This compromise "saves" the -common case uses of random access iterators, while at the same time -allowing iterators such as counting iterator and caching file -iterators to remain random access iterators (iterators where the -lifetime of the object returned by operator*() is tied to the -lifetime of the iterator). -

    - -

    -Note that the compromise resolution necessitates a change to -reverse_iterator. It would need to use a proxy to support -a[n] = t. -

    - -

    -Note also there is one kind of mutable random access iterator that -will no longer meet the new requirements. Currently, iterators that -return an r-value from operator[] meet the requirements for a -mutable random access iterartor, even though the expression a[n] = -t will only modify a temporary that goes away. With this proposed -resolution, a[n] = t will be required to have the same -operational semantics as *(a + n) = t. -

    - - - -

    Proposed resolution:

    - -

    -In section 24.1.4 [lib.bidirectdional.iterators], change the return -type in table 75 from "convertible to T" to -T&. -

    - -

    -In section 24.1.5 [lib.random.access.iterators], change the -operational semantics for a[n] to " the r-value of -a[n] is equivalent to the r-value of *(a + -n)". Add a new row in the table for the expression a[n] = t -with a return type of convertible to T and operational semantics of -*(a + n) = t. -

    - -

    [Lillehammer: Real problem, but should be addressed as part of - iterator redesign]

    - - - - - - - - -
    -

    309. Does sentry catch exceptions?

    -

    Section: 27.6 [iostream.format] Status: Open - Submitter: Martin Sebor Date: 2001-03-19

    -

    View all other issues in [iostream.format].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -The descriptions of the constructors of basic_istream<>::sentry -(27.6.1.1.3 [istream::sentry]) and basic_ostream<>::sentry -(27.6.2.4 [ostream::sentry]) do not explain what the functions do in -case an exception is thrown while they execute. Some current -implementations allow all exceptions to propagate, others catch them -and set ios_base::badbit instead, still others catch some but let -others propagate. -

    - -

    -The text also mentions that the functions may call setstate(failbit) -(without actually saying on what object, but presumably the stream -argument is meant). That may have been fine for -basic_istream<>::sentry prior to issue 195, since -the function performs an input operation which may fail. However, -issue 195 amends 27.6.1.1.3 [istream::sentry], p2 to -clarify that the function should actually call setstate(failbit | -eofbit), so the sentence in p3 is redundant or even somewhat -contradictory. -

    - -

    -The same sentence that appears in 27.6.2.4 [ostream::sentry], p3 -doesn't seem to be very meaningful for basic_istream<>::sentry -which performs no input. It is actually rather misleading since it -would appear to guide library implementers to calling -setstate(failbit) when os.tie()->flush(), the only called function, -throws an exception (typically, it's badbit that's set in response to -such an event). -

    - -

    Additional comments from Martin, who isn't comfortable with the - current proposed resolution (see c++std-lib-11530)

    - -

    -The istream::sentry ctor says nothing about how the function -deals with exemptions (27.6.1.1.2, p1 says that the class is -responsible for doing "exception safe"(*) prefix and suffix -operations but it doesn't explain what level of exception -safety the class promises to provide). The mockup example -of a "typical implementation of the sentry ctor" given in -27.6.1.1.2, p6, removed in ISO/IEC 14882:2003, doesn't show -exception handling, either. Since the ctor is not classified -as a formatted or unformatted input function, the text in -27.6.1.1, p1 through p4 does not apply. All this would seem -to suggest that the sentry ctor should not catch or in any -way handle exceptions thrown from any functions it may call. -Thus, the typical implementation of an istream extractor may -look something like [1]. -

    - -

    -The problem with [1] is that while it correctly sets ios::badbit -if an exception is thrown from one of the functions called from -the sentry ctor, if the sentry ctor reaches EOF while extracting -whitespace from a stream that has eofbit or failbit set in -exceptions(), it will cause an ios::failure to be thrown, which -will in turn cause the extractor to set ios::badbit. -

    - -

    -The only straightforward way to prevent this behavior is to -move the definition of the sentry object in the extractor -above the try block (as suggested by the example in 22.2.8, -p9 and also indirectly supported by 27.6.1.3, p1). See [2]. -But such an implementation will allow exceptions thrown from -functions called from the ctor to freely propagate to the -caller regardless of the setting of ios::badbit in the stream -object's exceptions(). -

    - -

    -So since neither [1] nor [2] behaves as expected, the only -possible solution is to have the sentry ctor catch exceptions -thrown from called functions, set badbit, and propagate those -exceptions if badbit is also set in exceptions(). (Another -solution exists that deals with both kinds of sentries, but -the code is non-obvious and cumbersome -- see [3].) -

    - -

    -Please note that, as the issue points out, current libraries -do not behave consistently, suggesting that implementors are -not quite clear on the exception handling in istream::sentry, -despite the fact that some LWG members might feel otherwise. -(As documented by the parenthetical comment here: -http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1480.html#309) -

    - -

    -Also please note that those LWG members who in Copenhagen -felt that "a sentry's constructor should not catch exceptions, -because sentries should only be used within (un)formatted input -functions and that exception handling is the responsibility of -those functions, not of the sentries," as noted here -http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2001/n1310.html#309 -would in effect be either arguing for the behavior described -in [1] or for extractors implemented along the lines of [3]. -

    - -

    -The original proposed resolution (Revision 25 of the issues -list) clarifies the role of the sentry ctor WRT exception -handling by making it clear that extractors (both library -or user-defined) should be implemented along the lines of -[2] (as opposed to [1]) and that no exception thrown from -the callees should propagate out of either function unless -badbit is also set in exceptions(). -

    - - -

    [1] Extractor that catches exceptions thrown from sentry:

    - -
    -
    struct S { long i; };
-
-istream& operator>> (istream &strm, S &s)
-{
-    ios::iostate err = ios::goodbit;
-    try {
-        const istream::sentry guard (strm, false);
-        if (guard) {
-            use_facet<num_get<char> >(strm.getloc ())
-                .get (istreambuf_iterator<char>(strm),
-                      istreambuf_iterator<char>(),
-                      strm, err, s.i);
-        }
-    }
-    catch (...) {
-        bool rethrow;
-        try {
-            strm.setstate (ios::badbit);
-            rethrow = false;
-        }
-        catch (...) {
-            rethrow = true;
-        }
-        if (rethrow)
-            throw;
-    }
-    if (err)
-        strm.setstate (err);
-    return strm;
-}
-
    -
    - -

    [2] Extractor that propagates exceptions thrown from sentry:

    - -
    -
    istream& operator>> (istream &strm, S &s)
-{
-    istream::sentry guard (strm, false);
-    if (guard) {
-        ios::iostate err = ios::goodbit;
-        try {
-            use_facet<num_get<char> >(strm.getloc ())
-                .get (istreambuf_iterator<char>(strm),
-                      istreambuf_iterator<char>(),
-                      strm, err, s.i);
-        }
-        catch (...) {
-            bool rethrow;
-            try {
-                strm.setstate (ios::badbit);
-                rethrow = false;
-            }
-            catch (...) {
-                rethrow = true;
-            }
-            if (rethrow)
-                throw;
-        }
-        if (err)
-            strm.setstate (err);
-    }
-    return strm;
-}
-
    -
    - -

    -[3] Extractor that catches exceptions thrown from sentry -but doesn't set badbit if the exception was thrown as a -result of a call to strm.clear(). -

    - -
    -
    istream& operator>> (istream &strm, S &s)
-{
-    const ios::iostate state = strm.rdstate ();
-    const ios::iostate except = strm.exceptions ();
-    ios::iostate err = std::ios::goodbit;
-    bool thrown = true;
-    try {
-        const istream::sentry guard (strm, false);
-        thrown = false;
-        if (guard) {
-            use_facet<num_get<char> >(strm.getloc ())
-                .get (istreambuf_iterator<char>(strm),
-                      istreambuf_iterator<char>(),
-                      strm, err, s.i);
-        }
-    }
-    catch (...) {
-        if (thrown && state & except)
-            throw;
-        try {
-            strm.setstate (ios::badbit);
-            thrown = false;
-        }
-        catch (...) {
-            thrown = true;
-        }
-        if (thrown)
-            throw;
-    }
-    if (err)
-        strm.setstate (err);
-
-    return strm;
-}
-
    -
    - -

    -[Pre-Berlin] Reopened at the request of Paolo Carlini and Steve Clamage. -

    - -

    -[Pre-Portland] A relevant newsgroup post: -

    - -

    -The current proposed resolution of issue #309 -(http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#309) is -unacceptable. I write commerical software and coding around this -makes my code ugly, non-intuitive, and requires comments referring -people to this very issue. Following is the full explanation of my -experience. -

    -

    -In the course of writing software for commercial use, I constructed -std::ifstream's based on user-supplied pathnames on typical POSIX -systems. -

    -

    -It was expected that some files that opened successfully might not read -successfully -- such as a pathname which actually refered to a -directory. Intuitively, I expected the streambuffer underflow() code -to throw an exception in this situation, and recent implementations of -libstdc++'s basic_filebuf do just that (as well as many of my own -custom streambufs). -

    -

    -I also intuitively expected that the istream code would convert these -exceptions to the "badbit' set on the stream object, because I had not -requested exceptions. I refer to 27.6.1.1. P4. -

    -

    -However, this was not the case on at least two implementations -- if -the first thing I did with an istream was call operator>>( T& ) for T -among the basic arithmetic types and std::string. Looking further I -found that the sentry's constructor was invoking the exception when it -pre-scanned for whitespace, and the extractor function (operator>>()) -was not catching exceptions in this situation. -

    -

    -So, I was in a situation where setting 'noskipws' would change the -istream's behavior even though no characters (whitespace or not) could -ever be successfully read. -

    -

    -Also, calling .peek() on the istream before calling the extractor() -changed the behavior (.peek() had the effect of setting the badbit -ahead of time). -

    -

    -I found this all to be so inconsistent and inconvenient for me and my -code design, that I filed a bugzilla entry for libstdc++. I was then -told that the bug cannot be fixed until issue #309 is resolved by the -committee. -

    - - - -

    Proposed resolution:

    - - -

    Rationale:

    -

    The LWG agrees there is minor variation between implementations, - but believes that it doesn't matter. This is a rarely used corner - case. There is no evidence that this has any commercial importance - or that it causes actual portability problems for customers trying - to write code that runs on multiple implementations.

    - - - - - -
    -

    342. seek and eofbit

    -

    Section: 27.6.1.3 [istream.unformatted] Status: Open - Submitter: Howard Hinnant Date: 2001-10-09

    -

    View all other issues in [istream.unformatted].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    I think we have a defect.

    - -

    According to lwg issue 60 which is now a dr, the -description of seekg in 27.6.1.3 [istream.unformatted] paragraph 38 now looks -like:

    - -

    -Behaves as an unformatted input function (as described in 27.6.1.3, -paragraph 1), except that it does not count the number of characters -extracted and does not affect the value returned by subsequent calls to -gcount(). After constructing a sentry object, if fail() != true, -executes rdbuf()->pubseekpos( pos). -

    - -

    And according to lwg issue 243 which is also now a dr, -27.6.1.3, paragraph 1 looks like:

    - -

    -Each unformatted input function begins execution by constructing an -object of class sentry with the default argument noskipws (second) -argument true. If the sentry object returns true, when converted to a -value of type bool, the function endeavors to obtain the requested -input. Otherwise, if the sentry constructor exits by throwing an -exception or if the sentry object returns false, when converted to a -value of type bool, the function returns without attempting to obtain -any input. In either case the number of extracted characters is set to -0; unformatted input functions taking a character array of non-zero -size as an argument shall also store a null character (using charT()) -in the first location of the array. If an exception is thrown during -input then ios::badbit is turned on in *this'ss error state. If -(exception()&badbit)!= 0 then the exception is rethrown. It also counts -the number of characters extracted. If no exception has been thrown it -ends by storing the count in a member object and returning the value -specified. In any event the sentry object is destroyed before leaving -the unformatted input function. -

    - -

    And finally 27.6.1.1.2/5 says this about sentry:

    - -

    -If, after any preparation is completed, is.good() is true, ok_ != false -otherwise, ok_ == false. -

    - -

    -So although the seekg paragraph says that the operation proceeds if -!fail(), the behavior of unformatted functions says the operation -proceeds only if good(). The two statements are contradictory when only -eofbit is set. I don't think the current text is clear which condition -should be respected. -

    - -

    Further discussion from Redmond:

    - -

    PJP: It doesn't seem quite right to say that seekg is -"unformatted". That makes specific claims about sentry that -aren't quite appropriate for seeking, which has less fragile failure -modes than actual input. If we do really mean that it's unformatted -input, it should behave the same way as other unformatted input. On -the other hand, "principle of least surprise" is that seeking from EOF -ought to be OK.

    - -

    -Pre-Berlin: Paolo points out several problems with the proposed resolution in -Ready state: -

    - -
      -
    • It should apply to both overloads of seekg.
      • -
    • tellg has similar issues, except that it should not call clear().
      • -
    • The point about clear() seems to apply to seekp().
      • -
    • Depending on the outcome of 419 -if the sentry -sets failbit when it finds eofbit already set, then -you can never seek away from the end of stream.
      • -
    - - - -

    Proposed resolution:

    - -

    Change 27.6.1.3 [istream.unformatted] to:

    -

    -Behaves as an unformatted input function (as described in 27.6.1.3, -paragraph 1), except that it does not count the number of characters -extracted, does not affect the value returned by subsequent calls to -gcount(), and does not examine the value returned by the sentry -object. After constructing a sentry object, if fail() != -true, executes rdbuf()->pubseekpos(pos). In -case of success, the function calls clear(). -In case of failure, the function calls setstate(failbit) -(which may throw ios_base::failure). -

    - -

    [Lillehammer: Matt provided wording.]

    - - - - -

    Rationale:

    -

    In C, fseek does clear EOF. This is probably what most users would - expect. We agree that having eofbit set should not deter a seek, - and that a successful seek should clear eofbit. Note - that fail() is true only if failbit - or badbit is set, so using !fail(), rather - than good(), satisfies this goal.

    - - - - - -
    -

    343. Unspecified library header dependencies

    -

    Section: 21 [strings], 23 [containers], 27 [input.output] Status: Open - Submitter: Martin Sebor Date: 2001-10-09

    -

    View all other issues in [strings].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -The synopses of the C++ library headers clearly show which names are -required to be defined in each header. Since in order to implement the -classes and templates defined in these headers declarations of other -templates (but not necessarily their definitions) are typically -necessary the standard in 17.4.4, p1 permits library implementers to -include any headers needed to implement the definitions in each header. -

    - -

    -For instance, although it is not explicitly specified in the synopsis of -<string>, at the point of definition of the std::basic_string template -the declaration of the std::allocator template must be in scope. All -current implementations simply include <memory> from within <string>, -either directly or indirectly, to bring the declaration of -std::allocator into scope. -

    - -

    -Additionally, however, some implementation also include <istream> and -<ostream> at the top of <string> to bring the declarations of -std::basic_istream and std::basic_ostream into scope (which are needed -in order to implement the string inserter and extractor operators -(21.3.7.9 [lib.string.io])). Other implementations only include -<iosfwd>, since strictly speaking, only the declarations and not the -full definitions are necessary. -

    - -

    -Obviously, it is possible to implement <string> without actually -providing the full definitions of all the templates std::basic_string -uses (std::allocator, std::basic_istream, and std::basic_ostream). -Furthermore, not only is it possible, doing so is likely to have a -positive effect on compile-time efficiency. -

    - -

    -But while it may seem perfectly reasonable to expect a program that uses -the std::basic_string insertion and extraction operators to also -explicitly include <istream> or <ostream>, respectively, it doesn't seem -reasonable to also expect it to explicitly include <memory>. Since -what's reasonable and what isn't is highly subjective one would expect -the standard to specify what can and what cannot be assumed. -Unfortunately, that isn't the case. -

    - -

    The examples below demonstrate the issue.

    - -

    Example 1:

    - -

    It is not clear whether the following program is complete:

    - -
    #include <string>
-
-extern std::basic_ostream<char> &strm;
-
-int main () {
-    strm << std::string ("Hello, World!\n");
-}
-
    - -

    or whether one must explicitly include <memory> or -<ostream> (or both) in addition to <string> in order for -the program to compile.

    - - -

    Example 2:

    - -

    Similarly, it is unclear whether the following program is complete:

    - -
    #include <istream>
-
-extern std::basic_iostream<char> &strm;
-
-int main () {
-    strm << "Hello, World!\n";
-}
-
    - -

    -or whether one needs to explicitly include <ostream>, and -perhaps even other headers containing the definitions of other -required templates:

    - -
    #include <ios>
-#include <istream>
-#include <ostream>
-#include <streambuf>
-
-extern std::basic_iostream<char> &strm;
-
-int main () {
-    strm << "Hello, World!\n";
-}
-
    - -

    Example 3:

    - -

    Likewise, it seems unclear whether the program below is complete:

    -
    #include <iterator>
-
-bool foo (std::istream_iterator<int> a, std::istream_iterator<int> b)
-{
-    return a == b;
-}
-
-int main () { }
-
    - -

    or whether one should be required to include <istream>.

    - -

    There are many more examples that demonstrate this lack of a -requirement. I believe that in a good number of cases it would be -unreasonable to require that a program explicitly include all the -headers necessary for a particular template to be specialized, but I -think that there are cases such as some of those above where it would -be desirable to allow implementations to include only as much as -necessary and not more.

    - -

    [ -post Bellevue: -]

    - - -
    -Position taken in prior reviews is that the idea of a table of header -dependencies is a good one. Our view is that a full paper is needed to -do justice to this, and we've made that recommendation to the issue -author. -
    - - - -

    Proposed resolution:

    -

    -For every C++ library header, supply a minimum set of other C++ library -headers that are required to be included by that header. The proposed -list is below (C++ headers for C Library Facilities, table 12 in -17.4.1.2, p3, are omitted): -

    - -
    +------------+--------------------+
-| C++ header |required to include |
-+============+====================+
-|<algorithm> |                    |
-+------------+--------------------+
-|<bitset>    |                    |
-+------------+--------------------+
-|<complex>   |                    |
-+------------+--------------------+
-|<deque>     |<memory>            |
-+------------+--------------------+
-|<exception> |                    |
-+------------+--------------------+
-|<fstream>   |<ios>               |
-+------------+--------------------+
-|<functional>|                    |
-+------------+--------------------+
-|<iomanip>   |<ios>               |
-+------------+--------------------+
-|<ios>       |<streambuf>         |
-+------------+--------------------+
-|<iosfwd>    |                    |
-+------------+--------------------+
-|<iostream>  |<istream>, <ostream>|
-+------------+--------------------+
-|<istream>   |<ios>               |
-+------------+--------------------+
-|<iterator>  |                    |
-+------------+--------------------+
-|<limits>    |                    |
-+------------+--------------------+
-|<list>      |<memory>            |
-+------------+--------------------+
-|<locale>    |                    |
-+------------+--------------------+
-|<map>       |<memory>            |
-+------------+--------------------+
-|<memory>    |                    |
-+------------+--------------------+
-|<new>       |<exception>         |
-+------------+--------------------+
-|<numeric>   |                    |
-+------------+--------------------+
-|<ostream>   |<ios>               |
-+------------+--------------------+
-|<queue>     |<deque>             |
-+------------+--------------------+
-|<set>       |<memory>            |
-+------------+--------------------+
-|<sstream>   |<ios>, <string>     |
-+------------+--------------------+
-|<stack>     |<deque>             |
-+------------+--------------------+
-|<stdexcept> |                    |
-+------------+--------------------+
-|<streambuf> |<ios>               |
-+------------+--------------------+
-|<string>    |<memory>            |
-+------------+--------------------+
-|<strstream> |                    |
-+------------+--------------------+
-|<typeinfo>  |<exception>         |
-+------------+--------------------+
-|<utility>   |                    |
-+------------+--------------------+
-|<valarray>  |                    |
-+------------+--------------------+
-|<vector>    |<memory>            |
-+------------+--------------------+
-
    - - -

    Rationale:

    -

    The portability problem is real. A program that works correctly on -one implementation might fail on another, because of different header -dependencies. This problem was understood before the standard was -completed, and it was a conscious design choice.

    -

    One possible way to deal with this, as a library extension, would -be an <all> header.

    - -

    -Hinnant: It's time we dealt with this issue for C++0X. Reopened. -

    - - - - - - - -
    -

    382. codecvt do_in/out result

    -

    Section: 22.2.1.4 [locale.codecvt] Status: Open - Submitter: Martin Sebor Date: 2002-08-30

    -

    View all other issues in [locale.codecvt].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -It seems that the descriptions of codecvt do_in() and do_out() leave -sufficient room for interpretation so that two implementations of -codecvt may not work correctly with the same filebuf. Specifically, -the following seems less than adequately specified: -

    - -
      -
    1. - the conditions under which the functions terminate -
      2. -
    2. - precisely when the functions return ok -
      3. -
    3. - precisely when the functions return partial -
      4. -
    4. - the full set of conditions when the functions return error -
      5. -
    - -
      -
    1. - 22.2.1.4.2 [locale.codecvt.virtuals], p2 says this about the effects of the - function: ...Stops if it encounters a character it cannot - convert... This assumes that there *is* a character to - convert. What happens when there is a sequence that doesn't form a - valid source character, such as an unassigned or invalid UNICODE - character, or a sequence that cannot possibly form a character - (e.g., the sequence "\xc0\xff" in UTF-8)? -
      2. -
    2. - Table 53 says that the function returns codecvt_base::ok - to indicate that the function(s) "completed the conversion." - Suppose that the source sequence is "\xc0\x80" in UTF-8, - with from pointing to '\xc0' and (from_end==from + 1). - It is not clear whether the return value should be ok - or partial (see below). -
      3. -
    3. - Table 53 says that the function returns codecvt_base::partial - if "not all source characters converted." With the from pointers - set up the same way as above, it is not clear whether the return - value should be partial or ok (see above). -
      4. -
    4. - Table 53, in the row describing the meaning of error mistakenly - refers to a "from_type" character, without the symbol from_type - having been defined. Most likely, the word "source" character - is intended, although that is not sufficient. The functions - may also fail when they encounter an invalid source sequence - that cannot possibly form a valid source character (e.g., as - explained in bullet 1 above). -
      5. -
    -

    -Finally, the conditions described at the end of 22.2.1.4.2 [locale.codecvt.virtuals], p4 don't seem to be possible: -

    -

    - "A return value of partial, if (from_next == from_end), - indicates that either the destination sequence has not - absorbed all the available destination elements, or that - additional source elements are needed before another - destination element can be produced." -

    -

    -If the value is partial, it's not clear to me that (from_next -==from_end) could ever hold if there isn't enough room -in the destination buffer. In order for (from_next==from_end) to -hold, all characters in that range must have been successfully -converted (according to 22.2.1.4.2 [locale.codecvt.virtuals], p2) and since there are no -further source characters to convert, no more room in the -destination buffer can be needed. -

    -

    -It's also not clear to me that (from_next==from_end) could ever -hold if additional source elements are needed to produce another -destination character (not element as incorrectly stated in the -text). partial is returned if "not all source characters have -been converted" according to Table 53, which also implies that -(from_next==from) does NOT hold. -

    -

    -Could it be that the intended qualifying condition was actually -(from_next != from_end), i.e., that the sentence was supposed -to read -

    -

    - "A return value of partial, if (from_next != from_end),..." -

    -

    -which would make perfect sense, since, as far as I understand it, -partial can only occur if (from_next != from_end)? -

    -

    [Lillehammer: Defer for the moment, but this really needs to be - fixed. Right now, the description of codecvt is too vague for it to - be a useful contract between providers and clients of codecvt - facets. (Note that both vendors and users can be both providers and - clients of codecvt facets.) The major philosophical issue is whether - the standard should only describe mappings that take a single wide - character to multiple narrow characters (and vice versa), or whether - it should describe fully general N-to-M conversions. When the - original standard was written only the former was contemplated, but - today, in light of the popularity of utf8 and utf16, that doesn't - seem sufficient for C++0x. Bill supports general N-to-M conversions; - we need to make sure Martin and Howard agree.]

    - - - -

    Proposed resolution:

    - - - - -
    -

    387. std::complex over-encapsulated

    -

    Section: 26.3 [complex.numbers] Status: Ready - Submitter: Gabriel Dos Reis Date: 2002-11-08

    -

    View all other issues in [complex.numbers].

    -

    View all issues with Ready status.

    -

    Discussion:

    -

    -The absence of explicit description of std::complex<T> layout -makes it imposible to reuse existing software developed in traditional -languages like Fortran or C with unambigous and commonly accepted -layout assumptions. There ought to be a way for practitioners to -predict with confidence the layout of std::complex<T> whenever T -is a numerical datatype. The absence of ways to access individual -parts of a std::complex<T> object as lvalues unduly promotes -severe pessimizations. For example, the only way to change, -independently, the real and imaginary parts is to write something like -

    - -
    complex<T> z;
-// ...
-// set the real part to r
-z = complex<T>(r, z.imag());
-// ...
-// set the imaginary part to i
-z = complex<T>(z.real(), i);
-
    - -

    -At this point, it seems appropriate to recall that a complex number -is, in effect, just a pair of numbers with no particular invariant to -maintain. Existing practice in numerical computations has it that a -complex number datatype is usually represented by Cartesian -coordinates. Therefore the over-encapsulation put in the specification -of std::complex<> is not justified. -

    - - - -

    Proposed resolution:

    -

    Add the following requirements to 26.3 [complex.numbers] as 26.3/4:

    -
    -

    If z is an lvalue expression of type cv std::complex<T> then

    - -
      -
    • the expression reinterpret_cast<cv T(&)[2]>(z) -is well-formed; and
      • -
    • reinterpret_cast<cv T(&)[2]>(z)[0]designates the -real part of z; and
      • -
    • reinterpret_cast<cv T(&)[2]>(z)[1]designates the -imaginary part of z.
      • -
    - -

    -Moreover, if a is an expression of pointer type cv complex<T>* -and the expression a[i] is well-defined for an integer expression -i then: -

    - -
      -
    • reinterpret_cast<cv T*>(a)[2*i] designates the real -part of a[i]; and
      • -
    • reinterpret_cast<cv T*>(a)[2*i+1] designates the -imaginary part of a[i].
      • -
    -
    - -

    -In 26.3.2 [complex] and 26.3.3 [complex.special] add the following member functions -(changing T to concrete types as appropriate for the specializations). -

    - -
    void real(T);
-void imag(T);
-
    - -

    -Add to 26.3.4 [complex.members] -

    - -
    -
    T real() const;
-
    -
    -Returns: the value of the real component -
    -
    void real(T val);
-
    -
    -Assigns val to the real component. -
    -
    T imag() const;
-
    -
    -Returns: the value of the imaginary component -
    -
    void imag(T val);
-
    -
    -Assigns val to the imaginary component. -
    -
    - -

    [Kona: The layout guarantee is absolutely necessary for C - compatibility. However, there was disagreement about the other part - of this proposal: retrieving elements of the complex number as - lvalues. An alternative: continue to have real() and imag() return - rvalues, but add set_real() and set_imag(). Straw poll: return - lvalues - 2, add setter functions - 5. Related issue: do we want - reinterpret_cast as the interface for converting a complex to an - array of two reals, or do we want to provide a more explicit way of - doing it? Howard will try to resolve this issue for the next - meeting.]

    - - -

    [pre-Sydney: Howard summarized the options in n1589.]

    - - -

    [ -Bellevue: -]

    - - -
    -Second half of proposed wording replaced and moved to Ready. -
    - -

    [ -Pre-Sophia Antipolis, Howard adds: -]

    - - -
    -Added the members to 26.3.3 [complex.special] and changed from Ready to Review. -
    - -

    [ -Post-Sophia Antipolis: -]

    - - -
    -Moved from WP back to Ready so that the "and 26.3.3 [complex.special]" in the proposed -resolution can be officially applied. -
    - - - -

    Rationale:

    -

    The LWG believes that C99 compatibility would be enough -justification for this change even without other considerations. All -existing implementations already have the layout proposed here.

    - - - - - -
    -

    394. behavior of formatted output on failure

    -

    Section: 27.6.2.6.1 [ostream.formatted.reqmts] Status: Open - Submitter: Martin Sebor Date: 2002-12-27

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -There is a contradiction in Formatted output about what bit is -supposed to be set if the formatting fails. On sentence says it's -badbit and another that it's failbit. -

    -

    -27.6.2.5.1, p1 says in the Common Requirements on Formatted output -functions: -

    -
         ... If the generation fails, then the formatted output function
-     does setstate(ios::failbit), which might throw an exception.
-
    -

    -27.6.2.5.2, p1 goes on to say this about Arithmetic Inserters: -

    -

    - ... The formatting conversion occurs as if it performed the - following code fragment: -

    -
         bool failed =
-         use_facet<num_put<charT,ostreambuf_iterator<charT,traits>
-         > >
-         (getloc()).put(*this, *this, fill(), val). failed();
-
-     ... If failed is true then does setstate(badbit) ...
-
    -

    -The original intent of the text, according to Jerry Schwarz (see -c++std-lib-10500), is captured in the following paragraph: -

    -

    -In general "badbit" should mean that the stream is unusable because -of some underlying failure, such as disk full or socket closure; -"failbit" should mean that the requested formatting wasn't possible -because of some inconsistency such as negative widths. So typically -if you clear badbit and try to output something else you'll fail -again, but if you clear failbit and try to output something else -you'll succeed. -

    -

    -In the case of the arithmetic inserters, since num_put cannot -report failure by any means other than exceptions (in response -to which the stream must set badbit, which prevents the kind of -recoverable error reporting mentioned above), the only other -detectable failure is if the iterator returned from num_put -returns true from failed(). -

    -

    -Since that can only happen (at least with the required iostream -specializations) under such conditions as the underlying failure -referred to above (e.g., disk full), setting badbit would seem -to be the appropriate response (indeed, it is required in -27.6.2.5.2, p1). It follows that failbit can never be directly -set by the arithmetic (it can only be set by the sentry object -under some unspecified conditions). -

    -

    -The situation is different for other formatted output functions -which can fail as a result of the streambuf functions failing -(they may do so by means other than exceptions), and which are -then required to set failbit. -

    -

    -The contradiction, then, is that ostream::operator<<(int) will -set badbit if the disk is full, while operator<<(ostream&, -char) will set failbit under the same conditions. To make the behavior -consistent, the Common requirements sections for the Formatted output -functions should be changed as proposed below. -

    -

    [Kona: There's agreement that this is a real issue. What we - decided at Kona: 1. An error from the buffer (which can be detected - either directly from streambuf's member functions or by examining a - streambuf_iterator) should always result in badbit getting set. - 2. There should never be a circumstance where failbit gets set. - That represents a formatting error, and there are no circumstances - under which the output facets are specified as signaling a - formatting error. (Even more so for string output that for numeric - because there's nothing to format.) If we ever decide to make it - possible for formatting errors to exist then the facets can signal - the error directly, and that should go in clause 22, not clause 27. - 3. The phrase "if generation fails" is unclear and should be - eliminated. It's not clear whether it's intended to mean a buffer - error (e.g. a full disk), a formatting error, or something else. - Most people thought it was supposed to refer to buffer errors; if - so, we should say so. Martin will provide wording.]

    - - - - -

    Proposed resolution:

    - - -

    Rationale:

    - - - - - - -
    -

    396. what are characters zero and one

    -

    Section: 23.3.5.1 [bitset.cons] Status: Ready - Submitter: Martin Sebor Date: 2003-01-05

    -

    View all other issues in [bitset.cons].

    -

    View all issues with Ready status.

    -

    Discussion:

    -

    -23.3.5.1, p6 [lib.bitset.cons] talks about a generic character -having the value of 0 or 1 but there is no definition of what -that means for charT other than char and wchar_t. And even for -those two types, the values 0 and 1 are not actually what is -intended -- the values '0' and '1' are. This, along with the -converse problem in the description of to_string() in 23.3.5.2, -p33, looks like a defect remotely related to DR 303. -

    -

    -http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#303 -

    - 
    23.3.5.1:
-  -6-  An element of the constructed string has value zero if the
-       corresponding character in str, beginning at position pos,
-       is 0. Otherwise, the element has the value one.
-
    - 
    23.3.5.2:
-  -33-  Effects: Constructs a string object of the appropriate
-        type and initializes it to a string of length N characters.
-        Each character is determined by the value of its
-        corresponding bit position in *this. Character position N
-        ?- 1 corresponds to bit position zero. Subsequent decreasing
-        character positions correspond to increasing bit positions.
-        Bit value zero becomes the character 0, bit value one becomes
-        the character 1.
-
    -

    -Also note the typo in 23.3.5.1, p6: the object under construction -is a bitset, not a string. -

    - -

    [ -Sophia Antipolis: -]

    - - -
    -

    -We note that bitset has been moved from section 23 to section 20, by -another issue (842) previously resolved at this meeting. -

    -

    -Disposition: move to ready. -

    -

    -We request that Howard submit a separate issue regarding the three to_string overloads. -

    -
    - - - -

    Proposed resolution:

    -

    Change the constructor's function declaration immediately before -23.3.5.1 [bitset.cons] p3 to:

    -
        template <class charT, class traits, class Allocator>
-    explicit
-    bitset(const basic_string<charT, traits, Allocator>& str,
-           typename basic_string<charT, traits, Allocator>::size_type pos = 0,
-           typename basic_string<charT, traits, Allocator>::size_type n =
-             basic_string<charT, traits, Allocator>::npos,
-           charT zero = charT('0'), charT one = charT('1'))
-
    -

    Change the first two sentences of 23.3.5.1 [bitset.cons] p6 to: "An -element of the constructed string has value 0 if the corresponding -character in str, beginning at position pos, -is zero. Otherwise, the element has the value 1.

    - -

    Change the text of the second sentence in 23.3.5.1, p5 to read: - "The function then throws invalid_argument if any of the rlen - characters in str beginning at position pos is other than zero - or one. The function uses traits::eq() to compare the character - values." -

    - -

    Change the declaration of the to_string member function - immediately before 23.3.5.2 [bitset.members] p33 to:

    -
        template <class charT, class traits, class Allocator>
-    basic_string<charT, traits, Allocator> 
-    to_string(charT zero = charT('0'), charT one = charT('1')) const;
-
    -

    Change the last sentence of 23.3.5.2 [bitset.members] p33 to: "Bit - value 0 becomes the character zero, bit value 1 becomes the - character one.

    -

    Change 23.3.5.3 [bitset.operators] p8 to:

    -

    Returns:

    -
      os << x.template to_string<charT,traits,allocator<charT> >(
-      use_facet<ctype<charT> >(os.getloc()).widen('0'),
-      use_facet<ctype<charT> >(os.getloc()).widen('1'));
-
    - - -

    Rationale:

    -

    There is a real problem here: we need the character values of '0' - and '1', and we have no way to get them since strings don't have - imbued locales. In principle the "right" solution would be to - provide an extra object, either a ctype facet or a full locale, - which would be used to widen '0' and '1'. However, there was some - discomfort about using such a heavyweight mechanism. The proposed - resolution allows those users who care about this issue to get it - right.

    -

    We fix the inserter to use the new arguments. Note that we already - fixed the analogous problem with the extractor in issue 303.

    - - - -

    [ -post Bellevue: -]

    - - -
    -We are happy with the resolution as proposed, and we move this to Ready. -
    - -

    [ -Howard adds: -]

    - - -
    -The proposed wording neglects the 3 newer to_string overloads. -
    - - - - -
    -

    397. ostream::sentry dtor throws exceptions

    -

    Section: 27.6.2.4 [ostream::sentry] Status: Open - Submitter: Martin Sebor Date: 2003-01-05

    -

    View other active issues in [ostream::sentry].

    -

    View all other issues in [ostream::sentry].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -17.4.4.8, p3 prohibits library dtors from throwing exceptions. -

    -

    -27.6.2.3, p4 says this about the ostream::sentry dtor: -

    - 
        -4- If ((os.flags() & ios_base::unitbuf) && !uncaught_exception())
-        is true, calls os.flush().
-
    -

    -27.6.2.6, p7 that describes ostream::flush() says: -

    - 
        -7- If rdbuf() is not a null pointer, calls rdbuf()->pubsync().
-        If that function returns ?-1 calls setstate(badbit) (which
-        may throw ios_base::failure (27.4.4.3)).
-
    -

    -That seems like a defect, since both pubsync() and setstate() can -throw an exception. -

    -

    [ -The contradiction is real. Clause 17 says destructors may never -throw exceptions, and clause 27 specifies a destructor that does -throw. In principle we might change either one. We're leaning -toward changing clause 17: putting in an "unless otherwise specified" -clause, and then putting in a footnote saying the sentry destructor -is the only one that can throw. PJP suggests specifying that -sentry::~sentry() should internally catch any exceptions it might cause. -]

    - - -

    [ -See 418 and 622 for related issues. -]

    - - - - -

    Proposed resolution:

    - - - - - -
    -

    398. effects of end-of-file on unformatted input functions

    -

    Section: 27.6.2.4 [ostream::sentry] Status: Open - Submitter: Martin Sebor Date: 2003-01-05

    -

    View other active issues in [ostream::sentry].

    -

    View all other issues in [ostream::sentry].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -While reviewing unformatted input member functions of istream -for their behavior when they encounter end-of-file during input -I found that the requirements vary, sometimes unexpectedly, and -in more than one case even contradict established practice (GNU -libstdc++ 3.2, IBM VAC++ 6.0, STLPort 4.5, SunPro 5.3, HP aCC -5.38, Rogue Wave libstd 3.1, and Classic Iostreams). -

    -

    -The following unformatted input member functions set eofbit if they -encounter an end-of-file (this is the expected behavior, and also -the behavior of all major implementations): -

    - 
        basic_istream<charT, traits>&
-    get (char_type*, streamsize, char_type);
-
    -

    - Also sets failbit if it fails to extract any characters. -

    - 
        basic_istream<charT, traits>&
-    get (char_type*, streamsize);
-
    -

    - Also sets failbit if it fails to extract any characters. -

    - 
        basic_istream<charT, traits>&
-    getline (char_type*, streamsize, char_type);
-
    -

    - Also sets failbit if it fails to extract any characters. -

    - 
        basic_istream<charT, traits>&
-    getline (char_type*, streamsize);
-
    -

    - Also sets failbit if it fails to extract any characters. -

    - 
        basic_istream<charT, traits>&
-    ignore (int, int_type);
-
    - 
        basic_istream<charT, traits>&
-    read (char_type*, streamsize);
-
    -

    - Also sets failbit if it encounters end-of-file. -

    - 
        streamsize readsome (char_type*, streamsize);
-
    - -

    -The following unformated input member functions set failbit but -not eofbit if they encounter an end-of-file (I find this odd -since the functions make it impossible to distinguish a general -failure from a failure due to end-of-file; the requirement is -also in conflict with all major implementation which set both -eofbit and failbit): -

    - 
        int_type get();
-
    - 
        basic_istream<charT, traits>&
-    get (char_type&);
-
    -

    -These functions only set failbit of they extract no characters, -otherwise they don't set any bits, even on failure (I find this -inconsistency quite unexpected; the requirement is also in -conflict with all major implementations which set eofbit -whenever they encounter end-of-file): -

    - 
        basic_istream<charT, traits>&
-    get (basic_streambuf<charT, traits>&, char_type);
-
    - 
        basic_istream<charT, traits>&
-    get (basic_streambuf<charT, traits>&);
-
    -

    -This function sets no bits (all implementations except for -STLport and Classic Iostreams set eofbit when they encounter -end-of-file): -

    - 
        int_type peek ();
-
    -

    Informally, what we want is a global statement of intent saying - that eofbit gets set if we trip across EOF, and then we can take - away the specific wording for individual functions. A full review - is necessary. The wording currently in the standard is a mishmash, - and changing it on an individual basis wouldn't make things better. - Dietmar will do this work.

    - - -

    Proposed resolution:

    - - - - -
    -

    408. Is vector<reverse_iterator<char*> > forbidden?

    -

    Section: 24.1 [iterator.requirements] Status: Open - Submitter: Nathan Myers Date: 2003-06-03

    -

    View other active issues in [iterator.requirements].

    -

    View all other issues in [iterator.requirements].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -I've been discussing iterator semantics with Dave Abrahams, and a -surprise has popped up. I don't think this has been discussed before. -

    - -

    -24.1 [iterator.requirements] says that the only operation that can be performed on "singular" -iterator values is to assign a non-singular value to them. (It -doesn't say they can be destroyed, and that's probably a defect.) -Some implementations have taken this to imply that there is no need -to initialize the data member of a reverse_iterator<> in the default -constructor. As a result, code like -

    -
      std::vector<std::reverse_iterator<char*> > v(7);
-  v.reserve(1000);
-
    -

    -invokes undefined behavior, because it must default-initialize the -vector elements, and then copy them to other storage. Of course many -other vector operations on these adapters are also left undefined, -and which those are is not reliably deducible from the standard. -

    - -

    -I don't think that 24.1 was meant to make standard-library iterator -types unsafe. Rather, it was meant to restrict what operations may -be performed by functions which take general user- and standard -iterators as arguments, so that raw pointers would qualify as -iterators. However, this is not clear in the text, others have come -to the opposite conclusion. -

    - -

    -One question is whether the standard iterator adaptors have defined -copy semantics. Another is whether they have defined destructor -semantics: is -

    -
      { std::vector<std::reverse_iterator<char*> >  v(7); }
-
    -

    -undefined too? -

    - -

    -Note this is not a question of whether algorithms are allowed to -rely on copy semantics for arbitrary iterators, just whether the -types we actually supply support those operations. I believe the -resolution must be expressed in terms of the semantics of the -adapter's argument type. It should make clear that, e.g., the -reverse_iterator<T> constructor is actually required to execute -T(), and so copying is defined if the result of T() is copyable. -

    - -

    -Issue 235, which defines reverse_iterator's default -constructor more precisely, has some relevance to this issue. -However, it is not the whole story. -

    - -

    -The issue was whether -

    -
      reverse_iterator() { }
-
    -

    -is allowed, vs. -

    -
      reverse_iterator() : current() { }
-
    - -

    -The difference is when T is char*, where the first leaves the member -uninitialized, and possibly equal to an existing pointer value, or -(on some targets) may result in a hardware trap when copied. -

    - -

    -8.5 paragraph 5 seems to make clear that the second is required to -satisfy DR 235, at least for non-class Iterator argument -types. -

    - -

    -But that only takes care of reverse_iterator, and doesn't establish -a policy for all iterators. (The reverse iterator adapter was just -an example.) In particular, does my function -

    -
      template <typename Iterator>
-    void f() { std::vector<Iterator>  v(7); } 
-
    -

    -evoke undefined behavior for some conforming iterator definitions? -I think it does, now, because vector<> will destroy those singular -iterator values, and that's explicitly disallowed. -

    - -

    -24.1 shouldn't give blanket permission to copy all singular iterators, -because then pointers wouldn't qualify as iterators. However, it -should allow copying of that subset of singular iterator values that -are default-initialized, and it should explicitly allow destroying any -iterator value, singular or not, default-initialized or not. -

    - -

    Related issue: 407

    -

    [ -We don't want to require all singular iterators to be copyable, -because that is not the case for pointers. However, default -construction may be a special case. Issue: is it really default -construction we want to talk about, or is it something like value -initialization? We need to check with core to see whether default -constructed pointers are required to be copyable; if not, it would be -wrong to impose so strict a requirement for iterators. -]

    - - - - -

    Proposed resolution:

    - - - - - -
    -

    417. what does ctype::do_widen() return on failure

    -

    Section: 22.2.1.1.2 [locale.ctype.virtuals] Status: Open - Submitter: Martin Sebor Date: 2003-09-18

    -

    View all other issues in [locale.ctype.virtuals].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -The Effects and Returns clauses of the do_widen() member function of -the ctype facet fail to specify the behavior of the function on failure. -That the function may not be able to simply cast the narrow character -argument to the type of the result since doing so may yield the wrong value -for some wchar_t encodings. Popular implementations of ctype<wchar_t> that -use mbtowc() and UTF-8 as the native encoding (e.g., GNU glibc) will fail -when the argument's MSB is set. There is no way for the the rest of locale -and iostream to reliably detect this failure. -

    -

    [Kona: This is a real problem. Widening can fail. It's unclear - what the solution should be. Returning WEOF works for the wchar_t - specialization, but not in general. One option might be to add a - default, like narrow. But that's an incompatible change. - Using traits::eof might seem like a good idea, but facets - don't have access to traits (a recurring problem). We could - have widen throw an exception, but that's a scary option; - existing library components aren't written with the assumption - that widen can throw.]

    - - - -

    Proposed resolution:

    - - - - -
    -

    418. exceptions thrown during iostream cleanup

    -

    Section: 27.4.2.1.6 [ios::Init] Status: Open - Submitter: Martin Sebor Date: 2003-09-18

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -The dtor of the ios_base::Init object is supposed to call flush() on the -6 standard iostream objects cout, cerr, clog, wcout, wcerr, and wclog. -This call may cause an exception to be thrown. -

    - -

    -17.4.4.8, p3 prohibits all library destructors from throwing exceptions. -

    - -

    -The question is: What should this dtor do if one or more of these calls -to flush() ends up throwing an exception? This can happen quite easily -if one of the facets installed in the locale imbued in the iostream -object throws. -

    -

    [Kona: We probably can't do much better than what we've got, so - the LWG is leaning toward NAD. At the point where the standard - stream objects are being cleaned up, the usual error reporting - mechanism are all unavailable. And exception from flush at this - point will definitely cause problems. A quality implementation - might reasonably swallow the exception, or call abort, or do - something even more drastic.]

    - - -

    [ -See 397 and 622 for related issues. -]

    - - - - -

    Proposed resolution:

    - - - - -
    -

    419. istream extractors not setting failbit if eofbit is already set

    -

    Section: 27.6.1.1.3 [istream::sentry] Status: Open - Submitter: Martin Sebor Date: 2003-09-18

    -

    View all other issues in [istream::sentry].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    - -27.6.1.1.3 [istream::sentry], p2 says that istream::sentry ctor prepares for input if is.good() -is true. p4 then goes on to say that the ctor sets the sentry::ok_ member to -true if the stream state is good after any preparation. 27.6.1.2.1 [istream.formatted.reqmts], p1 then -says that a formatted input function endeavors to obtain the requested input -if the sentry's operator bool() returns true. - -Given these requirements, no formatted extractor should ever set failbit if -the initial stream rdstate() == eofbit. That is contrary to the behavior of -all implementations I tested. The program below prints out - -eof = 1, fail = 0 -eof = 1, fail = 1 - -on all of them. -

    -
    -#include <sstream>
-#include <cstdio>
-
-int main()
-{
-    std::istringstream strm ("1");
-
-    int i = 0;
-
-    strm >> i;
-
-    std::printf ("eof = %d, fail = %d\n",
-                 !!strm.eof (), !!strm.fail ());
-
-    strm >> i;
-
-    std::printf ("eof = %d, fail = %d\n",
-                 !!strm.eof (), !!strm.fail ());
-}
-
-
    -

    -
    - -Comments from Jerry Schwarz (c++std-lib-11373): -
    - -Jerry Schwarz wrote: -
    - -I don't know where (if anywhere) it says it in the standard, but the -formatted extractors are supposed to set failbit if they don't extract -any characters. If they didn't then simple loops like -
    - -while (cin >> x); -
    - -would loop forever. -
    - -Further comments from Martin Sebor: -
    - -The question is which part of the extraction should prevent this from happening -by setting failbit when eofbit is already set. It could either be the sentry -object or the extractor. It seems that most implementations have chosen to -set failbit in the sentry [...] so that's the text that will need to be -corrected. - -

    -

    -Pre Berlin: This issue is related to 342. If the sentry -sets failbit when it finds eofbit already set, then -you can never seek away from the end of stream. -

    -

    Kona: Possibly NAD. If eofbit is set then good() will return false. We - then set ok to false. We believe that the sentry's - constructor should always set failbit when ok is false, and - we also think the standard already says that. Possibly it could be - clearer.

    - - - -

    Proposed resolution:

    -

    -Change 27.6.1.1.3 [istream::sentry], p2 to: -

    - -
    -
    explicit sentry(basic_istream<charT,traits>& is , bool noskipws = false);
    -

    --2- Effects: If is.good() is true -false, calls is.setstate(failbit). -Otherwise prepares for formatted or unformatted input. ... -

    -
    - - - - - - -
    -

    421. is basic_streambuf copy-constructible?

    -

    Section: 27.5.2.1 [streambuf.cons] Status: Open - Submitter: Martin Sebor Date: 2003-09-18

    -

    View all other issues in [streambuf.cons].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -The reflector thread starting with c++std-lib-11346 notes that the class -template basic_streambuf, along with basic_stringbuf and basic_filebuf, -is copy-constructible but that the semantics of the copy constructors -are not defined anywhere. Further, different implementations behave -differently in this respect: some prevent copy construction of objects -of these types by declaring their copy ctors and assignment operators -private, others exhibit undefined behavior, while others still give -these operations well-defined semantics. -

    - -

    -Note that this problem doesn't seem to be isolated to just the three -types mentioned above. A number of other types in the library section -of the standard provide a compiler-generated copy ctor and assignment -operator yet fail to specify their semantics. It's believed that the -only types for which this is actually a problem (i.e. types where the -compiler-generated default may be inappropriate and may not have been -intended) are locale facets. See issue 439. -

    - - -

    Proposed resolution:

    -

    -27.5.2 [lib.streambuf]: Add into the synopsis, public section, just above the destructor declaration: -

    - -
    -
    basic_streambuf(const basic_streambuf& sb);
-basic_streambuf& operator=(const basic_streambuf& sb);
-
    -
    - -

    Insert after 27.5.2.1, paragraph 2:

    -
    -
    basic_streambuf(const basic_streambuf& sb);
-
    - -

    Constructs a copy of sb.

    -

    Postcondtions:

    -
                    eback() == sb.eback()
-                gptr()  == sb.gptr()
-                egptr() == sb.egptr()
-                pbase() == sb.pbase()
-                pptr()  == sb.pptr()
-                epptr() == sb.epptr()
-                getloc() == sb.getloc()
-
    - -
    basic_streambuf& operator=(const basic_streambuf& sb);
-
    - -

    Assigns the data members of sb to this.

    - -

    Postcondtions:

    -
                    eback() == sb.eback()
-                gptr()  == sb.gptr()
-                egptr() == sb.egptr()
-                pbase() == sb.pbase()
-                pptr()  == sb.pptr()
-                epptr() == sb.epptr()
-                getloc() == sb.getloc()
-
    - -

    Returns: *this.

    -
    - -

    27.7.1 [lib.stringbuf]:

    - -

    Option A:

    - -
    -

    Insert into the basic_stringbuf synopsis in the private section:

    - -
    basic_stringbuf(const basic_stringbuf&);             // not defined
-basic_stringbuf& operator=(const basic_stringbuf&);  // not defined
-
    -
    - -

    Option B:

    - -
    -

    Insert into the basic_stringbuf synopsis in the public section:

    - -
    basic_stringbuf(const basic_stringbuf& sb);
-basic_stringbuf& operator=(const basic_stringbuf& sb);
-
    - -

    27.7.1.1, insert after paragraph 4:

    - -
    basic_stringbuf(const basic_stringbuf& sb);
    - -

    -Constructs an independent copy of sb as if with sb.str(), and with the openmode that sb was constructed with. -

    - -

    Postcondtions:

    -
                   str() == sb.str()
-               gptr()  - eback() == sb.gptr()  - sb.eback()
-               egptr() - eback() == sb.egptr() - sb.eback()
-               pptr()  - pbase() == sb.pptr()  - sb.pbase()
-               getloc() == sb.getloc()
-
    - -

    -Note: The only requirement on epptr() is that it point beyond the -initialized range if an output sequence exists. There is no requirement -that epptr() - pbase() == sb.epptr() - sb.pbase(). -

    - -
    basic_stringbuf& operator=(const basic_stringbuf& sb);
    -

    After assignment the basic_stringbuf has the same state as if it -were initially copy constructed from sb, except that the -basic_stringbuf is allowed to retain any excess capacity it might have, -which may in turn effect the value of epptr(). -

    -
    - -

    27.8.1.1 [lib.filebuf]

    - -

    Insert at the bottom of the basic_filebuf synopsis:

    - -
    -
    private:
-  basic_filebuf(const basic_filebuf&);             // not defined
-  basic_filebuf& operator=(const basic_filebuf&);  // not defined
-
    -
    -

    [Kona: this is an issue for basic_streambuf itself and for its - derived classes. We are leaning toward allowing basic_streambuf to - be copyable, and specifying its precise semantics. (Probably the - obvious: copying the buffer pointers.) We are less sure whether - the streambuf derived classes should be copyable. Howard will - write up a proposal.]

    - - -

    [Sydney: Dietmar presented a new argument against basic_streambuf - being copyable: it can lead to an encapsulation violation. Filebuf - inherits from streambuf. Now suppose you inhert a my_hijacking_buf - from streambuf. You can copy the streambuf portion of a filebuf to a - my_hijacking_buf, giving you access to the pointers into the - filebuf's internal buffer. Perhaps not a very strong argument, but - it was strong enough to make people nervous. There was weak - preference for having streambuf not be copyable. There was weak - preference for having stringbuf not be copyable even if streambuf - is. Move this issue to open for now. -]

    - - -

    [ -2007-01-12, Howard: -Rvalue Reference Recommendations for Chapter 27 -recommends protected copy constructor and assignment for basic_streambuf with the same semantics -as would be generated by the compiler. These members aid in derived classes implementing move semantics. -A protected copy constructor and copy assignment operator do not expose encapsulation more so than it is -today as each data member of a basic_streambuf is already both readable and writable by derived -classes via various get/set protected member functions (eback(), setp(), etc.). Rather -a protected copy constructor and copy assignment operator simply make the job of derived classes implementing -move semantics less tedious and error prone. -]

    - - - - -

    Rationale:

    -

    -27.5.2 [lib.streambuf]: The proposed basic_streambuf copy constructor -and assignment operator are the same as currently implied by the lack -of declarations: public and simply copies the data members. This -resolution is not a change but a clarification of the current -standard. -

    - -

    -27.7.1 [lib.stringbuf]: There are two reasonable options: A) Make -basic_stringbuf not copyable. This is likely the status-quo of -current implementations. B) Reasonable copy semantics of -basic_stringbuf can be defined and implemented. A copyable -basic_streambuf is arguably more useful than a non-copyable one. This -should be considered as new functionality and not the fixing of a -defect. If option B is chosen, ramifications from issue 432 are taken -into account. -

    - -

    -27.8.1.1 [lib.filebuf]: There are no reasonable copy semantics for -basic_filebuf. -

    - - - - - - -
    -

    423. effects of negative streamsize in iostreams

    -

    Section: 27 [input.output] Status: Open - Submitter: Martin Sebor Date: 2003-09-18

    -

    View all other issues in [input.output].

    -

    View all issues with Open status.

    -

    Discussion:

    - -

    -A third party test suite tries to exercise istream::ignore(N) with -a negative value of N and expects that the implementation will treat -N as if it were 0. Our implementation asserts that (N >= 0) holds and -aborts the test. -

    - -

    -I can't find anything in section 27 that prohibits such values but I don't -see what the effects of such calls should be, either (this applies to -a number of unformatted input functions as well as some member functions -of the basic_streambuf template). -

    - - -

    Proposed resolution:

    -

    -I propose that we add to each function in clause 27 that takes an argument, -say N, of type streamsize a Requires clause saying that "N >= 0." The intent -is to allow negative streamsize values in calls to precision() and width() -but disallow it in calls to streambuf::sgetn(), istream::ignore(), or -ostream::write(). -

    - -

    [Kona: The LWG agreed that this is probably what we want. However, we - need a review to find all places where functions in clause 27 take - arguments of type streamsize that shouldn't be allowed to go - negative. Martin will do that review.]

    - - - - - - -
    -

    427. stage 2 and rationale of DR 221

    -

    Section: 22.2.2.1.2 [facet.num.get.virtuals] Status: Open - Submitter: Martin Sebor Date: 2003-09-18

    -

    View other active issues in [facet.num.get.virtuals].

    -

    View all other issues in [facet.num.get.virtuals].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -The requirements specified in Stage 2 and reiterated in the rationale -of DR 221 (and echoed again in DR 303) specify that num_get<charT>:: -do_get() compares characters on the stream against the widened elements -of "012...abc...ABCX+-" -

    - -

    -An implementation is required to allow programs to instantiate the num_get -template on any charT that satisfies the requirements on a user-defined -character type. These requirements do not include the ability of the -character type to be equality comparable (the char_traits template must -be used to perform tests for equality). Hence, the num_get template cannot -be implemented to support any arbitrary character type. The num_get template -must either make the assumption that the character type is equality-comparable -(as some popular implementations do), or it may use char_traits<charT> to do -the comparisons (some other popular implementations do that). This diversity -of approaches makes it difficult to write portable programs that attempt to -instantiate the num_get template on user-defined types. -

    - -

    [Kona: the heart of the problem is that we're theoretically - supposed to use traits classes for all fundamental character - operations like assignment and comparison, but facets don't have - traits parameters. This is a fundamental design flaw and it - appears all over the place, not just in this one place. It's not - clear what the correct solution is, but a thorough review of facets - and traits is in order. The LWG considered and rejected the - possibility of changing numeric facets to use narrowing instead of - widening. This may be a good idea for other reasons (see issue - 459), but it doesn't solve the problem raised by this - issue. Whether we use widen or narrow the num_get facet - still has no idea which traits class the user wants to use for - the comparison, because only streams, not facets, are passed traits - classes. The standard does not require that two different - traits classes with the same char_type must necessarily - have the same behavior.]

    - - -

    Informally, one possibility: require that some of the basic -character operations, such as eq, lt, -and assign, must behave the same way for all traits classes -with the same char_type. If we accept that limitation on -traits classes, then the facet could reasonably be required to -use char_traits<charT>.

    - - -

    Proposed resolution:

    - - - - -
    -

    430. valarray subset operations

    -

    Section: 26.5.2.4 [valarray.sub] Status: Open - Submitter: Martin Sebor Date: 2003-09-18

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -The standard fails to specify the behavior of valarray::operator[](slice) -and other valarray subset operations when they are passed an "invalid" -slice object, i.e., either a slice that doesn't make sense at all (e.g., -slice (0, 1, 0) or one that doesn't specify a valid subset of the valarray -object (e.g., slice (2, 1, 1) for a valarray of size 1). -

    -

    [Kona: the LWG believes that invalid slices should invoke - undefined behavior. Valarrays are supposed to be designed for high - performance, so we don't want to require specific checking. We - need wording to express this decision.]

    - - -

    [ -Bellevue: -]

    - - -
    -Please note that the standard also fails to specify the behavior of -slice_array and gslice_array in the valid case. Bill Plauger will -endeavor to provide revised wording for slice_array and gslice_array. -
    - -

    [ -post-Bellevue: Bill provided wording. -]

    - - - -

    Proposed resolution:

    -

    -Insert after 26.5.2.4 [valarray.sub], paragraph 1: -

    - -
    -

    -The member operator is overloaded to provide several ways to select -sequences -of elements from among those controlled by *this. The first group of five -member operators work in conjunction with various overloads of operator= -(and other assigning operators) to allow selective replacement (slicing) of -the controlled sequence. The selected elements must exist. -

    -

    -The first member operator selects element off. For example: -

    - -
    valarray<char> v0("abcdefghijklmnop", 16);
-v0[3] = 'A';
-// v0 == valarray<char>("abcAefghijklmnop", 16)
-
    - -

    -The second member operator selects those elements of the controlled sequence -designated by slicearr. For example: -

    - -
    valarray<char> v0("abcdefghijklmnop", 16);
-valarray<char> v1("ABCDE", 5);
-v0[slice(2, 5, 3)] = v1;
-// v0 == valarray<char>("abAdeBghCjkDmnEp", 16)
-
    - -

    -The third member operator selects those elements of the controlled sequence -designated by gslicearr. For example: -

    - -
    valarray<char> v0("abcdefghijklmnop", 16);
-valarray<char> v1("ABCDEF", 6);
-const size_t lv[] = {2, 3};
-const size_t dv[] = {7, 2};
-const valarray<size_t> len(lv, 2), str(dv, 2);
-v0[gslice(3, len, str)] = v1;
-// v0 == valarray<char>("abcAeBgCijDlEnFp", 16)
-
    - -

    -The fourth member operator selects those elements of the controlled sequence -designated by boolarr. For example: -

    - -
    valarray<char> v0("abcdefghijklmnop", 16);
-valarray<char> v1("ABC", 3);
-const bool vb[] = {false, false, true, true, false, true};
-v0[valarray<bool>(vb, 6)] = v1;
-// v0 == valarray<char>("abABeCghijklmnop", 16)
-
    - -

    -The fifth member operator selects those elements of the controlled sequence -designated by indarr. For example: -

    - -
    valarray<char> v0("abcdefghijklmnop", 16);
-valarray<char> v1("ABCDE", 5);
-const size_t vi[] = {7, 5, 2, 3, 8};
-v0[valarray<size_t>(vi, 5)] = v1;
-// v0 == valarray<char>("abCDeBgAEjklmnop", 16)
-
    - -

    -The second group of five member operators each construct an object that -represents the value(s) selected. The selected elements must exist. -

    - -

    -The sixth member operator returns the value of element off. For example: -

    - -
    valarray<char> v0("abcdefghijklmnop", 16);
-// v0[3] returns 'd'
-
    - -

    -The seventh member operator returns an object of class valarray<Ty> -containing those elements of the controlled sequence designated by slicearr. -For example: -

    - -
    valarray<char> v0("abcdefghijklmnop", 16);
-// v0[slice(2, 5, 3)] returns valarray<char>("cfilo", 5)
-
    - -

    -The eighth member operator selects those elements of the controlled sequence -designated by gslicearr. For example: -

    - -
    valarray<char> v0("abcdefghijklmnop", 16);
-const size_t lv[] = {2, 3};
-const size_t dv[] = {7, 2};
-const valarray<size_t> len(lv, 2), str(dv, 2);
-// v0[gslice(3, len, str)] returns
-//    valarray<char>("dfhkmo", 6)
-
    - -

    -The ninth member operator selects those elements of the controlled sequence -designated by boolarr. For example: -

    - -
    valarray<char> v0("abcdefghijklmnop", 16);
-const bool vb[] = {false, false, true, true, false, true};
-// v0[valarray<bool>(vb, 6)] returns
-//    valarray<char>("cdf", 3)
-
    - -

    -The last member operator selects those elements of the controlled sequence -designated by indarr. For example: -

    - -
    valarray<char> v0("abcdefghijklmnop", 16);
-const size_t vi[] = {7, 5, 2, 3, 8};
-// v0[valarray<size_t>(vi, 5)] returns
-//    valarray<char>("hfcdi", 5)
-
    - -
    - - - - - -
    -

    431. Swapping containers with unequal allocators

    -

    Section: 20.1.2 [allocator.requirements], 25 [algorithms] Status: Open - Submitter: Matt Austern Date: 2003-09-20

    -

    View other active issues in [allocator.requirements].

    -

    View all other issues in [allocator.requirements].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    Clause 20.1.2 [allocator.requirements] paragraph 4 says that implementations - are permitted to supply containers that are unable to cope with - allocator instances and that container implementations may assume - that all instances of an allocator type compare equal. We gave - implementers this latitude as a temporary hack, and eventually we - want to get rid of it. What happens when we're dealing with - allocators that don't compare equal? -

    - -

    In particular: suppose that v1 and v2 are both - objects of type vector<int, my_alloc> and that - v1.get_allocator() != v2.get_allocator(). What happens if - we write v1.swap(v2)? Informally, three possibilities:

    - -

    1. This operation is illegal. Perhaps we could say that an - implementation is required to check and to throw an exception, or - perhaps we could say it's undefined behavior.

    -

    2. The operation performs a slow swap (i.e. using three - invocations of operator=, leaving each allocator with its - original container. This would be an O(N) operation.

    -

    3. The operation swaps both the vectors' contents and their - allocators. This would be an O(1) operation. That is:

    -
    - 
        my_alloc a1(...);
-    my_alloc a2(...);
-    assert(a1 != a2);
-
-    vector<int, my_alloc> v1(a1);
-    vector<int, my_alloc> v2(a2);
-    assert(a1 == v1.get_allocator());
-    assert(a2 == v2.get_allocator());
-
-    v1.swap(v2);
-    assert(a1 == v2.get_allocator());
-    assert(a2 == v1.get_allocator());
-
    -
    - -

    [Kona: This is part of a general problem. We need a paper - saying how to deal with unequal allocators in general.]

    - - -

    [pre-Sydney: Howard argues for option 3 in -N1599. -]

    - - -

    [ -2007-01-12, Howard: This issue will now tend to come up more often with move constructors -and move assignment operators. For containers, these members transfer resources (i.e. -the allocated memory) just like swap. -]

    - - -

    [ -Batavia: There is agreement to overload the container swap on the allocator's Swappable -requirement using concepts. If the allocator supports Swappable, then container's swap will -swap allocators, else it will perform a "slow swap" using copy construction and copy assignment. -]

    - - - - -

    Proposed resolution:

    - - - - - -
    -

    446. Iterator equality between different containers

    -

    Section: 24.1 [iterator.requirements], 23.1 [container.requirements] Status: Open - Submitter: Andy Koenig Date: 2003-12-16

    -

    View other active issues in [iterator.requirements].

    -

    View all other issues in [iterator.requirements].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -What requirements does the standard place on equality comparisons between -iterators that refer to elements of different containers. For example, if -v1 and v2 are empty vectors, is v1.end() == v2.end() allowed to yield true? -Is it allowed to throw an exception? -

    - -

    -The standard appears to be silent on both questions. -

    -

    [Sydney: The intention is that comparing two iterators from -different containers is undefined, but it's not clear if we say that, -or even whether it's something we should be saying in clause 23 or in -clause 24. Intuitively we might want to say that equality is defined -only if one iterator is reachable from another, but figuring out how -to say it in any sensible way is a bit tricky: reachability is defined -in terms of equality, so we can't also define equality in terms of -reachability. -]

    - - - - -

    Proposed resolution:

    - - - - - - -
    -

    454. basic_filebuf::open should accept wchar_t names

    -

    Section: 27.8.1.4 [filebuf.members] Status: Open - Submitter: Bill Plauger Date: 2004-01-30

    -

    View all other issues in [filebuf.members].

    -

    View all issues with Open status.

    -

    Duplicate of: 105

    -

    Discussion:

    -
        basic_filebuf *basic_filebuf::open(const char *, ios_base::open_mode);
-
    - -

    should be supplemented with the overload:

    - -
        basic_filebuf *basic_filebuf::open(const wchar_t *, ios_base::open_mode);
-
    - -

    -Depending on the operating system, one of these forms is fundamental and -the other requires an implementation-defined mapping to determine the -actual filename. -

    - -

    [Sydney: Yes, we want to allow wchar_t filenames. Bill will - provide wording.]

    - - -

    [ -In Toronto we noted that this is issue 5 from -N1569. -]

    - -

    -How does this interact with the newly-defined character types, and how -do we avoid interface explosion considering std::string overloads that -were added? Propose another solution that is different than the -suggestion proposed by PJP. -

    -

    -Suggestion is to make a member template function for basic_string (for -char, wchar_t, u16char, u32char instantiations), and then just keep a -const char* member. -

    -

    -Goal is to do implicit conversion between character string literals to -appropriate basic_string type. Not quite sure if this is possible. -

    -

    -Implementors are free to add specific overloads for non-char character -types. -

    - -

    [ -Martin adds pre-Sophia Antipolis: -]

    - - -
    -Please see issue 454: problems and solutions. -
    - -

    [ -Sophia Antipolis: -]

    - - -
    -

    -Beman is concerned that making these changes to basic_filebuf is not -usefully changed unless fstream is also changed; this also only handles -wchar_t and not other character types. -

    -

    -The TR2 filesystem library is a more complete solution, but is not available soon. -

    -
    - -

    [ -Martin adds: please reference -N2683 for -problems and solutions. -]

    - - - - -

    Proposed resolution:

    - -

    Change from:

    -
    -
    basic_filebuf<charT,traits>* open(
-	const char* s,
-	ios_base::openmode mode );
-
    - -

    -Effects: If is_open() != false, returns a null pointer. -Otherwise, initializes the filebuf as required. It then -opens a file, if possible, whose name is the NTBS s ("as if" -by calling std::fopen(s,modstr)).

    -
    - -

    to:

    - -
    -
    basic_filebuf<charT,traits>* open(
-	const char* s,
-	ios_base::openmode mode );
-
-basic_filebuf<charT,traits>* open(
-	const wchar_t* ws,
-	ios_base::openmode mode );
-
    - -

    -Effects: If is_open() != false, returns a null pointer. -Otherwise, initializes the filebuf as required. It then -opens a file, if possible, whose name is the NTBS s ("as if" -by calling std::fopen(s,modstr)). -For the second signature, the NTBS s is determined from the -WCBS ws in an implementation-defined manner. -

    - -

    -(NOTE: For a system that "naturally" represents a filename -as a WCBS, the NTBS s in the first signature may instead -be mapped to a WCBS; if so, it follows the same mapping -rules as the first argument to open.) -

    -
    - - - -

    Rationale:

    -

    -Slightly controversial, but by a 7-1 straw poll the LWG agreed to move -this to Ready. The controversy was because the mapping between wide -names and files in a filesystem is implementation defined. The -counterargument, which most but not all LWG members accepted, is that -the mapping between narrow files names and files is also -implemenation defined.

    - -

    [Lillehammer: Moved back to "open" status, at Beman's urging. -(1) Why just basic_filebuf, instead of also basic_fstream (and -possibly other things too). (2) Why not also constructors that take -std::basic_string? (3) We might want to wait until we see Beman's -filesystem library; we might decide that it obviates this.]

    - - -

    [ -post Bellevue: -]

    - - -
    -

    -Move again to Ready. -

    -

    -There is a timing issue here. Since the filesystem library will not be -in C++0x, this should be brought forward. This solution would remain -valid in the context of the proposed filesystem. -

    -

    -This issue has been kicking around for a while, and the wchar_t addition -alone would help many users. Thus, we suggest putting this on the -reflector list with an invitation for someone to produce proposed -wording that covers basic_fstream. In the meantime, we suggest that the -proposed wording be adopted as-is. -

    -

    -If more of the Lillehammer questions come back, they should be -introduced as separate issues. -

    -
    - - - - - - - - -
    -

    458. 24.1.5 contains unintented limitation for operator-

    -

    Section: 24.1.5 [random.access.iterators] Status: Open - Submitter: Daniel Frey Date: 2004-02-27

    -

    View all other issues in [random.access.iterators].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -In 24.1.5 [lib.random.access.iterators], table 76 the operational -semantics for the expression "r -= n" are defined as "return r += -n". -This means, that the expression -n must be valid, which is not the case -for unsigned types. -

    - -

    [ -Sydney: Possibly not a real problem, since difference type is required -to be a signed integer type. However, the wording in the standard may -be less clear than we would like. -]

    - - - - -

    Proposed resolution:

    -

    -To remove this limitation, I suggest to change the -operational semantics for this column to: -

    -
        { Distance m = n; 
-      if (m >= 0) 
-        while (m--) --r; 
-      else 
-        while (m++) ++r;
-      return r; }
-
    - - - - - - -
    -

    459. Requirement for widening in stage 2 is overspecification

    -

    Section: 22.2.2.1.2 [facet.num.get.virtuals] Status: Open - Submitter: Martin Sebor Date: 2004-03-16

    -

    View other active issues in [facet.num.get.virtuals].

    -

    View all other issues in [facet.num.get.virtuals].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    When parsing strings of wide-character digits, the standard - requires the library to widen narrow-character "atoms" and compare - the widened atoms against the characters that are being parsed. - Simply narrowing the wide characters would be far simpler, and - probably more efficient. The two choices are equivalent except in - convoluted test cases, and many implementations already ignore the - standard and use narrow instead of widen.

    - -

    -First, I disagree that using narrow() instead of widen() would -necessarily have unfortunate performance implications. A possible -implementation of narrow() that allows num_get to be implemented -in a much simpler and arguably comparably efficient way as calling -widen() allows, i.e. without making a virtual call to do_narrow every -time, is as follows: -

    - -
      inline char ctype<wchar_t>::narrow (wchar_t wc, char dflt) const
-  {
-      const unsigned wi = unsigned (wc);
-
-      if (wi > UCHAR_MAX)
-          return typeid (*this) == typeid (ctype<wchar_t>) ?
-                 dflt : do_narrow (wc, dflt);
-
-      if (narrow_ [wi] < 0) {
-         const char nc = do_narrow (wc, dflt);
-         if (nc == dflt)
-             return dflt;
-         narrow_ [wi] = nc;
-      }
-
-      return char (narrow_ [wi]);
-  }
-
    - -

    -Second, I don't think the change proposed in the issue (i.e., to use -narrow() instead of widen() during Stage 2) would be at all -drastic. Existing implementations with the exception of libstdc++ -currently already use narrow() so the impact of the change on programs -would presumably be isolated to just a single implementation. Further, -since narrow() is not required to translate alternate wide digit -representations such as those mentioned in issue 303 -to -their narrow equivalents (i.e., the portable source characters '0' -through '9'), the change does not necessarily imply that these -alternate digits would be treated as ordinary digits and accepted as -part of numbers during parsing. In fact, the requirement in 22.2.1.1.2 -[locale.ctype.virtuals], p13 forbids narrow() to translate an alternate -digit character, wc, to an ordinary digit in the basic source -character set unless the expression -(ctype<charT>::is(ctype_base::digit, wc) == true) holds. This in -turn is prohibited by the C standard (7.25.2.1.5, 7.25.2.1.5, and -5.2.1, respectively) for charT of either char or wchar_t. -

    - -

    [Sydney: To a large extent this is a nonproblem. As long as -you're only trafficking in char and wchar_t we're only dealing with a -stable character set, so you don't really need either 'widen' or -'narrow': can just use literals. Finally, it's not even clear whether -widen-vs-narrow is the right question; arguably we should be using -codecvt instead.]

    - - - - -

    Proposed resolution:

    -

    Change stage 2 so that implementations are permitted to use either -technique to perform the comparison:

    -
      -
    1. call widen on the atoms and compare (either by using - operator== or char_traits<charT>::eq) the input with - the widened atoms, or
      2. -
    2. call narrow on the input and compare the narrow input - with the atoms
      3. -
    3. do (1) or (2) only if charT is not char or wchar_t, - respectively; i.e., avoid calling widen or narrow - if it the source and destination types are the same
      4. -
    - - - - - -
    -

    463. auto_ptr usability issues

    -

    Section: D.9.1 [auto.ptr] Status: Open - Submitter: Rani Sharoni Date: 2003-12-07

    -

    View all other issues in [auto.ptr].

    -

    View all issues with Open status.

    -

    Discussion:

    - -

    -TC1 CWG DR #84 effectively made the template<class Y> operator auto_ptr<Y>() -member of auto_ptr (20.4.5.3/4) obsolete. -

    - -

    -The sole purpose of this obsolete conversion member is to enable copy -initialization base from r-value derived (or any convertible types like -cv-types) case: -

    -
    #include <memory>
-using std::auto_ptr;
-
-struct B {};
-struct D : B {};
-
-auto_ptr<D> source();
-int sink(auto_ptr<B>);
-int x1 = sink( source() ); // #1 EDG - no suitable copy constructor
-
    - -

    -The excellent analysis of conversion operations that was given in the final -auto_ptr proposal -(http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/1997/N1128.pdf) -explicitly specifies this case analysis (case 4). DR #84 makes the analysis -wrong and actually comes to forbid the loophole that was exploited by the -auto_ptr designers. -

    - -

    -I didn't encounter any compliant compiler (e.g. EDG, GCC, BCC and VC) that -ever allowed this case. This is probably because it requires 3 user defined -conversions and in fact current compilers conform to DR #84. -

    - -

    -I was surprised to discover that the obsolete conversion member actually has -negative impact of the copy initialization base from l-value derived -case:

    -
    auto_ptr<D> dp;
-int x2 = sink(dp); // #2 EDG - more than one user-defined conversion applies
-
    - -

    -I'm sure that the original intention was allowing this initialization using -the template<class Y> auto_ptr(auto_ptr<Y>& a) constructor (20.4.5.1/4) but -since in this copy initialization it's merely user defined conversion (UDC) -and the obsolete conversion member is UDC with the same rank (for the early -overloading stage) there is an ambiguity between them. -

    - -

    -Removing the obsolete member will have impact on code that explicitly -invokes it: -

    -
    int y = sink(source().operator auto_ptr<B>());
-
    - -

    -IMHO no one ever wrote such awkward code and the reasonable workaround for -#1 is: -

    -
    int y = sink( auto_ptr<B>(source()) );
-
    - -

    -I was even more surprised to find out that after removing the obsolete -conversion member the initialization was still ill-formed: -int x3 = sink(dp); // #3 EDG - no suitable copy constructor -

    - -

    -This copy initialization semantically requires copy constructor which means -that both template conversion constructor and the auto_ptr_ref conversion -member (20.4.5.3/3) are required which is what was explicitly forbidden in -DR #84. This is a bit amusing case in which removing ambiguity results with -no candidates. -

    - -

    -I also found exception safety issue with auto_ptr related to auto_ptr_ref: -

    -
    int f(auto_ptr<B>, std::string);
-auto_ptr<B> source2();
-
-// string constructor throws while auto_ptr_ref
-// "holds" the pointer
-int x4 = f(source2(), "xyz"); // #4
-
    - -

    -The theoretic execution sequence that will cause a leak: -

    -
      -
    1. call auto_ptr<B>::operator auto_ptr_ref<B>()
      2. -
    2. call string::string(char const*) and throw
      3. -
    - -

    -According to 20.4.5.3/3 and 20.4.5/2 the auto_ptr_ref conversion member -returns auto_ptr_ref<Y> that holds *this and this is another defect since -the type of *this is auto_ptr<X> where X might be different from Y. Several -library vendors (e.g. SGI) implement auto_ptr_ref<Y> with Y* as member which -is much more reasonable. Other vendor implemented auto_ptr_ref as -defectively required and it results with awkward and catastrophic code: -int oops = sink(auto_ptr<B>(source())); // warning recursive on all control -paths -

    - -

    -Dave Abrahams noticed that there is no specification saying that -auto_ptr_ref copy constructor can't throw. -

    - -

    -My proposal comes to solve all the above issues and significantly simplify -auto_ptr implementation. One of the fundamental requirements from auto_ptr -is that it can be constructed in an intuitive manner (i.e. like ordinary -pointers) but with strict ownership semantics which yield that source -auto_ptr in initialization must be non-const. My idea is to add additional -constructor template with sole propose to generate ill-formed, diagnostic -required, instance for const auto_ptr arguments during instantiation of -declaration. This special constructor will not be instantiated for other -types which is achievable using 14.8.2/2 (SFINAE). Having this constructor -in hand makes the constructor template<class Y> auto_ptr(auto_ptr<Y> const&) -legitimate since the actual argument can't be const yet non const r-value -are acceptable. -

    - -

    -This implementation technique makes the "private auxiliary class" -auto_ptr_ref obsolete and I found out that modern C++ compilers (e.g. EDG, -GCC and VC) consume the new implementation as expected and allow all -intuitive initialization and assignment cases while rejecting illegal cases -that involve const auto_ptr arguments. -

    - -

    The proposed auto_ptr interface:

    - -
    namespace std {
-    template<class X> class auto_ptr {
-    public:
-        typedef X element_type;
-
-        // 20.4.5.1 construct/copy/destroy:
-        explicit auto_ptr(X* p=0) throw();
-        auto_ptr(auto_ptr&) throw();
-        template<class Y> auto_ptr(auto_ptr<Y> const&) throw();
-        auto_ptr& operator=(auto_ptr&) throw();
-        template<class Y> auto_ptr& operator=(auto_ptr<Y>) throw();
-        ~auto_ptr() throw();
-
-        // 20.4.5.2 members:
-        X& operator*() const throw();
-        X* operator->() const throw();
-        X* get() const throw();
-        X* release() throw();
-        void reset(X* p=0) throw();
-
-    private:
-        template<class U>
-        auto_ptr(U& rhs, typename
-unspecified_error_on_const_auto_ptr<U>::type = 0);
-    };
-}
-
    - -

    -One compliant technique to implement the unspecified_error_on_const_auto_ptr -helper class is using additional private auto_ptr member class template like -the following: -

    -
    template<typename T> struct unspecified_error_on_const_auto_ptr;
-
-template<typename T>
-struct unspecified_error_on_const_auto_ptr<auto_ptr<T> const>
-{ typedef typename auto_ptr<T>::const_auto_ptr_is_not_allowed type; };
-
    - -

    -There are other techniques to implement this helper class that might work -better for different compliers (i.e. better diagnostics) and therefore I -suggest defining its semantic behavior without mandating any specific -implementation. IMO, and I didn't found any compiler that thinks otherwise, -14.7.1/5 doesn't theoretically defeat the suggested technique but I suggest -verifying this with core language experts. -

    - -

    Further changes in standard text:

    -

    Remove section 20.4.5.3

    - -

    Change 20.4.5/2 to read something like: -Initializing auto_ptr<X> from const auto_ptr<Y> will result with unspecified -ill-formed declaration that will require unspecified diagnostic.

    - -

    Change 20.4.5.1/4,5,6 to read:

    - -
    template<class Y> auto_ptr(auto_ptr<Y> const& a) throw();
    -

    4 Requires: Y* can be implicitly converted to X*.

    -

    5 Effects: Calls const_cast<auto_ptr<Y>&>(a).release().

    -

    6 Postconditions: *this holds the pointer returned from a.release().

    - -

    Change 20.4.5.1/10

    -
    template<class Y> auto_ptr& operator=(auto_ptr<Y> a) throw();
-
    -

    -10 Requires: Y* can be implicitly converted to X*. The expression delete -get() is well formed. -

    - -

    LWG TC DR #127 is obsolete.

    - -

    -Notice that the copy constructor and copy assignment operator should remain -as before and accept non-const auto_ptr& since they have effect on the form -of the implicitly declared copy constructor and copy assignment operator of -class that contains auto_ptr as member per 12.8/5,10: -

    -
    struct X {
-    // implicit X(X&)
-    // implicit X& operator=(X&)
-    auto_ptr<D> aptr_;
-};
-
    - -

    -In most cases this indicates about sloppy programming but preserves the -current auto_ptr behavior. -

    - -

    -Dave Abrahams encouraged me to suggest fallback implementation in case that -my suggestion that involves removing of auto_ptr_ref will not be accepted. -In this case removing the obsolete conversion member to auto_ptr<Y> and -20.4.5.3/4,5 is still required in order to eliminate ambiguity in legal -cases. The two constructors that I suggested will co exist with the current -members but will make auto_ptr_ref obsolete in initialization contexts. -auto_ptr_ref will be effective in assignment contexts as suggested in DR -#127 and I can't see any serious exception safety issues in those cases -(although it's possible to synthesize such). auto_ptr_ref<X> semantics will -have to be revised to say that it strictly holds pointer of type X and not -reference to an auto_ptr for the favor of cases in which auto_ptr_ref<Y> is -constructed from auto_ptr<X> in which X is different from Y (i.e. assignment -from r-value derived to base). -

    - -

    [Redmond: punt for the moment. We haven't decided yet whether we - want to fix auto_ptr for C++-0x, or remove it and replace it with - move_ptr and unique_ptr.]

    - - -

    [ -Oxford 2007: Recommend NAD. We're just going to deprecate it. It still works for simple use cases -and people know how to deal with it. Going forward unique_ptr is the recommended -tool. -]

    - - -

    [ -2007-11-09: Reopened at the request of David Abrahams, Alisdair Meredith and Gabriel Dos Reis. -]

    - - - - -

    Proposed resolution:

    -

    -Change the synopsis in D.9.1 [auto.ptr]: -

    - -
    namespace std { 
-  template <class Y> struct auto_ptr_ref {};
-
-  // exposition only
-  template <class T> struct constant_object;
-
-  // exposition only
-  template <class T>
-  struct cannot_transfer_ownership_from
-    : constant_object<T> {};
-
-  template <class X> class auto_ptr { 
-  public: 
-    typedef X element_type; 
-
-    // D.9.1.1 construct/copy/destroy: 
-    explicit auto_ptr(X* p =0) throw(); 
-    auto_ptr(auto_ptr&) throw(); 
-    template<class Y> auto_ptr(auto_ptr<Y> const&) throw(); 
-    auto_ptr& operator=(auto_ptr&) throw(); 
-    template<class Y> auto_ptr& operator=(auto_ptr<Y>&) throw();
-    auto_ptr& operator=(auto_ptr_ref<X> r) throw();
-    ~auto_ptr() throw(); 
-
-    // D.9.1.2 members: 
-    X& operator*() const throw();
-    X* operator->() const throw();
-    X* get() const throw();
-    X* release() throw();
-    void reset(X* p =0) throw();
-
-    // D.9.1.3 conversions:
-    auto_ptr(auto_ptr_ref<X>) throw();
-    template<class Y> operator auto_ptr_ref<Y>() throw();
-    template<class Y> operator auto_ptr<Y>() throw();
-
-    // exposition only
-    template<class U>
-    auto_ptr(U& rhs, typename cannot_transfer_ownership_from<U>::error = 0);
-  }; 
-
-  template <> class auto_ptr<void> 
-  { 
-  public: 
-    typedef void element_type; 
-  }; 
-
-}
-
    - -

    -Remove D.9.1.3 [auto.ptr.conv]. -

    - -

    -Change D.9.1 [auto.ptr], p3: -

    - -
    -The auto_ptr provides a semantics of strict ownership. An -auto_ptr owns the object it holds a pointer to. Copying an -auto_ptr copies the pointer and transfers ownership to the -destination. If more than one auto_ptr owns the same object at -the same time the behavior of the program is undefined. Templates -constant_object and cannot_transfer_ownership_from, -and the final constructor of auto_ptr are for exposition only. -For any types X and Y, initializing -auto_ptr<X> from const auto_ptr<Y> is -ill-formed, diagnostic required. [Note: The uses of -auto_ptr include providing temporary exception-safety for -dynamically allocated memory, passing ownership of dynamically allocated -memory to a function, and returning dynamically allocated memory from a -function. auto_ptr does not meet the CopyConstructible -and Assignable requirements for Standard Library container -elements and thus instantiating a Standard Library container with an -auto_ptr results in undefined behavior. -- end note] -
    - -

    -Change D.9.1.1 [auto.ptr.cons], p5: -

    - -
    -
    template<class Y> auto_ptr(auto_ptr<Y> const& a) throw();
-
    -
    -

    -Requires: Y* can be implicitly converted to X*. -

    -

    -Effects: Calls const_cast<auto_ptr<Y>&>(a).release(). -

    -

    -Postconditions: *this holds the pointer returned from a.release(). -

    -
    -
    - -

    -Change D.9.1.1 [auto.ptr.cons], p10: -

    - -
    -
    template<class Y> auto_ptr& operator=(auto_ptr<Y>& a) throw();
-
    -
    -

    -Requires: Y* can be implicitly converted to X*. -The expression delete get() is well formed. -

    -

    -Effects: Calls reset(a.release()). -

    -

    -Returns: *this. -

    -
    -
    - - - - - - -
    -

    471. result of what() implementation-defined

    -

    Section: 18.6.1 [type.info] Status: Open - Submitter: Martin Sebor Date: 2004-06-28

    -

    View all other issues in [type.info].

    -

    View all issues with Open status.

    -

    Discussion:

    - -

    [lib.exception] specifies the following:

    -
        exception (const exception&) throw();
-    exception& operator= (const exception&) throw();
-
-    -4- Effects: Copies an exception object.
-    -5- Notes: The effects of calling what() after assignment
-        are implementation-defined.
-
    - -

    -First, does the Note only apply to the assignment operator? If so, -what are the effects of calling what() on a copy of an object? Is -the returned pointer supposed to point to an identical copy of -the NTBS returned by what() called on the original object or not? -

    - -

    -Second, is this Note intended to extend to all the derived classes -in section 19? I.e., does the standard provide any guarantee for -the effects of what() called on a copy of any of the derived class -described in section 19? -

    - -

    -Finally, if the answer to the first question is no, I believe it -constitutes a defect since throwing an exception object typically -implies invoking the copy ctor on the object. If the answer is yes, -then I believe the standard ought to be clarified to spell out -exactly what the effects are on the copy (i.e., after the copy -ctor was called). -

    - -

    [Redmond: Yes, this is fuzzy. The issue of derived classes is - fuzzy too.]

    - - -

    [ -Batavia: Howard provided wording. -]

    - - -

    [ -Bellevue: -]

    - - -
    -

    -Eric concerned this is unimplementable, due to nothrow guarantees. -Suggested implementation would involve reference counting. -

    -

    -Is the implied reference counting subtle enough to call out a note on -implementation? Probably not. -

    -

    -If reference counting required, could we tighten specification further -to require same pointer value? Probably an overspecification, especially -if exception classes defer evalutation of final string to calls to -what(). -

    -

    -Remember issue moved open and not resolved at Batavia, but cannot -remember who objected to canvas a disenting opinion - please speak up if -you disagree while reading these minutes! -

    -

    -Move to Ready as we are accepting words unmodified. -

    -
    - -

    [ -Sophia Antipolis: -]

    - - -
    -The issue was pulled from Ready. It needs to make clear that only homogenous copying -is intended to be supported. Not coping from a dervied to a base. -
    - - - - -

    Proposed resolution:

    - -

    -Change 18.7.1 [exception] to: -

    - -
    -
    exception(const exception& e) throw();
-exception& operator=(const exception& e) throw();
    -
    -

    --4- Effects: Copies an exception object. -

    -

    - -5- Remarks: The effects of calling what() after assignment are implementation-defined. -

    -

    --5- Throws: Nothing. This also applies -to all standard library-defined classes that derive from exception. -

    -

    --7- Postcondition: strcmp(what(), e.what()) == 0. This also applies -to all standard library-defined classes that derive from exception. -

    - -
    -
    - - - - -
    -

    473. underspecified ctype calls

    -

    Section: 22.2.1.1 [locale.ctype] Status: Open - Submitter: Martin Sebor Date: 2004-07-01

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -Most ctype member functions come in two forms: one that operates -on a single character at a time and another form that operates -on a range of characters. Both forms are typically described by -a single Effects and/or Returns clause. -

    -

    -The Returns clause of each of the single-character non-virtual forms -suggests that the function calls the corresponding single character -virtual function, and that the array form calls the corresponding -virtual array form. Neither of the two forms of each virtual member -function is required to be implemented in terms of the other. -

    -

    -There are three problems: -

    -

    -1. One is that while the standard does suggest that each non-virtual -member function calls the corresponding form of the virtual function, -it doesn't actually explicitly require it. -

    -

    -Implementations that cache results from some of the virtual member -functions for some or all values of their arguments might want to -call the array form from the non-array form the first time to fill -the cache and avoid any or most subsequent virtual calls. Programs -that rely on each form of the virtual function being called from -the corresponding non-virtual function will see unexpected behavior -when using such implementations. -

    -

    -2. The second problem is that either form of each of the virtual -functions can be overridden by a user-defined function in a derived -class to return a value that is different from the one produced by -the virtual function of the alternate form that has not been -overriden. -

    -

    -Thus, it might be possible for, say, ctype::widen(c) to return one -value, while for ctype::widen(&c, &c + 1, &wc) to set -wc to another value. This is almost certainly not intended. Both -forms of every function should be required to return the same result -for the same character, otherwise the same program using an -implementation that calls one form of the functions will behave -differently than when using another implementation that calls the -other form of the function "under the hood." -

    -

    -3. The last problem is that the standard text fails to specify whether -one form of any of the virtual functions is permitted to be implemented -in terms of the other form or not, and if so, whether it is required -or permitted to call the overridden virtual function or not. -

    -

    -Thus, a program that overrides one of the virtual functions so that -it calls the other form which then calls the base member might end -up in an infinite loop if the called form of the base implementation -of the function in turn calls the other form. -

    -

    -Lillehammer: Part of this isn't a real problem. We already talk about -caching. 22.1.1/6 But part is a real problem. ctype virtuals may call -each other, so users don't know which ones to override to avoid avoid -infinite loops.

    - -

    This is a problem for all facet virtuals, not just ctype virtuals, -so we probably want a blanket statement in clause 22 for all -facets. The LWG is leaning toward a blanket prohibition, that a -facet's virtuals may never call each other. We might want to do that -in clause 27 too, for that matter. A review is necessary. Bill will -provide wording.

    - - -

    Proposed resolution:

    - - - - -
    -

    484. Convertible to T

    -

    Section: 24.1.1 [input.iterators] Status: Open - Submitter: Chris Jefferson Date: 2004-09-16

    -

    View all other issues in [input.iterators].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    From comp.std.c++:

    - -

    -I note that given an input iterator a for type T, -then *a only has to be "convertable to T", not actually of type T. -

    - -

    Firstly, I can't seem to find an exact definition of "convertable to T". -While I assume it is the obvious definition (an implicit conversion), I -can't find an exact definition. Is there one?

    - -

    Slightly more worryingly, there doesn't seem to be any restriction on -the this type, other than it is "convertable to T". Consider two input -iterators a and b. I would personally assume that most people would -expect *a==*b would perform T(*a)==T(*b), however it doesn't seem that -the standard requires that, and that whatever type *a is (call it U) -could have == defined on it with totally different symantics and still -be a valid inputer iterator.

    - -

    Is this a correct reading? When using input iterators should I write -T(*a) all over the place to be sure that the object i'm using is the -class I expect?

    - -

    This is especially a nuisance for operations that are defined to be - "convertible to bool". (This is probably allowed so that - implementations could return say an int and avoid an unnessary - conversion. However all implementations I have seen simply return a - bool anyway. Typical implemtations of STL algorithms just write - things like while(a!=b && *a!=0). But strictly - speaking, there are lots of types that are convertible to T but - that also overload the appropriate operators so this doesn't behave - as expected.

    - -

    If we want to make code like this legal (which most people seem to - expect), then we'll need to tighten up what we mean by "convertible - to T".

    - -

    [Lillehammer: The first part is NAD, since "convertible" is - well-defined in core. The second part is basically about pathological - overloads. It's a minor problem but a real one. So leave open for - now, hope we solve it as part of iterator redesign.]

    - - - -

    Proposed resolution:

    - - - - - -
    -

    485. output iterator insufficently constrained

    -

    Section: 24.1.2 [output.iterators] Status: Open - Submitter: Chris Jefferson Date: 2004-10-13

    -

    View all other issues in [output.iterators].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -The note on 24.1.2 Output iterators insufficently limits what can be -performed on output iterators. While it requires that each iterator is -progressed through only once and that each iterator is written to only -once, it does not require the following things:

    - -

    Note: Here it is assumed that x is an output iterator of type X which -has not yet been assigned to.

    - -

    a) That each value of the output iterator is written to: -The standard allows: -++x; ++x; ++x; -

    - -

    -b) That assignments to the output iterator are made in order -X a(x); ++a; *a=1; *x=2; is allowed -

    - -

    -c) Chains of output iterators cannot be constructed: -X a(x); ++a; X b(a); ++b; X c(b); ++c; is allowed, and under the current -wording (I believe) x,a,b,c could be written to in any order. -

    - -

    I do not believe this was the intension of the standard?

    -

    [Lillehammer: Real issue. There are lots of constraints we - intended but didn't specify. Should be solved as part of iterator - redesign.]

    - - - -

    Proposed resolution:

    - - - - - -
    -

    492. Invalid iterator arithmetic expressions

    -

    Section: 23 [containers], 24 [iterators], 25 [algorithms] Status: Open - Submitter: Thomas Mang Date: 2004-12-12

    -

    View other active issues in [containers].

    -

    View all other issues in [containers].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    Various clauses other than clause 25 make use of iterator arithmetic not -supported by the iterator category in question. -Algorithms in clause 25 are exceptional because of 25 [lib.algorithms], -paragraph 9, but this paragraph does not provide semantics to the -expression "iterator - n", where n denotes a value of a distance type -between iterators.

    - -

    1) Examples of current wording:

    - -

    Current wording outside clause 25:

    - -

    -23.2.2.4 [lib.list.ops], paragraphs 19-21: "first + 1", "(i - 1)", -"(last - first)" -23.3.1.1 [lib.map.cons], paragraph 4: "last - first" -23.3.2.1 [lib.multimap.cons], paragraph 4: "last - first" -23.3.3.1 [lib.set.cons], paragraph 4: "last - first" -23.3.4.1 [lib.multiset.cons], paragraph 4: "last - first" -24.4.1 [lib.reverse.iterators], paragraph 1: "(i - 1)" -

    - -

    -[Important note: The list is not complete, just an illustration. The -same issue might well apply to other paragraphs not listed here.]

    - -

    None of these expressions is valid for the corresponding iterator -category.

    - -

    Current wording in clause 25:

    - -

    -25.1.1 [lib.alg.foreach], paragraph 1: "last - 1" -25.1.3 [lib.alg.find.end], paragraph 2: "[first1, last1 - -(last2-first2))" -25.2.8 [lib.alg.unique], paragraph 1: "(i - 1)" -25.2.8 [lib.alg.unique], paragraph 5: "(i - 1)" -

    - -

    -However, current wording of 25 [lib.algorithms], paragraph 9 covers -neither of these four cases:

    - -

    Current wording of 25 [lib.algorithms], paragraph 9:

    - -

    -"In the description of the algorithms operator + and - are used for some -of the iterator categories for which they do not have to be defined. In -these cases the semantics of a+n is the same as that of

    -
    {X tmp = a;
-advance(tmp, n);
-return tmp;
-}
-
    -

    and that of b-a is the same as of return distance(a, b)"

    - -

    -This paragrpah does not take the expression "iterator - n" into account, -where n denotes a value of a distance type between two iterators [Note: -According to current wording, the expression "iterator - n" would be -resolved as equivalent to "return distance(n, iterator)"]. Even if the -expression "iterator - n" were to be reinterpreted as equivalent to -"iterator + -n" [Note: This would imply that "a" and "b" were -interpreted implicitly as values of iterator types, and "n" as value of -a distance type], then 24.3.4/2 interfers because it says: "Requires: n -may be negative only for random access and bidirectional iterators.", -and none of the paragraphs quoted above requires the iterators on which -the algorithms operate to be of random access or bidirectional category. -

    - -

    2) Description of intended behavior:

    - -

    -For the rest of this Defect Report, it is assumed that the expression -"iterator1 + n" and "iterator1 - iterator2" has the semantics as -described in current 25 [lib.algorithms], paragraph 9, but applying to -all clauses. The expression "iterator1 - n" is equivalent to an -result-iterator for which the expression "result-iterator + n" yields an -iterator denoting the same position as iterator1 does. The terms -"iterator1", "iterator2" and "result-iterator" shall denote the value of -an iterator type, and the term "n" shall denote a value of a distance -type between two iterators.

    - -

    -All implementations known to the author of this Defect Report comply -with these assumptions. -No impact on current code is expected.

    - -

    3) Proposed fixes:

    - - -

    Change 25 [lib.algorithms], paragraph 9 to:

    - -

    -"In the description of the algorithms operator + and - are used for some -of the iterator categories for which they do not have to be defined. In -this paragraph, a and b denote values of an iterator type, and n denotes -a value of a distance type between two iterators. In these cases the -semantics of a+n is the same as that of

    -
    {X tmp = a;
-advance(tmp, n);
-return tmp;
-}
-
    -

    ,the semantics of a-n denotes the value of an iterator i for which the -following condition holds: -advance(i, n) == a, -and that of b-a is the same as of -return distance(a, b)". -

    - -

    Comments to the new wording:

    - -

    -a) The wording " In this paragraph, a and b denote values of an iterator -type, and n denotes a value of a distance type between two iterators." -was added so the expressions "b-a" and "a-n" are distinguished regarding -the types of the values on which they operate. -b) The wording ",the semantics of a-n denotes the value of an iterator i -for which the following condition holds: advance(i, n) == a" was added -to cover the expression 'iterator - n'. The wording "advance(i, n) == a" -was used to avoid a dependency on the semantics of a+n, as the wording -"i + n == a" would have implied. However, such a dependency might well -be deserved. -c) DR 225 is not considered in the new wording. -

    - -

    -Proposed fixes regarding invalid iterator arithmetic expressions outside -clause 25:

    - -

    -Either -a) Move modified 25 [lib.algorithms], paragraph 9 (as proposed above) -before any current invalid iterator arithmetic expression. In that case, -the first sentence of 25 [lib.algorithms], paragraph 9, need also to be -modified and could read: "For the rest of this International Standard, -...." / "In the description of the following clauses including this -...." / "In the description of the text below ..." etc. - anyways -substituting the wording "algorithms", which is a straight reference to -clause 25. -In that case, 25 [lib.algorithms] paragraph 9 will certainly become -obsolete. -Alternatively, -b) Add an appropiate paragraph similar to resolved 25 [lib.algorithms], -paragraph 9, to the beginning of each clause containing invalid iterator -arithmetic expressions. -Alternatively, -c) Fix each paragraph (both current wording and possible resolutions of -DRs) containing invalid iterator arithmetic expressions separately. -

    - -

    5) References to other DRs:

    - -

    -See DR 225. -See DR 237. The resolution could then also read "Linear in last - -first". -

    - -

    [ -Bellevue: -]

    - - -
    -Keep open and ask Bill to provide wording. -
    - - -

    Proposed resolution:

    - -

    [Lillehammer: Minor issue, but real. We have a blanket statement -about this in 25/11. But (a) it should be in 17, not 25; and (b) it's -not quite broad enough, because there are some arithmetic expressions -it doesn't cover. Bill will provide wording.]

    - - - - - - - -
    -

    498. Requirements for partition() and stable_partition() too strong

    -

    Section: 25.2.13 [alg.partitions] Status: Open - Submitter: Sean Parent, Joe Gottman Date: 2005-05-04

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -Problem: -The iterator requirements for partition() and stable_partition() [25.2.12] -are listed as BidirectionalIterator, however, there are efficient algorithms -for these functions that only require ForwardIterator that have been known -since before the standard existed. The SGI implementation includes these (see -http://www.sgi.com/tech/stl/partition.html -and -http://www.sgi.com/tech/stl/stable_partition.html). -

    - - -

    Proposed resolution:

    -

    -Change 25.2.12 from

    -
    template<class BidirectionalIterator, class Predicate> 
-BidirectionalIterator partition(BidirectionalIterato r first, 
-                                BidirectionalIterator last, 
-                                Predicate pred); 
-
    -

    to

    -
    template<class ForwardIterator, class Predicate> 
-ForwardIterator partition(ForwardIterator first, 
-                          ForwardIterator last, 
-                          Predicate pred); 
-
    -

    Change the complexity from

    - -

    -At most (last - first)/2 swaps are done. Exactly (last - first) -applications of the predicate are done. -

    - -

    to

    - -

    -If ForwardIterator is a bidirectional_iterator, at most (last - first)/2 -swaps are done; otherwise at most (last - first) swaps are done. Exactly -(last - first) applications of the predicate are done. -

    - - - -

    Rationale:

    -

    -Partition is a "foundation" algorithm useful in many contexts (like sorting -as just one example) - my motivation for extending it to include forward -iterators is slist - without this extension you can't partition an slist -(without writing your own partition). Holes like this in the standard -library weaken the argument for generic programming (ideally I'd be able -to provide a library that would refine std::partition() to other concepts -without fear of conflicting with other libraries doing the same - but -that is a digression). I consider the fact that partition isn't defined -to work for ForwardIterator a minor embarrassment. -

    - -

    [Mont Tremblant: Moved to Open, request motivation and use cases -by next meeting. Sean provided further rationale by post-meeting -mailing.]

    - - - - - - - -
    -

    502. Proposition: Clarification of the interaction between a facet and an iterator

    -

    Section: 22.1.1.1.1 [locale.category] Status: Open - Submitter: Christopher Conrade Zseleghovski Date: 2005-06-07

    -

    View all other issues in [locale.category].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -Motivation: -

    - -

    -This requirement seems obvious to me, it is the essence of code modularity. -I have complained to Mr. Plauger that the Dinkumware library does not -observe this principle but he objected that this behaviour is not covered in -the standard. -

    - - -

    Proposed resolution:

    -

    -Append the following point to 22.1.1.1.1: -

    - -

    -6. The implementation of a facet of Table 52 parametrized with an -InputIterator/OutputIterator should use that iterator only as character -source/sink respectively. -For a *_get facet, it means that the value received depends only on the -sequence of input characters and not on how they are accessed. -For a *_put facet, it means that the sequence of characters output depends -only on the value to be formatted and not of how the characters are stored. -

    - -

    [ -Berlin: Moved to Open, Need to clean up this area to make it clear -locales don't have to contain open ended sets of facets. Jack, Howard, -Bill. -]

    - - - - - - - -
    -

    503. more on locales

    -

    Section: 22.2 [locale.categories] Status: Open - Submitter: P.J. Plauger Date: 2005-06-20

    -

    View other active issues in [locale.categories].

    -

    View all other issues in [locale.categories].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -a) In 22.2.1.1 para. 2 we refer to "the instantiations required in Table -51" to refer to the facet *objects* associated with a locale. And we -almost certainly mean just those associated with the default or "C" -locale. Otherwise, you can't switch to a locale that enforces a different -mapping between narrow and wide characters, or that defines additional -uppercase characters. -

    - -

    -b) 22.2.1.5 para. 3 (codecvt) has the same issues. -

    - -

    -c) 22.2.1.5.2 (do_unshift) is even worse. It *forbids* the generation of -a homing sequence for the basic character set, which might very well need -one. -

    - -

    -d) 22.2.1.5.2 (do_length) likewise dictates that the default mapping -between wide and narrow characters be taken as one-for-one. -

    - -

    -e) 22.2.2 para. 2 (num_get/put) is both muddled and vacuous, as far as -I can tell. The muddle is, as before, calling Table 51 a list of -instantiations. But the constraint it applies seems to me to cover -*all* defined uses of num_get/put, so why bother to say so? -

    - -

    -f) 22.2.3.1.2 para. 1(do_decimal_point) says "The required instantiations -return '.' or L'.'.) Presumably this means "as appropriate for the -character type. But given the vague definition of "required" earlier, -this overrules *any* change of decimal point for non "C" locales. -Surely we don't want to do that. -

    - -

    -g) 22.2.3.1.2 para. 2 (do_thousands_sep) says "The required instantiations -return ',' or L','.) As above, this probably means "as appropriate for the -character type. But this overrules the "C" locale, which requires *no* -character ('\0') for the thousands separator. Even if we agree that we -don't mean to block changes in decimal point or thousands separator, -we should also eliminate this clear incompatibility with C. -

    - -

    -h) 22.2.3.1.2 para. 2 (do_grouping) says "The required instantiations -return the empty string, indicating no grouping." Same considerations -as for do_decimal_point. -

    - -

    -i) 22.2.4.1 para. 1 (collate) refers to "instantiations required in Table -51". Same bad jargon. -

    - -

    -j) 22.2.4.1.2 para. 1 (do_compare) refers to "instantiations required -in Table 51". Same bad jargon. -

    - -

    -k) 22.2.5 para. 1 (time_get/put) uses the same muddled and vacuous -as num_get/put. -

    - -

    -l) 22.2.6 para. 2 (money_get/put) uses the same muddled and vacuous -as num_get/put. -

    - -

    -m) 22.2.6.3.2 (do_pos/neg_format) says "The instantiations required -in Table 51 ... return an object of type pattern initialized to -{symbol, sign, none, value}." This once again *overrides* the "C" -locale, as well as any other locale." -

    - -

    -3) We constrain the use_facet calls that can be made by num_get/put, -so why don't we do the same for money_get/put? Or for any of the -other facets, for that matter? -

    - -

    -4) As an almost aside, we spell out when a facet needs to use the ctype -facet, but several also need to use a codecvt facet and we don't say so. -

    -

    [ -Berlin: Bill to provide wording. -]

    - - - -

    Proposed resolution:

    -

    -

    - - - - - -
    -

    522. Tuple doesn't define swap

    -

    Section: 20.4 [tuple], TR1 6.1 [tr.tuple] Status: Ready - Submitter: Andy Koenig Date: 2005-07-03

    -

    View other active issues in [tuple].

    -

    View all other issues in [tuple].

    -

    View all issues with Ready status.

    -

    Discussion:

    -

    -Tuple doesn't define swap(). It should. -

    -

    [ -Berlin: Doug to provide wording. -]

    - -

    [ -Batavia: Howard to provide wording. -]

    - -

    [ -Toronto: Howard to provide wording (really this time). -]

    - - -

    [ -Bellevue: Alisdair provided wording. -]

    - - - - -

    Proposed resolution:

    - -

    -Add these signatures to 20.4 [tuple] -

    - -
    template <class... Types>
-  void swap(tuple<Types...>& x, tuple<Types...>& y);
-template <class... Types>
-  void swap(tuple<Types...>&& x, tuple<Types...>& y);
-template <class... Types>
-  void swap(tuple<Types...>& x, tuple<Types...>&& y); 
-
    - -

    -Add this signature to 20.4.1 [tuple.tuple] -

    - -
    void swap(tuple&&);
-
    - -

    -Add the following two sections to the end of the tuple clauses -

    - -
    -

    -20.3.1.7 tuple swap [tuple.swap] -

    - -
    void swap(tuple&& rhs); 
-
    - -
    -

    -Requires: Each type in Types shall be Swappable. -

    -

    -Effects: Calls swap for each element in *this and its corresponding element -in rhs. -

    -

    -Throws: Nothing, unless one of the element-wise swap calls throw an -exception. -

    -
    - -

    -20.3.1.8 tuple specialized algorithms [tuple.special] -

    - -
    template <class... Types>
-  void swap(tuple<Types...>& x, tuple<Types...>& y);
-template <class... Types>
-  void swap(tuple<Types...>&& x, tuple<Types...>& y);
-template <class... Types>
-  void swap(tuple<Types...>& x, tuple<Types...>&& y); 
-
    - -
    -

    -Effects: x.swap(y) -

    -
    -
    - - - - - - -
    -

    523. regex case-insensitive character ranges are unimplementable as specified

    -

    Section: 28 [re] Status: Open - Submitter: Eric Niebler Date: 2005-07-01

    -

    View all other issues in [re].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -A problem with TR1 regex is currently being discussed on the Boost -developers list. It involves the handling of case-insensitive matching -of character ranges such as [Z-a]. The proper behavior (according to the -ECMAScript standard) is unimplementable given the current specification -of the TR1 regex_traits<> class template. John Maddock, the author of -the TR1 regex proposal, agrees there is a problem. The full discussion -can be found at http://lists.boost.org/boost/2005/06/28850.php (first -message copied below). We don't have any recommendations as yet. -

    -

    --- Begin original message -- -

    -

    -The situation of interest is described in the ECMAScript specification -(ECMA-262), section 15.10.2.15: -

    -

    -"Even if the pattern ignores case, the case of the two ends of a range -is significant in determining which characters belong to the range. -Thus, for example, the pattern /[E-F]/i matches only the letters E, F, -e, and f, while the pattern /[E-f]/i matches all upper and lower-case -ASCII letters as well as the symbols [, \, ], ^, _, and `." -

    -

    -A more interesting case is what should happen when doing a -case-insentitive match on a range such as [Z-a]. It should match z, Z, -a, A and the symbols [, \, ], ^, _, and `. This is not what happens with -Boost.Regex (it throws an exception from the regex constructor). -

    -

    -The tough pill to swallow is that, given the specification in TR1, I -don't think there is any effective way to handle this situation. -According to the spec, case-insensitivity is handled with -regex_traits<>::translate_nocase(CharT) -- two characters are equivalent -if they compare equal after both are sent through the translate_nocase -function. But I don't see any way of using this translation function to -make character ranges case-insensitive. Consider the difficulty of -detecting whether "z" is in the range [Z-a]. Applying the transformation -to "z" has no effect (it is essentially std::tolower). And we're not -allowed to apply the transformation to the ends of the range, because as -ECMA-262 says, "the case of the two ends of a range is significant." -

    -

    -So AFAICT, TR1 regex is just broken, as is Boost.Regex. One possible fix -is to redefine translate_nocase to return a string_type containing all -the characters that should compare equal to the specified character. But -this function is hard to implement for Unicode, and it doesn't play nice -with the existing ctype facet. What a mess! -

    -

    --- End original message -- -

    - -

    [ -John Maddock adds: -]

    - - -

    -One small correction, I have since found that ICU's regex package does -implement this correctly, using a similar mechanism to the current -TR1.Regex. -

    -

    -Given an expression [c1-c2] that is compiled as case insensitive it: -

    -

    -Enumerates every character in the range c1 to c2 and converts it to it's -case folded equivalent. That case folded character is then used a key to a -table of equivalence classes, and each member of the class is added to the -list of possible matches supported by the character-class. This second step -isn't possible with our current traits class design, but isn't necessary if -the input text is also converted to a case-folded equivalent on the fly. -

    -

    -ICU applies similar brute force mechanisms to character classes such as -[[:lower:]] and [[:word:]], however these are at least cached, so the impact -is less noticeable in this case. -

    -

    -Quick and dirty performance comparisons show that expressions such as -"[X-\\x{fff0}]+" are indeed very slow to compile with ICU (about 200 times -slower than a "normal" expression). For an application that uses a lot of -regexes this could have a noticeable performance impact. ICU also has an -advantage in that it knows the range of valid characters codes: code points -outside that range are assumed not to require enumeration, as they can not -be part of any equivalence class. I presume that if we want the TR1.Regex -to work with arbitrarily large character sets enumeration really does become -impractical. -

    -

    -Finally note that Unicode has: -

    -

    -Three cases (upper, lower and title). -One to many, and many to one case transformations. -Character that have context sensitive case translations - for example an -uppercase sigma has two different lowercase forms - the form chosen depends -on context(is it end of a word or not), a caseless match for an upper case -sigma should match either of the lower case forms, which is why case folding -is often approximated by tolower(toupper(c)). -

    -

    -Probably we need some way to enumerate character equivalence classes, -including digraphs (either as a result or an input), and some way to tell -whether the next character pair is a valid digraph in the current locale. -

    -

    -Hoping this doesn't make this even more complex that it was already, -

    - -

    [ -Portland: Alisdair: Detect as invalid, throw an exception. -Pete: Possible general problem with case insensitive ranges. -]

    - - - - -

    Proposed resolution:

    - - - - - -
    -

    539. partial_sum and adjacent_difference should mention requirements

    -

    Section: 26.6.3 [partial.sum] Status: Open - Submitter: Marc Schoolderman Date: 2006-02-06

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -There are some problems in the definition of partial_sum and -adjacent_difference in 26.4 [lib.numeric.ops] -

    - -

    -Unlike accumulate and inner_product, these functions are not -parametrized on a "type T", instead, 26.4.3 [lib.partial.sum] simply -specifies the effects clause as; -

    - -

    -Assigns to every element referred to by iterator i in the range -[result,result + (last - first)) a value correspondingly equal to -

    -
    ((...(* first + *( first + 1)) + ...) + *( first + ( i - result )))
-
    -
    - -

    -And similarly for BinaryOperation. Using just this definition, it seems -logical to expect that: -

    - - -
    char i_array[4] = { 100, 100, 100, 100 };
-int  o_array[4];
-
-std::partial_sum(i_array, i_array+4, o_array);
-
    - -

    -Is equivalent to -

    - -
    int o_array[4] = { 100, 100+100, 100+100+100, 100+100+100+100 };
-
    - -

    -i.e. 100, 200, 300, 400, with addition happening in the result type, -int. -

    - -

    -Yet all implementations I have tested produce 100, -56, 44, -112, -because they are using an accumulator of the InputIterator's -value_type, which in this case is char, not int. -

    - -

    -The issue becomes more noticeable when the result of the expression *i + -*(i+1) or binary_op(*i, *i-1) can't be converted to the -value_type. In a contrived example: -

    - -
    enum not_int { x = 1, y = 2 };
-...
-not_int e_array[4] = { x, x, y, y };
-std::partial_sum(e_array, e_array+4, o_array);
-
    - -

    -Is it the intent that the operations happen in the input type, or in -the result type? -

    - -

    -If the intent is that operations happen in the result type, something -like this should be added to the "Requires" clause of 26.4.3/4 -[lib.partial.sum]: -

    - -

    -The type of *i + *(i+1) or binary_op(*i, *(i+1)) shall meet the -requirements of CopyConstructible (20.1.3) and Assignable -(23.1) types. -

    - -

    -(As also required for T in 26.4.1 [lib.accumulate] and 26.4.2 -[lib.inner.product].) -

    - -

    -The "auto initializer" feature proposed in -N1894 -is not required to -implement partial_sum this way. The 'narrowing' behaviour can still be -obtained by using the std::plus<> function object. -

    - -

    -If the intent is that operations happen in the input type, then -something like this should be added instead; -

    - -

    -The type of *first shall meet the requirements of -CopyConstructible (20.1.3) and Assignable (23.1) types. -The result of *i + *(i+1) or binary_op(*i, *(i+1)) shall be -convertible to this type. -

    - -

    -The 'widening' behaviour can then be obtained by writing a custom proxy -iterator, which is somewhat involved. -

    - -

    -In both cases, the semantics should probably be clarified. -

    - -

    -26.4.4 [lib.adjacent.difference] is similarly underspecified, although -all implementations seem to perform operations in the 'result' type: -

    - -
    unsigned char i_array[4] = { 4, 3, 2, 1 };
-int o_array[4];
-
-std::adjacent_difference(i_array, i_array+4, o_array);
-
    - -

    -o_array is 4, -1, -1, -1 as expected, not 4, 255, 255, 255. -

    - -

    -In any case, adjacent_difference doesn't mention the requirements on the -value_type; it can be brought in line with the rest of 26.4 -[lib.numeric.ops] by adding the following to 26.4.4/2 -[lib.adjacent.difference]: -

    - -

    -The type of *first shall meet the requirements of -CopyConstructible (20.1.3) and Assignable (23.1) types." -

    -

    [ -Berlin: Giving output iterator's value_types very controversial. Suggestion of -adding signatures to allow user to specify "accumulator". -]

    - - -

    [ -Bellevue: -]

    - - -
    -The intent of the algorithms is to perform their calculations using the type of the input iterator. -Proposed wording provided. -
    - -

    [ -Sophia Antipolis: -]

    - - -
    -We did not agree that the proposed resolution was correct. For example, -when the arguments are types (float*, float*, double*), the -highest-quality solution would use double as the type of the -accumulator. If the intent of the wording is to require that the type of -the accumulator must be the input_iterator's value_type, the wording -should specify it. -
    - - - -

    Proposed resolution:

    -

    -Add to section 26.6.3 [partial.sum] paragraph 4 the following two sentences: -

    - -
    -The type of *first shall meet the requirements of CopyConstructible? -(20.1.3?) and Assignable (23.1?) types. The result of *i + *(i+1) or -binary_op(*i, *(i+1)) shall be convertible to this type. -
    - -

    -Add to section 26.6.4 [adjacent.difference] paragraph 2 the following sentence: -

    - -
    -The type of *first shall meet the requirements of CopyConstructible? -(20.1.3) and Assignable (23.1) types. -
    - - - - - - -
    -

    546. _Longlong and _ULonglong are integer types

    -

    Section: TR1 5.1.1 [tr.rand.req] Status: Open - Submitter: Matt Austern Date: 2006-01-10

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -The TR sneaks in two new integer types, _Longlong and _Ulonglong, in [tr.c99]. -The rest of the TR should use that type. I believe this affects two places. -First, the random number requirements, 5.1.1/10-11, lists all of the types with -which template parameters named IntType and UIntType may be instantiated. -_Longlong (or "long long", assuming it is added to C++0x) should be added to the -IntType list, and UIntType (again, or "unsigned long long") should be added to -the UIntType list. Second, 6.3.2 lists the types for which hash<> is -required to be instantiable. _Longlong and _Ulonglong should be added to that -list, so that people may use long long as a hash key. -

    - - -

    Proposed resolution:

    -

    -

    - - - - - -
    -

    556. is Compare a BinaryPredicate?

    -

    Section: 25.3 [alg.sorting] Status: Open - Submitter: Martin Sebor Date: 2006-02-05

    -

    View all other issues in [alg.sorting].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -In 25, p8 we allow BinaryPredicates to return a type that's convertible -to bool but need not actually be bool. That allows predicates to return -things like proxies and requires that implementations be careful about -what kinds of expressions they use the result of the predicate in (e.g., -the expression in if (!pred(a, b)) need not be well-formed since the -negation operator may be inaccessible or return a type that's not -convertible to bool). -

    -

    -Here's the text for reference: -

    -

    - ...if an algorithm takes BinaryPredicate binary_pred as its argument - and first1 and first2 as its iterator arguments, it should work - correctly in the construct if (binary_pred(*first1, first2)){...}. -

    - -

    -In 25.3, p2 we require that the Compare function object return true -of false, which would seem to preclude such proxies. The relevant text -is here: -

    -

    - Compare is used as a function object which returns true if the first - argument is less than the second, and false otherwise... -

    - - -

    Proposed resolution:

    -

    -I think we could fix this by rewording 25.3, p2 to read somthing like: -

    -

    --2- Compare is used as a function object which returns -true if the first argument a BinaryPredicate. The -return value of the function call operator applied to an object of type -Compare, when converted to type bool, yields true -if the first argument of the call is less than the second, and -false otherwise. Compare comp is used throughout for -algorithms assuming an ordering relation. It is assumed that comp -will not apply any non-constant function through the dereferenced iterator. -

    - - -

    [ -Portland: Jack to define "convertible to bool" such that short circuiting isn't -destroyed. -]

    - - - - - -
    -

    564. stringbuf seekpos underspecified

    -

    Section: 27.7.1.4 [stringbuf.virtuals] Status: Open - Submitter: Martin Sebor Date: 2006-02-23

    -

    View all other issues in [stringbuf.virtuals].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -The effects of the seekpos() member function of -basic_stringbuf simply say that the function positions -the input and/or output sequences but fail to spell out exactly -how. This is in contrast to the detail in which seekoff() -is described. -

    - - -

    Proposed resolution:

    -

    - -Change 27.7.1.3, p13 to read: - -

    -
    -

    --13- Effects: Same as seekoff(off_type(sp), ios_base::beg, -which). Alters the stream position within the controlled sequences, -if possible, to correspond to the stream position stored in sp -(as described below). -

    -
      -
    • If (which & ios_base::in) != 0, positions the input sequence.
      • -
    • If (which & ios_base::out) != 0, positions the output sequence.
      • -
    • If sp is an invalid stream position, or if the function -positions neither sequence, the positioning operation fails. If sp -has not been obtained by a previous successful call to one of the positioning -functions (seekoff, seekpos, tellg, tellp) -the effect is undefined.
      • -
    -
    - - -

    [ -Kona (2007): A pos_type is a position in a stream by -definition, so there is no ambiguity as to what it means. Proposed -Disposition: NAD -]

    - - -

    [ -Post-Kona Martin adds: -I'm afraid I disagree -with the Kona '07 rationale for marking it NAD. The only text -that describes precisely what it means to position the input -or output sequence is in seekoff(). The seekpos() Effects -clause is inadequate in comparison and the proposed resolution -plugs the hole by specifying seekpos() in terms of seekoff(). -]

    - - - - - -
    -

    565. xsputn inefficient

    -

    Section: 27.5.2.4.5 [streambuf.virt.put] Status: Open - Submitter: Martin Sebor Date: 2006-02-23

    -

    View all issues with Open status.

    -

    Discussion:

    -

    - -streambuf::xsputn() is specified to have the effect of -"writing up to n characters to the output sequence as if by -repeated calls to sputc(c)." - -

    -

    - -Since sputc() is required to call overflow() when -(pptr() == epptr()) is true, strictly speaking -xsputn() should do the same. However, doing so would be -suboptimal in some interesting cases, such as in unbuffered mode or -when the buffer is basic_stringbuf. - -

    -

    - -Assuming calling overflow() is not really intended to be -required and the wording is simply meant to describe the general -effect of appending to the end of the sequence it would be worthwhile -to mention in xsputn() that the function is not actually -required to cause a call to overflow(). - -

    - - -

    Proposed resolution:

    -

    - -Add the following sentence to the xsputn() Effects clause in -27.5.2.4.5, p1 (N1804): - -

    -
    -

    --1- Effects: Writes up to n characters to the output -sequence as if by repeated calls to sputc(c). The characters -written are obtained from successive elements of the array whose first element -is designated by s. Writing stops when either n -characters have been written or a call to sputc(c) would return -traits::eof(). It is uspecified whether the function calls -overflow() when (pptr() == epptr()) becomes true or whether -it achieves the same effects by other means. -

    -
    -

    - -In addition, I suggest to add a footnote to this function with the -same text as Footnote 292 to make it extra clear that derived classes -are permitted to override xsputn() for efficiency. - -

    - - -

    [ -Kona (2007): We want to permit a streambuf that streams output directly -to a device without making calls to sputc or overflow. We believe that -has always been the intention of the committee. We believe that the -proposed wording doesn't accomplish that. Proposed Disposition: Open -]

    - - - - - -
    -

    568. log2 overloads missing

    -

    Section: TR1 8.16.4 [tr.c99.cmath.over] Status: New - Submitter: Paolo Carlini Date: 2006-03-07

    -

    View all issues with New status.

    -

    Discussion:

    -

    -log2 is missing from the list of "additional overloads" in TR1 8.16.4 [tr.c99.cmath.over] p1. -

    - -

    -Hinnant: This is a TR1 issue only. It is fixed in the current (N2135) WD. -

    - - -

    Proposed resolution:

    -

    -Add log2 to the list of functions in TR1 8.16.4 [tr.c99.cmath.over] p1. -

    - - - - - -
    -

    573. C++0x file positioning should handle modern file sizes

    -

    Section: 27.4.3 [fpos] Status: Open - Submitter: Beman Dawes Date: 2006-04-12

    -

    View all other issues in [fpos].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -There are two deficiencies related to file sizes: -

    -
      -
    1. It doesn't appear that the Standard Library is specified in - a way that handles modern file sizes, which are often too - large to be represented by an unsigned long.
      2. - -
    2. The std::fpos class does not currently have the ability to - set/get file positions.
      3. -
    -

    -The Dinkumware implementation of the Standard Library as shipped with the Microsoft compiler copes with these issues by: -

    -
      -
    1. Defining fpos_t be long long, which is large enough to - represent any file position likely in the foreseeable future.
      2. - -
    2. Adding member functions to class fpos. For example, -
      fpos_t seekpos() const;
-
      -
      3. -
    -

    -Because there are so many types relating to file positions and offsets (fpos_t, -fpos, pos_type, off_type, streamoff, streamsize, streampos, wstreampos, and -perhaps more), it is difficult to know if the Dinkumware extensions are -sufficient. But they seem a useful starting place for discussions, and they do -represent existing practice. -

    - -

    [ -Kona (2007): We need a paper. It would be nice if someone proposed -clarifications to the definitions of pos_type and off_type. Currently -these definitions are horrible. Proposed Disposition: Open -]

    - - - -

    Proposed resolution:

    -

    -

    - - - - - -
    -

    580. unused allocator members

    -

    Section: 20.1.2 [allocator.requirements] Status: Open - Submitter: Martin Sebor Date: 2006-06-14

    -

    View other active issues in [allocator.requirements].

    -

    View all other issues in [allocator.requirements].

    -

    View all issues with Open status.

    -

    Duplicate of: 479

    -

    Discussion:

    -

    - -C++ Standard Library templates that take an allocator as an argument -are required to call the allocate() and -deallocate() members of the allocator object to obtain -storage. However, they do not appear to be required to call any other -allocator members such as construct(), -destroy(), address(), and -max_size(). This makes these allocator members less than -useful in portable programs. - -

    -

    - -It's unclear to me whether the absence of the requirement to use these -allocator members is an unintentional omission or a deliberate -choice. However, since the functions exist in the standard allocator -and since they are required to be provided by any user-defined -allocator I believe the standard ought to be clarified to explictly -specify whether programs should or should not be able to rely on -standard containers calling the functions. - -

    -

    - -I propose that all containers be required to make use of these -functions. - -

    -

    [ -Batavia: We support this resolution. Martin to provide wording. -]

    - -

    [ -pre-Oxford: Martin provided wording. -]

    - - - -

    Proposed resolution:

    -

    - -Specifically, I propose to change 23.1 [container.requirements], -p9 as follows: - -

    -
    -

    --9- Copy constructors for all container types defined in this clause -that are parametrized on Allocator copy -anthe allocator argument from their respective -first parameters. - -All other constructors for these container types take an -const Allocator& argument (20.1.6), an -allocator whose value_type is the same as the container's -value_type. - -A copy of this argument isshall be used for any -memory allocation and deallocation performed, -by these constructors and by all member functions, during -the lifetime of each container object. Allocation shall be -performed "as if" by calling the allocate() member -function on a copy of the allocator object of the appropriate type -New Footnote), and deallocation "as if" by calling -deallocate() on a copy of the same allocator object of -the corresponding type. - -A copy of this argument shall also be used to construct and -destroy objects whose lifetime is managed by the container, including -but not limited to those of the container's value_type, -and to obtain their address. All objects residing in storage -allocated by a container's allocator shall be constructed "as if" by -calling the construct() member function on a copy of the -allocator object of the appropriate type. The same objects shall be -destroyed "as if" by calling destroy() on a copy of the -same allocator object of the same type. The address of such objects -shall be obtained "as if" by calling the address() member -function on a copy of the allocator object of the appropriate -type. - -Finally, a copy of this argument shall be used by its container -object to determine the maximum number of objects of the container's -value_type the container may store at the same time. The -container member function max_size() obtains this number -from the value returned by a call to -get_allocator().max_size(). - -In all container types defined in this clause that are -parametrized on Allocator, the member -get_allocator() returns a copy of the -Allocator object used to construct the -container.258) -

    -

    -New Footnote: This type may be different from Allocator: -it may be derived from Allocator via -Allocator::rebind<U>::other for the appropriate -type U. -

    -
    -

    - -The proposed wording seems cumbersome but I couldn't think of a better -way to describe the requirement that containers use their -Allocator to manage only objects (regardless of their -type) that persist over their lifetimes and not, for example, -temporaries created on the stack. That is, containers shouldn't be -required to call Allocator::construct(Allocator::allocate(1), -elem) just to construct a temporary copy of an element, or -Allocator::destroy(Allocator::address(temp), 1) to -destroy temporaries. - -

    - - -

    [ -Howard: This same paragraph will need some work to accommodate 431. -]

    - - -

    [ -post Oxford: This would be rendered NAD Editorial by acceptance of -N2257. -]

    - - - - - -
    -

    582. specialized algorithms and volatile storage

    -

    Section: 20.7.10.1 [uninitialized.copy] Status: Open - Submitter: Martin Sebor Date: 2006-06-14

    -

    View all other issues in [uninitialized.copy].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    - -The specialized algorithms [lib.specialized.algorithms] are specified -as having the general effect of invoking the following expression: - -

    - 
    -new (static_cast<void*>(&*i))
-    typename iterator_traits<ForwardIterator>::value_type (x)
-
-
    -

    - -This expression is ill-formed when the type of the subexpression -&*i is some volatile-qualified T. - -

    - -

    [ -Batavia: Lack of support for proposed resolution but agree there is a -defect. Howard to look at wording. Concern that move semantics -properly expressed if iterator returns rvalue. -]

    - - - - -

    Proposed resolution:

    -

    - -In order to allow these algorithms to operate on volatile storage I -propose to change the expression so as to make it well-formed even for -pointers to volatile types. Specifically, I propose the following -changes to clauses 20 and 24. Change 20.6.4.1, p1 to read: - -

    - 
    -Effects:
-
-typedef typename iterator_traits<ForwardIterator>::pointer    pointer;
-typedef typename iterator_traits<ForwardIterator>::value_type value_type;
-
-for (; first != last; ++result, ++first)
-    new (static_cast<void*>(const_cast<pointer>(&*result))
-        value_type (*first);
-
-
    -

    - -change 20.6.4.2, p1 to read - -

    - 
    -Effects:
-
-typedef typename iterator_traits<ForwardIterator>::pointer    pointer;
-typedef typename iterator_traits<ForwardIterator>::value_type value_type;
-
-for (; first != last; ++result, ++first)
-    new (static_cast<void*>(const_cast<pointer>(&*first))
-        value_type (*x);
-
-
    -

    - -and change 20.6.4.3, p1 to read - -

    - 
    -Effects:
-
-typedef typename iterator_traits<ForwardIterator>::pointer    pointer;
-typedef typename iterator_traits<ForwardIterator>::value_type value_type;
-
-for (; n--; ++first)
-    new (static_cast<void*>(const_cast<pointer>(&*first))
-        value_type (*x);
-
-
    -

    - -In addition, since there is no partial specialization for -iterator_traits<volatile T*> I propose to add one -to parallel such specialization for <const T*>. Specifically, I -propose to add the following text to the end of 24.3.1, p3: - -

    -

    - -and for pointers to volatile as - -

    - 
    -namespace std {
-template<class T> struct iterator_traits<volatile T*> {
-typedef ptrdiff_t difference_type;
-typedef T value_type;
-typedef volatile T* pointer;
-typedef volatile T& reference;
-typedef random_access_iterator_tag iterator_category;
-};
-}
-
-
    -

    - -Note that the change to iterator_traits isn't necessary -in order to implement the specialized algorithms in a way that allows -them to operate on volatile strorage. It is only necesassary in order -to specify their effects in terms of iterator_traits as -is done here. Implementations can (and some do) achieve the same -effect by means of function template overloading. - -

    - - - - -
    -

    585. facet error reporting

    -

    Section: 22.2 [locale.categories] Status: Open - Submitter: Martin Sebor, Paolo Carlini Date: 2006-06-22

    -

    View other active issues in [locale.categories].

    -

    View all other issues in [locale.categories].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    - -Section 22.2, paragraph 2 requires facet get() members -that take an ios_base::iostate& argument, -err, to ignore the (initial) value of the -argument, but to set it to ios_base::failbit in case of a -parse error. - -

    -

    - -We believe there are a few minor problems with this blanket -requirement in conjunction with the wording specific to each -get() member function. - -

    -

    - -First, besides get() there are other member functions -with a slightly different name (for example, -get_date()). It's not completely clear that the intent of -the paragraph is to include those as well, and at least one -implementation has interpreted the requirement literally. - -

    -

    - -Second, the requirement to "set the argument to -ios_base::failbit suggests that the functions are not -permitted to set it to any other value (such as -ios_base::eofbit, or even ios_base::eofbit | -ios_base::failbit). - -

    -

    - -However, 22.2.2.1.2, p5 (Stage 3 of num_get parsing) and -p6 (bool parsing) specifies that the do_get -functions perform err |= ios_base::eofbit, which -contradicts the earlier requirement to ignore err's initial -value. - -

    -

    - -22.2.6.1.2, p1 (the Effects clause of the money_get -facet's do_get member functions) also specifies that -err's initial value be used to compute the final -value by ORing it with either ios_base::failbit or -withios_base::eofbit | ios_base::failbit. - -

    - - -

    Proposed resolution:

    -

    - -We believe the intent is for all facet member functions that take an -ios_base::iostate& argument to: - -

    -
      -
    • - -ignore the initial value of the err argument, - -
      • -
    • - -reset err to ios_base::goodbit prior -to any further processing, - -
      • -
    • - -and set either ios_base::eofbit, or -ios_base::failbit, or both in err, as -appropriate, in response to reaching the end-of-file or on parse -error, or both. - -
      • -
    -

    - -To that effect we propose to change 22.2, p2 as follows: - -

    -

    - -The put() members make no provision for error -reporting. (Any failures of the OutputIterator argument must be -extracted from the returned iterator.) Unless otherwise -specified, the get() members that -take an ios_base::iostate& argument whose value -they ignore, but set to ios_base::failbit in case of a parse -error., err, start by evaluating -err = ios_base::goodbit, and may subsequently set -err to either ios_base::eofbit, or -ios_base::failbit, or ios_base::eofbit | -ios_base::failbit in response to reaching the end-of-file or in -case of a parse error, or both, respectively. - -

    - - -

    [ -Kona (2007): We need to change the proposed wording to clarify that the -phrase "the get members" actually denotes get(), get_date(), etc. -Proposed Disposition: Open -]

    - - - - -
    -

    588. requirements on zero sized tr1::arrays and other details

    -

    Section: 23.2.1 [array] Status: Open - Submitter: Gennaro Prota Date: 2006-07-18

    -

    View other active issues in [array].

    -

    View all other issues in [array].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -The wording used for section 23.2.1 [lib.array] seems to be subtly -ambiguous about zero sized arrays (N==0). Specifically: -

    -

    -* "An instance of array<T, N> stores N elements of type T, so that -[...]" -

    -

    -Does this imply that a zero sized array object stores 0 elements, i.e. -that it cannot store any element of type T? The next point clarifies -the rationale behind this question, basically how to implement begin() -and end(): -

    -

    -* 23.2.1.5 [lib.array.zero], p2: "In the case that N == 0, begin() == -end() == unique value." -

    -

    -What does "unique" mean in this context? Let's consider the following -possible implementations, all relying on a partial specialization: -

    -
    a)
-    template< typename T >
-    class array< T, 0 > {
-    
-        ....
-
-        iterator begin()
-        { return iterator( reinterpret_cast< T * >( this ) ); }
-        ....
-
-    };
-
    -

    -This has been used in boost, probably intending that the return value -had to be unique to the specific array object and that array couldn't -store any T. Note that, besides relying on a reinterpret_cast, has -(more than potential) alignment problems. -

    -
    b)
-    template< typename T >
-    class array< T, 0 > {
-    
-        T t;
-
-        iterator begin()
-        { return iterator( &t ); }
-        ....
-
-    };
-
    -

    -This provides a value which is unique to the object and to the type of -the array, but requires storing a T. Also, it would allow the user to -mistakenly provide an initializer list with one element. -

    -

    -A slight variant could be returning *the* null pointer of type T -

    -
        return static_cast<T*>(0);
-
    -

    -In this case the value would be unique to the type array<T, 0> but not -to the objects (all objects of type array<T, 0> with the same value -for T would yield the same pointer value). -

    -

    -Furthermore this is inconsistent with what the standard requires from -allocation functions (see library issue 9). -

    -

    -c) same as above but with t being a static data member; again, the -value would be unique to the type, not to the object. -

    -

    -d) to avoid storing a T *directly* while disallowing the possibility -to use a one-element initializer list a non-aggregate nested class -could be defined -

    -
        struct holder { holder() {} T t; } h;
-
    -

    -and then begin be defined as -

    -
     iterator begin() { return &h.t; }
-
    -

    -But then, it's arguable whether the array stores a T or not. -Indirectly it does. -

    -

    ------------------------------------------------------ -

    -

    -Now, on different issues: -

    -

    -* what's the effect of calling assign(T&) on a zero-sized array? There -seems to be only mention of front() and back(), in 23.2.1 [lib.array] -p4 (I would also suggest to move that bullet to section 23.2.1.5 -[lib.array.zero], for locality of reference) -

    -

    -* (minor) the opening paragraph of 23.2.1 [lib.array] wording is a bit -inconsistent with that of other sequences: that's not a problem in -itself, but compare it for instance with "A vector is a kind of -sequence that supports random access iterators"; though the intent is -obvious one might argue that the wording used for arrays doesn't tell -what an array is, and relies on the reader to infer that it is what -the <array> header defines. -

    -

    -* it would be desiderable to have a static const data member of type -std::size_t, with value N, for usage as integral constant expression -

    -

    -* section 23.1 [lib.container.requirements] seem not to consider -fixed-size containers at all, as it says: "[containers] control -allocation and deallocation of these objects [the contained objects] -through constructors, destructors, *insert and erase* operations" -

    -

    -* max_size() isn't specified: the result is obvious but, technically, -it relies on table 80: "size() of the largest possible container" -which, again, doesn't seem to consider fixed size containers -

    - - -

    Proposed resolution:

    -

    -

    - - -

    [ -Kona (2007): requirements on zero sized tr1::arrays and other details -Issue 617: std::array is a sequence that doesn't satisfy the sequence -requirements? Alisdair will prepare a paper. Proposed Disposition: Open -]

    - - - - - -
    -

    597. Decimal: The notion of 'promotion' cannot be emulated by user-defined types.

    -

    Section: TRDecimal 3.2 [trdec.types.types] Status: Open - Submitter: Daveed Vandevoorde Date: 2006-04-05

    -

    View other active issues in [trdec.types.types].

    -

    View all other issues in [trdec.types.types].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -In a private email, Daveed writes: -

    -
    -

    -I am not familiar with the C TR, but my guess is that the -class type approach still won't match a built-in type -approach because the notion of "promotion" cannot be -emulated by user-defined types. -

    -

    -Here is an example: -

    -
    -
    -		 struct S {
-		   S(_Decimal32 const&);  // Converting constructor
-		 };
-		 void f(S);
-
-		 void f(_Decimal64);
-
-		 void g(_Decimal32 d) {
-		   f(d);
-		 }
-
    - -
    -

    -If _Decimal32 is a built-in type, the call f(d) will likely -resolve to f(_Decimal64) because that requires only a -promotion, whereas f(S) requires a user-defined conversion. -

    -

    -If _Decimal32 is a class type, I think the call f(d) will be -ambiguous because both the conversion to _Decimal64 and the -conversion to S will be user-defined conversions with neither -better than the other. -

    -
    -

    -Robert comments: -

    -

    -In general, a library of arithmetic types cannot exactly emulate the -behavior of the intrinsic numeric types. There are several ways to tell -whether an implementation of the decimal types uses compiler -intrinisics or a library. For example: -

    -
                     _Decimal32 d1;
-                 d1.operator+=(5);  // If d1 is a builtin type, this won't compile.
-
    -

    -In preparing the decimal TR, we have three options: -

    -
      -
    1. require that the decimal types be class types
      2. -
    2. require that the decimal types be builtin types, like float and double
      3. -
    3. specify a library of class types, but allow enough implementor -latitude that a conforming implementation could instead provide builtin -types
      4. -
    -

    -We decided as a group to pursue option #3, but that approach implies -that implementations may not agree on the semantics of certain use -cases (first example, above), or on whether certain other cases are -well-formed (second example). Another potentially important problem is -that, under the present definition of POD, the decimal classes are not -POD types, but builtins will be. -

    -

    Note that neither example above implies any problems with respect to -C-to-C++ compatibility, since neither example can be expressed in C. -

    - - -

    Proposed resolution:

    - - - - - -
    -

    606. Decimal: allow narrowing conversions

    -

    Section: TRDecimal 3.2 [trdec.types.types] Status: Open - Submitter: Martin Sebor Date: 2006-06-15

    -

    View other active issues in [trdec.types.types].

    -

    View all other issues in [trdec.types.types].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -In c++std-lib-17205, Martin writes: -

    -

    ...was it a deliberate design choice to make narrowing -assignments ill-formed while permitting narrowing compound assignments? -For instance: -

    -
          decimal32 d32;
-      decimal64 d64;
-
-      d32 = 64;     // error
-      d32 += 64;    // okay
-
    -

    -In c++std-lib-17229, Robert responds: -

    -

    It is a vestige of an old idea that I forgot to remove -from the paper. Narrowing assignments should be permitted. The bug is -that the converting constructors that cause narrowing should not be -explicit. Thanks for pointing this out. -

    - -

    Proposed resolution:

    -

    -1. In "3.2.2 Class decimal32" synopsis, remove the explicit specifier from the narrowing conversions: -

    -
                    // 3.2.2.2 conversion from floating-point type:
-                explicit decimal32(decimal64 d64);
-                explicit decimal32(decimal128 d128);
-
    -

    -2. Do the same thing in "3.2.2.2. Conversion from floating-point type." -

    -

    -3. In "3.2.3 Class decimal64" synopsis, remove the explicit specifier from the narrowing conversion: -

    -
                    // 3.2.3.2 conversion from floating-point type:
-                explicit decimal64(decimal128 d128);
-
    -

    -4. Do the same thing in "3.2.3.2. Conversion from floating-point type." -

    - -

    [ -Redmond: We prefer explicit conversions for narrowing and implicit for widening. -]

    - - - - - - -
    -

    614. std::string allocator requirements still inconsistent

    -

    Section: 21.3 [basic.string] Status: Open - Submitter: Bo Persson Date: 2006-12-05

    -

    View other active issues in [basic.string].

    -

    View all other issues in [basic.string].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -This is based on N2134, where 21.3.1/2 states: -"... The Allocator object used shall be a copy of the Allocator object -passed to the basic_string object's constructor or, if the constructor does -not take an Allocator argument, a copy of a default-constructed Allocator -object." -

    -

    -Section 21.3.2/1 lists two constructors: -

    -
    basic_string(const basic_string<charT,traits,Allocator>& str );
-
-basic_string(const basic_string<charT,traits,Allocator>& str ,
-             size_type pos , size_type n = npos,
-             const Allocator& a = Allocator());
-
    -

    -and then says "In the first form, the Allocator value used is copied from -str.get_allocator().", which isn't an option according to 21.3.1. -

    -

    [ -Batavia: We need blanket statement to the effect of: -]

    - - -
      -
    1. If an allocator is passed in, use it, or,
      2. -
    2. If a string is passed in, use its allocator.
      3. -
    -

    [ -Review constructors and functions that return a string; make sure we follow these -rules (substr, operator+, etc.). Howard to supply wording. -]

    - - -

    [ -Bo adds: The new container constructor which takes only a size_type is not -consistent with 23.1 [container.requirements], p9 which says in part: - -

    -All other constructors for these container types take an -Allocator& argument (20.1.2), an allocator whose value type -is the same as the container's value type. A copy of this argument is -used for any memory allocation performed, by these constructors and by -all member functions, during the lifetime of each container object. -
    -]

    - - -

    [ -post Bellevue: We re-confirm that the issue is real. Pablo will provide wording. -]

    - - - - -

    Proposed resolution:

    -

    -

    - - - - - -
    -

    617. std::array is a sequence that doesn't satisfy the sequence requirements?

    -

    Section: 23.2.1 [array] Status: Open - Submitter: Bo Persson Date: 2006-12-30

    -

    View other active issues in [array].

    -

    View all other issues in [array].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -The <array> header is given under 23.2 [sequences]. -23.2.1 [array]/paragraph 3 says: -

    -

    -"Unless otherwise specified, all array operations are as described in -23.1 [container.requirements]". -

    -

    -However, array isn't mentioned at all in section 23.1 [container.requirements]. -In particular, Table 82 "Sequence requirements" lists several operations (insert, erase, clear) -that std::array does not have in 23.2.1 [array]. -

    -

    -Also, Table 83 "Optional sequence operations" lists several operations that -std::array does have, but array isn't mentioned. -

    - - -

    Proposed resolution:

    -

    -

    - - - - - -
    -

    629. complex insertion and locale dependence

    -

    Section: 26.3.6 [complex.ops] Status: Ready - Submitter: Gabriel Dos Reis Date: 2007-01-28

    -

    View all other issues in [complex.ops].

    -

    View all issues with Ready status.

    -

    Discussion:

    -

    -is there an issue opened for (0,3) as complex number with -the French local? With the English local, the above parses as an -imaginery complex number. With the French locale it parses as a -real complex number. -

    - -

    -Further notes/ideas from the lib-reflector, messages 17982-17984: -

    - -
    -

    -Add additional entries in num_punct to cover the complex separator (French would be ';'). -

    -

    -Insert a space before the comma, which should eliminate the ambiguity. -

    -

    -Solve the problem for ordered sequences in general, perhaps with a -dedicated facet. Then complex should use that solution. -

    -
    - -

    [ -Bellevue: -]

    - - -
    -

    -After much discussion, we agreed on the following: Add a footnote: -

    -

    -[In a locale in which comma is being used as a decimal point character, -inserting "showbase" into the output stream forces all outputs to show -an explicit decimal point character; then all inserted complex sequences -will extract unambiguously.] -

    -

    -And move this to READY status. -

    -
    - -

    [ -Pre-Sophia Antipolis, Howard adds: -]

    - - -
    -Changed "showbase" to "showpoint" and changed from Ready to Review. -
    - -

    [ -Post-Sophia Antipolis: -]

    - - -
    -

    -I neglected to pull this issue from the formal motions page after the "showbase" to "showpoint" change. -In Sophia Antipolis this change was reviewed by the LWG and the issue was set to Ready. We subsequently -voted the footnote into the WP with "showbase". -

    -

    -I'm changing from WP back to Ready to pick up the "showbase" to "showpoint" change. -

    -
    - - - -

    Proposed resolution:

    -

    -Add a footnote to 26.3.6 [complex.ops] p16: -

    - -
    -[In a locale in which comma is being used as a decimal point character, -inserting showpoint into the output stream forces all outputs to show -an explicit decimal point character; then all inserted complex sequences -will extract unambiguously.] -
    - - - - - -
    -

    630. arrays of valarray

    -

    Section: 26.5.2.1 [valarray.cons] Status: Open - Submitter: Martin Sebor Date: 2007-01-28

    -

    View other active issues in [valarray.cons].

    -

    View all other issues in [valarray.cons].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    - -Section 26.1 [numeric.requirements], p1 suggests that a -valarray specialization on a type T that -satisfies the requirements enumerated in the paragraph is itself a -valid type on which valarray may be instantiated -(Footnote 269 makes this clear). I.e., -valarray<valarray<T> > is valid as long as -T is valid. However, since implementations of -valarray are permitted to initialize storage allocated by -the class by invoking the default ctor of T followed by -the copy assignment operator, such implementations of -valarray wouldn't work with (perhaps user-defined) -specializations of valarray whose assignment operator had -undefined behavior when the size of its argument didn't match the size -of *this. By "wouldn't work" I mean that it would -be impossible to resize such an array of arrays by calling the -resize() member function on it if the function used the -copy assignment operator after constructing all elements using the -default ctor (e.g., by invoking new value_type[N]) to -obtain default-initialized storage) as it's permitted to do. - -

    -

    - -Stated more generally, the problem is that -valarray<valarray<T> >::resize(size_t) isn't -required or guaranteed to have well-defined semantics for every type -T that satisfies all requirements in -26.1 [numeric.requirements]. - -

    -

    - -I believe this problem was introduced by the adoption of the -resolution outlined in N0857, -Assignment of valarrays, from 1996. The copy assignment -operator of the original numerical array classes proposed in N0280, -as well as the one proposed in N0308 -(both from 1993), had well-defined semantics for arrays of unequal -size (the latter explicitly only when *this was empty; -assignment of non empty arrays of unequal size was a runtime error). - -

    -

    - -The justification for the change given in N0857 was the "loss of -performance [deemed] only significant for very simple operations on -small arrays or for architectures with very few registers." - -

    -

    - -Since tiny arrays on a limited subset of hardware architectures are -likely to be an exceedingly rare case (despite the continued -popularity of x86) I propose to revert the resolution and make the -behavior of all valarray assignment operators -well-defined even for non-conformal arrays (i.e., arrays of unequal -size). I have implemented this change and measured no significant -degradation in performance in the common case (non-empty arrays of -equal size). I have measured a 50% (and in some cases even greater) -speedup in the case of assignments to empty arrays versus calling -resize() first followed by an invocation of the copy -assignment operator. - -

    - -

    [ -Bellevue: -]

    - - -
    -If no proposed wording by June meeting, this issue should be closed NAD. -
    - - - -

    Proposed resolution:

    -

    - -Change 26.5.2.2 [valarray.assign], p1 as follows: - -

    -
    -

    - - -valarray<T>& operator=(const valarray<T>& x); - - -

    -

    - --1- Each element of the *this array is assigned the value -of the corresponding element of the argument array. The -resulting behavior is undefined if When the length of -the argument array is not equal to the length of the *this -array. resizes *this to make the two -arrays the same length, as if by calling -resize(x.size()), before performing the assignment. - -

    -
    -

    - -And add a new paragraph just below paragraph 1 with the following -text: - -

    -
    -

    - --2- Postcondition: size() == x.size(). - -

    -
    -

    - -Also add the following paragraph to 26.5.2.2 [valarray.assign], immediately after p4: - -

    -
    -

    - --?- When the length, N of the array referred -to by the argument is not equal to the length of *this, -the operator resizes *this to make the two arrays the -same length, as if by calling resize(N), before -performing the assignment. - -

    -
    - -

    [ -pre-Sophia Antipolis, Martin adds the following compromise wording, but -prefers the original proposed resolution: -]

    - - -

    -Change 26.5.2.2 [valarray.assign], p1 as follows: -

    - -
    -

    - -1- Requires: size() == 0 || size() == x.size(). -

    -

    - -2- Effects: If size() == 0 calls x.resize(x.size()) first. - Each element of the *this array is assigned the value of the - corresponding element of the argument array. -

    -

    - -3- Postcondition: size() == x.size(). -

    -
    - -

    -Add the following paragraph to 26.5.2.2 [valarray.assign], immediately after -p4: -

    - -
    -

    - -?- When size() == 0 and the length, N of the array referred to by - the argument is not equal to the length of *this, the operator - resizes *this to make the two arrays the same length, as if by - calling resize(N), before performing the assignment. Otherwise, - when size() > 0 and size() != N, the behavior is undefined. -

    -
    - - - -

    [ -Kona (2007): Gaby to propose wording for an alternative resolution in -which you can assign to a valarray of size 0, but not to any other -valarray whose size is unequal to the right hand side of the assignment. -]

    - - - - - -
    -

    631. conflicting requirements for BinaryPredicate

    -

    Section: 25 [algorithms] Status: Open - Submitter: James Kanze Date: 2007-01-31

    -

    View all other issues in [algorithms].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -The general requirements for BinaryPredicate (in 25 [algorithms]/8) contradict the implied specific requirements for -some functions. In particular, it says that: -

    - -

    -[...] if an algorithm takes BinaryPredicate binary_pred -as its argument and first1 and first2 as its -iterator arguments, it should work correctly in the construct if -(binary_pred (*first1 , *first2 )){...}. -BinaryPredicate always takes the first iterator type as its -first argument, that is, in those cases when T value is -part of the signature, it should work correctly in the context of if -(binary_pred (*first1 , value)){...}. -

    - -

    -In the description of upper_bound (25.3.3.2 [upper.bound]/2), however, the use is described as -"!comp(value, e)", where e is an -element of the sequence (a result of dereferencing -*first). -

    - -

    -In the description of lexicographical_compare, we have both -"*first1 < *first2" and "*first2 -< *first1" (which presumably implies "comp( -*first1, *first2 )" and "comp( *first2, -*first1 )". -

    - -

    [ -Toronto: Moved to Open. ConceptGCC seems to get lower_bound -and upper_bound to work withoutt these changes. -]

    - - - - -

    Proposed resolution:

    -

    -Logically, the BinaryPredicate is used as an ordering -relationship, with the semantics of "less than". Depending on the -function, it may be used to determine equality, or any of the inequality -relationships; doing this requires being able to use it with either -parameter first. I would thus suggest that the requirement be: -

    - -

    -[...] BinaryPredicate always takes the first iterator -value_type as one of its arguments, it is unspecified which. If -an algorithm takes BinaryPredicate binary_pred as its -argument and first1 and first2 as its -iterator arguments, it should work correctly both in the construct -if (binary_pred (*first1 , *first2 )){...} and -if (binary_pred (*first2, *first1)){...}. In -those cases when T value is part of the signature, it -should work correctly in the context of if (binary_pred -(*first1 , value)){...} and of if (binary_pred -(value, *first1)){...}. [Note: if the two -types are not identical, and neither is convertable to the other, this -may require that the BinaryPredicate be a functional object -with two overloaded operator()() functions. --end note] -

    - -

    -Alternatively, one could specify an order for each function. IMHO, this -would be more work for the committee, more work for the implementors, -and of no real advantage for the user: some functions, such as -lexicographical_compare or equal_range, will still require both -functions, and it seems like a much easier rule to teach that both -functions are always required, rather than to have a complicated list of -when you only need one, and which one. -

    - - - - - -
    -

    632. Time complexity of size() for std::set

    -

    Section: 23.1 [container.requirements] Status: Open - Submitter: Lionel B Date: 2007-02-01

    -

    View other active issues in [container.requirements].

    -

    View all other issues in [container.requirements].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -A recent news group discussion: -

    -
    -

    -Anyone know if the Standard has anything to say about the time complexity -of size() for std::set? I need to access a set's size (/not/ to know if it is empty!) heavily -during an algorithm and was thus wondering whether I'd be better off -tracking the size "manually" or whether that'd be pointless. -

    -

    -That would be pointless. size() is O(1). -

    -

    -Nit: the standard says "should" have constant time. Implementations may take -license to do worse. I know that some do this for std::list<> as a part of -some trade-off with other operation. -

    - -

    -I was aware of that, hence my reluctance to use size() for std::set. -

    -

    -However, this reason would not apply to std::set<> as far as I can see. -

    -

    -Ok, I guess the only option is to try it and see... -

    -
    - -

    -If I have any recommendation to the C++ Standards Committee it is that -implementations must (not "should"!) document clearly[1], where known, the -time complexity of *all* container access operations. -

    -

    -[1] In my case (gcc 4.1.1) I can't swear that the time complexity of size() -for std::set is not documented... but if it is it's certainly well hidden -away. -

    - - - -

    Proposed resolution:

    -

    -

    - - -

    [ -Kona (2007): This issue affects all the containers. We'd love to see a -paper dealing with the broad issue. We think that the complexity of the -size() member of every container -- except possibly list -- should be -O(1). Alan has volunteered to provide wording. -]

    - - -

    [ -Bellevue: -]

    - - -
    -Mandating O(1) size will not fly, too many implementations would be -invalidated. Alan to provide wording that toughens wording, but that -does not absolutely mandate O(1). -
    - - - - -
    -

    635. domain of allocator::address

    -

    Section: 20.1.2 [allocator.requirements] Status: Open - Submitter: Howard Hinnant Date: 2007-02-08

    -

    View other active issues in [allocator.requirements].

    -

    View all other issues in [allocator.requirements].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -The table of allocator requirements in 20.1.2 [allocator.requirements] describes -allocator::address as: -

    -
    a.address(r)
-a.address(s)
-
    -

    -where r and s are described as: -

    -

    -a value of type X::reference obtained by the expression *p. -

    - -

    -and p is -

    - -

    -a value of type X::pointer, obtained by calling a1.allocate, -where a1 == a -

    - -

    -This all implies that to get the address of some value of type T that -value must have been allocated by this allocator or a copy of it. -

    - -

    -However sometimes container code needs to compare the address of an external value of -type T with an internal value. For example list::remove(const T& t) -may want to compare the address of the external value t with that of a value -stored within the list. Similarly vector or deque insert may -want to make similar comparisons (to check for self-referencing calls). -

    - -

    -Mandating that allocator::address can only be called for values which the -allocator allocated seems overly restrictive. -

    - - - -

    Proposed resolution:

    -

    -Change 20.1.2 [allocator.requirements]: -

    - -
    -

    -r : a value of type X::reference obtained by the expression *p. -

    -

    -s : a value of type X::const_reference obtained by the -expression *q or by conversion from a value r. -

    -
    - -

    [ -post Oxford: This would be rendered NAD Editorial by acceptance of -N2257. -]

    - - -

    [ -Kona (2007): This issue is section 8 of N2387. There was some discussion of it but -no resolution to this issue was recorded. Moved to Open. -]

    - - - - - - - -
    -

    644. Possible typos in 'function' description

    -

    Section: X [func.wrap.func.undef] Status: Open - Submitter: Bo Persson Date: 2007-02-25

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -X [func.wrap.func.undef] -

    -

    -The note in paragraph 2 refers to 'undefined void operators', while the -section declares a pair of operators returning bool. -

    - -

    [ -Post-Sophia Antipolis: -]

    - - -
    -Changed from Pending WP to Open. This issue was voted to WP at the same time the operators were -changed from private to deleted. The two issues stepped on each other. What do we want the return -type of these deleted functions to be? -
    - - - -

    Proposed resolution:

    -

    -Change 20.6.15.2 [func.wrap.func] -

    - -
    ...
-private:
-   // X [func.wrap.func.undef], undefined operators:
-   template<class Function2> bool void operator==(const function<Function2>&);
-   template<class Function2> bool void operator!=(const function<Function2>&);
-};
-
    - -

    -Change X [func.wrap.func.undef] -

    - -
    template<class Function2> bool void operator==(const function<Function2>&);
-template<class Function2> bool void operator!=(const function<Function2>&);
-
    - - - - - -
    -

    659. istreambuf_iterator should have an operator->()

    -

    Section: 24.5.3 [istreambuf.iterator] Status: Open - Submitter: Niels Dekker Date: 2007-03-25

    -

    View all other issues in [istreambuf.iterator].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -Greg Herlihy has clearly demonstrated that a user defined input -iterator should have an operator->(), even if its -value type is a built-in type (comp.std.c++, "Re: Should any iterator -have an operator->() in C++0x?", March 2007). And as Howard -Hinnant remarked in the same thread that the input iterator -istreambuf_iterator doesn't have one, this must be a -defect! -

    -

    -Based on Greg's example, the following code demonstrates the issue: -

     #include <iostream> 
- #include <fstream>
- #include <streambuf> 
-
- typedef char C;
- int main ()
- {
-   std::ifstream s("filename", std::ios::in);
-   std::istreambuf_iterator<char> i(s);
-
-   (*i).~C();  // This is well-formed...
-   i->~C();  // ... so this should be supported!
- }
-
    - -

    -Of course, operator-> is also needed when the value_type of -istreambuf_iterator is a class. -

    -

    -The operator-> could be implemented in various ways. For instance, -by storing the current value inside the iterator, and returning its -address. Or by returning a proxy, like operator_arrow_proxy, from -http://www.boost.org/boost/iterator/iterator_facade.hpp -

    -

    -I hope that the resolution of this issue will contribute to getting a -clear and consistent definition of iterator concepts. -

    - - -

    Proposed resolution:

    -

    -Add to the synopsis in 24.5.3 [istreambuf.iterator]: -

    - -
    charT operator*() const;
-pointer operator->() const;
-istreambuf_iterator<charT,traits>& operator++();
-
    - -

    -Change 24.5.3 [istreambuf.iterator], p1: -

    - -

    -The class template istreambuf_iterator reads successive -characters from the streambuf for which it was constructed. -operator* provides access to the current input character, if -any. operator-> may return a proxy. Each time -operator++ is evaluated, the iterator advances to the next -input character. If the end of stream is reached -(streambuf_type::sgetc() returns traits::eof()), the -iterator becomes equal to the end of stream iterator value. The default -constructor istreambuf_iterator() and the constructor -istreambuf_iterator(0) both construct an end of stream iterator -object suitable for use as an end-of-range. -

    - - - -

    [ -Kona (2007): The proposed resolution is inconsistent because the return -type of istreambuf_iterator::operator->() is specified to be pointer, -but the proposed text also states that "operator-> may return a proxy." -]

    - - -

    [ -Niels Dekker (mailed to Howard Hinnant): -]

    - -
    -

    -The proposed resolution does -not seem inconsistent to me. istreambuf_iterator::operator->() should -have istreambuf_iterator::pointer as return type, and this return type -may in fact be a proxy. -

    -

    -AFAIK, the resolution of 445 ("iterator_traits::reference -unspecified for some iterator categories") implies that for any iterator -class Iter, the return type of operator->() is Iter::pointer, by -definition. I don't think Iter::pointer needs to be a raw pointer. -

    -

    -Still I wouldn't mind if the text "operator-> may return a proxy" would -be removed from the resolution. I think it's up to the library -implementation, how to implement istreambuf_iterator::operator->(). As -longs as it behaves as expected: i->m should have the same effect as -(*i).m. Even for an explicit destructor call, i->~C(). The main issue -is just: istreambuf_iterator should have an operator->()! -

    -
    - - - - -
    -

    667. money_get's widened minus sign

    -

    Section: 22.2.6.1.2 [locale.money.get.virtuals] Status: Open - Submitter: Thomas Plum Date: 2007-04-16

    -

    View other active issues in [locale.money.get.virtuals].

    -

    View all other issues in [locale.money.get.virtuals].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -22.2.6.1.2 [locale.money.get.virtuals], para 1 says: -

    - -

    -The result is returned as an integral value -stored in units or as a sequence of digits possibly preceded by a -minus sign (as produced by ct.widen(c) where c is '-' or in the range -from '0' through '9', inclusive) stored in digits. -

    - -

    -The following -objection has been raised: -

    - -

    -Some implementations interpret this to mean that a facet derived from -ctype<wchar_t> can provide its own member do_widen(char) -which produces e.g. L'@' for the "widened" minus sign, and that the -'@' symbol will appear in the resulting sequence of digits. Other -implementations have assumed that one or more places in the standard permit the -implementation to "hard-wire" L'-' as the "widened" minus sign. Are -both interpretations permissible, or only one? -

    - -

    -[Plum ref _222612Y14] -

    - -

    -Furthermore: if ct.widen('9') produces L'X' (a non-digit), does a -parse fail if a '9' appears in the subject string? [Plum ref _22263Y33] -

    - -

    [ -Kona (2007): Bill and Dietmar to provide proposed wording. -]

    - - -

    [ -post Bellevue: Bill adds: -]

    - - -
    -The Standard is clear that the minus sign stored in digits is ct.widen('-'). -The subject string must contain characters c in the set [-0123456789] -which are translated by ct.widen(c) calls before being stored in digits; -the widened characters are not relevant to the parsing of the subject string. -
    - - -

    Proposed resolution:

    -

    -

    - - - - - -
    -

    668. money_get's empty minus sign

    -

    Section: 22.2.6.1.2 [locale.money.get.virtuals] Status: Open - Submitter: Thomas Plum Date: 2007-04-16

    -

    View other active issues in [locale.money.get.virtuals].

    -

    View all other issues in [locale.money.get.virtuals].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -22.2.6.1.2 [locale.money.get.virtuals], para 3 says: -

    - -

    -If pos or neg is empty, the sign component is -optional, and if no sign is detected, the result is given the sign -that corresponds to the source of the empty string. -

    - -

    -The following -objection has been raised: -

    - -

    -A negative_sign of "" means "there is no -way to write a negative sign" not "any null sequence is a negative -sign, so it's always there when you look for it". -

    - -

    -[Plum ref _222612Y32] -

    - -

    [ -Kona (2007): Bill to provide proposed wording and interpretation of existing wording. -]

    - - - - -

    Proposed resolution:

    -

    -

    - - - - - -
    -

    669. Equivalent postive and negative signs in money_get

    -

    Section: 22.2.6.1.2 [locale.money.get.virtuals] Status: Open - Submitter: Thomas Plum Date: 2007-04-16

    -

    View other active issues in [locale.money.get.virtuals].

    -

    View all other issues in [locale.money.get.virtuals].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -22.2.6.1.2 [locale.money.get.virtuals], para 3 sentence 4 says: -

    - -

    -If the first character of pos is equal to the first character of neg, -or if both strings are empty, the result is given a positive sign. -

    - -

    -One interpretation is that an input sequence must match either the -positive pattern or the negative pattern, and then in either event it -is interpreted as positive. The following objections has been raised: -

    - -

    -The input can successfully match only a positive sign, so the negative -pattern is an unsuccessful match. -

    - -

    -[Plum ref _222612Y34, 222612Y51b] -

    - -

    [ -Bill to provide proposed wording and interpretation of existing wording. -]

    - - - - -

    Proposed resolution:

    -

    -

    - - - - - -
    -

    670. money_base::pattern and space

    -

    Section: 22.2.6.3 [locale.moneypunct] Status: Open - Submitter: Thomas Plum Date: 2007-04-16

    -

    View all issues with Open status.

    -

    Duplicate of: 836

    -

    Discussion:

    - - -

    -22.2.6.3 [locale.moneypunct], para 2 says: -

    - -

    -The value space indicates that at least one space is required at -that position. -

    - -

    -The following objection has been raised: -

    - -

    -Whitespace is optional when matching space. (See 22.2.6.1.2 [locale.money.get.virtuals], para 2.) -

    - -

    -[Plum ref _22263Y22] -

    - -

    [ -Kona (2007): Bill to provide proposed wording. We agree that C++03 is -ambiguous, and that we want C++0X to say "space" means 0 or more -whitespace characters on input. -]

    - - - - -

    Proposed resolution:

    -

    -

    - - - - - -
    -

    671. precision of hexfloat

    -

    Section: 22.2.2.2.2 [facet.num.put.virtuals] Status: Open - Submitter: John Salmon Date: 2007-04-20

    -

    View all other issues in [facet.num.put.virtuals].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -I am trying to understand how TR1 supports hex float (%a) output. -

    -

    -As far as I can tell, it does so via the following: -

    -

    -8.15 Additions to header <locale> [tr.c99.locale] -

    -

    -In subclause 22.2.2.2.2 [facet.num.put.virtuals], Table 58 Floating-point conversions, after -the line: -floatfield == ios_base::scientific %E -

    -

    -add the two lines: -

    -
    floatfield == ios_base::fixed | ios_base::scientific && !uppercase %a
-floatfield == ios_base::fixed | ios_base::scientific %A 2
-
    -

    -[Note: The additional requirements on print and scan functions, later -in this clause, ensure that the print functions generate hexadecimal -floating-point fields with a %a or %A conversion specifier, and that -the scan functions match hexadecimal floating-point fields with a %g -conversion specifier.  end note] -

    -

    -Following the thread, in 22.2.2.2.2 [facet.num.put.virtuals], we find: -

    -

    -For conversion from a floating-point type, if (flags & fixed) != 0 or -if str.precision() > 0, then str.precision() is specified in the -conversion specification. -

    -

    -This would seem to imply that when floatfield == fixed|scientific, the -precision of the conversion specifier is to be taken from -str.precision().  Is this really what's intended?  I sincerely hope -that I'm either missing something or this is an oversight.  Please -tell me that the committee did not intend to mandate that hex floats -(and doubles) should by default be printed as if by %.6a. -

    - -

    [ -Howard: I think the fundamental issue we overlooked was that with %f, -%e, %g, the default precision was always 6.  With %a the default -precision is not 6, it is infinity.  So for the first time, we need to -distinguish between the default value of precision, and the precision -value 6. -]

    - - - - -

    Proposed resolution:

    -

    -

    - - -

    [ -Kona (2007): Robert volunteers to propose wording. -]

    - - - - - -
    -

    675. Move assignment of containers

    -

    Section: 23.1 [container.requirements] Status: Review - Submitter: Howard Hinnant Date: 2007-05-05

    -

    View other active issues in [container.requirements].

    -

    View all other issues in [container.requirements].

    -

    View all issues with Review status.

    -

    Discussion:

    -

    -James Hopkin pointed out to me that if vector<T> move assignment is O(1) -(just a swap) then containers such as vector<shared_ptr<ostream>> might have -the wrong semantics under move assignment when the source is not truly an rvalue, but a -moved-from lvalue (destructors could run late). -

    - -
    vector<shared_ptr<ostream>> v1;
-vector<shared_ptr<ostream>> v2;
-...
-v1 = v2;               // #1
-v1 = std::move(v2);    // #2
-
    - -

    -Move semantics means not caring what happens to the source (v2 in this example). -It doesn't mean not caring what happens to the target (v1). In the above example -both assignments should have the same effect on v1. Any non-shared ostream's -v1 owns before the assignment should be closed, whether v1 is undergoing -copy assignment or move assignment. -

    - -

    -This implies that the semantics of move assignment of a generic container should be -clear, swap instead of just swap. An alternative which could achieve the same -effect would be to move assign each element. In either case, the complexity of move -assignment needs to be relaxed to O(v1.size()). -

    - -

    -The performance hit of this change is not nearly as drastic as it sounds. -In practice, the target of a move assignment has always just been move constructed -or move assigned from. Therefore under clear, swap semantics (in -this common use case) we are still achieving O(1) complexity. -

    - - - -

    Proposed resolution:

    -

    -Change 23.1 [container.requirements]: -

    - -
    - - - - - - - - - - - - -
    Table 89: Container requirements
    expressionreturn typeoperational semanticsassertion/note pre/post-conditioncomplexity
    a = rv;X&All existing elements of a are either move assigned or destructeda shall be equal to the -value that rv had -before this construction -(Note C) linear
    - -

    -Notes: the algorithms swap(), equal() and -lexicographical_compare() are defined in clause 25. Those -entries marked "(Note A)" should have constant complexity. Those entries -marked "(Note B)" have constant complexity unless -allocator_propagate_never<X::allocator_type>::value is -true, in which case they have linear complexity. -Those entries -marked "(Note C)" have constant complexity if a.get_allocator() == -rv.get_allocator() or if either -allocator_propagate_on_move_assignment<X::allocator_type>::value -is true or -allocator_propagate_on_copy_assignment<X::allocator_type>::value -is true and linear complexity otherwise. -

    -
    - - - -

    [ -post Bellevue Howard adds: -]

    - - -
    -

    -This issue was voted to WP in Bellevue, but accidently got stepped on by -N2525 -which was voted to WP simulataneously. Moving back to Open for the purpose of getting -the wording right. The intent of this issue and N2525 are not in conflict. -

    -
    - -

    [ -post Sophia Antipolis Howard updated proposed wording: -]

    - - - - - -
    -

    676. Moving the unordered containers

    -

    Section: 23.4 [unord] Status: Open - Submitter: Howard Hinnant Date: 2007-05-05

    -

    View other active issues in [unord].

    -

    View all other issues in [unord].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -Move semantics are missing from the unordered containers. The proposed -resolution below adds move-support consistent with -N1858 -and the current working draft. -

    - -

    -The current proposed resolution simply lists the requirements for each function. -These might better be hoisted into the requirements table for unordered associative containers. -Futhermore a mild reorganization of the container requirements could well be in order. -This defect report is purposefully ignoring these larger issues and just focusing -on getting the unordered containers "moved". -

    - - - -

    Proposed resolution:

    - -

    -Add to 23.4 [unord]: -

    - -
    template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x, 
-            unordered_map<Key, T, Hash, Pred, Alloc>& y); 
-
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x, 
-            unordered_map<Key, T, Hash, Pred, Alloc>&& y);
-
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_map<Key, T, Hash, Pred, Alloc>&& x, 
-            unordered_map<Key, T, Hash, Pred, Alloc>& y);
-
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x, 
-            unordered_multimap<Key, T, Hash, Pred, Alloc>& y);
-
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x, 
-            unordered_multimap<Key, T, Hash, Pred, Alloc>&& y);
-
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>&& x, 
-            unordered_multimap<Key, T, Hash, Pred, Alloc>& y);
-
-...
-
-template <class Value, class Hash, class Pred, class Alloc> 
-  void swap(unordered_set<Value, Hash, Pred, Alloc>& x, 
-            unordered_set<Value, Hash, Pred, Alloc>& y); 
-
-template <class Value, class Hash, class Pred, class Alloc> 
-  void swap(unordered_set<Value, Hash, Pred, Alloc>& x, 
-            unordered_set<Value, Hash, Pred, Alloc>&& y);
-
-template <class Value, class Hash, class Pred, class Alloc> 
-  void swap(unordered_set<Value, Hash, Pred, Alloc>&& x, 
-            unordered_set<Value, Hash, Pred, Alloc>& y);
-
-template <class Value, class Hash, class Pred, class Alloc> 
-  void swap(unordered_multiset<Value, Hash, Pred, Alloc>& x, 
-            unordered_multiset<Value, Hash, Pred, Alloc>& y);
-
-template <class Value, class Hash, class Pred, class Alloc> 
-  void swap(unordered_multiset<Value, Hash, Pred, Alloc>& x, 
-            unordered_multiset<Value, Hash, Pred, Alloc>&& y);
-
-template <class Value, class Hash, class Pred, class Alloc> 
-  void swap(unordered_multiset<Value, Hash, Pred, Alloc>&& x, 
-            unordered_multiset<Value, Hash, Pred, Alloc>& y);
-
    - -

    unordered_map

    - -

    -Change 23.4.1 [unord.map]: -

    - -
    class unordered_map
-{
-    ...
-    unordered_map(const unordered_map&);
-    unordered_map(unordered_map&&);
-    ~unordered_map();
-    unordered_map& operator=(const unordered_map&);
-    unordered_map& operator=(unordered_map&&);
-    ...
-    // modifiers 
-    std::pair<iterator, bool> insert(const value_type& obj); 
-    template <class P> pair<iterator, bool> insert(P&& obj);
-    iterator       insert(iterator hint, const value_type& obj);
-    template <class P> iterator       insert(iterator hint, P&& obj);
-    const_iterator insert(const_iterator hint, const value_type& obj);
-    template <class P> const_iterator insert(const_iterator hint, P&& obj);
-    ...
-    void swap(unordered_map&&);
-    ...
-    mapped_type& operator[](const key_type& k);
-    mapped_type& operator[](key_type&& k);
-    ...
-};
-
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x, 
-            unordered_map<Key, T, Hash, Pred, Alloc>& y);
-
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x, 
-            unordered_map<Key, T, Hash, Pred, Alloc>&& y);
-
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_map<Key, T, Hash, Pred, Alloc>&& x, 
-            unordered_map<Key, T, Hash, Pred, Alloc>& y);
-
    - -

    -Add to 23.4.1.1 [unord.map.cnstr]: -

    - -
    -
    template <class InputIterator>
-  unordered_map(InputIterator f, InputIterator l, 
-                size_type n = implementation-defined, 
-                const hasher& hf = hasher(), 
-                const key_equal& eql = key_equal(), 
-                const allocator_type& a = allocator_type());
-
    - -

    - -Requires: If the iterator's dereference operator returns an -lvalue or a const rvalue pair<key_type, mapped_type>, -then both key_type and mapped_type shall be -CopyConstructible. - -

    -
    - -

    -Add to 23.4.1.2 [unord.map.elem]: -

    - -
    - -
    mapped_type& operator[](const key_type& k);
    - -
    -

    ...

    -

    -Requires: key_type shall be CopyConstructible -and mapped_type shall be DefaultConstructible. -

    -
    - -
    mapped_type& operator[](key_type&& k);
    - -
    -

    -Effects: If the unordered_map does not already contain an -element whose key is equivalent to k , inserts the value -std::pair<const key_type, mapped_type>(std::move(k), mapped_type()). -

    - -

    -Requires: mapped_type shall be DefaultConstructible. -

    - -

    -Returns: A reference to x.second, where x is the -(unique) element whose key is equivalent to k. -

    - -
    - -
    - -

    -Add new section [unord.map.modifiers]: -

    - -
    -
    pair<iterator, bool> insert(const value_type& x);
-template <class P> pair<iterator, bool> insert(P&& x);
-iterator       insert(iterator hint, const value_type& x);
-template <class P> iterator       insert(iterator hint, P&& x);
-const_iterator insert(const_iterator hint, const value_type& x);
-template <class P> const_iterator insert(const_iterator hint, P&& x);
-template <class InputIterator>
-  void insert(InputIterator first, InputIterator last);
-
    - -
    -

    -Requires: Those signatures taking a const value_type& parameter -requires both the key_type and the mapped_type to be -CopyConstructible. -

    - -

    -P shall be convertible to value_type. - If P is instantiated as a reference -type, then the argument x is copied from. Otherwise x -is considered to be an rvalue as it is converted to value_type -and inserted into the unordered_map. Specifically, in such -cases CopyConstructible is not required of key_type or -mapped_type unless the conversion from P specifically -requires it (e.g. if P is a tuple<const key_type, -mapped_type>, then key_type must be -CopyConstructible). -

    - -

    -The signature taking InputIterator -parameters requires CopyConstructible of both -key_type and mapped_type if the dereferenced -InputIterator returns an lvalue or const rvalue -value_type. -

    - -
    - -
    - -

    -Add to 23.4.1.3 [unord.map.swap]: -

    - -
    -
    template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x, 
-            unordered_map<Key, T, Hash, Pred, Alloc>& y);
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x, 
-            unordered_map<Key, T, Hash, Pred, Alloc>&& y);
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_map<Key, T, Hash, Pred, Alloc>&& x, 
-            unordered_map<Key, T, Hash, Pred, Alloc>& y);
-
    -
    - -

    unordered_multimap

    - -

    -Change 23.4.2 [unord.multimap]: -

    - -
    class unordered_multimap
-{
-    ...
-    unordered_multimap(const unordered_multimap&);
-    unordered_multimap(unordered_multimap&&);
-    ~unordered_multimap();
-    unordered_multimap& operator=(const unordered_multimap&);
-    unordered_multimap& operator=(unordered_multimap&&);
-    ...
-    // modifiers 
-    iterator insert(const value_type& obj); 
-    template <class P> iterator insert(P&& obj);
-    iterator       insert(iterator hint, const value_type& obj);
-    template <class P> iterator       insert(iterator hint, P&& obj);
-    const_iterator insert(const_iterator hint, const value_type& obj);
-    template <class P> const_iterator insert(const_iterator hint, P&& obj);
-    ...
-    void swap(unordered_multimap&&);
-    ...
-};
-
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x, 
-            unordered_multimap<Key, T, Hash, Pred, Alloc>& y);
-
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x, 
-            unordered_multimap<Key, T, Hash, Pred, Alloc>&& y);
-
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>&& x, 
-            unordered_multimap<Key, T, Hash, Pred, Alloc>& y);
-
    - -

    -Add to 23.4.2.1 [unord.multimap.cnstr]: -

    - -
    -
    template <class InputIterator>
-  unordered_multimap(InputIterator f, InputIterator l, 
-                size_type n = implementation-defined, 
-                const hasher& hf = hasher(), 
-                const key_equal& eql = key_equal(), 
-                const allocator_type& a = allocator_type());
-
    - -

    - -Requires: If the iterator's dereference operator returns an -lvalue or a const rvalue pair<key_type, mapped_type>, -then both key_type and mapped_type shall be -CopyConstructible. - -

    -
    - -

    -Add new section [unord.multimap.modifiers]: -

    - -
    -
    iterator insert(const value_type& x);
-template <class P> iterator       insert(P&& x);
-iterator       insert(iterator hint, const value_type& x);
-template <class P> iterator       insert(iterator hint, P&& x);
-const_iterator insert(const_iterator hint, const value_type& x);
-template <class P> const_iterator insert(const_iterator hint, P&& x);
-template <class InputIterator>
-  void insert(InputIterator first, InputIterator last);
-
    - -
    -

    -Requires: Those signatures taking a const value_type& parameter -requires both the key_type and the mapped_type to be -CopyConstructible. -

    - -

    -P shall be convertible to value_type. - If P is instantiated as a reference -type, then the argument x is copied from. Otherwise x -is considered to be an rvalue as it is converted to value_type -and inserted into the unordered_multimap. Specifically, in such -cases CopyConstructible is not required of key_type or -mapped_type unless the conversion from P specifically -requires it (e.g. if P is a tuple<const key_type, -mapped_type>, then key_type must be -CopyConstructible). -

    - -

    -The signature taking InputIterator -parameters requires CopyConstructible of both -key_type and mapped_type if the dereferenced -InputIterator returns an lvalue or const rvalue -value_type. -

    -
    - -
    - -

    -Add to 23.4.2.2 [unord.multimap.swap]: -

    - -
    -
    template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x, 
-            unordered_multimap<Key, T, Hash, Pred, Alloc>& y);
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x, 
-            unordered_multimap<Key, T, Hash, Pred, Alloc>&& y);
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>&& x, 
-            unordered_multimap<Key, T, Hash, Pred, Alloc>& y);
-
    -
    - -

    unordered_set

    - -

    -Change 23.4.3 [unord.set]: -

    - -
    class unordered_set
-{
-    ...
-    unordered_set(const unordered_set&);
-    unordered_set(unordered_set&&);
-    ~unordered_set();
-    unordered_set& operator=(const unordered_set&);
-    unordered_set& operator=(unordered_set&&);
-    ...
-    // modifiers 
-    std::pair<iterator, bool> insert(const value_type& obj); 
-    pair<iterator, bool> insert(value_type&& obj);
-    iterator       insert(iterator hint, const value_type& obj);
-    iterator       insert(iterator hint, value_type&& obj);
-    const_iterator insert(const_iterator hint, const value_type& obj);
-    const_iterator insert(const_iterator hint, value_type&& obj);
-    ...
-    void swap(unordered_set&&);
-    ...
-};
-
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_set<Key, T, Hash, Pred, Alloc>& x, 
-            unordered_set<Key, T, Hash, Pred, Alloc>& y);
-
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_set<Key, T, Hash, Pred, Alloc>& x, 
-            unordered_set<Key, T, Hash, Pred, Alloc>&& y);
-
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_set<Key, T, Hash, Pred, Alloc>&& x, 
-            unordered_set<Key, T, Hash, Pred, Alloc>& y);
-
    - -

    -Add to 23.4.3.1 [unord.set.cnstr]: -

    - -
    -
    template <class InputIterator>
-  unordered_set(InputIterator f, InputIterator l, 
-                size_type n = implementation-defined, 
-                const hasher& hf = hasher(), 
-                const key_equal& eql = key_equal(), 
-                const allocator_type& a = allocator_type());
-
    - -

    - -Requires: If the iterator's dereference operator returns an -lvalue or a const rvalue value_type, then the -value_type shall be CopyConstructible. - -

    -
    - -

    -Add new section [unord.set.modifiers]: -

    - -
    -
    pair<iterator, bool> insert(const value_type& x);
-pair<iterator, bool> insert(value_type&& x);
-iterator       insert(iterator hint, const value_type& x);
-iterator       insert(iterator hint, value_type&& x);
-const_iterator insert(const_iterator hint, const value_type& x);
-const_iterator insert(const_iterator hint, value_type&& x);
-template <class InputIterator>
-  void insert(InputIterator first, InputIterator last);
-
    - -
    - -

    -Requires: Those signatures taking a const -value_type& parameter requires the value_type to -be CopyConstructible. -

    - -

    -The signature taking InputIterator parameters requires -CopyConstructible of value_type if the dereferenced -InputIterator returns an lvalue or const rvalue -value_type. -

    - -
    - -
    - -

    -Add to 23.4.3.2 [unord.set.swap]: -

    - -
    -
    template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_set<Key, T, Hash, Pred, Alloc>& x, 
-            unordered_set<Key, T, Hash, Pred, Alloc>& y);
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_set<Key, T, Hash, Pred, Alloc>& x, 
-            unordered_set<Key, T, Hash, Pred, Alloc>&& y);
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_set<Key, T, Hash, Pred, Alloc>&& x, 
-            unordered_set<Key, T, Hash, Pred, Alloc>& y);
-
    -
    - -

    unordered_multiset

    - -

    -Change 23.4.4 [unord.multiset]: -

    - -
    class unordered_multiset
-{
-    ...
-    unordered_multiset(const unordered_multiset&);
-    unordered_multiset(unordered_multiset&&);
-    ~unordered_multiset();
-    unordered_multiset& operator=(const unordered_multiset&);
-    unordered_multiset& operator=(unordered_multiset&&);
-    ...
-    // modifiers 
-    iterator insert(const value_type& obj); 
-    iterator insert(value_type&& obj);
-    iterator       insert(iterator hint, const value_type& obj);
-    iterator       insert(iterator hint, value_type&& obj);
-    const_iterator insert(const_iterator hint, const value_type& obj);
-    const_iterator insert(const_iterator hint, value_type&& obj);
-    ...
-    void swap(unordered_multiset&&);
-    ...
-};
-
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>& x, 
-            unordered_multiset<Key, T, Hash, Pred, Alloc>& y);
-
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>& x, 
-            unordered_multiset<Key, T, Hash, Pred, Alloc>&& y);
-
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>&& x, 
-            unordered_multiset<Key, T, Hash, Pred, Alloc>& y);
-
    - -

    -Add to 23.4.4.1 [unord.multiset.cnstr]: -

    - -
    -
    template <class InputIterator>
-  unordered_multiset(InputIterator f, InputIterator l, 
-                size_type n = implementation-defined, 
-                const hasher& hf = hasher(), 
-                const key_equal& eql = key_equal(), 
-                const allocator_type& a = allocator_type());
-
    - -

    - -Requires: If the iterator's dereference operator returns an -lvalue or a const rvalue value_type, then the -value_type shall be CopyConstructible. - -

    -
    - -

    -Add new section [unord.multiset.modifiers]: -

    - -
    -
    iterator insert(const value_type& x);
-iterator insert(value_type&& x);
-iterator       insert(iterator hint, const value_type& x);
-iterator       insert(iterator hint, value_type&& x);
-const_iterator insert(const_iterator hint, const value_type& x);
-const_iterator insert(const_iterator hint, value_type&& x);
-template <class InputIterator>
-  void insert(InputIterator first, InputIterator last);
-
    - -
    - -

    -Requires: Those signatures taking a const -value_type& parameter requires the value_type to -be CopyConstructible. -

    - -

    -The signature taking InputIterator parameters requires -CopyConstructible of value_type if the dereferenced -InputIterator returns an lvalue or const rvalue -value_type. -

    - -
    - -
    - -

    -Add to 23.4.4.2 [unord.multiset.swap]: -

    - -
    -
    template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>& x, 
-            unordered_multiset<Key, T, Hash, Pred, Alloc>& y);
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>& x, 
-            unordered_multiset<Key, T, Hash, Pred, Alloc>&& y);
-template <class Key, class T, class Hash, class Pred, class Alloc> 
-  void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>&& x, 
-            unordered_multiset<Key, T, Hash, Pred, Alloc>& y);
-
    -
    - - - -

    [ -Voted to WP in Bellevue. -]

    - - -

    [ -post Bellevue, Pete notes: -]

    - - -
    -

    -Please remind people who are reviewing issues to check that the text -modifications match the current draft. Issue 676, for example, adds two -overloads for unordered_map::insert taking a hint. One takes a -const_iterator and returns a const_iterator, and the other takes an -iterator and returns an iterator. This was correct at the time the issue -was written, but was changed in Toronto so there is only one hint -overload, taking a const_iterator and returning an iterator. -

    -

    -This issue is not ready. In addition to the relatively minor signature -problem I mentioned earlier, it puts requirements in the wrong places. -Instead of duplicating requirements throughout the template -specifications, it should put them in the front matter that talks about -requirements for unordered containers in general. This presentation -problem is editorial, but I'm not willing to do the extensive rewrite -that it requires. Please put it back into Open status. -

    -
    - - - - -
    -

    688. reference_wrapper, cref unsafe, allow binding to rvalues

    -

    Section: 20.6.5.1 [refwrap.const] Status: Open - Submitter: Peter Dimov Date: 2007-05-10

    -

    View all other issues in [refwrap.const].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -A reference_wrapper can be constructed from an rvalue, either by using -the constructor, or via cref (and ref in some corner cases). This leads -to a dangling reference being stored into the reference_wrapper object. -Now that we have a mechanism to detect an rvalue, we can fix them to -disallow this source of undefined behavior. -

    - -

    -Also please see the thread starting at c++std-lib-17398 for some good discussion on this subject. -

    - - - -

    Proposed resolution:

    -

    -In 20.6 [function.objects], add the following two signatures to the synopsis: -

    - -
    template <class T> void ref(const T&& t) = delete;
-template <class T> void cref(const T&& t) = delete;
-
    - - - -

    [ -N2292 -addresses the first part of the resolution but not the second. -]

    - - -

    [ -Bellevue: Doug noticed problems with the current wording. -]

    - - -

    [ -post Bellevue: Howard and Peter provided revised wording. -]

    - - -

    [ -This resolution depends on a "favorable" resolution of CWG 606: that is, -the "special deduction rule" is disabled with the const T&& pattern. -]

    - - - - - -
    -

    691. const_local_iterator cbegin, cend missing from TR1

    -

    Section: 23.4 [unord], TR1 6.3 [tr.hash] Status: Ready - Submitter: Joaquín M López Muñoz Date: 2007-06-14

    -

    View other active issues in [unord].

    -

    View all other issues in [unord].

    -

    View all issues with Ready status.

    -

    Discussion:

    -

    -The last version of TR1 does not include the following member -functions -for unordered containers: -

    - -
    const_local_iterator cbegin(size_type n) const;
-const_local_iterator cend(size_type n) const;
-
    - -

    -which looks like an oversight to me. I've checked th TR1 issues lists -and the latest working draft of the C++0x std (N2284) and haven't -found any mention to these menfuns or to their absence. -

    -

    -Is this really an oversight, or am I missing something? -

    - - - -

    Proposed resolution:

    -

    -Add the following two rows to table 93 (unordered associative container -requirements) in section 23.1.5 [unord.req]: -

    - -
    - - - - - - - - - - - -
    Unordered associative container requirements (in addition to container)
    expression return type assertion/note pre/post-condition complexity
    b.cbegin(n) const_local_iterator n shall be in the range [0, bucket_count()). Note: [b.cbegin(n), b.cend(n)) is a valid range containing all of the elements in the nth bucket. Constant
    b.cend(n) const_local_iterator n shall be in the range [0, bucket_count()). Constant
    -
    - -

    -Add to the synopsis in 23.4.1 [unord.map]: -

    - -
    const_local_iterator cbegin(size_type n) const;
-const_local_iterator cend(size_type n) const;
-
    - -

    -Add to the synopsis in 23.4.2 [unord.multimap]: -

    - -
    const_local_iterator cbegin(size_type n) const;
-const_local_iterator cend(size_type n) const;
-
    - -

    -Add to the synopsis in 23.4.3 [unord.set]: -

    - -
    const_local_iterator cbegin(size_type n) const;
-const_local_iterator cend(size_type n) const;
-
    - -

    -Add to the synopsis in 23.4.4 [unord.multiset]: -

    - -
    const_local_iterator cbegin(size_type n) const;
-const_local_iterator cend(size_type n) const;
-
    - - - - - - -
    -

    692. get_money and put_money should be formatted I/O functions

    -

    Section: 27.6.4 [ext.manip] Status: Review - Submitter: Martin Sebor Date: 2007-06-22

    -

    View other active issues in [ext.manip].

    -

    View all other issues in [ext.manip].

    -

    View all issues with Review status.

    -

    Discussion:

    -

    -In a private email Bill Plauger notes: -

    -

    -I believe that the function that implements get_money -[from N2072] -should behave as a formatted input function, and the function that -implements put_money should behave as a formatted output -function. This has implications regarding the skipping of whitespace -and the handling of errors, among other things. -

    -

    -The words don't say that right now and I'm far from convinced that -such a change is editorial. -

    -

    -Martin's response: -

    -

    -I agree that the manipulators should handle exceptions the same way as -formatted I/O functions do. The text in N2072 assumes so but the -Returns clause explicitly omits exception handling for the sake -of brevity. The spec should be clarified to that effect. -

    -

    -As for dealing with whitespace, I also agree it would make sense for -the extractors and inserters involving the new manipulators to treat -it the same way as formatted I/O. -

    - - -

    Proposed resolution:

    -

    -Add a new paragraph immediately above p4 of 27.6.4 [ext.manip] with the -following text: -

    -

    -Effects: The expression in >> get_money(mon, intl) -described below behaves as a formatted input function (as -described in 27.6.1.2.1 [istream.formatted.reqmts]). -

    -

    -Also change p4 of 27.6.4 [ext.manip] as follows: -

    -

    -Returns: An object s of unspecified type such that -if in is an object of type basic_istream<charT, -traits> then the expression in >> get_money(mon, intl) behaves as a formatted input function -that calls f(in, mon, intl) were -called. The function f can be defined as... -

    - - -

    [ -post Bellevue: -]

    - - -
    -We recommend moving immediately to Review. We've looked at the issue and -have a consensus that the proposed resolution is correct, but want an -iostream expert to sign off. Alisdair has taken the action item to putt -this up on the reflector for possible movement by Howard to Tenatively -Ready. -
    - - - - -
    -

    696. istream::operator>>(int&) broken

    -

    Section: 27.6.1.2.2 [istream.formatted.arithmetic] Status: New - Submitter: Martin Sebor Date: 2007-06-23

    -

    View all other issues in [istream.formatted.arithmetic].

    -

    View all issues with New status.

    -

    Discussion:

    -

    -From message c++std-lib-17897: -

    -

    -The code shown in 27.6.1.2.2 [istream.formatted.arithmetic] as the "as if" -implementation of the two arithmetic extractors that don't have a -corresponding num_get interface (i.e., the -short and int overloads) is subtly buggy in -how it deals with EOF, overflow, and other similar -conditions (in addition to containing a few typos). -

    -

    -One problem is that if num_get::get() reaches the EOF -after reading in an otherwise valid value that exceeds the limits of -the narrower type (but not LONG_MIN or -LONG_MAX), it will set err to -eofbit. Because of the if condition testing for -(err == 0), the extractor won't set -failbit (and presumably, return a bogus value to the -caller). -

    -

    -Another problem with the code is that it never actually sets the -argument to the extracted value. It can't happen after the call to -setstate() since the function may throw, so we need to -show when and how it's done (we can't just punt as say: "it happens -afterwards"). However, it turns out that showing how it's done isn't -quite so easy since the argument is normally left unchanged by the -facet on error except when the error is due to a misplaced thousands -separator, which causes failbit to be set but doesn't -prevent the facet from storing the value. -

    - - -

    Proposed resolution:

    -

    -

    - - - - - -
    -

    698. system_error needs const char* constructors

    -

    Section: 19.4.5.1 [syserr.syserr.overview] Status: Review - Submitter: Daniel Krügler Date: 2007-06-24

    -

    View all issues with Review status.

    -

    Discussion:

    -

    -In 19.4.5.1 [syserr.syserr.overview] we have the class definition of -std::system_error. In contrast to all exception classes, which -are constructible with a what_arg string (see 19.1 [std.exceptions], -or ios_base::failure in 27.4.2.1.1 [ios::failure]), only overloads with with -const string& are possible. For consistency with the re-designed -remaining exception classes this class should also provide -c'tors which accept a const char* what_arg string. -

    -

    -Please note that this proposed addition makes sense even -considering the given implementation hint for what(), because -what_arg is required to be set as what_arg of the base class -runtime_error, which now has the additional c'tor overload -accepting a const char*. -

    - - -

    Proposed resolution:

    -

    -This proposed wording assumes issue 832 has been accepted and applied to the working paper. -

    - -

    -Change 19.4.5.1 [syserr.syserr.overview] Class system_error overview, as indicated: -

    - -
    public:
-  system_error(error_code ec, const string& what_arg);
-  system_error(error_code ec, const char* what_arg);
-  system_error(error_code ec);
-  system_error(int ev, const error_category* ecat,
-      const string& what_arg);
-  system_error(int ev, const error_category* ecat,
-      const char* what_arg);
-  system_error(int ev, const error_category* ecat);
-
    - -

    -To 19.4.5.2 [syserr.syserr.members] Class system_error members add: -

    - -
    -
    system_error(error_code ec, const char* what_arg);
-
    -
    -

    -Effects: Constructs an object of class system_error. -

    -

    -Postconditions: code() == ec and strcmp(runtime_error::what(), what_arg) == 0. -

    -
    - -
    system_error(int ev, const error_category* ecat, const char* what_arg);
-
    - -
    -

    -Effects: Constructs an object of class system_error. -

    -

    -Postconditions: code() == error_code(ev, ecat) and strcmp(runtime_error::what(), what_arg) == 0. -

    -
    -
    - - - - - - -
    -

    701. assoc laguerre poly's

    -

    Section: TR1 5.2.1.1 [tr.num.sf.Lnm] Status: New - Submitter: Christopher Crawford Date: 2007-06-30

    -

    View all issues with New status.

    -

    Discussion:

    -

    -I see that the definition the associated Laguerre -polynomials TR1 5.2.1.1 [tr.num.sf.Lnm] has been corrected since -N1687. -However, the draft standard only specifies ranks of integer value m, -while the associated Laguerre polynomials are actually valid for real -values of m > -1. In the case of non-integer values of m, the -definition Ln(m) = (1/n!)exx-m (d/dx)n (e-xxm+n) -must be used, which also holds for integer values of m. See -Abramowitz & Stegun, 22.11.6 for the general case, and 22.5.16-17 for -the integer case. In fact fractional values are most commonly used in -physics, for example to m = +/- 1/2 to describe the harmonic -oscillator in 1 dimension, and 1/2, 3/2, 5/2, ... in 3 -dimensions. -

    -

    -If I am correct, the calculation of the more general case is no -more difficult, and is in fact the function implemented in the GNU -Scientific Library. I would urge you to consider upgrading the -standard, either adding extra functions for real m or switching the -current ones to double. -

    - - -

    Proposed resolution:

    -

    -

    - - - - - -
    -

    702. Restriction in associated Legendre functions

    -

    Section: TR1 5.2.1.2 [tr.num.sf.Plm] Status: New - Submitter: Christopher Crawford Date: 2007-06-30

    -

    View all issues with New status.

    -

    Discussion:

    -

    -One other small thing, in TR1 5.2.1.2 [tr.num.sf.Plm], the restriction should be -|x| <= 1, not x >= 0.

    - - -

    Proposed resolution:

    -

    -

    - - - - - -
    -

    704. MoveAssignable requirement for container value type overly strict

    -

    Section: 23.1 [container.requirements] Status: Open - Submitter: Howard Hinnant Date: 2007-05-20

    -

    View other active issues in [container.requirements].

    -

    View all other issues in [container.requirements].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -The move-related changes inadvertently overwrote the intent of 276. -Issue 276 removed the requirement of CopyAssignable from -most of the member functions of node-based containers. But the move-related changes -unnecessarily introduced the MoveAssignable requirement for those members which used to -require CopyAssignable. -

    - -

    -We also discussed (c++std-lib-18722) the possibility of dropping MoveAssignable -from some of the sequence requirements. Additionally the in-place construction -work may further reduce requirements. For purposes of an easy reference, here are the -minimum sequence requirements as I currently understand them. Those items in requirements -table in the working draft which do not appear below have been purposefully omitted for -brevity as they do not have any requirements of this nature. Some items which do not -have any requirements of this nature are included below just to confirm that they were -not omitted by mistake. -

    - - - - - - - - -
    Container Requirements
    X u(a)value_type must be CopyConstructible
    X u(rv)array and containers with a propagate_never allocator require value_type to be MoveConstructible
    a = uSequences require value_type to be CopyConstructible and CopyAssignable. - Associative containers require value_type to be CopyConstructible.
    a = rvarray requires value_type to be MoveAssignable. - Sequences and Associative containers with propagate_never and propagate_on_copy_construction allocators require value_type to be MoveConstructible.
    swap(a,u)array and containers with propagate_never and - propagate_on_copy_construction allocators require value_type to be Swappable.
    - -

    -

    - - - - - - - - - - - - - - - - - -
    Sequence Requirements
    X(n)value_type must be DefaultConstructible
    X(n, t)value_type must be CopyConstructible
    X(i, j)If the iterators return an lvalue the value_type must be CopyConstructible. - If the iterators return an rvalue the value_type must be MoveConstructible.
    a.insert(p, t)The value_type must be CopyConstructible. - The sequences vector and deque also require the value_type to be CopyAssignable.
    a.insert(p, rv)The value_type must be MoveConstructible. - The sequences vector and deque also require the value_type to be MoveAssignable.
    a.insert(p, n, t)The value_type must be CopyConstructible. - The sequences vector and deque also require the value_type to be CopyAssignable.
    a.insert(p, i, j)If the iterators return an lvalue the value_type must be CopyConstructible. - The sequences vector and deque also require the value_type to be CopyAssignable when the iterators return an lvalue. - If the iterators return an rvalue the value_type must be MoveConstructible. - The sequences vector and deque also require the value_type to be MoveAssignable when the iterators return an rvalue.
    a.erase(p)The sequences vector and deque require the value_type to be MoveAssignable.
    a.erase(q1, q2)The sequences vector and deque require the value_type to be MoveAssignable.
    a.clear()
    a.assign(i, j)If the iterators return an lvalue the value_type must be CopyConstructible and CopyAssignable. - If the iterators return an rvalue the value_type must be MoveConstructible and MoveAssignable.
    a.assign(n, t)The value_type must be CopyConstructible and CopyAssignable.
    a.resize(n)The value_type must be DefaultConstructible. - The sequence vector also requires the value_type to be MoveConstructible.
    a.resize(n, t)The value_type must be CopyConstructible.
    - -

    -

    - - - - - - - - - - - - - -
    Optional Sequence Requirements
    a.front()
    a.back()
    a.push_front(t)The value_type must be CopyConstructible.
    a.push_front(rv)The value_type must be MoveConstructible.
    a.push_back(t)The value_type must be CopyConstructible.
    a.push_back(rv)The value_type must be MoveConstructible.
    a.pop_front()
    a.pop_back()
    a[n]
    a.at[n]
    - -

    -

    - - - - - - - - - - - -
    Associative Container Requirements
    X(i, j)If the iterators return an lvalue the value_type must be CopyConstructible. - If the iterators return an rvalue the value_type must be MoveConstructible.
    a_uniq.insert(t)The value_type must be CopyConstructible.
    a_uniq.insert(rv)The key_type and the mapped_type (if it exists) must be MoveConstructible.
    a_eq.insert(t)The value_type must be CopyConstructible.
    a_eq.insert(rv)The key_type and the mapped_type (if it exists) must be MoveConstructible.
    a.insert(p, t)The value_type must be CopyConstructible.
    a.insert(p, rv)The key_type and the mapped_type (if it exists) must be MoveConstructible.
    a.insert(i, j)If the iterators return an lvalue the value_type must be CopyConstructible. - If the iterators return an rvalue the key_type and the mapped_type (if it exists) must be MoveConstructible..
    - -

    -

    - - - - - - - - - - - -
    Unordered Associative Container Requirements
    X(i, j, n, hf, eq)If the iterators return an lvalue the value_type must be CopyConstructible. - If the iterators return an rvalue the value_type must be MoveConstructible.
    a_uniq.insert(t)The value_type must be CopyConstructible.
    a_uniq.insert(rv)The key_type and the mapped_type (if it exists) must be MoveConstructible.
    a_eq.insert(t)The value_type must be CopyConstructible.
    a_eq.insert(rv)The key_type and the mapped_type (if it exists) must be MoveConstructible.
    a.insert(p, t)The value_type must be CopyConstructible.
    a.insert(p, rv)The key_type and the mapped_type (if it exists) must be MoveConstructible.
    a.insert(i, j)If the iterators return an lvalue the value_type must be CopyConstructible. - If the iterators return an rvalue the key_type and the mapped_type (if it exists) must be MoveConstructible..
    - -

    -

    - - - - - -
    Miscellaneous Requirements
    map[lvalue-key]The key_type must be CopyConstructible. - The mapped_type must be DefaultConstructible and MoveConstructible.
    map[rvalue-key]The key_type must be MoveConstructible. - The mapped_type must be DefaultConstructible and MoveConstructible.
    - -

    [ -Kona (2007): Howard and Alan to update requirements table in issue with emplace signatures. -]

    - - -

    [ -Bellevue: This should be handled as part of the concepts work. -]

    - - - - -

    Proposed resolution:

    - - - - - - -
    -

    708. Locales need to be per thread and updated for POSIX changes

    -

    Section: 22 [localization] Status: Open - Submitter: Peter Dimov Date: 2007-07-28

    -

    View all other issues in [localization].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -The POSIX "Extended API Set Part 4," -

    -

    -http://www.opengroup.org/sib/details.tpl?id=C065 -

    -

    -introduces extensions to the C locale mechanism that -allow multiple concurrent locales to be used in the same application -by introducing a type locale_t that is very similar to -std::locale, and a number of _l functions that make use of it. -

    -

    -The global locale (set by setlocale) is now specified to be per- -process. If a thread does not call uselocale, the global locale is -in effect for that thread. It can install a per-thread locale by -using uselocale. -

    -

    -There is also a nice querylocale mechanism by which one can obtain -the name (such as "de_DE") for a specific facet, even for combined -locales, with no std::locale equivalent. -

    -

    -std::locale should be harmonized with the new POSIX locale_t -mechanism and provide equivalents for uselocale and querylocale. -

    - -

    [ -Kona (2007): Bill and Nick to provide wording. -]

    - - - - -

    Proposed resolution:

    -

    -

    - - - - - -
    -

    709. char_traits::not_eof has wrong signature

    -

    Section: 21.1.3 [char.traits.specializations] Status: Review - Submitter: Bo Persson Date: 2007-08-13

    -

    View all other issues in [char.traits.specializations].

    -

    View all issues with Review status.

    -

    Discussion:

    -

    -The changes made for constexpr in 21.1.3 [char.traits.specializations] have -not only changed the not_eof function from pass by const reference to -pass by value, it has also changed the parameter type from int_type to -char_type. -

    -

    -This doesn't work for type char, and is inconsistent with the -requirements in Table 56, Traits requirements, 21.1.1 [char.traits.require]. -

    - -

    -Pete adds: -

    - -

    -For what it's worth, that may not have been an intentional change. -N2349, which detailed the changes for adding constant expressions to -the library, has strikeout bars through the const and the & that -surround the char_type argument, but none through char_type itself. -So the intention may have been just to change to pass by value, with -text incorrectly copied from the standard. -

    - - - -

    Proposed resolution:

    -

    -Change the signature in 21.1.3.1 [char.traits.specializations.char], -21.1.3.2 [char.traits.specializations.char16_t], 21.1.3.3 [char.traits.specializations.char32_t], -and 21.1.3.4 [char.traits.specializations.wchar.t] to -

    - -
    static constexpr int_type not_eof(char_type int_type c);
-
    - - - -

    [ -Bellevue: -]

    - - -
    -Resolution: NAD editorial - up to Pete's judgment -
    - -

    [ -Post Sophia Antipolis -]

    - - -
    -Moved from Pending NAD Editorial to Review. The proposed wording appears to be correct but non-editorial. -
    - - - - -
    -

    711. Contradiction in empty shared_ptr

    -

    Section: 20.7.12.2.5 [util.smartptr.shared.obs] Status: Open - Submitter: Peter Dimov Date: 2007-08-24

    -

    View all other issues in [util.smartptr.shared.obs].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -A discussion on -comp.std.c++ -has identified a contradiction in the shared_ptr specification. -The note: -

    - -

    -[ Note: this constructor allows creation of an empty shared_ptr instance with a non-NULL stored pointer. --end note ] -

    - -

    -after the aliasing constructor -

    - -
    template<class Y> shared_ptr(shared_ptr<Y> const& r, T *p);
-
    - -

    -reflects the intent of -N2351 -to, well, allow the creation of an empty shared_ptr -with a non-NULL stored pointer. -

    - -

    -This is contradicted by the second sentence in the Returns clause of 20.7.12.2.5 [util.smartptr.shared.obs]: -

    - -
    -
    T* get() const;
-
    -

    -Returns: the stored pointer. Returns a null pointer if *this is empty. -

    -
    - -

    [ -Bellevue: -]

    - - -
    -

    -Adopt option 1 and move to review, not ready. -

    -

    -There was a lot of confusion about what an empty shared_ptr is (the term -isn't defined anywhere), and whether we have a good mental model for how -one behaves. We think it might be possible to deduce what the definition -should be, but the words just aren't there. We need to open an issue on -the use of this undefined term. (The resolution of that issue might -affect the resolution of issue 711.) -

    -

    -The LWG is getting more uncomfortable with the aliasing proposal (N2351) -now that we realize some of its implications, and we need to keep an eye -on it, but there isn't support for removing this feature at this time. -

    -
    - -

    [ -Sophia Antipolis: -]

    - - -
    -

    -We heard from Peter Dimov, who explained his reason for preferring solution 1. -

    -

    -Because it doesn't seem to add anything. It simply makes the behavior -for p = 0 undefined. For programmers who don't create empty pointers -with p = 0, there is no difference. Those who do insist on creating them -presumably have a good reason, and it costs nothing for us to define the -behavior in this case. -

    -

    -The aliasing constructor is sharp enough as it is, so "protecting" users -doesn't make much sense in this particular case. -

    -

    -> Do you have a use case for r being empty and r being non-null? -

    -

    -I have received a few requests for it from "performance-conscious" -people (you should be familiar with this mindset) who don't like the -overhead of allocating and maintaining a control block when a null -deleter is used to approximate a raw pointer. It is obviously an "at -your own risk", low-level feature; essentially a raw pointer behind a -shared_ptr facade. -

    -

    -We could not agree upon a resolution to the issue; some of us thought -that Peter's description above is supporting an undesirable behavior. -

    -
    - - - -

    Proposed resolution:

    -

    -In keeping the N2351 spirit and obviously my preference, change 20.7.12.2.5 [util.smartptr.shared.obs]: -

    - -
    -
    T* get() const;
-
    -

    -Returns: the stored pointer. Returns a null pointer if *this is empty. -

    -
    - -

    -Alternative proposed resolution: (I won't be happy if we do this, but it's possible): -

    - -

    -Change 20.7.12.2.1 [util.smartptr.shared.const]: -

    - -
    -
    template<class Y> shared_ptr(shared_ptr<Y> const& r, T *p);
-
    -
    -

    -Requires: If r is empty, p shall be 0. -

    -

    -[ Note: this constructor allows creation of an empty shared_ptr -instance with a non-NULL stored pointer. --- end note ] -

    -
    -
    - - - - - - -
    -

    713. sort() complexity is too lax

    -

    Section: 25.3.1.1 [sort] Status: Ready - Submitter: Matt Austern Date: 2007-08-30

    -

    View all issues with Ready status.

    -

    Discussion:

    -

    -The complexity of sort() is specified as "Approximately N -log(N) (where N == last - first ) comparisons on the -average", with no worst case complicity specified. The intention was to -allow a median-of-three quicksort implementation, which is usually O(N -log N) but can be quadratic for pathological inputs. However, there is -no longer any reason to allow implementers the freedom to have a -worst-cast-quadratic sort algorithm. Implementers who want to use -quicksort can use a variant like David Musser's "Introsort" (Software -Practice and Experience 27:983-993, 1997), which is guaranteed to be O(N -log N) in the worst case without incurring additional overhead in the -average case. Most C++ library implementers already do this, and there -is no reason not to guarantee it in the standard. -

    - - -

    Proposed resolution:

    -

    -In 25.3.1.1 [sort], change the complexity to "O(N log N)", and remove footnote 266: -

    - -
    -

    -Complexity: Approximately O(N log(N)) (where N == last - first ) -comparisons on the average.266) -

    -

    -266) -If the worst case behavior is important stable_sort() (25.3.1.2) or partial_sort() -(25.3.1.3) should be used. -

    -
    - - - - - - -
    -

    714. search_n complexity is too lax

    -

    Section: 25.1.12 [alg.search] Status: Ready - Submitter: Matt Austern Date: 2007-08-30

    -

    View all other issues in [alg.search].

    -

    View all issues with Ready status.

    -

    Discussion:

    -

    -The complexity for search_n (25.1.12 [alg.search] par 7) is specified as "At most -(last - first ) * count applications of the corresponding predicate if -count is positive, or 0 otherwise." This is unnecessarily pessimistic. -Regardless of the value of count, there is no reason to examine any -element in the range more than once. -

    - - -

    Proposed resolution:

    -

    -Change the complexity to "At most (last - first) applications of the corresponding predicate". -

    - -
    -
    template<class ForwardIterator, class Size, class T> 
-  ForwardIterator 
-    search_n(ForwardIterator first , ForwardIterator last , Size count , 
-             const T& value ); 
-
-template<class ForwardIterator, class Size, class T, 
-         class BinaryPredicate> 
-  ForwardIterator 
-    search_n(ForwardIterator first , ForwardIterator last , Size count , 
-             const T& value , BinaryPredicate pred );
-
    -
    -

    -Complexity: At most (last - first ) * count applications of the corresponding predicate -if count is positive, or 0 otherwise. -

    -
    -
    - - - - - - -
    -

    716. Production in [re.grammar] not actually modified

    -

    Section: 28.13 [re.grammar] Status: New - Submitter: Stephan T. Lavavej Date: 2007-08-31

    -

    View all issues with New status.

    -

    Discussion:

    -

    -TR1 7.13 [tr.re.grammar]/3 and C++0x WP 28.13 [re.grammar]/3 say: -

    - -
    -

    -The following productions within the ECMAScript grammar are modified as follows: -

    - -
    CharacterClass ::
-[ [lookahead ∉ {^}] ClassRanges ]
-[ ^ ClassRanges ]
-
    - -
    - -

    -This definition for CharacterClass appears to be exactly identical to that in ECMA-262. -

    - -

    -Was an actual modification intended here and accidentally omitted, or was this production accidentally included? -

    - - -

    Proposed resolution:

    -

    -Remove this mention of the CharacterClass production. -

    - -
    CharacterClass ::
-[ [lookahead ∉ {^}] ClassRanges ]
-[ ^ ClassRanges ]
-
    - - - - - - -
    -

    718. basic_string is not a sequence

    -

    Section: 21.3 [basic.string] Status: Open - Submitter: Bo Persson Date: 2007-08-18

    -

    View other active issues in [basic.string].

    -

    View all other issues in [basic.string].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -Paragraph 21.3 [basic.string]/3 states: -

    - -
    -

    -The class template basic_string conforms to the requirements for a -Sequence (23.1.1) and for a Reversible Container (23.1). -

    -
    - -

    -First of all, 23.1.3 [sequence.reqmts] is no longer "Sequence" but "Sequence container". -Secondly, after the resent changes to containers (emplace, push_back, -const_iterator parameters to insert and erase), basic_string is not -even close to conform to the current requirements. -

    - -

    [ -Bellevue: -]

    - - -
    -
      -
    • emplace, for example, may not make sense for strings. Is also likely suboptimal
      • -
    • with concepts do we need to maintain string as sequence container?
      • -
    • One approach might be to say something like: string is a sequence except it doesn't have these functions
      • -
    -
      -
    • basic_string already has push_back
      • -
    • const_iterator parameters to insert and erase should be added to basic_string
      • -
    • this leaves emplace to handle -- we have the following options: -
        -
      • option 1: add it to string even though it's optional
        • -
      • option 2: make emplace optional to sequences (move from table 89 to 90)
        • -
      • option 3: say string not sequence (the proposal),
        • -
      • option 4: add an exception to basic string wording.
        • -
      -
      • -
    -General consensus is to suggest option 2. -
    - - - -

    Proposed resolution:

    -

    -Remove this sentence, in recognition of the fact that basic_string is -not just a vector-light for literal types, but something quite -different, a string abstraction in its own right. -

    - - - - - -
    -

    719. std::is_literal type traits should be provided

    -

    Section: 20.5 [meta] Status: Open - Submitter: Daniel Krügler Date: 2007-08-25

    -

    View all other issues in [meta].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -Since the inclusion of constexpr in the standard draft N2369 we have -a new type category "literal", which is defined in 3.9 [basic.types]/p.11: -

    - -
    -

    --11- A type is a literal type if it is: -

    -
      -
    • a scalar type; or
      • -

    • a class type (clause 9) with

      -
        -
      • a trivial copy constructor,
        • -
      • a trivial destructor,
        • -
      • at least one constexpr constructor other than the copy constructor,
        • -
      • no virtual base classes, and
        • -
      • all non-static data members and base classes of literal types; or
        • -
      -
      • -
    • an array of literal type.
      • -
    -
    - -

    -I strongly suggest that the standard provides a type traits for -literal types in 20.5.4.3 [meta.unary.prop] for several reasons: -

    - -
      -
    1. To keep the traits in sync with existing types.
      2. -
    2. I see many reasons for programmers to use this trait in template - code to provide optimized template definitions for these types, - see below.
      3. -
    3. A user-provided definition of this trait is practically impossible -to write portably.
      4. -
    - -

    -The special problem of reason (c) is that I don't see currently a -way to portably test the condition for literal class types: -

    - -
    -
      -
    • at least one constexpr constructor other than the copy constructor,
      • -
    -
    - -

    -Here follows a simply example to demonstrate it's usefulness: -

    - -
    template <typename T>
-constexpr typename std::enable_if<std::is_literal<T>::value, T>::type
-abs(T x) {
-  return x < T() ? -x : x;
-}
-
-template <typename T>
-typename std::enable_if<!std::is_literal<T>::value, T>::type
-abs(const T& x) {
-  return x < T() ? -x : x;
-}
-
    - -

    -Here we have the possibility to provide a general abs function -template that can be used in ICE's if it's argument is a literal -type which's value is a constant expression, otherwise we -have an optimized version for arguments which are expensive -to copy and therefore need the usage of arguments of -reference type (instead of const T& we could decide to -use T&&, but that is another issue). -

    - -

    [ -Alisdair is considering preparing a paper listing a number of missing -type traits, and feels that it might be useful to handle them all -together rather than piecemeal. This would affect issue 719 and 750. -These two issues should move to OPEN pending AM paper on type traits. -]

    - - - - -

    Proposed resolution:

    -

    -In 20.5.2 [meta.type.synop] in the group "type properties", -just below the line -

    - -
    template <class T> struct is_pod;
-
    - -

    -add a new one: -

    - -
    template <class T> struct is_literal;
-
    - -

    -In 20.5.4.3 [meta.unary.prop], table Type Property Predicates, just -below the line for the is_pod property add a new line: -

    - - - - - - - - - - -
    TemplateConditionPreconditions
    template <class T> struct is_literal;T is a literal type (3.9)T shall be a complete type, an -array of unknown bound, or -(possibly cv-qualified) void.
    - - - - - - -
    -

    720. Omissions in constexpr usages

    -

    Section: 23.2.1 [array], 23.3.5 [template.bitset] Status: Ready - Submitter: Daniel Krügler Date: 2007-08-25

    -

    View other active issues in [array].

    -

    View all other issues in [array].

    -

    View all issues with Ready status.

    -

    Discussion:

    -
      -
    1. -The member function bool array<T,N>::empty() const should be a -constexpr because this is easily to proof and to implement following it's operational -semantics defined by Table 87 (Container requirements) which says: a.size() == 0. -
      2. -
    2. -The member function bool bitset<N>::test() const must be a -constexpr (otherwise it would violate the specification of constexpr -bitset<N>::operator[](size_t) const, because it's return clause delegates to test()). -
      3. -
    3. -I wonder how the constructor bitset<N>::bitset(unsigned long) can -be declared as a constexpr. Current implementations usually have no such bitset -c'tor which would fulfill the requirements of a constexpr c'tor because they have a -non-empty c'tor body that typically contains for-loops or memcpy to compute the -initialisation. What have I overlooked here? -
      4. -
    - -

    [ -Sophia Antipolis: -]

    - - -
    -

    -We handle this as two parts -

    -
      -
    1. -The proposed resolution is correct; move to ready. -
      2. -
    2. -The issue points out a real problem, but the issue is larger than just -this solution. We believe a paper is needed, applying the full new -features of C++ (including extensible literals) to update std::bitset. -We note that we do not consider this new work, and that is should be -handled by the Library Working Group. -
      3. -
    -

    -In order to have a consistent working paper, Alisdair and Daniel produced a new wording for the resolution. -

    -
    - - - -

    Proposed resolution:

    -
      -
    1. -

      In the class template definition of 23.2.1 [array]/p. 3 change

      -
      constexpr bool empty() const;
-
      -
      2. - -
    2. -

      In the class template definition of 23.3.5 [template.bitset]/p. 1 change

      -
      constexpr bool test(size_t pos ) const;
-
      - -

      -and in 23.3.5.2 [bitset.members] change -

      - -
      constexpr bool test(size_t pos ) const;
-
      - -
      3. -
    - - - - - -
    -

    721. wstring_convert inconsistensies

    -

    Section: 22.1.3.2.2 [conversions.string] Status: New - Submitter: Bo Persson Date: 2007-08-27

    -

    View all issues with New status.

    -

    Discussion:

    -

    -Paragraph 3 says that the Codecvt template parameter shall meet the -requirements of std::codecvt, even though std::codecvt itself cannot -be used (because of a protected destructor). -

    - -

    -How are we going to explain this code to beginning programmers? -

    - -
    template<class I, class E, class S>
-struct codecvt : std::codecvt<I, E, S>
-{
-    ~codecvt()
-    { }
-};
-
-void main()
-{
-    std::wstring_convert<codecvt<wchar_t, char, std::mbstate_t> > compiles_ok;
-    
-    std::wstring_convert<std::codecvt<wchar_t, char, std::mbstate_t> >   not_ok;
-}
-
    - - - -

    Proposed resolution:

    -

    -

    - - - - - -
    -

    723. basic_regex should be moveable

    -

    Section: 28.8 [re.regex] Status: Open - Submitter: Daniel Krügler Date: 2007-08-29

    -

    View all other issues in [re.regex].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -According to the current state of the standard draft, the class -template basic_regex, as described in 28.8 [re.regex]/3, is -neither MoveConstructible nor MoveAssignable. -IMO it should be, because typical regex state machines tend -to have a rather large data quantum and I have seen several -use cases, where a factory function returns regex values, -which would take advantage of moveabilities. -

    - -

    [ -Sophia Antipolis: -]

    - - -
    -Needs wording for the semantics, the idea is agreed upon. -
    - - -

    Proposed resolution:

    -
      -
    1. -

      -In the header <regex> synopsis 28.4 [re.syn], just below the function -template swap add two further overloads: -

      -
      template <class charT, class traits> 
-  void swap(basic_regex<charT, traits>& e1,  basic_regex<charT, traits>& e2);
-template <class charT, class traits>
-  void swap(basic_regex<charT, traits>&& e1, basic_regex<charT, traits>& e2);
-template <class charT, class traits>
-  void swap(basic_regex<charT, traits>& e1,  basic_regex<charT, traits>&& e2);
-
      -

      -In the class definition of basic_regex, just below 28.8 [re.regex]/3, -perform the following changes: -

      -
      2. - -
    2. -

      Just after the copy c'tor:

      -
      basic_regex(basic_regex&&);
-
      -
      3. - -
    3. -

      Just after the copy-assignment op.:

      -
      basic_regex& operator=(basic_regex&&);
-
      -
      4. - -
    4. -

      Just after the first assign overload insert:

      -
      basic_regex& assign(basic_regex&& that);
-
      -
      5. - -
    5. -

      Change the current swap function to read:

      -
      void swap(basic_regex&&);
-
      -
      6. - -
    6. -

      In 28.8.2 [re.regex.construct], just below the copy c'tor add a -corresponding member definition of:

      -
      basic_regex(basic_regex&&);
-
      -
      7. - -
    7. -

      Also in 28.8.2 [re.regex.construct], just below the copy assignment -c'tor add a corresponding member definition of:

      -
      basic_regex& operator=(basic_regex&&);
-
      -
      8. - -
    8. -

      In 28.8.3 [re.regex.assign], just below the first assign overload add -a corresponding member definition of:

      -
      basic_regex& assign(basic_regex&& that);
-
      -
      9. - -
    9. -

      In 28.8.6 [re.regex.swap], change the signature of swap to -say:

      -
      void swap(basic_regex&& e);
-
      -
      10. - -
    10. -

      In 28.8.7.1 [re.regex.nmswap], just below the single binary swap -function, add the two missing overloads:

      -
      template <class charT, class traits>
-  void swap(basic_regex<charT, traits>&& e1, basic_regex<charT, traits>& e2);
-template <class charT, class traits>
-  void swap(basic_regex<charT, traits>& e1, basic_regex<charT, traits>&& e2);
-
      -
      11. -
    - -

    -Of course there would be need of corresponding proper standardese -to describe these additions. -

    - - - - - - -
    -

    724. DefaultConstructible is not defined

    -

    Section: 20.1.1 [utility.arg.requirements] Status: Open - Submitter: Pablo Halpern Date: 2007-09-12

    -

    View other active issues in [utility.arg.requirements].

    -

    View all other issues in [utility.arg.requirements].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -The DefaultConstructible requirement is referenced in -several places in the August 2007 working draft -N2369, -but is not defined anywhere. -

    - -

    [ -Bellevue: -]

    - - -
    -

    -Walking into the default/value-initialization mess... -

    -

    -Why two lines? Because we need both expressions to be valid. -

    -

    -AJM not sure what the phrase "default constructed" means. This is -unfortunate, as the phrase is already used 24 times in the library! -

    -

    -Example: const int would not accept first line, but will accept the second. -

    -

    -This is an issue that must be solved by concepts, but we might need to solve it independantly first. -

    -

    -It seems that the requirements are the syntax in the proposed first -column is valid, but not clear what semantics we need. -

    -

    -A table where there is no post-condition seems odd, but appears to sum up our position best. -

    -

    -At a minimum an object is declared and is destuctible. -

    -

    -Move to open, as no-one happy to produce wording on the fly. -

    -
    - - -

    Proposed resolution:

    -

    -In section 20.1.1 [utility.arg.requirements], before table 33, add the -following table: -

    - -

    Table 33: DefaultConstructible requirements

    - -
    - - - - - - - - - - -
    -

    expression

    -     		-

    post-condition

    -
    -

    T - t;
    - T()

    -     		-

    T - is default constructed.

    -
    - -
    - - - - - - -
    -

    726. Missing regex_replace() overloads

    -

    Section: 28.11.4 [re.alg.replace] Status: Open - Submitter: Stephan T. Lavavej Date: 2007-09-22

    -

    View other active issues in [re.alg.replace].

    -

    View all other issues in [re.alg.replace].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -Two overloads of regex_replace() are currently provided: -

    - -
    template <class OutputIterator, class BidirectionalIterator, 
-    class traits, class charT> 
-  OutputIterator 
-  regex_replace(OutputIterator out, 
-                BidirectionalIterator first, BidirectionalIterator last, 
-                const basic_regex<charT, traits>& e, 
-                const basic_string<charT>& fmt, 
-                regex_constants::match_flag_type flags = 
-                  regex_constants::match_default);
- 
-template <class traits, class charT> 
-  basic_string<charT> 
-  regex_replace(const basic_string<charT>& s, 
-                const basic_regex<charT, traits>& e, 
-                const basic_string<charT>& fmt, 
-                regex_constants::match_flag_type flags = 
-                  regex_constants::match_default);
-
    - -
      -
    1. Overloads taking const charT * are provided for regex_match() and -regex_search(), but not regex_replace(). This is inconsistent.
      2. -
    2. -

      The absence of const charT * overloads prevents ordinary-looking code from compiling, such as:

      - -
      const string s("kitten");
-const regex r("en");
-cout << regex_replace(s, r, "y") << endl;
-
      - -

      -The compiler error message will be something like "could not deduce -template argument for 'const std::basic_string<_Elem> &' from 'const -char[1]'". -

      - -

      -Users expect that anything taking a basic_string<charT> can also take a -const charT *. In their own code, when they write a function taking -std::string (or std::wstring), they can pass a const char * (or const -wchar_t *), thanks to basic_string's implicit constructor. Because the -regex algorithms are templated on charT, they can't rely on -basic_string's implicit constructor (as the compiler error message -indicates, template argument deduction fails first). -

      - -

      -If a user figures out what the compiler error message means, workarounds -are available - but they are all verbose. Explicit template arguments -could be given to regex_replace(), allowing basic_string's implicit -constructor to be invoked - but charT is the last template argument, not -the first, so this would be extremely verbose. Therefore, constructing -a basic_string from each C string is the simplest workaround. -

      -
      3. - -
    3. -There is an efficiency consideration: constructing basic_strings can -impose performance costs that could be avoided by a library -implementation taking C strings and dealing with them directly. -(Currently, for replacement sources, C strings can be converted into -iterator pairs at the cost of verbosity, but for format strings, there -is no way to avoid constructing a basic_string.) -
      4. -
    - -

    [ -Sophia Antipolis: -]

    - - -
    -We note that Boost already has these overloads. However, the proposed -wording is provided only for 28.11.4 [re.alg.replace]; wording is needed for the synopsis -as well. We also note that this has impact on match_results::format, -which may require further overloads. -
    - - - -

    Proposed resolution:

    -

    -Provide additional overloads for regex_replace(): one additional -overload of the iterator-based form (taking const charT* fmt), and three -additional overloads of the convenience form (one taking const charT* -str, another taking const charT* fmt, and the third taking both const -charT* str and const charT* fmt). 28.11.4 [re.alg.replace]: -

    - -
    -
    template <class OutputIterator, class BidirectionalIterator, 
-    class traits, class charT> 
-  OutputIterator 
-  regex_replace(OutputIterator out, 
-                BidirectionalIterator first, BidirectionalIterator last, 
-                const basic_regex<charT, traits>& e, 
-                const basic_string<charT>& fmt, 
-                regex_constants::match_flag_type flags = 
-                  regex_constants::match_default);
-
-template <class OutputIterator, class BidirectionalIterator, 
-    class traits, class charT> 
-  OutputIterator 
-  regex_replace(OutputIterator out, 
-                BidirectionalIterator first, BidirectionalIterator last, 
-                const basic_regex<charT, traits>& e, 
-                const charT* fmt, 
-                regex_constants::match_flag_type flags = 
-                  regex_constants::match_default);
-
    -

    ...

    -
    template <class traits, class charT> 
-  basic_string<charT> 
-  regex_replace(const basic_string<charT>& s, 
-                const basic_regex<charT, traits>& e, 
-                const basic_string<charT>& fmt, 
-                regex_constants::match_flag_type flags = 
-                  regex_constants::match_default);
-
-template <class traits, class charT> 
-  basic_string<charT> 
-  regex_replace(const basic_string<charT>& s, 
-                const basic_regex<charT, traits>& e, 
-                const charT* fmt, 
-                regex_constants::match_flag_type flags = 
-                  regex_constants::match_default);
-
-template <class traits, class charT> 
-  basic_string<charT> 
-  regex_replace(const charT* s, 
-                const basic_regex<charT, traits>& e, 
-                const basic_string<charT>& fmt, 
-                regex_constants::match_flag_type flags = 
-                  regex_constants::match_default);
-
-template <class traits, class charT> 
-  basic_string<charT> 
-  regex_replace(const charT* s, 
-                const basic_regex<charT, traits>& e, 
-                const charT* fmt, 
-                regex_constants::match_flag_type flags = 
-                  regex_constants::match_default);
-
    -
    - - - - - - -
    -

    727. regex_replace() doesn't accept basic_strings with custom traits and allocators

    -

    Section: 28.11.4 [re.alg.replace] Status: New - Submitter: Stephan T. Lavavej Date: 2007-09-22

    -

    View other active issues in [re.alg.replace].

    -

    View all other issues in [re.alg.replace].

    -

    View all issues with New status.

    -

    Discussion:

    -

    -regex_match() and regex_search() take const basic_string<charT, ST, -SA>&. regex_replace() takes const basic_string<charT>&. This prevents -regex_replace() from accepting basic_strings with custom traits and -allocators. -

    - - -

    Proposed resolution:

    -

    -Overloads of regex_replace() taking basic_string should be additionally -templated on class ST, class SA and take const basic_string<charT, ST, -SA>&. Consistency with regex_match() and regex_search() would place -class ST, class SA as the first template arguments; compatibility with -existing code using TR1 and giving explicit template arguments to -regex_replace() would place class ST, class SA as the last template -arguments. -

    - - - - - -
    -

    728. Problem in [rand.eng.mers]/6

    -

    Section: 26.4.3.2 [rand.eng.mers] Status: Ready - Submitter: Stephan Tolksdorf Date: 2007-09-21

    -

    View all other issues in [rand.eng.mers].

    -

    View all issues with Ready status.

    -

    Discussion:

    -

    -The mersenne_twister_engine is required to use a seeding method that is given -as an algorithm parameterized over the number of bits W. I doubt whether the given generalization -of an algorithm that was originally developed only for unsigned 32-bit integers is appropriate -for other bit widths. For instance, W could be theoretically 16 and UIntType a 16-bit integer, in -which case the given multiplier would not fit into the UIntType. Moreover, T. Nishimura and M. -Matsumoto have chosen a dif ferent multiplier for their 64 bit Mersenne Twister -[reference]. -

    - -

    -I see two possible resolutions: -

    - -
      -
    1. Restrict the parameter W of the mersenne_twister_template to values of 32 or 64 and use the -multiplier from [the above reference] for the 64-bit case (my preference)
      2. -
    2. Interpret the state array for any W as a 32-bit array of appropriate length (and a specified byte -order) and always employ the 32-bit algorithm for seeding -
      3. -
    - -

    -See N2424 -for further discussion. -

    - -

    [ -Bellevue: -]

    - - -
    -

    -Stephan Tolksdorf has additional comments on N2424. He comments: "there -is a typo in the required behaviour for mt19937_64: It should be the -10000th (not 100000th) invocation whose value is given, and the value -should be 9981545732273789042 (not 14002232017267485025)." These values -need checking. -

    -

    -Take the proposed recommendation in N2424 and move to REVIEW. -

    -
    - - - - -

    Proposed resolution:

    - -

    -See N2424 -for the proposed resolution. -

    - -

    [ -Stephan Tolksdorf adds pre-Bellevue: -]

    - - -
    -I support the proposed resolution in -N2424, -but there is a typo in the -required behaviour for mt19937_64: It should be the 10000th (not -100000th) invocation whose value is given, and the value should be -9981545732273789042 (not 14002232017267485025). The change to para. 8 -proposed by Charles Karney should also be included in the proposed -wording. -
    - -

    [ -Sophia Antipolis: -]

    - - -
    -Note the main part of the issue is resolved by -N2424. -
    - - - - - - -
    -

    732. Defect in [rand.dist.samp.genpdf]

    -

    Section: 26.4.8.5.3 [rand.dist.samp.genpdf] Status: Open - Submitter: Stephan Tolksdorf Date: 2007-09-21

    -

    View all other issues in [rand.dist.samp.genpdf].

    -

    View all issues with Open status.

    -

    Duplicate of: 795

    -

    Discussion:

    -

    -26.4.8.5.3 [rand.dist.samp.genpdf] describes the interface for a distribution template that is -meant to simulate random numbers from any general distribution given only the density and the -support of the distribution. I'm not aware of any general purpose algorithm that would be capable -of correctly and efficiently implementing the described functionality. From what I know, this is -essentially an unsolved research problem. Existing algorithms either require more knowledge -about the distribution and the problem domain or work only under very limited circumstances. -Even the state of the art special purpose library UNU.RAN does not solve the problem in full -generality, and in any case, testing and customer support for such a library feature would be a -nightmare. -

    - -

    -Possible resolution: For these reasons, I propose to delete section 26.4.8.5.3 [rand.dist.samp.genpdf]. -

    - -

    [ -Bellevue: -]

    - - -
    -

    -Disagreement persists. -

    -

    -Objection to this issue is that this function takes a general functor. -The general approach would be to normalize this function, integrate it, -and take the inverse of the integral, which is not possible in general. -An example function is sin(1+n*x) -- for any spatial frequency that the -implementor chooses, there is a value of n that renders that choice -arbitrarily erroneous. -

    -

    -Correction: The formula above should instead read 1+sin(n*x). -

    -

    -Objector proposes the following possible compromise positions: -

    -
      -
    • -rand.dist.samp.genpdf takes an number of points so that implementor need not guess. -
      • -
    • replace rand.disk.samp.genpdf with an extension to either or both -of the discrete functions to take arguments that take a functor and -number of points in place of the list of probabilities. Reference -issues 793 and 794. -
      • -
    -
    - - - -

    Proposed resolution:

    -

    -See N2424 -for the proposed resolution. -

    - - - - - -
    -

    734. Unnecessary restriction in [rand.dist.norm.chisq]

    -

    Section: 26.4.8.4.3 [rand.dist.norm.chisq] Status: Review - Submitter: Stephan Tolksdorf Date: 2007-09-21

    -

    View all issues with Review status.

    -

    Discussion:

    -

    -chi_squared_distribution, fisher_f_distribution and student_t_distribution -have parameters for the "degrees of freedom" n and m that are specified as integers. For the -following two reasons this is an unnecessary restriction: First, in many applications such as -Bayesian inference or Monte Carlo simulations it is more convenient to treat the respective param- -eters as continuous variables. Second, the standard non-naive algorithms (i.e. -O(1) algorithms) -for simulating from these distributions work with floating-point parameters anyway (all three -distributions could be easily implemented using the Gamma distribution, for instance). -

    - -

    -Similar arguments could in principle be made for the parameters t and k of the discrete -binomial_distribution and negative_binomial_distribution, though in both cases continuous -parameters are less frequently used in practice and in case of the binomial_distribution -the implementation would be significantly complicated by a non-discrete parameter (in most -implementations one would need an approximation of the log-gamma function instead of just the -log-factorial function). -

    - -

    -Possible resolution: For these reasons, I propose to change the type of the respective parameters -to double. -

    - -

    [ -Bellevue: -]

    - - -
    -In N2424. Not wildly enthusiastic, not really felt necessary. Less -frequently used in practice. Not terribly bad either. Move to OPEN. -
    - -

    [ -Sophia Antipolis: -]

    - - -
    -

    -Marc Paterno: The generalizations were explicitly left out when designing the facility. It's harder to test. -

    -

    -Marc Paterno: Ask implementers whether floating-point is a significant burden. -

    -

    -Alisdair: It's neater to do it now, do ask Bill Plauger. -

    -

    -Disposition: move to review with the option for "NAD" if it's not straightforward to implement; unanimous consent. -

    -
    - - - -

    Proposed resolution:

    -

    -See N2424 -for the proposed resolution. -

    - -

    [ -Stephan Tolksdorf adds pre-Bellevue: -]

    - - -
    -

    -In 26.4.8.4.3 [rand.dist.norm.chisq]: -

    - -
    -

    -Delete ", where n is a positive integer" in the first paragraph. -

    - -

    -Replace both occurrences of "explicit chi_squared_distribution(int n = 1);" -with "explicit chi_squared_distribution(RealType n = 1);". -

    - -

    -Replace both occurrences of "int n() const;" with "RealType n() const;". -

    - -
    - -

    -In 26.4.8.4.5 [rand.dist.norm.f]: -

    -
    -

    -Delete ", where m and n are positive integers" in the first paragraph. -

    - -

    -Replace both occurrences of -

    -
    explicit fisher_f_distribution(int m = 1, int n = 1);
-
    -

    -with -

    -
    explicit fisher_f_distribution(RealType m = 1, RealType n = 1);
-
    - -

    -Replace both occurrences of "int m() const;" with "RealType m() const;". -

    - -

    -Replace both occurrences of "int n() const;" with "RealType n() const;". -

    -
    - -

    -In 26.4.8.4.6 [rand.dist.norm.t]: -

    - -
    -

    -Delete ", where n is a positive integer" in the first paragraph. -

    - -

    -Replace both occurrences of "explicit student_t_distribution(int n = 1);" -with "explicit student_t_distribution(RealType n = 1);". -

    - -

    -Replace both occurrences of "int n() const;" with "RealType n() const;". -

    -
    - -
    - - - - - -
    -

    742. Enabling swap for proxy iterators

    -

    Section: 20.1.1 [utility.arg.requirements] Status: Open - Submitter: Howard Hinnant Date: 2007-10-10

    -

    View other active issues in [utility.arg.requirements].

    -

    View all other issues in [utility.arg.requirements].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -This issue was split from 672. 672 now just -deals with changing the requirements of T in the Swappable -requirement from CopyConstructible and CopyAssignable to -MoveConstructible and MoveAssignable. -

    - -

    -This issue seeks to widen the Swappable requirement to support proxy iterators. Here -is example code: -

    - -
    namespace Mine {
-
-template <class T>
-struct proxy {...};
-
-template <class T>
-struct proxied_iterator
-{
-   typedef T value_type;
-   typedef proxy<T> reference;
-   reference operator*() const;
-   ...
-};
-
-struct A
-{
-   // heavy type, has an optimized swap, maybe isn't even copyable or movable, just swappable
-   void swap(A&);
-   ...
-};
-
-void swap(A&, A&);
-void swap(proxy<A>, A&);
-void swap(A&, proxy<A>);
-void swap(proxy<A>, proxy<A>);
-
-}  // Mine
-
-...
-
-Mine::proxied_iterator<Mine::A> i(...)
-Mine::A a;
-swap(*i1, a);
-
    - -

    -The key point to note in the above code is that in the call to swap, *i1 -and a are different types (currently types can only be Swappable with the -same type). A secondary point is that to support proxies, one must be able to pass rvalues -to swap. But note that I am not stating that the general purpose std::swap -should accept rvalues! Only that overloaded swaps, as in the example above, be allowed -to take rvalues. -

    - -

    -That is, no standard library code needs to change. We simply need to have a more flexible -definition of Swappable. -

    - -

    [ -Bellevue: -]

    - - -
    -

    -While we believe Concepts work will define a swappable concept, we -should still resolve this issue if possible to give guidance to the -Concepts work. -

    -

    -Would an ambiguous swap function in two namespaces found by ADL break -this wording? Suggest that the phrase "valid expression" means such a -pair of types would still not be swappable. -

    -

    -Motivation is proxy-iterators, but facility is considerably more -general. Are we happy going so far? -

    -

    -We think this wording is probably correct and probably an improvement on -what's there in the WP. On the other hand, what's already there in the -WP is awfully complicated. Why do we need the two bullet points? They're -too implementation-centric. They don't add anything to the semantics of -what swap() means, which is there in the post-condition. What's wrong -with saying that types are swappable if you can call swap() and it -satisfies the semantics of swapping? -

    -
    - - - -

    Proposed resolution:

    -

    -Change 20.1.1 [utility.arg.requirements]: -

    - -
    - -

    --1- The template definitions in the C++ Standard Library refer to various -named requirements whose details are set out in tables 31-38. In these -tables, T and V are is a types to be supplied by a C++ program -instantiating a template; a, b, and c are -values of type const T; s and t are modifiable -lvalues of type T; u is a value of type (possibly -const) T; and rv is a non-const -rvalue of type T; w is a value of type T; and v is a value of type V. -

    - - - - - - - -
    Table 37: Swappable requirements [swappable]
    expressionreturn typepost-condition
    swap(sw,tv)voidtw has the value originally -held by uv, and -uv has the value originally held -by tw
    -

    -The Swappable requirement is met by satisfying one or more of the following conditions: -

    -
      -
    • -T is Swappable if T and V are -the same type and T satisfies the -CopyConstructible -MoveConstructible requirements (Table 34 -33) and the CopyAssignable -MoveAssignable requirements (Table 36 -35); -
      • -
    • -T is Swappable with V if a namespace scope function named -swap exists in the same namespace as the definition of -T or V, such that the expression -swap(tw,u v) is valid and has the -semantics described in this table. -
      • -
    -
    -
    - - - - - - -
    -

    747. We have 3 separate type traits to identify classes supporting no-throw operations

    -

    Section: 20.5.4.3 [meta.unary.prop] Status: Open - Submitter: Alisdair Meredith Date: 2007-10-10

    -

    View all other issues in [meta.unary.prop].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -We have 3 separate type traits to identify classes supporting no-throw -operations, which are very useful when trying to provide exception safety -guarantees. However, I'm not entirely clear on what the current wording -requires of a conforming implementation. To quote from -has_nothrow_default_constructor: -

    -

    -or T is a class type with a default constructor that is known not to throw -any exceptions -

    -

    -What level of magic do we expect to deduce if this is known? -

    -

    -E.g. -

    - -
    struct test{
- int x;
- test() : x() {}
-};
-
    -

    -Should I expect a conforming compiler to - assert( has_nothrow_constructor<test>::value ) -

    -

    -Is this a QoI issue? -

    -

    -Should I expect to 'know' only if-and-only-if there is an inline definition -available? -

    -

    -Should I never expect that to be true, and insist that the user supplies an -empty throw spec if they want to assert the no-throw guarantee? -

    -

    -It would be helpful to maybe have a footnote explaining what is required, -but right now I don't know what to suggest putting in the footnote. -

    -

    -(agreement since is that trivial ops and explicit no-throws are required. -Open if QoI should be allowed to detect further) -

    - -

    [ -Bellevue: -]

    - - -
    -This looks like a QoI issue. -In the case of trivial and nothrow it is known. Static analysis of the program is definitely into QoI. -Move to OPEN. Need to talk to Core about this. -
    - - -

    Proposed resolution:

    -

    -

    - - - - - -
    -

    750. The current definition for is_convertible requires that the type be -implicitly convertible, so explicit constructors are ignored.

    -

    Section: 20.5.5 [meta.rel] Status: Open - Submitter: Alisdair Meredith Date: 2007-10-10

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -With the pending arrival of explicit conversion functions though, I'm -wondering if we want an additional trait, is_explictly_convertible? -

    - -

    [ -Bellevue: -]

    - - -
    -Alisdair is considering preparing a paper listing a number of missing -type traits, and feels that it might be useful to handle them all -together rather than piecemeal. This would affect issue 719 and 750. -These two issues should move to OPEN pending AM paper on type traits. -
    - - -

    Proposed resolution:

    -

    -

    - - - - - -
    -

    751. change pass-by-reference members of vector<bool> to pass-by-value?

    -

    Section: 23.2.7 [vector.bool] Status: New - Submitter: Alisdair Meredith Date: 2007-10-10

    -

    View other active issues in [vector.bool].

    -

    View all other issues in [vector.bool].

    -

    View all issues with New status.

    -

    Discussion:

    -

    -A number of vector<bool> members take const bool& as arguments. -Is there any chance we could change them to pass-by-value or would I -be wasting everyone's time if wrote up an issue? -

    - -

    [ -post Bellevue: -]

    - - -
    -

    -As we understand it, the original requester (Martin Sebor) would like -for implementations to be permitted to pass-by-value. Alisdair suggests -that if this is to be resolved, it should be resolved more generally, -e.g. in other containers as well. -

    -

    -We note that this would break ABI. However, we also suspect that this -might be covered under the "as-if" rule in section 1.9. -

    -

    -Many in the group feel that for vector<bool>, this is a "don't care", -and that at this point in the process it's not worth the bandwidth. -

    -

    -Issue 679 -- which was in ready status pre-Bellevue and is -now in the working paper -- is related to this, though not a duplicate. -

    -

    -Moving to Open with a task for Alisdair to craft a informative note to -be put whereever appropriate in the WP. This note would clarify places -where pass-by-const-ref can be transformed to pass-by-value under the -as-if rule. -

    -
    - - - -

    Proposed resolution:

    -

    -

    - - - - - -
    -

    752. Allocator complexity requirement

    -

    Section: 20.1.2 [allocator.requirements] Status: Review - Submitter: Hans Boehm Date: 2007-10-11

    -

    View other active issues in [allocator.requirements].

    -

    View all other issues in [allocator.requirements].

    -

    View all issues with Review status.

    -

    Discussion:

    -

    -Did LWG recently discuss 20.1.2 [allocator.requirements]-2, which states that "All the operations -on the allocators are expected to be amortized constant time."? -

    -

    -As I think I pointed out earlier, this is currently fiction for -allocate() if it has to obtain memory from the OS, and it's unclear to -me how to interpret this for construct() and destroy() if they deal with -large objects. Would it be controversial to officially let these take -time linear in the size of the object, as they already do in real life? -

    -

    -Allocate() more blatantly takes time proportional to the size of the -object if you mix in GC. But it's not really a new problem, and I think -we'd be confusing things by leaving the bogus requirements there. The -current requirement on allocate() is generally not important anyway, -since it takes O(size) to construct objects in the resulting space. -There are real performance issues here, but they're all concerned with -the constants, not the asymptotic complexity. -

    - - -

    Proposed resolution:

    -

    -Change 20.1.2 [allocator.requirements]/2: -

    - -
    -

    --2- Table 39 describes the requirements on types manipulated through -allocators. All the operations on the allocators are expected to be -amortized constant time. Table 40 describes the -requirements on allocator types. -

    -
    - - - - - -
    -

    753. Move constructor in draft

    -

    Section: 20.1.1 [utility.arg.requirements] Status: Open - Submitter: Yechezkel Mett Date: 2007-10-14

    -

    View other active issues in [utility.arg.requirements].

    -

    View all other issues in [utility.arg.requirements].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -The draft standard n2369 uses the term move constructor in a few -places, but doesn't seem to define it. -

    - -

    -MoveConstructible requirements are defined in Table 33 in 20.1.1 [utility.arg.requirements] as -follows: -

    - -
    - - - - - - - - - - - -
    MoveConstructible requirements
    expression post-condition
    T t = rv t is equivalent to the value of rv before the construction
    [Note: There is no requirement on the value of rv after the -construction. -- end note]
    -
    - -

    -(where rv is a non-const rvalue of type T). -

    - -

    -So I assume the move constructor is the constructor that would be used -in filling the above requirement. -

    - -

    -For vector::reserve, vector::resize and the vector modifiers given in -23.2.6.4 [vector.modifiers] we have -

    - -
    -Requires: If value_type has a move constructor, that constructor shall -not throw any exceptions. -
    - -

    -Firstly "If value_type has a move constructor" is superfluous; every -type which can be put into a vector has a move constructor (a copy -constructor is also a move constructor). Secondly it means that for -any value_type which has a throwing copy constructor and no other move -constructor these functions cannot be used -- which I think will come -as a shock to people who have been using such types in vector until -now! -

    - -

    -I can see two ways to correct this. The simpler, which is presumably -what was intended, is to say "If value_type has a move constructor and -no copy constructor, the move constructor shall not throw any -exceptions" or "If value_type has a move constructor which changes the -value of its parameter,". -

    - -

    -The other alternative is add to MoveConstructible the requirement that -the expression does not throw. This would mean that not every type -that satisfies the CopyConstructible requirements also satisfies the -MoveConstructible requirements. It would mean changing requirements in -various places in the draft to allow either MoveConstructible or -CopyConstructible, but I think the result would be clearer and -possibly more concise too. -

    - - -

    Proposed resolution:

    -

    -Add new defintions to 17.1 [definitions]: -

    - -
    -

    -move constructor -

    -

    -a constructor which accepts only rvalue arguments of that type, and modifies the rvalue as a -side effect during the construction. -

    -

    -move assignment operator -

    -

    -an assignment operator which accepts only rvalue arguments of that type, and modifies the rvalue as a -side effect during the assignment. -

    -

    -move assignment -

    -

    -use of the move assignment operator. -

    -
    - -

    [ -Howard adds post-Bellevue: -]

    - - -
    -

    -Unfortunately I believe the wording recommended by the LWG in Bellevue is incorrect. reserve et. al. will use a move constructor -if one is available, else it will use a copy constructor. A type may have both. If the move constructor is -used, it must not throw. If the copy constructor is used, it can throw. The sentence in the proposed wording -is correct without the recommended insertion. The Bellevue LWG recommended moving this issue to Ready. I am -unfortunately pulling it back to Open. But I'm drafting wording to atone for this egregious action. :-) -

    -
    - - - - - - -
    -

    758. shared_ptr and nullptr

    -

    Section: 20.7.12.2 [util.smartptr.shared] Status: Review - Submitter: Joe Gottman Date: 2007-10-31

    -

    View other active issues in [util.smartptr.shared].

    -

    View all other issues in [util.smartptr.shared].

    -

    View all issues with Review status.

    -

    Discussion:

    -

    -Consider the following program: -

    - -
    int main() {
-   shared_ptr<int> p(nullptr); 
-   return 0;
-}
-
    - -

    -This program will fail to compile because shared_ptr uses the following -template constructor to construct itself from pointers: -

    - -
    template <class Y> shared_ptr(Y *);
-
    - -

    -According -to N2431, -the conversion from nullptr_t to Y * is not -deducible, so the above constructor will not be found. There are similar problems with the -constructors that take a pointer and a deleter or a -pointer, a deleter and an allocator, as well as the -corresponding forms of reset(). Note that N2435 -will solve this problem for constructing from just nullptr, but not for constructors that use -deleters or allocators or for reset(). -

    - -

    -In the case of the functions that take deleters, there is the additional -question of what argument should be passed to the deleter when it is -eventually called. There are two reasonable possibilities: nullptr or -static_cast<T *>(0), where T is the template argument of the -shared_ptr. It is not immediately clear which of these is better. If -D::operator() is a template function similar to shared_ptr's -constructor, then d(static_cast<T*>(0)) will compile and d(nullptr) -will not. On the other hand, if D::operator()() takes a parameter that -is a pointer to some type other that T (for instance U* where U derives -from T) then d(nullptr) will compile and d(static_cast<T *>(0)) may not. -

    - -

    [ -Bellevue: -]

    - - -
    -

    -The general idea is right, we need to be able to pass a nullptr to a -shared_ptr, but there are a few borderline editorial issues here. (For -example, the single-argument nullptr_t constructor in the class synopsis -isn't marked explicit, but it is marked explicit in the proposed wording -for 20.6.6.2.1. There is a missing empty parenthesis in the form that -takes a nullptr_t, a deleter, and an allocator.) -

    -

    -More seriously: this issue says that a shared_ptr constructed from a -nullptr is empty. Since "empty" is undefined, it's hard to know whether -that's right. This issue is pending on handling that term better. -

    -

    -Peter suggests definition of empty should be "does not own anything" -

    -

    -Is there an editorial issue that post-conditions should refer to get() = -nullptr, rather than get() = 0? -

    -

    -No strong feeling towards accept or NAD, but prefer to make a decision than leave it open. -

    -

    -Seems there are no technical merits between NAD and Ready, comes down to -"Do we intentially want to allow/disallow null pointers with these -functions". Staw Poll - support null pointers 5 - No null pointers 0 -

    -

    -Move to Ready, modulo editorial comments -

    -
    - -

    [ -post Bellevue Peter adds: -]

    - - -
    -

    -The following wording changes are less intrusive: -

    - -

    -In 20.7.12.2.1 [util.smartptr.shared.const], add: -

    - -
    shared_ptr(nullptr_t);
-
    - -

    -after: -

    - -
    shared_ptr();
-
    - -

    -(Absence of explicit intentional.) -

    - -

    -px.reset( nullptr ) seems a somewhat contrived way to write px.reset(), so -I'm not convinced of its utility. -

    -

    -It's similarly not clear to me whether the deleter constructors need to be -extended to take nullptr, but if they need to: -

    -

    -Add -

    - -
    template<class D> shared_ptr(nullptr_t p, D d);
-template<class D, class A> shared_ptr(nullptr_t p, D d, A a);
-
    - -

    -after -

    - -
    template<class Y, class D> shared_ptr(Y* p, D d);
-template<class Y, class D, class A> shared_ptr(Y* p, D d, A a);
-
    - -

    -Note that this changes the semantics of the new constructors such that they -consistently call d(p) instead of d((T*)0) when p is nullptr. -

    -

    -The ability to be able to pass 0/NULL to a function that takes a shared_ptr -has repeatedly been requested by users, but the other additions that the -proposed resolution makes are not supported by real world demand or -motivating examples. -

    -

    -It might be useful to split the obvious and non-controversial nullptr_t -constructor into a separate issue. Waiting for "empty" to be clarified is -unnecessary; this is effectively an alias for the default constructor. -

    -
    - -

    [ -Sophia Antipolis: -]

    - - -
    -

    -We want to remove the reset functions from the proposed resolution. -

    -

    -The remaining proposed resolution text (addressing the constructors) are wanted. -

    -

    -Disposition: move to review. The review should check the wording in the then-current working draft. -

    -
    - - - -

    Proposed resolution:

    -

    -Add the following constructors to 20.7.12.2 [util.smartptr.shared]: -

    - -
    shared_ptr(nullptr_t);
-template <class D> shared_ptr(nullptr_t, D d);
-template <class D, class A> shared_ptr(nullptr_t, D d, A a);
-
    - - - -

    -Add the following constructor definitions to 20.7.12.2.1 [util.smartptr.shared.const]: -

    - -
    -
     explicit shared_ptr(nullptr_t);
-
    -
    -

    -Effects: Constructs an empty shared_ptr object. -

    -

    -Postconditions: use_count() == 0 && get() == 0. -

    -

    -Throws: nothing. -

    -
    -
    - -
    -
    template <class D> shared_ptr(nullptr_t, D d);
-template <class D, class A> shared_ptr<nullptr_t, D d, A a);
-
    -
    -

    -Requires: D shall be CopyConstructible. The copy constructor and -destructor of D shall not throw exceptions. The expression -d(static_cast<T *>(0)) shall be well-formed, shall have well defined behavior, -and shall not throw exceptions. A shall be an allocator (20.1.2 [allocator.requirements]). -The copy constructor and destructor of A shall not throw -exceptions. -

    -

    -Effects: Constructs a shared_ptr object that owns a null pointer of type T * -and deleter d. The -second constructor shall use a copy of a to allocate memory for -internal use. -

    -

    -Postconditions: use_count() == 1 and get() == 0. -

    -

    -Throws: bad_alloc, or an implementation-defined exception when a -resource other than memory could not be obtained. -

    -

    -Exception safety: If an exception is thrown, d(static_cast<Y *>(nullptr)) is called. -

    -
    -
    - - - - - - - - -
    -

    760. The emplace issue

    -

    Section: 23.1 [container.requirements] Status: Open - Submitter: Paolo Carlini Date: 2007-11-11

    -

    View other active issues in [container.requirements].

    -

    View all other issues in [container.requirements].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -In an emplace member function the function parameter pack may be bound -to a priori unlimited number of objects: some or all of them can be -elements of the container itself. Apparently, in order to conform to the -blanket statement 23.1 [container.requirements]/11, the implementation must check all of them for -that possibility. A possible solution can involve extending the -exception in 23.1 [container.requirements]/12 also to the emplace member. As a side note, the -push_back and push_front member functions are luckily not affected by -this problem, can be efficiently implemented anyway -

    - -

    [ -Related to 767 -]

    - - -

    [ -Bellevue: -]

    - - -
    -

    -The proposed addition (13) is partially redundant with the existing -paragraph 12. Why was the qualifier "rvalues" added to paragraph 12? Why -does it not cover subelements and pointers? -

    -

    -Resolution: Alan Talbot to rework language, then set state to Review. -

    -
    - - - -

    Proposed resolution:

    -

    -Add after 23.1 [container.requirements]/12: -

    - -
    -

    --12- Objects passed to member functions of a container as rvalue references shall not be elements of that container. No -diagnostic required. -

    -

    - --13- Objects bound to the function parameter pack of the emplace member function shall not be elements or -sub-objects of elements of the container. No diagnostic required. - -

    - -
    - - - - - - -
    -

    762. std::unique_ptr requires complete type?

    -

    Section: 20.7.11 [unique.ptr] Status: Ready - Submitter: Daniel Krügler Date: 2007-11-30

    -

    View all other issues in [unique.ptr].

    -

    View all issues with Ready status.

    -

    Discussion:

    -

    -In contrast to the proposed std::shared_ptr, std::unique_ptr -does currently not support incomplete types, because it -gives no explicit grant - thus instantiating unique_ptr with -an incomplete pointee type T automatically belongs to -undefined behaviour according to 17.4.3.7 [res.on.functions]/2, last -bullet. This is an unnecessary restriction and prevents -many well-established patterns - like the bridge pattern - -for std::unique_ptr. -

    - -

    [ -Bellevue: -]

    - - -
    -Move to open. The LWG is comfortable with the intent of allowing -incomplete types and making unique_ptr more like shared_ptr, but we are -not comfortable with the wording. The specification for unique_ptr -should be more like that of shared_ptr. We need to know, for individual -member functions, which ones require their types to be complete. The -shared_ptr specification is careful to say that for each function, and -we need the same level of care here. We also aren't comfortable with the -"part of the operational semantic" language; it's not used elsewhere in -the standard, and it's not clear what it means. We need a volunteer to -produce new wording. -
    - - -

    Proposed resolution:

    -

    -The proposed changes in the following revision refers to the current state of -N2521 including the assumption that 20.7.11.4 [unique.ptr.compiletime] will be removed -according to the current state of 740. -

    -

    -The specialization unique_ptr<T[]> has some more restrictive constraints on -type-completeness on T than unique_ptr<T>. The following proposed wordings -try to cope with that. If the committee sees less usefulness on relaxed -constraints on unique_ptr<T[]>, the alternative would be to stop this relaxation -e.g. by adding one further bullet to 20.7.11.3 [unique.ptr.runtime]/1: -"T shall be a complete type, if used as template argument of -unique_ptr<T[], D> -

    -

    -This issue has some overlap with 673, but it seems not to cause any -problems with this one, -because 673 adds only optional requirements on D that do not conflict -with the here discussed -ones, provided that D::pointer's operations (including default -construction, copy construction/assignment, -and pointer conversion) are specified not to throw, otherwise this -would have impact on the -current specification of unique_ptr. -

    - -
      -
    1. -

      -In 20.7.11 [unique.ptr]/2 add as the last sentence to the existing para: -

      - -
      -The unique_ptr provides a semantics of strict ownership. A -unique_ptr owns the object it holds a pointer to. A -unique_ptr is not CopyConstructible, nor -CopyAssignable, however it is MoveConstructible and -MoveAssignable. The template parameter T of -unique_ptr may be an incomplete type. [ Note: The -uses of unique_ptr include providing exception safety for -dynamically allcoated memory, passing ownership of dynamically allocated -memory to a function, and returning dynamically allocated memory from a -function. -- end note ] -
      -
      2. - -
    2. -

      -20.7.11.2.1 [unique.ptr.single.ctor]/1: No changes necessary. -

      - -
      -

      [ -N.B.: We only need the requirement that D is DefaultConstructible. -The current wording says just this. -]

      - -
      -
      3. - -
    3. -

      -In 20.7.11.2.1 [unique.ptr.single.ctor]/5 change the requires clause to say: -

      - -
      -

      -Requires: The expression D()(p) shall be well formed. The default constructor -of D shall not throw an exception. -D must not be a reference type. - -D shall be default constructible, and that construction -shall not throw an exception. - -

      -

      [ -N.B.: There is no need that the expression D()(p) is well-formed at -this point. I assume that the current wording is based on the -corresponding shared_ptr wording. In case of shared_ptr this -requirement is necessary, because the corresponding c'tor *can* fail -and must invoke delete p/d(p) in this case. Unique_ptr is simpler in -this regard. The *only* functions that must insist on well-formedness -and well-definedness of the expression get_deleter()(get()) are (1) -the destructor and (2) reset. The reasoning for the wording change to -explicitly require DefaultConstructible of D is to guarantee that -invocation of -D's default c'tor is both well-formed and well-defined. Note also that -we do *not* need the -requirement that T must be complete, also in contrast to shared_ptr. -Shared_ptr needs this, because it's c'tor is a template c'tor which -potentially requires Convertible<Y*, X*>, which -again requires Completeness of Y, if !SameType<X, Y> -]

      - -
      -
      4. - -
    4. -

      -Merge 20.7.11.2.1 [unique.ptr.single.ctor]/12+13 thereby removing the sentence -of 12, but transferring the "requires" to 13: -

      - -
      -

      -Requires: If D is not an lvalue-reference type then[..] -

      -

      [ -N.B.: For the same reasons as for (3), there is no need that d(p) is -well-formed/well-defined at this point. The current wording guarantees -all what we need, namely that the initialization of both the T* -pointer and the D deleter are well-formed and well-defined. -]

      - -
      -
      5. - -
    5. -20.7.11.2.1 [unique.ptr.single.ctor]/17: No changes necessary. -
      6. -
    6. -

      20.7.11.2.1 [unique.ptr.single.ctor]/21:

      - -
      -Requires: If D is not a reference type, construction of -the deleter D from an rvalue of type E shall be well -formed and shall not throw an exception. If D is a reference -type, then E shall be the same type as D (diagnostic -required). U* shall be implicitly convertible to T*. -[Note: These requirements imply that T and U -be complete types. -- end note] -
      - -

      [ -N.B.: The current wording of 21 already implicitly guarantees that U -is completely defined, because it requires that Convertible<U*, T*> is -true. If the committee wishes this explicit requirement can be added, -e.g. "U shall be a complete type." -]

      - -
      7. - -
    7. -

      -20.7.11.2.2 [unique.ptr.single.dtor]: Just before p1 add a new paragraph: -

      -
      -

      -Requires: The expression get_deleter()(get()) shall be well-formed, -shall have well-defined behavior, and shall not throw exceptions. -[Note: The use of default_delete requires T to -be a complete type. -- end note] -

      -

      [ -N.B.: This requirement ensures that the whole responsibility on -type-completeness of T is delegated to this expression. -]

      - -
      -
      8. - -
    8. -

      -20.7.11.2.3 [unique.ptr.single.asgn]/1: No changes necessary, except the -current editorial issue, that "must shall" has to be changed to -"shall", but this change is not a special part of this resolution. -

      - -

      [ -N.B. The current wording is sufficient, because we can delegate all -further requirements on the requirements of the effects clause -]

      - -
      9. - -
    9. -

      -20.7.11.2.3 [unique.ptr.single.asgn]/6: -

      - -
      -Requires: Assignment of the deleter D from an rvalue -D shall not throw an exception. U* shall be implicitly -convertible to T*. -[Note: These requirements imply that T and U -be complete types. -- end note] -
      - -

      [ -N.B.: The current wording of p. 6 already implicitly guarantees that -U is completely defined, because it requires that Convertible<U*, T*> -is true, see (6)+(8). -]

      - -
      10. - -
    10. -

      -20.7.11.2.3 [unique.ptr.single.asgn]/11: No changes necessary. -

      -

      [ -N.B.: Delegation to requirements of effects clause is sufficient. -]

      - -
      11. - -
    11. -20.7.11.2.4 [unique.ptr.single.observers]/1+4+7+9+11: -
      12. - -
      -
      T* operator->() const;
      -
      -Note: Use typically requires T shall be complete. -- end note] -
      -
      - -
    12. -20.7.11.2.5 [unique.ptr.single.modifiers]/1: No changes necessary. -
      13. - -
    13. -

      -20.7.11.2.5 [unique.ptr.single.modifiers]/4: Just before p. 4 add a new paragraph: -

      -
      -Requires: The expression get_deleter()(get()) shall be well-formed, -shall have well-defined behavior, and shall not throw exceptions. -
      -
      14. - -
    14. -20.7.11.2.5 [unique.ptr.single.modifiers]/7: No changes necessary. -
      15. - -
    15. -

      -20.7.11.3 [unique.ptr.runtime]: Add one additional bullet on paragraph 1: -

      - -
      -

      -A specialization for array types is provided with a slightly altered interface. -

      - -
        -
      • -... -
        • -
      • -T shall be a complete type. -
        • -
      -
      -
      16. -
    - -

    [ -post Bellevue: Daniel provided revised wording. -]

    - - - - - - - -
    -

    765. more on iterator validity

    -

    Section: 24.1 [iterator.requirements] Status: New - Submitter: Martin Sebor Date: 2007-12-14

    -

    View other active issues in [iterator.requirements].

    -

    View all other issues in [iterator.requirements].

    -

    View all issues with New status.

    -

    Discussion:

    -

    - -Issue 278 -defines the meaning of the term "invalid iterator" as one that may be -singular. - -

    -

    - -Consider the following code: - -

    - 
       std::deque<int> x, y;
-   std::deque<int>::iterator i = x.end(), j = y.end();
-   x.swap(y);
-
    -

    - -Given that swap() is required not to invalidate iterators -and using the definition above, what should be the expected result of -comparing i and j to x.end() -and y.end(), respectively, after the swap()? - -

    -

    - -I.e., is the expression below required to evaluate -to true? - -

    - 
       i == y.end() && j == x.end()
-
    -

    - -(There are at least two implementations where the expression -returns false.) - -

    -

    - -More generally, is the definition introduced in issue 278 meant to -make any guarantees about whether iterators actually point to the same -elements or be associated with the same containers after a -non-invalidating operation as they did before? - -

    -

    - -Here's a motivating example intended to demonstrate the importance of -the question: - -

    - 
       Container x, y ({ 1, 2});   // pseudocode to initialize y with { 1, 2 }
-   Container::iterator i = y.begin() + 1;
-   Container::iterator j = y.end();
-   std::swap(x, y);
-   std::find(i, j, 3);
-
    -

    - -swap() guarantees that i and j -continue to be valid. Unless the spec says that even though they are -valid they may no longer denote a valid range the code above must be -well-defined. Expert opinions on this differ as does the behavior of -popular implementations for some standard Containers. - -

    - - -

    Proposed resolution:

    -

    -

    - - - - - -
    -

    769. std::function should use nullptr_t instead of "unspecified-null-pointer-type"

    -

    Section: 20.6.15.2 [func.wrap.func] Status: Ready - Submitter: Daniel Krügler Date: 2008-01-10

    -

    View all issues with Ready status.

    -

    Discussion:

    -

    -N2461 already replaced in 20.6.15.2 [func.wrap.func] it's originally proposed -(implicit) conversion operator to "unspecified-bool-type" by the new -explicit bool conversion, but the inverse conversion should also -use the new std::nullptr_t type instead of "unspecified-null-pointer- -type". -

    - - -

    Proposed resolution:

    - -

    -In 20.6 [function.objects], header <functional> synopsis replace: -

    - -
    template<class R, class... ArgTypes>
-  bool operator==(const function<R(ArgTypes...)>&, unspecified-null-pointer-type nullptr_t);
-template<class R, class... ArgTypes>
-  bool operator==(unspecified-null-pointer-type nullptr_t , const function<R(ArgTypes...)>&);
-template<class R, class... ArgTypes>
-  bool operator!=(const function<R(ArgTypes...)>&, unspecified-null-pointer-type nullptr_t);
-template<class R, class... ArgTypes>
-  bool operator!=(unspecified-null-pointer-type nullptr_t , const function<R(ArgTypes...)>&);
-
    - -

    -In the class function synopsis of 20.6.15.2 [func.wrap.func] replace -

    - -
    function(unspecified-null-pointer-type nullptr_t);
-...
-function& operator=(unspecified-null-pointer-type nullptr_t);
-
    - -

    -In 20.6.15.2 [func.wrap.func], "Null pointer comparisons" replace: -

    - -
    template <class R, class... ArgTypes>
-  bool operator==(const function<R(ArgTypes...)>&, unspecified-null-pointer-type nullptr_t);
-template <class R, class... ArgTypes>
-  bool operator==(unspecified-null-pointer-type nullptr_t , const function<R(ArgTypes...)>&);
-template <class R, class... ArgTypes>
-  bool operator!=(const function<R(ArgTypes...)>&, unspecified-null-pointer-type nullptr_t);
-template <class R, class... ArgTypes>
-  bool operator!=(unspecified-null-pointer-type nullptr_t , const function<R(ArgTypes...)>&);
-
    - -

    -In 20.6.15.2.1 [func.wrap.func.con], replace -

    - -
    function(unspecified-null-pointer-type nullptr_t);
-...
-function& operator=(unspecified-null-pointer-type nullptr_t);
-
    - -

    -In 20.6.15.2.6 [func.wrap.func.nullptr], replace -

    - -
    template <class R, class... ArgTypes>
-  bool operator==(const function<R(ArgTypes...)>& f, unspecified-null-pointer-type nullptr_t);
-template <class R, class... ArgTypes>
-  bool operator==(unspecified-null-pointer-type nullptr_t , const function<R(ArgTypes...)>& f);
-
    - -

    -and replace -

    - -
    template <class R, class... ArgTypes>
-  bool operator!=(const function<R(ArgTypes...)>& f, unspecified-null-pointer-type nullptr_t);
-template <class R, class... ArgTypes>
-  bool operator!=(unspecified-null-pointer-type nullptr_t , const function<R(ArgTypes...)>& f);
-
    - - - - - - -
    -

    771. Impossible throws clause in [string.conversions]

    -

    Section: 21.4 [string.conversions] Status: Ready - Submitter: Daniel Krügler Date: 2008-01-13

    -

    View other active issues in [string.conversions].

    -

    View all other issues in [string.conversions].

    -

    View all issues with Ready status.

    -

    Discussion:

    -

    -The new to_string and to_wstring functions described in 21.4 [string.conversions] -have throws clauses (paragraphs 8 and 16) which say: -

    - -
    -Throws: nothing -
    - -

    -Since all overloads return either a std::string or a std::wstring by value -this throws clause is impossible to realize in general, since the basic_string -constructors can fail due to out-of-memory conditions. Either these throws -clauses should be removed or should be more detailled like: -

    - -
    -Throws: Nothing if the string construction throws nothing -
    - -

    -Further there is an editorial issue in p. 14: All three to_wstring -overloads return a string, which should be wstring instead (The -header <string> synopsis of 21.2 [string.classes] is correct in this -regard). -

    - - - -

    Proposed resolution:

    -

    -In 21.4 [string.conversions], remove the paragraphs 8 and 16. -

    - -
    -
    string to_string(long long val); 
-string to_string(unsigned long long val); 
-string to_string(long double val); 
-
    -
    -Throws: nothing -
    -
    - -
    -
    wstring to_wstring(long long val); 
-wstring to_wstring(unsigned long long val); 
-wstring to_wstring(long double val); 
-
    -
    -Throws: nothing -
    -
    - - - - - - -
    -

    772. Impossible return clause in [string.conversions]

    -

    Section: 21.4 [string.conversions] Status: Ready - Submitter: Daniel Krügler Date: 2008-01-13

    -

    View other active issues in [string.conversions].

    -

    View all other issues in [string.conversions].

    -

    View all issues with Ready status.

    -

    Discussion:

    -

    -The return clause 21.4 [string.conversions]/paragraph 15 of the new to_wstring -overloads says: -

    - -
    -Returns: each function returns a wstring object holding the character -representation of the value of its argument that would be generated by -calling wsprintf(buf, fmt, val) with a format specifier of L"%lld", L"%ulld", -or L"%f", respectively. -
    - -

    -Problem is: There does not exist any wsprintf function in C99 (I checked -the 2nd edition of ISO 9899, and the first and the second corrigenda from -2001-09-01 and 2004-11-15). What probably meant here is the function -swprintf from <wchar.h>/<cwchar>, but this has the non-equivalent -declaration: -

    - -
    int swprintf(wchar_t * restrict s, size_t n,
-const wchar_t * restrict format, ...);
-
    - -

    -therefore the paragraph needs to mention the size_t parameter n. -

    - - - -

    Proposed resolution:

    -

    -Change the current wording of 21.4 [string.conversions]/p. 15 to: -

    - -
    -Returns: eEach function returns a -wstring object holding the character representation of the -value of its argument that would be generated by calling -wsswprintf(buf, bufsz, fmt, -val) with a format specifier fmt of L"%lld", -L"%ulld", or L"%f", respectively, where buf -designates an internal character buffer of sufficient size bufsz. -
    - -

    -[Hint to the editor: The resolution also adds to mention the name of -the format specifier "fmt"] -

    - -

    -I also would like to remark that the current wording of it's equivalent -paragraph 7 should also mention the meaning of buf and fmt. -

    - -

    -Change the current wording of 21.4 [string.conversions]/p. 7 to: -

    - -
    -Returns: eEach function returns a string object holding the -character representation of the value of its argument that would be -generated by calling sprintf(buf, fmt, val) with a format specifier fmt of -"%lld", "%ulld", or "%f", respectively, where buf designates an internal -character buffer of sufficient size. -
    - - - - - - -
    -

    774. Member swap undefined for most containers

    -

    Section: 23 [containers] Status: Open - Submitter: Alisdair Meredith Date: 2008-01-14

    -

    View other active issues in [containers].

    -

    View all other issues in [containers].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -It appears most containers declare but do not define a member-swap -function. -

    - -

    -This is unfortunate, as all overload the swap algorithm to call the -member-swap function! -(required for swappable guarantees [Table 37] and Container Requirements -[Table 87]) -

    - -

    -Note in particular that Table 87 gives semantics of a.swap(b) as swap(a,b), -yet for all containers we define swap(a,b) to call a.swap(b) - a circular -definition. -

    - -

    -A quick survey of clause 23 shows that the following containers provide a -definition for member-swap: -

    - -
    array
-queue
-stack
-vector
-
    - -

    -Whereas the following declare it, but do not define the semantics: -

    - -
    deque
-list
-map
-multimap
-multiset
-priority_queue
-set
-unordered_map
-unordered_multi_map
-unordered_multi_set
-unordered_set
-
    - -

    -Suggested resolution: -

    -
    -Provide a definition for each of the affected containers... -
    - -

    [ -Bellevue: -]

    - - -
    -Move to Open and ask Alisdair to provide wording. -
    - - -

    Proposed resolution:

    -

    -Wording provided in -N2590. -

    - - - - - -
    -

    776. Undescribed assign function of std::array

    -

    Section: 23.2.1 [array] Status: Ready - Submitter: Daniel Krügler Date: 2008-01-20

    -

    View other active issues in [array].

    -

    View all other issues in [array].

    -

    View all issues with Ready status.

    -

    Discussion:

    -

    -The class template array synopsis in 23.2.1 [array]/3 declares a member -function -

    - -
    void assign(const T& u);
-
    - -

    -which's semantic is no-where described. Since this signature is -not part of the container requirements, such a semantic cannot -be derived by those. -

    - -

    -I found only one reference to this function in the issue list, -588 where the question is raised: -

    - -
    -what's the effect of calling assign(T&) on a zero-sized array? -
    - -

    -which does not answer the basic question of this issue. -

    - -

    -If this function shall be part of the std::array, it's probable -semantic should correspond to that of boost::array, but of -course such wording must be added. -

    - - -

    Proposed resolution:

    -

    -Just after the section 23.2.1.4 [array.data] add the following new section: -

    - -

    -23.2.1.5 array::fill [array.fill] -

    - -
    -
    void fill(const T& u);
-
    - -

    -1: Effects: fill_n(begin(), N, u) -

    -
    - -

    -[N.B: I wonder, why class array does not have a "modifiers" -section. If it had, then assign would naturally belong to it] -

    - -

    -Change the synopsis in 23.2.1 [array]/3: -

    - -
    template <class T, size_t N>
-struct array { 
-  ...
-  void assign fill(const T& u);
-  ...
-
    - - -

    [ -Bellevue: -]

    - - -
    -

    -Suggest substituting "fill" instead of "assign". -

    -

    -Set state to Review given substitution of "fill" for "assign". -

    -
    - - - - -
    -

    779. Resolution of #283 incomplete

    -

    Section: 25.2.8 [alg.remove] Status: Ready - Submitter: Daniel Krügler Date: 2008-01-25

    -

    View all other issues in [alg.remove].

    -

    View all issues with Ready status.

    -

    Discussion:

    -

    -The resolution of 283 did not resolve similar necessary changes for algorithm -remove_copy[_if], -which seems to be an oversight. -

    - - -

    Proposed resolution:

    -

    -In 25.2.8 [alg.remove]/p.6, replace the N2461 requires clause with: -

    - -
    -Requires: Type T is EqualityComparable (31). The ranges [first,last) -and [result,result + (last - first)) shall not overlap. The expression *result = *first shall be -valid. -
    - - - - - - -
    -

    780. std::merge() specification incorrect/insufficient

    -

    Section: 25.3.4 [alg.merge] Status: New - Submitter: Daniel Krügler Date: 2008-01-25

    -

    View all issues with New status.

    -

    Discussion:

    -

    -Though issue 283 has fixed many open issues, it seems that some are still open: -

    - -

    -Both 25.3.4 [lib.alg.merge] in 14882:2003 and 25.3.4 [alg.merge] in N2461 -have no Requires element and the Effects element contains some requirements, -which is probably editorial. Worse is that: -

    - -
      -
    • -no assignment requirements are specified (neither implicit nor explicit). -
      • - -
    • -the effects clause just speaks of "merges", which is badly worded -near to a circular definition. -
      • - -
    • -p. 2 mentions a range [first, last), which is not defined by the -function arguments or otherwise. -
      • - -
    • -p. 2 says "according to the ordering defined by comp" which is both -incomplete (because -this excludes the first variant with <) and redundant (because the -following subordinate -clause mentions comp again) -
      • -
    - - - -

    Proposed resolution:

    -

    -In 25.3.4 [alg.merge] replace p.1+ 2: -

    - -
    -

    -Effects: Merges Copies all the elements of the two sorted ranges [first1,last1) and -[first2,last2) into the range -[result,result + (last1 - first1) + (last2 - first2)) -[result, last) (where last is equal to result + (last1 -- first1) + (last2 - first2)), such that resulting range will be -sorted in non-decreasing order; that is, for every iterator i in -[result,last) other than result, the condition *i < *(i - 1) or, -respectively, comp(*i, *(i - 1)) will be false. -

    - -

    -Requires: The resulting range shall not overlap with either of the original ranges. The list will be sorted in non-decreasing -order according to the ordering defined by comp; that is, for every iterator i in -[first,last) other than first, the condition *i < *(i - 1) or -comp(*i, *(i - 1)) will be false. The results of the expressions *first1 and *first2 -shall be writable to the output iterator. -

    -
    - -

    -[N.B.: I attempted to reuse the wording style of inplace_merge, -therefore proposing to -insert ", respectively," between both predicate tests. This is no -strictly necessary as -other parts of <algorithm> show, just a matter of consistency] -

    - - - - - - -
    -

    785. Random Number Requirements in TR1

    -

    Section: TR1 5.1.4.5 [tr.rand.eng.disc], TR1 5.1.4.6 [tr.rand.eng.xor] Status: New - Submitter: John Maddock Date: 2008-01-15

    -

    View all issues with New status.

    -

    Discussion:

    -

    -Table 16 of TR1 requires that all Pseudo Random Number generators have a -

    - -
    seed(integer-type s)
-
    - -

    -member function that is equivalent to: -

    - -
    mygen = Generator(s)
-
    - -

    -But the generators xor_combine and discard_block have no such seed member, only the -

    - -
    template <class Gen>
-seed(Gen&);
-
    - -

    -member, which will not accept an integer literal as an argument: something that appears to violate the intent of Table 16. -

    - -

    -So... is this a bug in TR1? -

    - -

    This is a real issue BTW, since the Boost implementation does adhere -to the requirements of Table 16, while at least one commercial -implementation does not and follows a strict adherence to sections -5.1.4.5 and 5.1.4.6 instead. -

    - -

    [ -Jens adds: -]

    - - -
    -Both engines do have the necessary -constructor, therefore the omission of the seed() member -functions appears to be an oversight. -
    - - - -

    Proposed resolution:

    -

    -

    - - - - - -
    -

    787. complexity of binary_search

    -

    Section: 25.3.3.4 [binary.search] Status: Ready - Submitter: Daniel Krügler Date: 2007-09-08

    -

    View all issues with Ready status.

    -

    Discussion:

    -

    -In 25.3.3.4 [binary.search]/3 the complexity of binary_search is described as -

    - -
    -At most log(last - first) + 2 comparisons. -
    - -

    -This should be precised and brought in line with the nomenclature used for -lower_bound, upper_bound, and equal_range. -

    - -

    -All existing libraries I'm aware of, delegate to -lower_bound (+ one further comparison). Since -issue 384 -has now WP status, the resolution of #787 should -be brought in-line with 384 by changing the + 2 -to + O(1). -

    - -

    [ -Sophia Antipolis: -]

    - - -
    -Alisdair prefers to apply an upper bound instead of O(1), but that would -require fixing for lower_bound, upper_bound etc. as well. If he really -cares about it, he'll send an issue to Howard. -
    - - - -

    Proposed resolution:

    -

    -Change 25.3.3.4 [binary.search]/3 -

    - -
    -Complexity: At most log2(last - first) + 2 O(1) comparisons. -
    - - - - - -
    -

    788. ambiguity in [istream.iterator]

    -

    Section: 24.5.1 [istream.iterator] Status: New - Submitter: Martin Sebor Date: 2008-02-06

    -

    View other active issues in [istream.iterator].

    -

    View all other issues in [istream.iterator].

    -

    View all issues with New status.

    -

    Discussion:

    -

    -The description of how an istream_iterator object becomes an -end-of-stream iterator is a) ambiguous and b) out of date WRT -issue 468: -

    - -
    -istream_iterator reads (using operator>>) successive elements from the -input stream for which it was constructed. After it is constructed, and -every time ++ is used, the iterator reads and stores a value of T. If -the end of stream is reached (operator void*() on the stream returns -false), the iterator becomes equal to the end-of-stream iterator value. -The constructor with no arguments istream_iterator() always constructs -an end of stream input iterator object, which is the only legitimate -iterator to be used for the end condition. The result of operator* on an -end of stream is not defined. For any other iterator value a const T& is -returned. The result of operator-> on an end of stream is not defined. -For any other iterator value a const T* is returned. It is impossible to -store things into istream iterators. The main peculiarity of the istream -iterators is the fact that ++ operators are not equality preserving, -that is, i == j does not guarantee at all that ++i == ++j. Every time ++ -is used a new value is read. -
    - -

    -istream::operator void*() returns null if istream::fail() is true, -otherwise non-null. istream::fail() returns true if failbit or -badbit is set in rdstate(). Reaching the end of stream doesn't -necessarily imply that failbit or badbit is set (e.g., after -extracting an int from stringstream("123") the stream object will -have reached the end of stream but fail() is false and operator -void*() will return a non-null value). -

    - -

    -Also I would prefer to be explicit about calling fail() here -(there is no operator void*() anymore.) -

    - - -

    Proposed resolution:

    -

    -Change 24.5.1 [istream.iterator]/1: -

    - -
    -istream_iterator reads (using operator>>) successive elements from the -input stream for which it was constructed. After it is constructed, and -every time ++ is used, the iterator reads and stores a value of T. If -the end of stream is reached the iterator fails to read and store a value of T -(operator void*() fail() on the stream returns -false true), the iterator becomes equal to the end-of-stream iterator value. -The constructor with no arguments istream_iterator() always constructs -an end of stream input iterator object, which is the only legitimate -iterator to be used for the end condition. The result of operator* on an -end of stream is not defined. For any other iterator value a const T& is -returned. The result of operator-> on an end of stream is not defined. -For any other iterator value a const T* is returned. It is impossible to -store things into istream iterators. The main peculiarity of the istream -iterators is the fact that ++ operators are not equality preserving, -that is, i == j does not guarantee at all that ++i == ++j. Every time ++ -is used a new value is read. -
    - - - - - -
    -

    793. discrete_distribution missing constructor

    -

    Section: 26.4.8.5.1 [rand.dist.samp.discrete] Status: Open - Submitter: P.J. Plauger Date: 2008-02-09

    -

    View other active issues in [rand.dist.samp.discrete].

    -

    View all other issues in [rand.dist.samp.discrete].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -discrete_distribution should have a constructor like: -

    - -
    template<class _Fn>
-  discrete_distribution(result_type _Count, double _Low, double _High,
-                        _Fn& _Func);
-
    - -

    -(Makes it easier to fill a histogram with function values over a range.) -

    - -

    [ -Bellevue: -]

    - - -
    -How do you specify the function so that it does not return negative -values? If you do it is a bad construction. This requirement is already -there. Where in each bin does one evaluate the function? In the middle. -Need to revisit tomorrow. -
    - -

    [ -Sophia Antipolis: -]

    - - -
    -

    -Bill is not requesting this. -

    -

    -Marc Paterno: _Fn cannot return negative values at the points where the -function is sampled. It is sampled in the middle of each bin. _Fn cannot -return 0 everywhere it is sampled. -

    -

    -Jens: lambda expressions are rvalues -

    -

    -Add a library issue to provide an -initializer_list<double> constructor for -discrete_distribution. -

    -

    -Marc Paterno: dislikes reference for _Fn parameter. Make it pass-by-value (to use lambda), -use std::ref to wrap giant-state function objects. -

    -

    -Daniel: See random_shuffle, pass-by-rvalue-reference. -

    -

    -Daniel to draft wording. -

    -
    - -

    [ -Pre San Francisco, Daniel provided wording: -]

    - - -
    -The here proposed changes of the WP refer to the current state of -N2691. -During the Sophia Antipolis meeting two different proposals came up -regarding the functor argument type, either by value or by rvalue-reference. -For consistence with existing conventions (state-free algorithms and the -general_pdf_distribution c'tor signature) the author decided to propose a -function argument that is provided by value. If severe concerns exists that -stateful functions would be of dominant relevance, it should be possible to -replace the two occurrences of Func by Func&& in this proposal as part -of an editorial process. -
    - - - -

    Proposed resolution:

    -
      -
    1. -

      -In 26.4.8.5.1 [rand.dist.samp.discrete]/1, class discrete_distribution, just -before the member declaration -

      - -
      explicit discrete_distribution(const param_type& parm);
-
      - -

      -insert: -

      - - -
      template<typename Func>
-discrete_distribution(result_type nf, double xmin, double xmax, Func fw);
-
      -
      2. - -
    2. -

      -Between p.4 and p.5 insert a series of new paragraphs as part of the -new member description:: -

      -
      template<typename Func>
-discrete_distribution(result_type nf, double xmin, double xmax, Func fw);
-
      - -

      -Complexity: Exactly nf invocations of fw. -

      -

      -Requires: -

      -
        -
      1. -fw shall be callable with one argument of type double, and shall -return values of a type convertible to double;
        2. - -
      2. If nf > 0, the relation xmin < xmax shall hold, and for all sample values -xk, fw(xk) shall return a weight value wk that is non-negative, non-NaN, -and non-infinity;
        3. - -
      3. The following relations shall hold: nf ≥ 0, and 0 < S = w0+. . .+wn-1.
        4. - -
      - -

      -Effects: -

      -
        -
      1. If nf == 0, sets n = 1 and lets the sequence w have length n = 1 and - consist of the single value w0 = 1.
        2. - -
      2. -

        Otherwise, sets n = nf, deltax = (xmax - xmin)/n and xcent = xmin + -0.5 * deltax.

        -
        For each k = 0, . . . ,n-1, calculates:
-  xk = xcent + k * deltax
-  wk = fw(xk)
-
        -
        3. -
      3. -

        Constructs a discrete_distribution object with probabilities:

        -
        pk = wk/S  for k = 0, . . . , n-1.
-
        -
        4. -
      -
      -
      3. -
    - - - - - -
    -

    794. piecewise_constant_distribution missing constructor

    -

    Section: 26.4.8.5.2 [rand.dist.samp.pconst] Status: Open - Submitter: P.J. Plauger Date: 2008-02-09

    -

    View other active issues in [rand.dist.samp.pconst].

    -

    View all other issues in [rand.dist.samp.pconst].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -piecewise_constant_distribution should have a constructor like: -

    - -
    template<class _Fn>
-   piecewise_constant_distribution(size_t _Count,
-            _Ty _Low, _Ty _High, _Fn& _Func);
-
    - -

    -(Makes it easier to fill a histogram with function values over a range. -The two (reference 793) make a sensible replacement for -general_pdf_distribution.) -

    - -

    [ -Sophia Antipolis: -]

    - - -
    -

    -Marc: uses variable width of bins and weight for each bin. This is not -giving enough flexibility to control both variables. -

    -

    -Add a library issue to provide an constructor taking an -initializer_list<double> and _Fn for piecewise_constant_distribution. -

    -

    -Daniel to draft wording. -

    -
    - -

    [ -Pre San Francisco, Daniel provided wording. -]

    - - -
    -The here proposed changes of the WP refer to the current state of -N2691. -For reasons explained in 793, the author decided to propose a function -argument that is provided by value. The issue proposes a c'tor signature, -that does not take advantage of the full flexibility of -piecewise_constant_distribution, -because it restricts on a constant bin width, but the use-case seems to -be popular enough to justify it's introduction. -
    - - - -

    Proposed resolution:

    - -
      -
    1. -

      -In 26.4.8.5.2 [rand.dist.samp.pconst]/1, class piecewise_constant_distribution, -just before the member declaration -

      - -
      explicit piecewise_constant_distribution(const param_type& parm);
-
      -

      -insert: -

      -
      template<typename Func>
-piecewise_constant_distribution(size_t nf, RealType xmin, RealType xmax, Func fw);
-
      -
      2. - -
    2. -

      -Between p.4 and p.5 insert a new sequence of paragraphs nominated -below as [p5_1], [p5_2], -[p5_3], and [p5_4] as part of the new member description: -

      - -
      template<typename Func>
-piecewise_constant_distribution(size_t nf, RealType xmin, RealType xmax, Func fw);
-
      -
      -

      -[p5_1] Complexity: Exactly nf invocations of fw. -

      -

      -[p5_2] Requires: -

      -
        -
      1. fw shall be callable with one argument of type RealType, and shall -return values of a type convertible to double; -
        2. -
      2. -For all sample values xk defined below, fw(xk) shall return a weight -value wk that is non-negative, non-NaN, and non-infinity; -
        3. -
      3. -The following relations shall hold: xmin < xmax, and -0 < S = w0+. . .+wn-1. -
        4. -
      -

      -[p5_3] Effects: -

      -
        -
      1. -

        If nf == 0,

        -
          -
        1. -sets deltax = xmax - xmin, and
          2. -
        2. lets the sequence w have length n = 1 and consist of the single - value w0 = 1, and
          3. -
        3. lets the sequence b have length n+1 with b0 = xmin and - b1 = xmax -
          4. -
        -
        2. -
      2. -

        Otherwise,

        -
          -
        1. sets n = nf, deltax = (xmax - xmin)/n, - xcent = xmin + 0.5 * deltax, and -
          2. -

        2. lets the sequences w and b have length n and n+1, resp. and

          -
          for each k = 0, . . . ,n-1, calculates:
-  dxk = k * deltax
-  bk = xmin + dxk
-  xk = xcent + dxk
-  wk = fw(xk),
-
          -

          and

          -
          3. -
        3. sets bn = xmax
          4. -
        -
        3. -
      3. -

        -Constructs a piecewise_constant_distribution object with -the above computed sequence b as the interval boundaries -and with the probability densities: -

        -
        ρk = wk/(S * deltax)  for k = 0, . . . , n-1.
-
        -
        4. -
      -

      -[p5_4] Remarks: In this context, the subintervals [bk, bk+1) are commonly - known as the bins of a histogram. -

      -
      -
      -
      3. -
    - - - - - - -
    -

    800. Issues in 26.4.7.1 [rand.util.seedseq](6)

    -

    Section: 26.4.7.1 [rand.util.seedseq] Status: Open - Submitter: Stephan Tolksdorf Date: 2008-02-18

    -

    View other active issues in [rand.util.seedseq].

    -

    View all other issues in [rand.util.seedseq].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -The for-loop in the algorithm specification has n iterations, where n is -defined to be end - begin, i.e. the number of supplied w-bit quantities. -Previous versions of this algorithm and the general logic behind it -suggest that this is an oversight and that in the context of the -for-loop n should be the number of full 32-bit quantities in b (rounded -upwards). If w is 64, the current algorithm throws away half of all bits -in b. If w is 16, the current algorithm sets half of all elements in v -to 0. -

    - -

    -There are two more minor issues: -

    - -
      -
    • -Strictly speaking end - begin is not defined since -InputIterator is not required to be a random access iterator. -
      • -
    • -Currently all integral types are allowed as input to the seed_seq -constructor, including bool. IMHO allowing bools unnecessarily -complicates the implementation without any real benefit to the user. -I'd suggest to exclude bools as input. -
      • -
    - -

    [ -Bellevue: -]

    - - -
    -Move to OPEN Bill will try to propose a resolution by the next meeting. -
    - -

    [ -post Bellevue: Bill provided wording. -]

    - - -

    -This issue is made moot if 803 is accepted. -

    - - - -

    Proposed resolution:

    -

    -Replace 26.4.7.1 [rand.util.seedseq] paragraph 6 with: -

    - -
    -

    -Effects: Constructs a seed_seq object by effectively concatenating the -low-order u bits of each of the elements of the supplied sequence [begin, -end) -in ascending order of significance to make a (possibly very large) unsigned -binary number b having a total of n bits, and then carrying out the -following -algorithm: -

    - -
    for( v.clear(); n > 0; n -= 32 )
-   v.push_back(b mod 232), b /= 232;
-
    -
    - - - - - -
    -

    801. tuple and pair trivial members

    -

    Section: 20.4 [tuple] Status: Open - Submitter: Lawrence Crowl Date: 2008-02-18

    -

    View other active issues in [tuple].

    -

    View all other issues in [tuple].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -Classes with trivial special member functions are inherently more -efficient than classes without such functions. This efficiency is -particularly pronounced on modern ABIs that can pass small classes -in registers. Examples include value classes such as complex numbers -and floating-point intervals. Perhaps more important, though, are -classes that are simple collections, like pair and tuple. When the -parameter types of these classes are trivial, the pairs and tuples -themselves can be trivial, leading to substantial performance wins. -

    -

    -The current working draft make specification of trivial functions -(where possible) much easer through defaulted and deleted functions. -As long as the semantics of defaulted and deleted functions match -the intended semantics, specification of defaulted and deleted -functions will yield more efficient programs. -

    -

    -There are at least two cases where specification of an explicitly -defaulted function may be desirable. -

    -

    -First, the std::pair template has a non-trivial default constructor, -which prevents static initialization of the pair even when the -types are statically initializable. Changing the definition to -

    - -
    pair() = default;
-
    - -

    -would enable such initialization. Unfortunately, the change is -not semantically neutral in that the current definition effectively -forces value initialization whereas the change would not value -initialize in some contexts. -

    - -

    -** Does the committee confirm that forced value initialization -was the intent? If not, does the committee wish to change the -behavior of std::pair in C++0x? -

    -

    -Second, the same default constructor issue applies to std::tuple. -Furthermore, the tuple copy constructor is current non-trivial, -which effectively prevents passing it in registers. To enable -passing tuples in registers, the copy constructor should be -make explicitly defaulted. The new declarations are: -

    - -
    tuple() = default;
-tuple(const tuple&) = default;
-
    - -

    -This changes is not implementation neutral. In particular, it -prevents implementations based on pointers to the parameter -types. It does however, permit implementations using the -parameter types as bases. -

    -

    -** How does the committee wish to trade implementation -efficiency versus implementation flexibility? -

    - -

    [ -Bellevue: -]

    - - -
    -

    -General agreement; the first half of the issue is NAD. -

    -

    -Before voting on the second half, it was agreed that a "Strongly Favor" -vote meant support for trivial tuples (assuming usual requirements met), -even at the expense of other desired qualities. A "Weakly Favor" vote -meant support only if not at the expense of other desired qualities. -

    -

    -Concensus: Go forward, but not at expense of other desired qualities. -

    -

    -It was agreed to Alisdair should fold this work in with his other -pair/tuple action items, above, and that issue 801 should be "open", but -tabled until Alisdair's proposals are disposed of. -

    -
    - - -

    Proposed resolution:

    -

    -

    - - - - - -
    -

    803. Simplification of seed_seq::seq_seq

    -

    Section: 26.4.7.1 [rand.util.seedseq] Status: Review - Submitter: Charles Karney Date: 2008-02-22

    -

    View other active issues in [rand.util.seedseq].

    -

    View all other issues in [rand.util.seedseq].

    -

    View all issues with Review status.

    -

    Discussion:

    -

    -seed_seq(InputIterator begin, InputIterator end); constructs a seed_seq -object repacking the bits of supplied sequence [begin, end) into a -32-bit vector. -

    -

    -This repacking triggers several problems: -

    -
      -
    1. -Distinctness of the output of seed_seq::generate required the -introduction of the initial "if (w < 32) v.push_back(n);" (Otherwise -the unsigned short vectors [1, 0] and [1] generate the same sequence.) -
      2. -
    2. -Portability demanded the introduction of the template parameter u. -(Otherwise some sequences could not be obtained on computers where no -integer types are exactly 32-bits wide.) -
      3. -
    3. -The description and algorithm have become unduly complicated. -
      4. -
    -

    -I propose simplifying this seed_seq constructor to be "32-bit only". -Despite it's being simpler, there is NO loss of functionality (see -below). -

    -

    -Here's how the description would read -

    -
    -

    -26.4.7.1 [rand.util.seedseq] Class seed_seq -

    - -
    -
    template<class InputIterator>
-  seed_seq(InputIterator begin, InputIterator end);
-
    -
    -

    -5 Requires: NO CHANGE -

    -

    -6 Effects: Constructs a seed_seq object by -

    -
    -
    for (InputIterator s = begin; s != end; ++s)
-   v.push_back((*s) mod 2^32);
-
    -
    -
    -
    -
    - -

    -Discussion: -

    -

    -The chief virtues here are simplicity, portability, and generality. -

    -
      -
    • -Simplicity -- compare the above specification with the -n2461 proposal. -
      • -
    • -Portability -- with iterator_traits<InputIterator>::value_type = -uint_least32_t the user is guaranteed to get the same behavior across -platforms. -
      • -
    • -Generality -- any behavior that the -n2461 -proposal can achieve can be -obtained with this simpler proposal (albeit with a shuffling of bits -in the input sequence). -
      • -
    -

    -Arguments (and counter-arguments) against making this change (and -retaining the -n2461 -behavior) are: -

    -
      -
    • -

      -The user can pass an array of unsigned char and seed_seq will nicely - repack it. -

      -

      - Response: So what? Consider the seed string "ABC". The - n2461 - proposal results in -

      -
      v = { 0x3, 0x434241 };
-
      -

      -while the simplified proposal yields -

      -
      v = { 0x41, 0x42, 0x43 };
-
      -

      -The results produced by seed_seq::generate with the two inputs are -different but nevertheless equivalently "mixed up" and this remains -true even if the seed string is long. -

      -
      • -
    • -

      -With long strings (e.g., with bit-length comparable to the number of - bits in the state), v is longer (by a factor of 4) with the simplified - proposal and seed_seq::generate will be slower. -

      -

      -Response: It's unlikely that the efficiency of seed_seq::generate will - be a big issue. If it is, the user is free to repack the seed vector - before constructing seed_seq. -

      -
      • -
    • -

      -A user can pass an array of 64-bit integers and all the bits will be - used. -

      -

      - Response: Indeed. However, there are many instances in the - n2461 - where integers are silently coerced to a narrower width and this - should just be a case of the user needing to read the documentation. - The user can of course get equivalent behavior by repacking his seed - into 32-bit pieces. Furthermore, the unportability of the - n2461 - proposal with -

      -
      unsigned long s[] = {1, 2, 3, 4};
-seed_seq q(s, s+4);
-
      -

      - which typically results in v = {1, 2, 3, 4} on 32-bit machines and in -v = {1, 0, 2, 0, 3, 0, 4, 0} on 64-bit machines is a major pitfall for - unsuspecting users. -

      -
      • -
    - -

    -Note: this proposal renders moot issues 782 and 800. -

    - -

    [ -Bellevue: -]

    - - -
    -Walter needs to ask Fermilab for guidance. Defer till tomorrow. Bill likes the proposed resolution. -
    - -

    [ -Sophia Antipolis: -]

    - - -
    -

    -Marc Paterno wants portable behavior between 32bit and 64bit machines; -we've gone to significant trouble to support portability of engines and -their values. -

    -

    -Jens: the new algorithm looks perfectly portable -

    -

    -Marc Paterno to review off-line. -

    -

    -Modify the proposed resolution to read "Constructs a seed_seq object by the following algorithm ..." -

    -

    -Disposition: move to review; unanimous consent. -

    -

    -(moots 782 and 800) -

    -
    - - - -

    Proposed resolution:

    -

    -Change 26.4.7.1 [rand.util.seedseq]: -

    - -
    -
    template<class InputIterator, 
-  size_t u = numeric_limits<iterator_traits<InputIterator>::value_type>::digits>
-  seed_seq(InputIterator begin, InputIterator end);
-
    -
    -

    --5- Requires: InputIterator shall satisfy the requirements of an input iterator (24.1.1) -such that iterator_traits<InputIterator>::value_type shall denote an integral type. -

    -

    --6- Constructs a seed_seq object by the following algorithm rearranging some or all of the bits of the supplied sequence -[begin,end) of w-bit quantities into 32-bit units, as if by the following: -

    -

    -First extract the rightmost u bits from each of the n = end -- begin elements of the supplied sequence and concatenate all the -extracted bits to initialize a single (possibly very large) unsigned -binary number, b = ∑n-1i=0 (begin[i] -mod 2u) · 2w·i (in which the bits of each begin[i] -are treated as denoting an unsigned quantity). Then carry out -the following algorithm: -

    -
    
-v.clear(); 
-if ($w$ < 32) 
-  v.push_back($n$); 
-for( ; $n$ > 0; --$n$) 
-  v.push_back(b mod 232), b /= 232;
-
    -
    -
    
-for (InputIterator s = begin; s != end; ++s)
-   v.push_back((*s) mod 232);
-
    -
    -
    -
    - - - - - -
    -

    804. Some problems with classes error_code/error_condition

    -

    Section: 19.4 [syserr] Status: Review - Submitter: Daniel Krügler Date: 2008-02-24

    -

    View other active issues in [syserr].

    -

    View all other issues in [syserr].

    -

    View all issues with Review status.

    -

    Discussion:

    -
      -
    1. -

      -19.4.2.1 [syserr.errcode.overview]/1, class error_code and -19.4.3.1 [syserr.errcondition.overview]/, class error_condition synopses -declare an expository data member cat_: -

      -
      const error_category& cat_; // exposition only
-
      -

      -which is used to define the semantics of several members. The decision -to use a member of reference type lead to several problems: -

      -
        -
      1. -The classes are not (Copy)Assignable, which is probably not the intent. -
        2. -
      2. -The post conditions of all modifiers from -19.4.2.3 [syserr.errcode.modifiers] and 19.4.3.3 [syserr.errcondition.modifiers], resp., -cannot be fulfilled. -
        3. -
      -

      -The simple fix would be to replace the reference by a pointer member. -

      -
      2. - -
    2. -I would like to give the editorial remark that in both classes the -constrained operator= -overload (template with ErrorCodeEnum argument) makes in invalid -usage of std::enable_if: By using the default value for the second enable_if -parameter the return type would be defined to be void& even in otherwise -valid circumstances - this return type must be explicitly provided (In -error_condition the first declaration uses an explicit value, but of wrong -type). -
      3. - -
    3. -The member function message throws clauses ( -19.4.1.2 [syserr.errcat.virtuals]/10, 19.4.2.4 [syserr.errcode.observers]/8, and -19.4.3.4 [syserr.errcondition.observers]/6) guarantee "throws nothing", -although -they return a std::string by value, which might throw in out-of-memory -conditions (see related issue 771). -
      4. -
    - -

    [ -Sophia Antipolis: -]

    - - -
    -

    -Part A: NAD (editorial), cleared by the resolution of issue 832. -

    -

    -Part B: Technically correct, save for typo. Rendered moot by the concept proposal -(N2620) NAD (editorial). -

    -

    -Part C: We agree; this is consistent with the resolution of issue 721. -

    -

    -Howard: please ping Beman, asking him to clear away parts A and B from -the wording in the proposed resolution, so it is clear to the editor -what needs to be applied to the working paper. -

    -

    -Beman provided updated wording. Since issue 832 is not going -forward, the provided wording includes resolution of part A. -

    -
    - - - -

    Proposed resolution:

    - -

    -Resolution of part A: -

    -
    -

    -Change 19.4.2.1 [syserr.errcode.overview] Class error_code overview synopsis as indicated: -

    - -
    private:
-  int val_;                    // exposition only
-  const error_category&* cat_; // exposition only
-
    - -

    -Change 19.4.2.2 [syserr.errcode.constructors] Class error_code constructors as indicated: -

    - -
    -
    error_code();
-
    -
    -

    -Effects: Constructs an object of type error_code. -

    -

    -Postconditions: val_ == 0 and cat_ == &system_category. -

    -

    -Throws: Nothing. -

    -
    -
    error_code(int val, const error_category& cat);
-
    -
    -

    -Effects: Constructs an object of type error_code. -

    -

    -Postconditions: val_ == val and cat_ == &cat. -

    -

    -Throws: Nothing. -

    -
    -
    - -

    -Change 19.4.2.3 [syserr.errcode.modifiers] Class error_code modifiers as indicated: -

    - -
    -
    void assign(int val, const error_category& cat);
-
    -
    -

    -Postconditions: val_ == val and cat_ == &cat. -

    -

    -Throws: Nothing. -

    -
    -
    - -

    -Change 19.4.2.4 [syserr.errcode.observers] Class error_code observers as indicated: -

    - -
    -const error_category& category() const; -
    -

    -Returns: *cat_. -

    -

    -Throws: Nothing. -

    -
    -
    - -

    -Change 19.4.3.1 [syserr.errcondition.overview] Class error_condition overview synopsis as indicated: -

    - -
    private:
-  int val_;                    // exposition only
-  const error_category&* cat_; // exposition only
-
    - -

    -Change 19.4.3.2 [syserr.errcondition.constructors] Class error_condition constructors as indicated: -

    -

    [ -(If the proposed resolution of issue 805 has already been applied, the -name posix_category will have been changed to generic_category. That has -no effect on this resolution.) -]

    - - -
    -
    error_condition();
-
    -
    -

    -Effects: Constructs an object of type error_condition. -

    -

    -Postconditions: val_ == 0 and cat_ == &posix_category. -

    -

    -Throws: Nothing. -

    -
    -
    error_condition(int val, const error_category& cat);
-
    -
    -

    -Effects: Constructs an object of type error_condition. -

    -

    -Postconditions: val_ == val and cat_ == &cat. -

    -

    -Throws: Nothing. -

    -
    -
    - -

    -Change 19.4.3.3 [syserr.errcondition.modifiers] Class error_condition modifiers as indicated: -

    - -
    -void assign(int val, const error_category& cat); -
    -

    -Postconditions: val_ == val and cat_ == &cat. -

    -

    -Throws: Nothing. -

    -
    -
    - -

    -Change 19.4.3.4 [syserr.errcondition.observers] Class error_condition observers as indicated: -

    - -
    -const error_category& category() const; -
    -

    -Returns: *cat_. -

    -

    -Throws: Nothing. -

    -
    -
    -
    - -

    -Resolution of part C: -

    - -
    - -

    -In 19.4.1.2 [syserr.errcat.virtuals], remove the throws clause p. 10. -

    - -
    -
    virtual string message(int ev) const = 0;
-
    - -
    -

    -Returns: A string that describes the error condition denoted by ev. -

    -

    -Throws: Nothing. -

    -
    -
    - -

    -In 19.4.2.4 [syserr.errcode.observers], remove the throws clause p. 8. -

    - -
    -
    string message() const;
-
    -
    -

    -Returns: category().message(value()). -

    -

    -Throws: Nothing. -

    -
    -
    - -

    -In 19.4.3.4 [syserr.errcondition.observers], remove the throws clause p. 6. -

    - -
    -
    string message() const;
-
    -
    -

    -Returns: category().message(value()). -

    -

    -Throws: Nothing. -

    -
    -
    - -
    - - - - - - -
    -

    805. posix_error::posix_errno concerns

    -

    Section: 19.4 [syserr] Status: Ready - Submitter: Jens Maurer Date: 2008-02-24

    -

    View other active issues in [syserr].

    -

    View all other issues in [syserr].

    -

    View all issues with Ready status.

    -

    Discussion:

    -

    -19.4 [syserr] -

    - -
    namespace posix_error {
-  enum posix_errno {
-    address_family_not_supported, // EAFNOSUPPORT
-    ...
-
    - -

    -should rather use the new scoped-enum facility (7.2 [dcl.enum]), -which would avoid the necessity for a new posix_error -namespace, if I understand correctly. -

    - -

    [ -Further discussion: -]

    - - -
    -

    -See N2347, -Strongly Typed Enums, since renamed Scoped Enums. -

    -

    -Alberto Ganesh Barbati also raised this issue in private email, and also proposed the scoped-enum solution. -

    -

    -Nick Stoughton asked in Bellevue that posix_error and posix_errno not be used as names. The LWG agreed. -

    -

    -The wording for the Proposed resolution was provided by Beman Dawes. -

    -
    - - -

    Proposed resolution:

    -

    -Change System error support 19.4 [syserr] as indicated: -

    - -
    namespace posix_error {
-  enum posix_errno class errc {
-    address_family_not_supported, // EAFNOSUPPORT
-    ...
-    wrong_protocol_type, // EPROTOTYPE
-  };
-} // namespace posix_error
-
-template <> struct is_error_condition_enum<posix_error::posix_errno errc>
-  : public true_type {}
-
-namespace posix_error {
-  error_code make_error_code(posix_errno errc e);
-  error_condition make_error_condition(posix_errno errc e);
-} // namespace posix_error
-
    - -

    -Change System error support 19.4 [syserr] : -

    - -
    -The is_error_code_enum and is_error_condition_enum templates may be -specialized for user-defined types to indicate that such a type is -eligible for class error_code and class error_condition automatic -conversions, respectively. -
    - -

    -Change System error support 19.4 [syserr] and its subsections: -

    - -
    -
      -
    • -remove all occurrences of posix_error:: -
      • -
    • -change all instances of posix_errno to errc -
      • -
    • -change all instances of posix_category to generic_category -
      • -
    • -change all instances of get_posix_category to get_generic_category -
      • -
    -
    - -

    -Change Error category objects 19.4.1.5 [syserr.errcat.objects], paragraph 2: -

    - -
    -Remarks: The object's default_error_condition and equivalent virtual -functions shall behave as specified for the class error_category. The -object's name virtual function shall return a pointer to the string -"POSIX" "GENERIC". -
    - -

    -Change 19.4.2.5 [syserr.errcode.nonmembers] Class error_code non-member functions as indicated: -

    - -
    -
    error_code make_error_code(posix_errno errc e);
-
    - -
    -Returns: error_code(static_cast<int>(e), posixgeneric_category). -
    -
    - -

    -Change 19.4.3.5 [syserr.errcondition.nonmembers] Class error_condition non-member functions as indicated: -

    - -
    -
    error_condition make_error_condition(posix_errno errc e);
-
    - -
    -Returns: error_condition(static_cast<int>(e), posixgeneric_category). -
    -
    - - - -

    Rationale:

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    Names Considered
    portable -Too non-specific. Did not wish to reserve such a common word in -namespace std. Not quite the right meaning, either. -
    portable_error -Too long. Explicit qualification is always required for scoped enums, so -a short name is desirable. Not quite the right meaning, either. May be -misleading because *_error in the std lib is usually an exception class -name. -
    std_error -Fairly short, yet explicit. But in fully qualified names like -std::std_error::not_enough_memory, the std_ would be unfortunate. Not -quite the right meaning, either. May be misleading because *_error in -the std lib is usually an exception class name. -
    generic -Short enough. The category could be generic_category. Fully qualified -names like std::generic::not_enough_memory read well. Reserving in -namespace std seems dicey. -
    generic_error -Longish. The category could be generic_category. Fully qualified names -like std::generic_error::not_enough_memory read well. Misleading because -*_error in the std lib is usually an exception class name. -
    generic_err -A bit less longish. The category could be generic_category. Fully -qualified names like std::generic_err::not_enough_memory read well. -
    gen_err -Shorter still. The category could be generic_category. Fully qualified -names like std::gen_err::not_enough_memory read well. -
    generr -Shorter still. The category could be generic_category. Fully qualified -names like std::generr::not_enough_memory read well. -
    error -Shorter still. The category could be generic_category. Fully qualified -names like std::error::not_enough_memory read well. Do we want to use -this general a name? -
    err -Shorter still. The category could be generic_category. Fully qualified -names like std::err::not_enough_memory read well. Although alone it -looks odd as a name, given the existing errno and namespace std names, -it seems fairly intuitive. -Problem: err is used throughout the standard library as an argument name -and in examples as a variable name; it seems too confusing to add yet -another use of the name. -
    errc -Short enough. The "c" stands for "constant". The category could be -generic_category. Fully qualified names like -std::errc::not_enough_memory read well. Although alone it looks odd as a -name, given the existing errno and namespace std names, it seems fairly -intuitive. There are no uses of errc in the current C++ standard. -
    - - - - - -
    -

    806. unique_ptr::reset effects incorrect, too permissive

    -

    Section: 20.7.11.2.5 [unique.ptr.single.modifiers] Status: Ready - Submitter: Peter Dimov Date: 2008-03-13

    -

    View all issues with Ready status.

    -

    Discussion:

    -

    -void unique_ptr::reset(T* p = 0) is currently specified as: -

    - -
    -Effects: If p == get() there are no effects. Otherwise get_deleter()(get()). -
    - -

    -There are two problems with this. One, if get() == 0 and p != 0, the -deleter is called with a NULL pointer, and this is probably not what's -intended (the destructor avoids calling the deleter with 0.) -

    - -

    -Two, the special check for get() == p is generally not needed and such a -situation usually indicates an error in the client code, which is being -masked. As a data point, boost::shared_ptr was changed to assert on such -self-resets in 2001 and there were no complaints. -

    - -

    -One might think that self-resets are necessary for operator= to work; it's specified to perform -

    - -
    reset( u.release() );
-
    - -

    -and the self-assignment -

    - -
    p = move(p);
-
    - -

    -might appear to result in a self-reset. But it doesn't; the release() is -performed first, zeroing the stored pointer. In other words, p.reset( -q.release() ) works even when p and q are the same unique_ptr, and there -is no need to special-case p.reset( q.get() ) to work in a similar -scenario, as it definitely doesn't when p and q are separate. -

    - - - -

    Proposed resolution:

    - -

    -Change 20.7.11.2.5 [unique.ptr.single.modifiers]: -

    - -
    -
    void reset(T* p = 0);
-
    -
    --4- Effects: If p == get() == 0 there are no effects. Otherwise get_deleter()(get()). -
    -
    - -

    -Change 20.7.11.3.3 [unique.ptr.runtime.modifiers]: -

    - -
    -
    void reset(T* p = 0);
-
    -
    -

    ...

    -

    --2- Effects: If p == get() == 0 there are no effects. Otherwise get_deleter()(get()). -

    -
    -
    - - - - - - -
    -

    807. tuple construction should not fail unless its element's construction fails

    -

    Section: 20.4.1.2 [tuple.cnstr] Status: Ready - Submitter: Howard Hinnant Date: 2008-03-13

    -

    View all issues with Ready status.

    -

    Discussion:

    -

    -527 Added a throws clause to bind constructors. I believe the same throws clause -should be added to tuple except it ought to take into account move constructors as well. -

    - - -

    Proposed resolution:

    -

    -Add to 20.4.1.2 [tuple.cnstr]: -

    - -
    -

    -For each tuple constructor and assignment operator, an exception is thrown only if the construction -or assignment of one of the types in Types throws an exception. -

    -
    - - - - - -
    -

    808. [forward] incorrect redundant specification

    -

    Section: 20.2.2 [forward] Status: Ready - Submitter: Jens Maurer Date: 2008-03-13

    -

    View other active issues in [forward].

    -

    View all other issues in [forward].

    -

    View all issues with Ready status.

    -

    Discussion:

    -

    -p4 (forward) says: -

    -
    -Return type: If T is an lvalue-reference type, an lvalue; otherwise, an rvalue. -
    - -

    -First of all, lvalue-ness and rvalue-ness are properties of an expression, -not of a type (see 3.10 [basic.lval]). Thus, the phrasing "Return type" is wrong. -Second, the phrase says exactly what the core language wording says for -folding references in 14.3.1 [temp.arg.type]/p4 and for function return values -in 5.2.2 [expr.call]/p10. (If we feel the wording should be retained, it should -at most be a note with cross-references to those sections.) -

    -

    -The prose after the example talks about "forwarding as an int& (an lvalue)" etc. -In my opinion, this is a category error: "int&" is a type, "lvalue" is a -property of an expression, orthogonal to its type. (Btw, expressions cannot -have reference type, ever.) -

    -

    -Similar with move: -

    -
    -Return type: an rvalue. -
    -

    -is just wrong and also redundant. -

    - - -

    Proposed resolution:

    -

    -Change 20.2.2 [forward] as indicated: -

    - -
    -
    template <class T> T&& forward(typename identity<T>::type&& t);
-
    - -
    -

    ...

    -

    -Return type: If T is an lvalue-reference type, an lvalue; otherwise, an rvalue. -

    -

    ...

    -

    --7- In the first call to factory, A1 is deduced as int, so 2 is forwarded to A's constructor -as an int&& (an rvalue). In the second call to factory, A1 is deduced -as int&, so i is forwarded to A's constructor as an int& (an lvalue). -In both cases, A2 is deduced as double, so 1.414 is forwarded to A's constructor as -double&& (an rvalue). -

    -
    - -
    template <class T> typename remove_reference<T>::type&& move(T&& t);
-
    - -
    -

    ...

    -

    -Return type: an rvalue. -

    -
    - -
    - - - - - - -
    -

    809. std::swap should be overloaded for array types

    -

    Section: 25.2.3 [alg.swap] Status: Ready - Submitter: Niels Dekker Date: 2008-02-28

    -

    View all other issues in [alg.swap].

    -

    View all issues with Ready status.

    -

    Discussion:

    -

    -For the sake of generic programming, the header <algorithm> should provide an -overload of std::swap for array types: -

    template<class T, size_t N> void swap(T (&a)[N], T (&b)[N]);
-
    - - -

    -It became apparent to me that this overload is missing, when I considered how to write a swap -function for a generic wrapper class template. -(Actually I was thinking of Boost's value_initialized.) -Please look at the following template, W, and suppose that is intended to be a very -generic wrapper: -

    template<class T> class W {
-public:
-   T data;
-};
-
    -Clearly W<T> is CopyConstructible and CopyAssignable, and therefore -Swappable, whenever T is CopyConstructible and CopyAssignable. -Moreover, W<T> is also Swappable when T is an array type -whose element type is CopyConstructible and CopyAssignable. -Still it is recommended to add a custom swap function template to such a class template, -for the sake of efficiency and exception safety. -(E.g., Scott Meyers, Effective C++, Third Edition, item 25: Consider support for a non-throwing -swap.) -This function template is typically written as follows: -
    template<class T> void swap(W<T>& x, W<T>& y) {
-  using std::swap;
-  swap(x.data, y.data);
-}
-
    -Unfortunately, this will introduce an undesirable inconsistency, when T is an array. -For instance, W<std::string[8]> is Swappable, but the current Standard does not -allow calling the custom swap function that was especially written for W! -
    W<std::string[8]> w1, w2;  // Two objects of a Swappable type.
-std::swap(w1, w2);  // Well-defined, but inefficient.
-using std::swap;
-swap(w1, w2);  // Ill-formed, just because ADL finds W's swap function!!!
-
    - -W's swap function would try to call std::swap for an array, -std::string[8], which is not supported by the Standard Library. -This issue is easily solved by providing an overload of std::swap for array types. -This swap function should be implemented in terms of swapping the elements of the arrays, so that -it would be non-throwing for arrays whose element types have a non-throwing swap. - - -

    -Note that such an overload of std::swap should also support multi-dimensional -arrays. Fortunately that isn't really an issue, because it would do so automatically, by -means of recursion. -

    - -

    -For your information, there was a discussion on this issue at comp.lang.c++.moderated: [Standard -Library] Shouldn't std::swap be overloaded for C-style arrays? -

    - - -

    Proposed resolution:

    -

    -Add an extra condition to the definition of Swappable requirements [swappable] in 20.1.1 [utility.arg.requirements]: -

    -
    -- T is Swappable if T is an array type whose element type is Swappable. -
    -

    -Add the following to 25.2.3 [alg.swap]: -

    -
    -
    template<class T, size_t N> void swap(T (&a)[N], T (&b)[N]);
-
    -
    -Requires: Type T shall be Swappable. -
    -
    -Effects: swap_ranges(a, a + N, b); -
    -
    - - - - - -
    -

    810. Missing traits dependencies in operational semantics of extended manipulators

    -

    Section: 27.6.4 [ext.manip] Status: New - Submitter: Daniel Krügler Date: 2008-03-01

    -

    View other active issues in [ext.manip].

    -

    View all other issues in [ext.manip].

    -

    View all issues with New status.

    -

    Discussion:

    -

    -The recent draft (as well as the original proposal n2072) uses an -operational semantic -for get_money ([ext.manip]/3) and put_money ([ext.manip]/5), which uses -

    - -
    istreambuf_iterator<charT>
-
    - -

    -and -

    - -
    ostreambuf_iterator<charT>
-
    - -

    -resp, instead of the iterator instances, with explicitly provided -traits argument (The operational semantic defined by f is also traits -dependent). This is an obvious oversight because both *stream_buf -c'tors expect a basic_streambuf<charT,traits> as argument. -

    -

    -The same problem occurs within the get_time and put_time semantic (p. -7 and p. 9) -of n2071 incorporated in N2521, where additional to the problem we -have an editorial issue in get_time (streambuf_iterator instead of -istreambuf_iterator). -

    - - -

    Proposed resolution:

    -

    -In 27.6.4 [ext.manip]/3 within function f replace the first line -

    - -
    template <class charT, class traits, class moneyT> 
-void f(basic_ios<charT, traits>& str, moneyT& mon, bool intl) { 
-   typedef istreambuf_iterator<charT, traits> Iter;
-   ...
-
    - -

    -In 27.6.4 [ext.manip]/4 remove the first template charT parameter: -

    - -
    template <class charT, class moneyT> unspecified put_money(const moneyT& mon, bool intl = false);
-
    - -

    -In 27.6.4 [ext.manip]/5 within function f replace the first line -

    - -
    template <class charT, class traits, class moneyT> 
-void f(basic_ios<charT, traits>& str, const moneyT& mon, bool intl) { 
-  typedef ostreambuf_iterator<charT, traits> Iter;
-  ...
-
    - -

    -In 27.6.4 [ext.manip]/7 within function f replace the first line -

    - -
    template <class charT, class traits> 
-void f(basic_ios<charT, traits>& str, struct tm *tmb, const charT *fmt) { 
-  typedef istreambuf_iterator<charT, traits> Iter;
-  ...
-
    - -

    -In 27.6.4 [ext.manip]/8 add const: -

    - -
    template <class charT> unspecified put_time(const struct tm *tmb, const charT *fmt);
-
    - -

    -In 27.6.4 [ext.manip]/9 within function f replace the first line -

    - -
    template <class charT, class traits> 
-void f(basic_ios<charT, traits>& str, const struct tm *tmb, const charT *fmt) { 
-  typedef ostreambuf_iterator<charT, traits> Iter;
-  ...
-
    - -

    -Add to the <iomanip> synopsis in 27.6 [iostream.format] -

    - -
    template <class moneyT> unspecified get_money(moneyT& mon, bool intl = false);
-template <class moneyT> unspecified put_money(const moneyT& mon, bool intl = false);
-template <class charT> unspecified get_time(struct tm *tmb, const charT *fmt);
-template <class charT> unspecified put_time(const struct tm *tmb, const charT *fmt);
-
    - - - - - - -
    -

    811. pair of pointers no longer works with literal 0

    -

    Section: 20.2.3 [pairs] Status: New - Submitter: Doug Gregor Date: 2008-03-14

    -

    View all other issues in [pairs].

    -

    View all issues with New status.

    -

    Discussion:

    -
    #include <utility>
-
-int main()
-{
-   std::pair<char *, char *> p (0,0);
-}
-
    - -

    -I just got a bug report about that, because it's valid C++03, but not -C++0x. The important realization, for me, is that the emplace -proposal---which made push_back variadic, causing the push_back(0) -issue---didn't cause this break in backward compatibility. The break -actually happened when we added this pair constructor as part of adding -rvalue references into the language, long before variadic templates or -emplace came along: -

    - -
    template<class U, class V> pair(U&& x, V&& y);
-
    - -

    -Now, concepts will address this issue by constraining that pair -constructor to only U's and V's that can properly construct "first" and -"second", e.g. (from -N2322): -

    - -
    template<class U , class V >
-requires Constructible<T1, U&&> && Constructible<T2, V&&>
-pair(U&& x , V&& y );
-
    - - - -

    Proposed resolution:

    -

    -

    - - - - - -
    -

    812. unsolicited multithreading considered harmful?

    -

    Section: 25.3.1 [alg.sort] Status: New - Submitter: Paul McKenney Date: 2008-02-27

    -

    View all issues with New status.

    -

    Discussion:

    -

    -Multi-threading is a good thing, but unsolicited multi-threading can -potentially be harmful. For example, sort() performance might be -greatly increased via a multithreaded implementation. However, such -a multithreaded implementation could result in concurrent invocations -of the user-supplied comparator. This would in turn result in problems -given a caching comparator that might be written for complex sort keys. -Please note that this is not a theoretical issue, as multithreaded -implementations of sort() already exist. -

    -

    -Having a multithreaded sort() available is good, but it should not -be the default for programs that are not explicitly multithreaded. -Users should not be forced to deal with concurrency unless they have -asked for it. -

    - -

    [ -This may be covered by -N2410 -Thread-Safety in the Standard Library (Rev 1). -]

    - - - -

    Proposed resolution:

    -

    -

    - - - - - -
    -

    813. "empty" undefined for shared_ptr

    -

    Section: 20.7.12.2 [util.smartptr.shared] Status: Ready - Submitter: Matt Austern Date: 2008-02-26

    -

    View other active issues in [util.smartptr.shared].

    -

    View all other issues in [util.smartptr.shared].

    -

    View all issues with Ready status.

    -

    Discussion:

    -

    -Several places in 20.7.12.2 [util.smartptr.shared] refer to an "empty" shared_ptr. -However, that term is nowhere defined. The closest thing we have to a -definition is that the default constructor creates an empty shared_ptr -and that a copy of a default-constructed shared_ptr is empty. Are any -other shared_ptrs empty? For example, is shared_ptr((T*) 0) empty? What -are the properties of an empty shared_ptr? We should either clarify this -term or stop using it. -

    -

    -One reason it's not good enough to leave this term up to the reader's -intuition is that, in light of -N2351 -and issue 711, most readers' -intuitive understanding is likely to be wrong. Intuitively one might -expect that an empty shared_ptr is one that doesn't store a pointer, -but, whatever the definition is, that isn't it. - - -

    [ -Peter adds: -]

    - - -
    -

    -Or, what is an "empty" shared_ptr? -

    - -
      -
    • -

      -Are any other shared_ptrs empty? -

      -

      -Yes. Whether a given shared_ptr instance is empty or not is (*) -completely specified by the last mutating operation on that instance. -Give me an example and I'll tell you whether the shared_ptr is empty or -not. -

      -
      -(*) If it isn't, this is a legitimate defect. -
      -
      • - -
    • -

      -For example, is shared_ptr((T*) 0) empty? -

      -

      -No. If it were empty, it would have a use_count() of 0, whereas it is -specified to have an use_count() of 1. -

      -
      • - -
    • -

      -What are the properties of an empty shared_ptr? -

      -

      -The properties of an empty shared_ptr can be derived from the -specification. One example is that its destructor is a no-op. Another is -that its use_count() returns 0. I can enumerate the full list if you -really like. -

      -
      • - -
    • -

      -We should either clarify this term or stop using it. -

      -

      -I don't agree with the imperative tone -

      -

      -A clarification would be either a no-op - if it doesn't contradict the -existing wording - or a big mistake if it does. -

      -

      -I agree that a clarification that is formally a no-op may add value. -

      -
      • - -
    • -

      -However, that term is nowhere defined. -

      -

      -Terms can be useful without a definition. Consider the following -simplistic example. We have a type X with the following operations -defined: -

      -
      X x;
-X x2(x);
-X f(X x);
-X g(X x1, X x2);
-
      -

      -A default-constructed value is green.
      -A copy has the same color as the original.
      -f(x) returns a red value if the argument is green, a green value otherwise.
      -g(x1,x2) returns a green value if the arguments are of the same color, a red value otherwise. -

      - -

      -Given these definitions, you can determine the color of every instance -of type X, even if you have absolutely no idea what green and red mean. -

      - -

      -Green and red are "nowhere defined" and completely defined at the same time. -

      -
      • -
    - -

    -Alisdair's wording is fine. -

    -
    - - -

    Proposed resolution:

    -

    -Append the following sentance to 20.7.12.2 [util.smartptr.shared] -

    -
    -The shared_ptr class template stores a pointer, usually obtained -via new. shared_ptr implements semantics of -shared ownership; the last remaining owner of the pointer is responsible for -destroying the object, or otherwise releasing the resources associated with -the stored pointer. A shared_ptr object that does not own -a pointer is said to be empty. -
    - - - - - -
    -

    814. vector<bool>::swap(reference, reference) not defined

    -

    Section: 23.2.7 [vector.bool] Status: New - Submitter: Alisdair Meredith Date: 2008-03-17

    -

    View other active issues in [vector.bool].

    -

    View all other issues in [vector.bool].

    -

    View all issues with New status.

    -

    Discussion:

    -

    -vector<bool>::swap(reference, reference) has no definition. -

    - - -

    Proposed resolution:

    -

    -

    - - - - - -
    -

    815. std::function and reference_closure do not use perfect forwarding

    -

    Section: 20.6.15.2.4 [func.wrap.func.inv] Status: Open - Submitter: Alisdair Meredith Date: 2008-03-16

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -std::function and reference_closure should use "perfect forwarding" as -described in the rvalue core proposal. -

    - -

    [ -Sophia Antipolis: -]

    - - -
    -According to Doug Gregor, as far as std::function is concerned, perfect -forwarding can not be obtained because of type erasure. Not everyone -agreed with this diagnosis of forwarding. -
    - - - -

    Proposed resolution:

    -

    -

    - - - - - -
    -

    816. Should bind()'s returned functor have a nofail copy ctor when bind() is nofail?

    -

    Section: 20.6.11.1.3 [func.bind.bind] Status: New - Submitter: Stephan T. Lavavej Date: 2008-02-08

    -

    View other active issues in [func.bind.bind].

    -

    View all other issues in [func.bind.bind].

    -

    View all issues with New status.

    -

    Discussion:

    -

    -Library Issue 527 notes that bind(f, t1, ..., tN) -should be nofail when f, t1, ..., tN have nofail copy ctors. -

    -

    -However, no guarantees are provided for the copy ctor of the functor -returned by bind(). (It's guaranteed to have a copy ctor, which can -throw implementation-defined exceptions: bind() returns a forwarding -call wrapper, TR1 3.6.3/2. A forwarding call wrapper is a call wrapper, -TR1 3.3/4. Every call wrapper shall be CopyConstructible, TR1 3.3/4. -Everything without an exception-specification may throw -implementation-defined exceptions unless otherwise specified, C++03 -17.4.4.8/3.) -

    -

    -Should the nofail guarantee requested by Library Issue 527 be extended -to cover both calling bind() and copying the returned functor? -

    - -

    [ -Howard adds: -]

    - - -
    -tuple construction should probably have a similar guarantee. -
    - - - -

    Proposed resolution:

    -

    -

    - - - - - -
    -

    817. bind needs to be moved

    -

    Section: 20.6.11.1.3 [func.bind.bind] Status: New - Submitter: Howard Hinnant Date: 2008-03-17

    -

    View other active issues in [func.bind.bind].

    -

    View all other issues in [func.bind.bind].

    -

    View all issues with New status.

    -

    Discussion:

    -

    -The functor retureed by bind() should have a move constructor that -requires only move construction of its contained functor and bound arguments. -That way move-only functors can be passed to objects such as thread. -

    -

    -This issue is related to issue 816. -

    - - -

    Proposed resolution:

    -

    -

    - - - - - -
    -

    818. wording for memory ordering

    -

    Section: 29.1 [atomics.order] Status: New - Submitter: Jens Maurer Date: 2008-03-22

    -

    View all issues with New status.

    -

    Discussion:

    -

    -29.1 [atomics.order] p1 says in the table that -

    - -
    - - - - - - - - -
    ElementMeaning
    memory_order_acq_relthe operation has both acquire and release semantics
    -
    - -

    -To my naked eye, that seems to imply that even an atomic read has both -acquire and release semantics. -

    - -

    -Then, p1 says in the table: -

    - -
    - - - - - - - - -
    ElementMeaning
    memory_order_seq_cstthe operation has both acquire and release semantics, - and, in addition, has sequentially-consistent operation ordering
    -
    - -

    -So that seems to be "the same thing" as memory_order_acq_rel, with additional -constraints. -

    - -

    -I'm then reading p2, where it says: -

    - -
    -The memory_order_seq_cst operations that load a value are acquire operations -on the affected locations. The memory_order_seq_cst operations that store a value -are release operations on the affected locations. -
    - -

    -That seems to imply that atomic reads only have acquire semantics. If that -is intended, does this also apply to memory_order_acq_rel and the individual -load/store operations as well? -

    - -

    -Also, the table in p1 contains phrases with "thus" that seem to indicate -consequences of normative wording in 1.10 [intro.multithread]. That shouldn't be in -normative text, for the fear of redundant or inconsistent specification with -the other normative text. -

    - -

    -Double-check 29.4 [atomics.types.operations] that each -operation clearly says whether it's a load or a store operation, or -both. (It could be clearer, IMO. Solution not in current proposed resolution.) -

    - -

    -29.1 [atomics.order] p2: What's a "consistent execution"? It's not defined in -1.10 [intro.multithread], it's just used in notes there. -

    - -

    -And why does 29.4 [atomics.types.operations] p9 for "load" say: -

    - - -
    -Requires: The order argument shall not be memory_order_acquire -nor memory_order_acq_rel. -
    - -

    -(Since this is exactly the same restriction as for "store", it seems to be a typo.) -

    - -

    -And then: 29.4 [atomics.types.operations] p12: -

    - -
    -These operations are read-modify-write operations in the sense of the -"synchronizes with" definition (1.10 [intro.multithread]), so both such an operation and the -evaluation that produced the input value synchronize with any evaluation -that reads the updated value. -
    - -

    -This is redundant with 1.10 [intro.multithread], see above for the reasoning. -

    - - -

    Proposed resolution:

    -

    -Replace the cross-reference in p1 to refer to 1.1 [intro.scope] instead of -1.7 [intro.memory]. -Rephrase the table in as follows (maybe don't use a table): -

    - -
    -

    -For memory_order_relaxed, no operation orders memory. -

    - -

    -For memory_order_release, memory_order_acq_rel, and memory_order_seq_cst, -a store operation performs a release operation on the affected memory location. -

    - -

    -For memory_order_acquire, memory_order_acq_rel, and memory_order_seq_cst, -a load operation performs an acquire operation on the affected memory location. -

    -
    - -

    -Rephrase 29.1 [atomics.order] p2: -

    - -
    -The memory_order_seq_cst operations that load a value are -acquire operations on the affected locations. The -memory_order_seq_cst operations that store a value are release -operations on the affected locations. -In addition, in a consistent -execution, tThere must be is a single -total order S on all -memory_order_seq_cst operations, consistent with the happens before -order and modification orders for all affected locations, such that each -memory_order_seq_cst operation observes either the last preceding -modification according to this order S, or the result of an operation -that is not memory_order_seq_cst. [Note: Although it is not explicitly -required that S include locks, it can always be extended to an order -that does include lock and unlock operations, since the ordering between -those is already included in the happens before ordering. -- end note] -
    - -

    -Rephrase 29.4 [atomics.types.operations] p12 as: -

    - -
    -Effects: Atomically replaces the value pointed to by object or by -this with desired. Memory is affected according to the value of order. -These operations are read-modify-write operations in the sense of the -"synchronizes with" definition (1.10 [intro.multithread]), so both such an operation and the -evaluation that produced the input value synchronize with any evaluation -that reads the updated value. -
    - -

    -Same in p15, p20, p22. -

    - - - - - - -
    -

    819. rethrow_if_nested

    -

    Section: 18.7.6 [except.nested] Status: New - Submitter: Alisdair Meredith Date: 2008-03-25

    -

    View all issues with New status.

    -

    Discussion:

    -

    -Looking at the wording I submitted for rethrow_if_nested, I don't think I -got it quite right. -

    - -

    -The current wording says: -

    - -
    -
    template <class E> void rethrow_if_nested(const E& e);
-
    -
    -

    -Effects: Calls e.rethrow_nested() only if e -is publicly derived from nested_exception. -

    -
    -
    - -

    -This is trying to be a bit subtle, by requiring e (not E) to be publicly -derived from nested_exception the idea is that a dynamic_cast would be -required to be sure. Unfortunately, if e is dynamically but not statically -derived from nested_exception, e.rethrow_nested() is ill-formed. -

    - - -

    Proposed resolution:

    - - - - - -
    -

    820. current_exception()'s interaction with throwing copy ctors

    -

    Section: 18.7.5 [propagation] Status: New - Submitter: Stephan T. Lavavej Date: 2008-03-26

    -

    View other active issues in [propagation].

    -

    View all other issues in [propagation].

    -

    View all issues with New status.

    -

    Discussion:

    -

    -As of N2521, the Working Paper appears to be silent about what -current_exception() should do if it tries to copy the currently handled -exception and its copy constructor throws. 18.7.5 [propagation]/7 says "If the -function needs to allocate memory and the attempt fails, it returns an -exception_ptr object that refers to an instance of bad_alloc.", but -doesn't say anything about what should happen if memory allocation -succeeds but the actual copying fails. -

    - -

    -I see three alternatives: (1) return an exception_ptr object that refers -to an instance of some fixed exception type, (2) return an exception_ptr -object that refers to an instance of the copy ctor's thrown exception -(but if that has a throwing copy ctor, an infinite loop can occur), or -(3) call terminate(). -

    - -

    -I believe that terminate() is the most reasonable course of action, but -before we go implement that, I wanted to raise this issue. -

    - -

    [ -Peter's summary: -]

    - - -
    -

    -The current practice is to not have throwing copy constructors in -exception classes, because this can lead to terminate() as described in -15.5.1 [except.terminate]. Thus calling terminate() in this situation seems -consistent and does not introduce any new problems. -

    - -

    -However, the resolution of core issue 475 may relax this requirement: -

    - -
    -The CWG agreed with the position that std::uncaught_exception() should -return false during the copy to the exception object and that std::terminate() -should not be called if that constructor exits with an exception. -
    - -

    -Since throwing copy constructors will no longer call terminate(), option -(3) doesn't seem reasonable as it is deemed too drastic a response in a -recoverable situation. -

    - -

    -Option (2) cannot be adopted by itself, because a potential infinite -recursion will need to be terminated by one of the other options. -

    - -
    - - -

    Proposed resolution:

    -

    -Add the following paragraph after 18.7.5 [propagation]/7: -

    - -
    -

    -Returns (continued): If the attempt to copy the current exception -object throws an exception, the function returns an exception_ptr that -refers to the thrown exception or, if this is not possible, to an -instance of bad_exception. -

    -

    -[Note: The copy constructor of the thrown exception may also fail, so -the implementation is allowed to substitute a bad_exception to avoid -infinite recursion. -- end note.] -

    -
    - - - - - - -
    -

    821. Minor cleanup : unique_ptr

    -

    Section: 20.7.11.3.3 [unique.ptr.runtime.modifiers] Status: New - Submitter: Alisdair Meredith Date: 2008-03-30

    -

    View all issues with New status.

    -

    Discussion:

    -

    -Reading resolution of LWG issue 673 I noticed the following: -

    - -
    -
    void reset(T* pointer p = 0 pointer());
-
    - -

    --1- Requires: Does not accept pointer types which are convertible -to T* pointer (diagnostic -required). [Note: One implementation technique is to create a private -templated overload. -- end note] -

    -
    - -

    -This could be cleaned up by mandating the overload as a public deleted -function. In addition, we should probably overload reset on nullptr_t -to be a stronger match than the deleted overload. Words... -

    - - -

    Proposed resolution:

    -

    -Add to class template definition in 20.7.11.3 [unique.ptr.runtime] -

    - -
    -
    // modifiers 
-T* release(); 
-void reset(T* p = 0); 
-void reset( nullptr_t );
-template< typename T > void reset( T ) = delete;
-void swap(unique_ptr&& u);
-
    -
    - -

    -Update 20.7.11.3.3 [unique.ptr.runtime.modifiers] -

    - -
    -
    void reset(pointer p = pointer());
-void reset(nullptr_t);
-
    - -

    --1- Requires: Does not accept pointer types which are convertible -to pointer (diagnostic -required). [Note: One implementation technique is to create a private -templated overload. -- end note] -

    -

    -Effects: If get() == nullptr there are no effects. Otherwise get_deleter()(get()). -

    -

    ...

    -
    - -

    [ -Note this wording incorporates resolutions for 806 (New) and 673 (Ready). -]

    - - - - - - -
    -

    822. Object with explicit copy constructor no longer CopyConstructible

    -

    Section: 20.1.1 [utility.arg.requirements] Status: New - Submitter: James Kanze Date: 2008-04-01

    -

    View other active issues in [utility.arg.requirements].

    -

    View all other issues in [utility.arg.requirements].

    -

    View all issues with New status.

    -

    Discussion:

    -

    -I just noticed that the following program is legal in C++03, but -is forbidden in the current draft: -

    - -
    #include <vector>
-#include <iostream>
-
-class Toto
-{
-public:
-    Toto() {}
-    explicit Toto( Toto const& ) {}
-} ;
-
-int
-main()
-{
-    std::vector< Toto > v( 10 ) ;
-    return 0 ;
-}
-
    - -

    -Is this change intentional? (And if so, what is the -justification? I wouldn't call such code good, but I don't see -any reason to break it unless we get something else in return.) -

    - - - -

    Proposed resolution:

    -

    -In 20.1.1 [utility.arg.requirements] change Table 33: MoveConstructible requirements [moveconstructible]: -

    - -
    - - - - - - - - - - -
    expressionpost-condition
    T t(rv) = rvt is equivalent to the value of rv before the construction
    ...
    -
    - -

    -In 20.1.1 [utility.arg.requirements] change Table 34: CopyConstructible requirements [copyconstructible]: -

    - -
    - - - - - - - - - - -
    expressionpost-condition
    T t(u) = uthe value of u is unchanged and is equivalent to t
    ...
    -
    - - - - - -
    -

    823. identity<void> seems broken

    -

    Section: 20.2.2 [forward] Status: Review - Submitter: Walter Brown Date: 2008-04-09

    -

    View other active issues in [forward].

    -

    View all other issues in [forward].

    -

    View all issues with Review status.

    -

    Discussion:

    -

    -N2588 seems to have added an operator() member function to the -identity<> helper in 20.2.2 [forward]. I believe this change makes it no -longer possible to instantiate identity<void>, as it would require -forming a reference-to-void type as this operator()'s parameter type. -

    - -

    -Suggested resolution: Specialize identity<void> so as not to require -the member function's presence. -

    - -

    [ -Sophia Antipolis: -]

    - - -
    -

    -Jens: suggests to add a requires clause to avoid specializing on void. -

    -

    -Alisdair: also consider cv-qualified void. -

    -

    -Alberto provided proposed wording. -

    -
    - - -

    Proposed resolution:

    -

    -Change definition of identity in 20.2.2 [forward], paragraph 2, to: -

    - -
    template <class T>  struct identity {
-    typedef T type;
-
-    requires ReferentType<T>
-      const T& operator()(const T& x) const;
-  };
-
    -

    ...

    -
      requires ReferentType<T>
-    const T& operator()(const T& x) const;
-
    - - -

    Rationale:

    -

    -The point here is to able to write T& given T and ReferentType is -precisely the concept that guarantees so, according to N2677 -(Foundational concepts). Because of this, it seems preferable than an -explicit check for cv void using SameType/remove_cv as it was suggested -in Sophia. In particular, Daniel remarked that there may be types other -than cv void which aren't referent types (int[], perhaps?). -

    - - - - - -
    -

    824. rvalue ref issue with basic_string inserter

    -

    Section: 21.3.8.9 [string.io] Status: Ready - Submitter: Alisdair Meredith Date: 2008-04-10

    -

    View all other issues in [string.io].

    -

    View all issues with Ready status.

    -

    Discussion:

    -

    -In the current working paper, the <string> header synopsis at the end of -21.2 [string.classes] lists a single operator<< overload -for basic_string. -

    - -
    template<class charT, class traits, class Allocator>
- basic_ostream<charT, traits>&
-   operator<<(basic_ostream<charT, traits>&& os,
-              const basic_string<charT,traits,Allocator>& str);
-
    - -

    -The definition in 21.3.8.9 [string.io] lists two: -

    - -
    template<class charT, class traits, class Allocator>
- basic_ostream<charT, traits>&
-   operator<<(basic_ostream<charT, traits>& os,
-              const basic_string<charT,traits,Allocator>& str);
-
-template<class charT, class traits, class Allocator>
- basic_ostream<charT, traits>&
-   operator<<(basic_ostream<charT, traits>&& os,
-              const basic_string<charT,traits,Allocator>& str);
-
    - -

    -I believe the synopsis in 21.2 [string.classes] is correct, and the first of the two -signatures in 21.3.8.9 [string.io] should be deleted. -

    - - -

    Proposed resolution:

    -

    -Delete the first of the two signatures in 21.3.8.9 [string.io]: -

    - -
    template<class charT, class traits, class Allocator>
- basic_ostream<charT, traits>&
-   operator<<(basic_ostream<charT, traits>& os,
-              const basic_string<charT,traits,Allocator>& str);
-
-template<class charT, class traits, class Allocator>
- basic_ostream<charT, traits>&
-   operator<<(basic_ostream<charT, traits>&& os,
-              const basic_string<charT,traits,Allocator>& str);
-
    - - - - - -
    -

    825. Missing rvalues reference stream insert/extract operators?

    -

    Section: 19.4.2.1 [syserr.errcode.overview], 20.7.12.2.8 -[util.smartptr.shared.io], 22.2.8 [facets.examples], 23.3.5.3 -[bitset.operators], 26.3.6 [complex.ops], 27.5 [stream.buffers], 28.9 -[re.submatch] Status: Open - Submitter: Alisdair Meredith Date: 2008-04-10

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -Should the following use rvalues references to stream in insert/extract -operators? -

    - -
      -
    • 19.4.2.1 [syserr.errcode.overview]
      • -
    • 20.7.12.2.8 [util.smartptr.shared.io]
      • -
    • 22.2.8 [facets.examples]
      • -
    • 23.3.5.3 [bitset.operators]
      • -
    • 26.3.6 [complex.ops]
      • -
    • Doubled signatures in 27.5 [stream.buffers] for character inserters -(ref 27.6.2.6.4 [ostream.inserters.character]) -+ definition 27.6.2.6.4 [ostream.inserters.character]
      • -
    • 28.9 [re.submatch]
      • -
    - -

    [ -Sophia Antipolis -]

    - - -
    -Agree with the idea in the issue, Alisdair to provide wording. -
    - - - -

    Proposed resolution:

    -

    -

    - - - - - -
    -

    827. constexpr shared_ptr::shared_ptr()?

    -

    Section: 20.7.12.2.1 [util.smartptr.shared.const] Status: New - Submitter: Peter Dimov Date: 2008-04-11

    -

    View all other issues in [util.smartptr.shared.const].

    -

    View all issues with New status.

    -

    Discussion:

    -

    -Would anyone object to making the default constructor of shared_ptr (and -weak_ptr and enable_shared_from_this) constexpr? This would enable -static initialization for shared_ptr variables, eliminating another -unfair advantage of raw pointers. -

    - - -

    Proposed resolution:

    -

    -

    - - - - - -
    -

    828. Static initialization for std::mutex?

    -

    Section: 30.3.1.1 [thread.mutex.class] Status: Review - Submitter: Peter Dimov Date: 2008-04-18

    -

    View all issues with Review status.

    -

    Discussion:

    -

    -[Note: I'm assuming here that 3.6.2 [basic.start.init]/1 will be fixed.] -

    -

    -Currently std::mutex doesn't support static initialization. This is a -regression with respect to pthread_mutex_t, which does. I believe that -we should strive to eliminate such regressions in expressive power where -possible, both to ease migration and to not provide incentives to (or -force) people to forego the C++ primitives in favor of pthreads. -

    - -

    [ -Sophia Antipolis: -]

    - - -
    -

    -We believe this is implementable on POSIX, because the initializer-list -feature and the constexpr feature make this work. Double-check core -language about static initialization for this case. Ask core for a core -issue about order of destruction of statically-initialized objects wrt. -dynamically-initialized objects (should come afterwards). Check -non-POSIX systems for implementability. -

    -

    -If ubiquitous implementability cannot be assured, plan B is to introduce -another constructor, make this constexpr, which is -conditionally-supported. To avod ambiguities, this new constructor needs -to have an additional parameter. -

    -
    - - -

    Proposed resolution:

    -

    -Change 30.3.1.1 [thread.mutex.class]: -

    - -
    class mutex { 
-public: 
-  constexpr mutex(); 
-  ...
-
    - - - - - -
    -

    829. current_exception wording unclear about exception type

    -

    Section: 18.7.5 [propagation] Status: Ready - Submitter: Beman Dawes Date: 2008-04-20

    -

    View other active issues in [propagation].

    -

    View all other issues in [propagation].

    -

    View all issues with Ready status.

    -

    Discussion:

    -

    Consider this code:

    - -
    -
    exception_ptr xp;
    -
    try {do_something(); }
-
-catch (const runtime_error& ) {xp = current_exception();}
-
-...
-
-rethrow_exception(xp);
    -
    - -

    -Say do_something() throws an exception object of type -range_error. What is the type of the exception object thrown by -rethrow_exception(xp) above? It must have a type of range_error; -if it were of type runtime_error it still isn't possible to -propagate an exception and the exception_ptr/current_exception/rethrow_exception -machinery serves no useful purpose. -

    - -

    -Unfortunately, the current wording does not explicitly say that. Different -people read the current wording and come to different conclusions. While it may -be possible to deduce the correct type from the current wording, it would be -much clearer to come right out and explicitly say what the type of the referred -to exception is. -

    - -

    [ -Peter adds: -]

    - - -
    -

    -I don't like the proposed resolution of 829. The normative text is -unambiguous that the exception_ptr refers to the currently handled -exception. This term has a standard meaning, see 15.3 [except.handle]/8; this is the -exception that throw; would rethrow, see 15.1 [except.throw]/7. -

    -

    -A better way to address this is to simply add the non-normative example -in question as a clarification. The term currently handled exception -should be italicized and cross-referenced. A [Note: the currently -handled exception is the exception that a throw expression without an -operand (15.1 [except.throw]/7) would rethrow. --end note] is also an option. -

    -
    - - - -

    Proposed resolution:

    - -

    -After 18.7.5 [propagation] , paragraph 7, add the indicated text: -

    - -
    -
    exception_ptr current_exception();
    - -
    -

    -Returns: exception_ptr object that refers -to the currently handled exception (15.3 [except.handle]) or a copy of the currently handled -exception, or a null exception_ptr object if no exception is being handled. If -the function needs to allocate memory and the attempt fails, it returns an -exception_ptr object that refers to an instance of bad_alloc. -It is unspecified whether the return values of two successive calls to -current_exception refer to the same exception object. -[Note: that is, it -is unspecified whether current_exception -creates a new copy each time it is called. --- end note] -

    - -

    -Throws: nothing. -

    - -
    -
    - - - - - - -
    -

    830. Incomplete list of char_traits specializations

    -

    Section: 21.1 [char.traits] Status: Open - Submitter: Dietmar Kühl Date: 2008-04-23

    -

    View all other issues in [char.traits].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    - Paragraph 4 of 21.1 [char.traits] mentions that this - section specifies two specializations (char_traits<char> - and (char_traits<wchar_t>). However, there are actually - four specializations provided, i.e. in addition to the two above also - char_traits<char16_t> and char_traits<char32_t>). - I guess this was just an oversight and there is nothing wrong with just - fixing this. -

    - -

    [ -Alisdair adds: -]

    - -
    -char_traits< char16/32_t > -should also be added to <ios_fwd> in 27.2 [iostream.forward], and all the specializations -taking a char_traits parameter in that header. -
    - -

    [ -Sophia Antipolis: -]

    - - -
    -

    -Idea of the issue is ok. -

    -

    -Alisdair to provide wording, once that wording arrives, move to review. -

    -
    - - - -

    Proposed resolution:

    -

    - Replace paragraph 4 of 21.1 [char.traits] by: -

    -
    -

    - This subclause specifies a struct template, char_traits<charT>, - and four explicit specializations of it, char_traits<char>, - char_traits<char16_t>, char_traits<char32_t>, and - char_traits<wchar_t>, all of which appear in the header - <string> and satisfy the requirements below. -

    -
    - - - - - -
    -

    832. Applying constexpr to System error support

    -

    Section: 19.4 [syserr] Status: Open - Submitter: Beman Dawes Date: 2008-05-14

    -

    View other active issues in [syserr].

    -

    View all other issues in [syserr].

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -Initialization of objects of class error_code -(19.4.2 [syserr.errcode]) and class -error_condition (19.4.3 [syserr.errcondition]) can be made simpler and more reliable by use of -the new constexpr feature -[N2349] -of C++0x. Less code will need to be -generated for both library implementations and user programs when -manipulating constant objects of these types. -

    - -

    -This was not proposed originally because the constant expressions -proposal was moving into the standard at about the same time as the -Diagnostics Enhancements proposal -[N2241], -and it wasn't desirable to -make the later depend on the former. There were also technical concerns -as to how constexpr would apply to references. Those concerns are now -resolved; constexpr can't be used for references, and that fact is -reflected in the proposed resolution. -

    - -

    -Thanks to Jens Maurer, Gabriel Dos Reis, and Bjarne Stroustrup for clarification of constexpr requirements. -

    - -

    -LWG issue 804 is related in that it raises the question of whether the -exposition only member cat_ of class error_code (19.4.2 [syserr.errcode]) and class -error_condition (19.4.3 [syserr.errcondition]) should be presented as a reference or pointer. -While in the context of 804 that is arguably an editorial question, -presenting it as a pointer becomes more or less required with this -proposal, given constexpr does not play well with references. The -proposed resolution thus changes the private member to a pointer, which -also brings it in sync with real implementations. -

    - -

    [ -Sophia Antipolis: -]

    - - -
    -On going question of extern pointer vs. inline functions for interface. -
    - -

    [ -Pre-San Francisco: -]

    - - -
    -

    -Beman Dawes reports that this proposal is unimplementable, and thus NAD. -

    -

    -Implementation would require constexpr objects of classes derived -from class error_category, which has virtual functions, and that is -not allowed by the core language. This was determined when trying to -implement the proposal using a constexpr enabled compiler provided -by Gabriel Dos Reis, and subsequently verified in discussions with -Gabriel and Jens Maurer. -

    - -
    - - -

    Proposed resolution:

    -

    -The proposed wording assumes the LWG 805 proposed wording has been -applied to the WP, resulting in the former posix_category being renamed -generic_category. If 805 has not been applied, the names in this -proposal must be adjusted accordingly. -

    - -

    -Change 19.4.1.1 [syserr.errcat.overview] Class -error_category overview error_category synopsis as -indicated: -

    - -
    const error_category& get_generic_category();
-const error_category& get_system_category();
-
-static extern const error_category&* const generic_category = get_generic_category();
-static extern const error_category&* const native_category system_category = get_system_category();
-
    - -

    -Change 19.4.1.5 [syserr.errcat.objects] Error category objects as indicated: -

    - -
    -
    extern const error_category&* const get_generic_category();
-
    -

    -Returns: A reference generic_category shall point -to an a statically initialized object of a type derived from -class error_category. -

    - -

    -Remarks: The object's default_error_condition and equivalent virtual -functions shall behave as specified for the class error_category. The -object's name virtual function shall return a pointer to the string -"GENERIC". -

    - -
    extern const error_category&* const get_system_category();
-
    - -

    -Returns: A reference system_category shall point -to an a statically -initialized object of a type derived from class error_category. -

    - -

    -Remarks: The object's equivalent virtual functions shall behave as -specified for class error_category. The object's name virtual function -shall return a pointer to the string "system". The object's -default_error_condition virtual function shall behave as follows: -

    - -

    -If the argument ev corresponds to a POSIX errno value posv, the function -shall return error_condition(posv, generic_category). Otherwise, the -function shall return error_condition(ev, system_category). What -constitutes correspondence for any given operating system is -unspecified. [Note: The number of potential system error codes is large -and unbounded, and some may not correspond to any POSIX errno value. -Thus implementations are given latitude in determining correspondence. --- end note] -

    -
    - -

    -Change 19.4.2.1 [syserr.errcode.overview] Class error_code overview as indicated: -

    - -
    class error_code {
-public:
-  ...;
-  constexpr error_code(int val, const error_category&* cat);
-  ...
-  void assign(int val, const error_category&* cat);
-  ...
-  const error_category&* category() const;
-  ...
-private:
-  int val_;                    // exposition only
-  const error_category&* cat_; // exposition only
-
    - -

    -Change 19.4.2.2 [syserr.errcode.constructors] Class error_code constructors as indicated: -

    - -
    -
    constexpr error_code(int val, const error_category&* cat);
-
    -

    -Effects: Constructs an object of type error_code. -

    -

    -Postconditions: val_ == val and cat_ == cat. -

    -

    -Throws: Nothing. -

    -
    - -

    -Change 19.4.2.3 [syserr.errcode.modifiers] Class error_code modifiers as indicated: -

    - -
    -
    void assign(int val, const error_category&* cat);
-
    -

    -Postconditions: val_ == val and cat_ == cat. -

    -

    -Throws: Nothing. -

    -
    - -

    -Change 19.4.2.4 [syserr.errcode.observers] Class error_code observers as indicated: -

    - -
    -
    const error_category&* category() const;
-
    - -

    -Returns: cat_. -

    -

    -Throws: Nothing. -

    -
    - -

    -Change 19.4.3.1 [syserr.errcondition.overview] Class error_condition overview as indicated: -

    - -
    -
    class error_condition {
-public:
-  ...;
-  constexpr error_condition(int val, const error_category&* cat);
-  ...
-  void assign(int val, const error_category&* cat);
-  ...
-  const error_category&* category() const;
-  ...
-private:
-  int val_;                    // exposition only
-  const error_category&* cat_; // exposition only
-
    -
    - -

    -Change 19.4.3.2 [syserr.errcondition.constructors] Class error_condition constructors as indicated: -

    - -
    -
    constexpr error_condition(int val, const error_category&* cat);
-
    -

    -Effects: Constructs an object of type error_condition. -

    -

    -Postconditions: val_ == val and cat_ == cat. -

    -

    -Throws: Nothing. -

    -
    - -

    -Change 19.4.3.3 [syserr.errcondition.modifiers] Class error_condition modifiers as indicated: -

    - -
    -
    void assign(int val, const error_category&* cat);
-
    -

    -Postconditions: val_ == val and cat_ == cat. -

    -

    -Throws: Nothing. -

    -
    - -

    -Change 19.4.3.4 [syserr.errcondition.observers] Class error_condition observers as indicated: -

    - -
    -
    const error_category&* category() const;
-
    -

    -Returns: cat_. -

    -

    -Throws: Nothing. -

    -
    - -

    -Throughout 19.4 [syserr] System error support, change "category()." to "category()->". -Appears approximately six times. -

    - -

    -[Partially Editorial] In 19.4.4 [syserr.compare] Comparison operators, -paragraphs 2 and 4, change "category.equivalent(" to -"category()->equivalent(". -

    - -

    -Change 19.4.5.1 [syserr.syserr.overview] Class system_error overview as indicated: -

    - -
    public:
-  system_error(error_code ec, const string& what_arg);
-  system_error(error_code ec);
-  system_error(int ev, const error_category&* ecat,
-      const string& what_arg);
-  system_error(int ev, const error_category&* ecat);
-
    - -

    -Change 19.4.5.2 [syserr.syserr.members] Class system_error members as indicated: -

    - -
    -
    system_error(int ev, const error_category&* ecat, const string& what_arg);
-
    -
    -

    -Effects: Constructs an object of class system_error. -

    -

    -Postconditions: code() == error_code(ev, ecat) and -strcmp(runtime_error::what(), what_arg.c_str()) == 0. -

    -
    - -
    system_error(int ev, const error_category&* ecat);
-
    -
    -

    -Effects: Constructs an object of class system_error. -

    -

    -Postconditions: code() == error_code(ev, ecat) and -strcmp(runtime_error::what(), "") == 0. -

    -
    -
    - - - - - - -
    -

    833. Freestanding implementations header list needs review for C++0x

    -

    Section: 17.4.1.3 [compliance] Status: Open - Submitter: Beman Dawes Date: 2008-05-14

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -Once the C++0x standard library is feature complete, the LWG needs to -review 17.4.1.3 [compliance] Freestanding implementations header list to -ensure it reflects LWG consensus. -

    - - -

    Proposed resolution:

    - - - - - -
    -

    834. Unique_ptr::pointer requirements underspecified

    -

    Section: 20.7.11.2 [unique.ptr.single] Status: Open - Submitter: Daniel Krügler Date: 2008-05-14

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -Issue 673 (including recent updates by 821) proposes a useful -extension point for unique_ptr by granting support for an optional -deleter_type::pointer to act as pointer-like replacement for element_type* -(In the following: pointer). -

    -

    -Unfortunately no requirements are specified for the type pointer which has -impact on at least two key features of unique_ptr: -

    - -
      -
    1. Operational fail-safety.
      2. -
    2. (Well-)Definedness of expressions.
      3. -
    - -

    -Unique_ptr specification makes great efforts to require that essentially *all* -operations cannot throw and therefore adds proper wording to the affected -operations of the deleter as well. If user-provided pointer-emulating types -("smart pointers") will be allowed, either *all* throw-nothing clauses have to -be replaced by weaker "An exception is thrown only if pointer's {op} throws -an exception"-clauses or it has to be said explicitly that all used -operations of -pointer are required *not* to throw. I understand the main focus of unique_ptr -to be as near as possible to the advantages of native pointers which cannot -fail and thus strongly favor the second choice. Also, the alternative position -would make it much harder to write safe and simple template code for -unique_ptr. Additionally, I assume that a general statement need to be given -that all of the expressions of pointer used to define semantics are required to -be well-formed and well-defined (also as back-end for 762). -

    - -

    [ -Sophia Antipolis: -]

    - - -
    -

    -Howard: We maybe need a core concept PointerLike, but we don't need the -arithmetic (see shared_ptr vs. vector<T>::iterator. -

    -

    -Howard will go through and enumerate the individual requirements wrt. pointer for each member function. -

    -
    - - - -

    Proposed resolution:

    -

    -Add the following sentence just at the end of the newly proposed -20.7.11.2 [unique.ptr.single]/p. 3: -

    - -
    -unique_ptr<T, D>::pointer's operations shall be well-formed, shall have well -defined behavior, and shall not throw exceptions. -
    - - - - - -
    -

    835. tying two streams together (correction to DR 581)

    -

    Section: 27.4.4.2 [basic.ios.members] Status: New - Submitter: Martin Sebor Date: 2008-05-17

    -

    View other active issues in [basic.ios.members].

    -

    View all other issues in [basic.ios.members].

    -

    View all issues with New status.

    -

    Discussion:

    -

    - -The fix for -issue 581, -now integrated into the working paper, overlooks a couple of minor -problems. - -

    -

    - -First, being an unformatted function once again, flush() -is required to create a sentry object whose constructor must, among -other things, flush the tied stream. When two streams are tied -together, either directly or through another intermediate stream -object, flushing one will also cause a call to flush() on -the other tied stream(s) and vice versa, ad infinitum. The program -below demonstrates the problem. - -

    -

    - -Second, as Bo Persson notes in his -comp.lang.c++.moderated post, -for streams with the unitbuf flag set such -as std::stderr, the destructor of the sentry object will -again call flush(). This seems to create an infinite -recursion for std::cerr << std::flush; - -

    -
    - 
    #include <iostream>
-
-int main ()
-{
-   std::cout.tie (&std::cerr);
-   std::cerr.tie (&std::cout);
-   std::cout << "cout\n";
-   std::cerr << "cerr\n";
-} 
-
    -
    - -

    Proposed resolution:

    -

    - -I think an easy way to plug the first hole is to add a requires clause -to ostream::tie(ostream *tiestr) requiring the this -pointer not be equal to any pointer on the list starting -with tiestr->tie() -through tiestr()->tie()->tie() and so on. I am not -proposing that we require implementations to traverse this list, -although I think we could since the list is unlikely to be very long. - -

    -

    - -Add a Requires clause to 27.4.4.2 [basic.ios.members] withethe following -text: - -

    -
    - -Requires: If (tiestr != 0) is -true, tiestr must not be reachable by traversing the -linked list of tied stream objects starting -from tiestr->tie(). - -
    -

    - -In addition, to prevent the infinite recursion that Bo writes about in -his comp.lang.c++.moderated post, I propose to change -27.6.2.4 [ostream::sentry], p2 like so: - -

    -
    - -If ((os.flags() & ios_base::unitbuf) && -!uncaught_exception()) is true, -calls os.flush() os.rdbuf()->pubsync(). - -
    - - - - -
    -

    836. - effects of money_base::space and - money_base::none on money_get -

    -

    Section: 22.2.6.1.2 [locale.money.get.virtuals] Status: New - Submitter: Martin Sebor Date: 2008-05-17

    -

    View other active issues in [locale.money.get.virtuals].

    -

    View all other issues in [locale.money.get.virtuals].

    -

    View all issues with New status.

    -

    Duplicate of: 670

    -

    Discussion:

    -

    - -In paragraph 2, 22.2.6.1.2 [locale.money.get.virtuals] specifies the following: - -

    -
    - -Where space or none appears in the format -pattern, except at the end, optional white space (as recognized -by ct.is) is consumed after any required space. - -
    -

    - -This requirement can be (and has been) interpreted two mutually -exclusive ways by different readers. One possible interpretation -is that: - -

    -
    -
      -
    1. - -where money_base::space appears in the format, at least -one space is required, and - -
      2. -
    2. - -where money_base::none appears in the format, space is -allowed but not required. - -
      3. -
    -
    -

    - -The other is that: - -

    -
    - -where either money_base::space or money_base::none appears in the format, white space is optional. - -
    - - -

    Proposed resolution:

    -

    - -I propose to change the text to make it clear that the first -interpretation is intended, that is, to make following change to -22.2.6.1.2 [locale.money.get.virtuals], p2: - -

    - -
    - -When money_base::space -or money_base::none appears as the last -element in the format pattern, except at the end, optional -white space (as recognized by ct.is) is consumed after -any required space. no white space is consumed. Otherwise, -where money_base::space appears in any of the initial -elements of the format pattern, at least one white space character is -required. Where money_base::none appears in any of the -initial elements of the format pattern, white space is allowed but not -required. In either case, any required followed by all optional white -space (as recognized by ct.is()) is consumed. -If (str.flags() & str.showbase) is false, ... - -
    - - - - -
    -

    837. - basic_ios::copyfmt() overly loosely specified -

    -

    Section: 27.4.4.2 [basic.ios.members] Status: New - Submitter: Martin Sebor Date: 2008-05-17

    -

    View other active issues in [basic.ios.members].

    -

    View all other issues in [basic.ios.members].

    -

    View all issues with New status.

    -

    Discussion:

    -

    - -The basic_ios::copyfmt() member function is specified in 27.4.4.2 [basic.ios.members] to have the following effects: - -

    -
    - -Effects: If (this == &rhs) does -nothing. Otherwise assigns to the member objects of *this -the corresponding member objects of rhs, except that - -
      -
    • - -rdstate() and rdbuf() are left unchanged; - -
      • -
    • - -exceptions() is altered last by -calling exceptions(rhs.except) - -
      • -
    • - -the contents of arrays pointed at by pword -and iword are copied not the pointers themselves - -
      • -
    -
    -

    - -Since the rest of the text doesn't specify what the member objects -of basic_ios are this seems a little too loose. - -

    - - -

    Proposed resolution:

    -

    - -I propose to tighten things up by adding a Postcondition clause -to the function like so: - -

    -
    - Postconditions: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    copyfmt() postconditions
    ElementValue
    rdbuf()unchanged
    tie()rhs.tie()
    rdstate()unchanged
    exceptions()rhs.exceptions()
    flags()rhs.flags()
    width()rhs.width()
    precision()rhs.precision()
    fill()rhs.fill()
    getloc()rhs.getloc()
    -
    -

    - -The format of the table follows Table 117 (as -of N2588): basic_ios::init() -effects. - -

    -

    - -The intent of the new table is not to impose any new requirements or -change existing ones, just to be more explicit about what I believe is -already there. - -

    - - - - -
    -

    838. - can an end-of-stream iterator become a non-end-of-stream one? -

    -

    Section: 24.5.1 [istream.iterator] Status: New - Submitter: Martin Sebor Date: 2008-05-17

    -

    View other active issues in [istream.iterator].

    -

    View all other issues in [istream.iterator].

    -

    View all issues with New status.

    -

    Discussion:

    -

    - -From message c++std-lib-20003... - -

    -

    - -The description of istream_iterator in -24.5.1 [istream.iterator], p1 specifies that objects of the -class become the end-of-stream (EOS) iterators under the -following condition (see also issue 836 another problem -with this paragraph): - -

    -
    - -If the end of stream is reached (operator void*() on the -stream returns false), the iterator becomes equal to -the end-of-stream iterator value. - -
    -

    - -One possible implementation approach that has been used in practice is -for the iterator to set its in_stream pointer to 0 when -it reaches the end of the stream, just like the default ctor does on -initialization. The problem with this approach is that -the Effects clause for operator++() says the -iterator unconditionally extracts the next value from the stream by -evaluating *in_stream >> value, without checking -for (in_stream == 0). - -

    -

    - -Conformance to the requirement outlined in the Effects clause -can easily be verified in programs by setting eofbit -or failbit in exceptions() of the associated -stream and attempting to iterate past the end of the stream: each -past-the-end access should trigger an exception. This suggests that -some other, more elaborate technique might be intended. - -

    -

    - -Another approach, one that allows operator++() to attempt -to extract the value even for EOS iterators (just as long -as in_stream is non-0) is for the iterator to maintain a -flag indicating whether it has reached the end of the stream. This -technique would satisfy the presumed requirement implied by -the Effects clause mentioned above, but it isn't supported by -the exposition-only members of the class (no such flag is shown). This -approach is also found in existing practice. - -

    -

    - -The inconsistency between existing implementations raises the question -of whether the intent of the specification is that a non-EOS iterator -that has reached the EOS become a non-EOS one again after the -stream's eofbit flag has been cleared? That is, are the -assertions in the program below expected to pass? - -

    -
    - 
       sstream strm ("1 ");
-   istream_iterator eos;
-   istream_iterator it (strm);
-   int i;
-   i = *it++
-   assert (it == eos);
-   strm.clear ();
-   strm << "2 3 ";
-   assert (it != eos);
-   i = *++it;
-   assert (3 == i);
-
    -
    -

    - -Or is it intended that once an iterator becomes EOS it stays EOS until -the end of its lifetime? - -

    - - -

    Proposed resolution:

    -

    - -The discussion of this issue on the reflector suggests that the intent -of the standard is for an istreambuf_iterator that has -reached the EOS to remain in the EOS state until the end of its -lifetime. Implementations that permit EOS iterators to return to a -non-EOS state may only do so as an extension, and only as a result of -calling istream_iterator member functions on EOS -iterators whose behavior is in this case undefined. - -

    -

    - -To this end we propose to change 24.5.1 [istream.iterator], p1, -as follows: - -

    -
    - -The result of operator-> on an end-of-stream -is not defined. For any other iterator value a const T* -is returned. Invoking operator++() on -an end-of-stream iterator is undefined. It is impossible -to store things into istream iterators... - -
    -

    - -Add pre/postconditions to the member function descriptions of istream_iterator like so: - -

    -
    - -
    istream_iterator();
    - -Effects: Constructs the end-of-stream iterator.
    -Postcondition: in_stream == 0. - -
    istream_iterator(istream_type &s);
    - -Effects: Initializes in_stream with &s. value -may be initialized during construction or the first time it is -referenced.
    -Postcondition: in_stream == &s. - -
    istream_iterator(const istream_iterator &x);
    - -Effects: Constructs a copy of x.
    -Postcondition: in_stream == x.in_stream. - -
    istream_iterator& operator++();
    - -Requires: in_stream != 0.
    -Effects: *in_stream >> value. - -
    istream_iterator& operator++(int);
    - -Requires: in_stream != 0.
    -Effects: - 
    istream_iterator tmp (*this);
-*in_stream >> value;
-return tmp;
-
    -
    -
    - - - - -
    -

    839. Maps and sets missing splice operation

    -

    Section: 23.3 [associative], 23.4 [unord] Status: Open - Submitter: Alan Talbot Date: 2008-05-18

    -

    View all issues with Open status.

    -

    Discussion:

    -

    -Splice is a very useful feature of list. This functionality is also very -useful for any other node based container, and I frequently wish it were -available for maps and sets. It seems like an omission that these -containers lack this capability. Although the complexity for a splice is -the same as for an insert, the actual time can be much less since the -objects need not be reallocated and copied. When the element objects are -heavy and the compare operations are fast (say a map<int, huge_thingy>) -this can be a big win. -

    - -

    -Suggested resolution: -

    - -

    -Add the following signatures to map, set, multimap, multiset, and the unordered associative containers: -

    -
     
-void splice(list<T,Allocator>&& x);
-void splice(list<T,Allocator>&& x, const_iterator i);
-void splice(list<T,Allocator>&& x, const_iterator first, const_iterator last);
-
    - -

    -Hint versions of these are also useful to the extent hint is useful. -(I'm looking for guidance about whether hints are in fact useful.) -

    - -
     
-void splice(const_iterator position, list<T,Allocator>&& x);
-void splice(const_iterator position, list<T,Allocator>&& x, const_iterator i);
-void splice(const_iterator position, list<T,Allocator>&& x, const_iterator first, const_iterator last);
-
    - -

    [ -Sophia Antipolis: -]

    - - -
    -

    -Don't try to splice "list" into the other containers, it should be container-type. -

    -

    -forward_list already has splice_after. -

    -

    -Would "splice" make sense for an unordered_map? -

    -

    -Jens, Robert: "splice" is not the right term, it implies maintaining ordering in lists. -

    -

    -Howard: adopt? -

    -

    -Jens: absorb? -

    -

    -Alan: subsume? -

    -

    -Robert: recycle? -

    -

    -Howard: transfer? (but no direction) -

    -

    -Jens: transfer_from. No. -

    -

    -Alisdair: Can we give a nothrow guarantee? If your compare() and hash() doesn't throw, yes. -

    -

    -Daniel: For unordered_map, we can't guarantee nothrow. -

    -
    - - - -

    Proposed resolution:

    - - - - - -
    -

    841. cstdint.syn inconsistent with C99

    -

    Section: 18.3.1 [cstdint.syn] Status: New - Submitter: Martin Sebor Date: 2008-05-17

    -

    View all other issues in [cstdint.syn].

    -

    View all issues with New status.

    -

    Discussion:

    -

    - -In specifying the names of macros and types defined in -header <stdint.h>, C99 makes use of the -symbol N to accommodate unusual platforms with -word sizes that aren't powers of two. C99 -permits N to take on any positive integer value -(including, for example, 24). - -

    -

    - -In cstdint.syn Header <cstdint> -synopsis, C++ on the other hand, fixes the value -of N to 8, 16, 32, and 64, and specifies only -types with these exact widths. - -

    -

    -

    - -In addition, paragraph 1 of the same section makes use of a rather -informal shorthand notation to specify sets of macros. When -interpreted strictly, the notation specifies macros such -as INT_8_MIN that are not intended to be specified. - -

    - -Finally, the section is missing the usual table of symbols defined -in that header, making it inconsistent with the rest of the -specification. - -

    - -

    Proposed resolution:

    -

    - -I propose to use the same approach in the C++ spec as C99 uses, that -is, to specify the header synopsis in terms of "exposition only" types -that make use of the symbol N to denote one or -more of a theoretically unbounded set of widths. - -

    -

    - -Further, I propose to add a new table to section listing the symbols -defined in the header using a more formal notation that avoids -introducing inconsistencies. - -

    -

    - -To this effect, in cstdint.syn -Header <cstdint> synopsis, replace both the -synopsis and paragraph 1 with the following text: - -

    -
    -

    -

      -
    1. - -In the names defined in the <cstdint> header, the -symbol N represents a positive decimal integer -with no leading zeros (e.g., 8 or 24, but not 0, 04, or 048). With the -exception of exact-width types, macros and types for values -of N in the set of 8, 16, 32, and 64 are -required. Exact-width types, and any macros and types for values -of N other than 8, 16, 32, and 64 are -optional. However, if an implementation provides integer types with -widths of 8, 16, 32, or 64 bits, the corresponding exact-width types -and macros are required. - -
      2. -
    - - 
    namespace std {
-
-   // required types
-
-   // Fastest minimum-width integer types
-   typedef signed integer type   int_fast8_t;
-   typedef signed integer type   int_fast16_t;
-   typedef signed integer type   int_fast32_t;
-   typedef signed integer type   int_fast64_t;
-
-   typedef unsigned integer type uint_fast8_t;
-   typedef unsigned integer type uint_fast16_t;
-   typedef unsigned integer type uint_fast32_t;
-   typedef unsigned integer type uint_fast64_t;
-
-   // Minimum-width integer types
-   typedef signed integer type   int_least8_t;
-   typedef signed integer type   int_least16_t;
-   typedef signed integer type   int_least32_t;
-   typedef signed integer type   int_least64_t;
-
-   typedef unsigned integer type uint_least8_t;
-   typedef unsigned integer type uint_least16_t;
-   typedef unsigned integer type uint_least32_t;
-   typedef unsigned integer type uint_least64_t;
-
-   // Greatest-width integer types
-   typedef signed integer type   intmax_t;
-   typedef unsigned integer type uintmax_t;
-
-   // optionally defined types
-
-   // Exact-width integer types
-   typedef signed integer type   intN_t;
-   typedef unsigned integer type uintN_t;
-
-   // Fastest minimum-width integer types for values
-   // of N other than 8, 16, 32, and 64
-   typedef signed integer type   uint_fastN_t;
-   typedef unsigned integer type uint_fastN_t;
-
-   // Minimum-width integer types for values
-   // of N other than 8, 16, 32, and 64
-   typedef signed integer type   uint_leastN_t;
-   typedef unsigned integer type uint_leastN_t;
-
-   // Integer types capable of holding object pointers
-   typedef signed integer type   intptr_t;
-   typedef signed integer type   intptr_t;
-
-}
    -
    -

    - -[Note to editor: Remove all of the existing paragraph 1 from cstdint.syn.] - -

    -
    - Table ??: Header <cstdint> synopsis - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    TypeName(s)
    Macros:INTN_MININTN_MAXUINTN_MAX
    INT_FASTN_MININT_FASTN_MAXUINT_FASTN_MAX
    INT_LEASTN_MININT_LEASTN_MAXUINT_LEASTN_MAX
    INTPTR_MININTPTR_MAXUINTPTR_MAX
    INTMAX_MININTMAX_MAXUINTMAX_MAX
    PTRDIFF_MINPTRDIFF_MAXPTRDIFF_MAX
    SIG_ATOMIC_MINSIG_ATOMIC_MAXSIZE_MAX
    WCHAR_MINWCHAR_MAX
    WINT_MINWINT_MAX
    INTN_C()UINTN_C()
    INTMAX_C()UINTMAX_C()
    Types:intN_tuintN_t
    int_fastN_tuint_fastN_t
    int_leastN_tuint_leastN_t
    intptr_tuintptr_t
    intmax_tuintmax_t
    -
    - - - - - -
    -

    842. ConstructibleAsElement and bit containers

    -

    Section: 23.1 [container.requirements], 23.2.7 [vector.bool], 23.3.5 [template.bitset] Status: Ready - Submitter: Howard Hinnant Date: 2008-06-03

    -

    View other active issues in [container.requirements].

    -

    View all other issues in [container.requirements].

    -

    View all issues with Ready status.

    -

    Discussion:

    -

    -23.1 [container.requirements]/p3 says: -

    - -
    -Objects stored in these components shall be constructed using -construct_element (20.6.9). For each operation that inserts an -element of type T into a container (insert, -push_back, push_front, emplace, etc.) with -arguments args... T shall be ConstructibleAsElement, -as described in table 88. [Note: If the component is instantiated -with a scoped allocator of type A (i.e., an allocator for which -is_scoped_allocator<A>::value is true), then -construct_element may pass an inner allocator argument to -T's constructor. -- end note] -
    - -

    -However vector<bool, A> (23.2.7 [vector.bool]) and bitset<N> -(23.3.5 [template.bitset]) store bits, not bools, and bitset<N> -does not even have an allocator. But these containers are governed by this clause. Clearly this -is not implementable. -

    - - -

    Proposed resolution:

    -

    -Change 23.1 [container.requirements]/p3: -

    - -
    -Objects stored in these components shall be constructed using -construct_element (20.6.9), unless otherwise specified. -For each operation that inserts an -element of type T into a container (insert, -push_back, push_front, emplace, etc.) with -arguments args... T shall be ConstructibleAsElement, -as described in table 88. [Note: If the component is instantiated -with a scoped allocator of type A (i.e., an allocator for which -is_scoped_allocator<A>::value is true), then -construct_element may pass an inner allocator argument to -T's constructor. -- end note] -
    - -

    -Change 23.2.7 [vector.bool]/p2: -

    - -
    -Unless described below, all operations have the same requirements and semantics as the primary vector template, -except that operations dealing with the bool value type map to bit values in the container storage, -and construct_element (23.1 [container.requirements]) is not used to construct these values. -
    - -

    -Move 23.3.5 [template.bitset] to clause 20. -

    - - - - - - -
    -

    843. Reference Closure

    -

    Section: 20.6.17.1 [func.referenceclosure.cons] Status: New - Submitter: Lawrence Crowl Date: 2008-06-02

    -

    View all issues with New status.

    -

    Discussion:

    -

    -The std::reference_closure type has a deleted copy assignment operator -under the theory that references cannot be assigned, and hence the -assignment of its reference member must necessarily be ill-formed. -

    -

    -However, other types, notably std::reference_wrapper and std::function -provide for the "copying of references", and thus the current definition -of std::reference_closure seems unnecessarily restrictive. In particular, -it should be possible to write generic functions using both std::function -and std::reference_closure, but this generality is much harder when -one such type does not support assignment. -

    -

    -The definition of reference_closure does not necessarily imply direct -implementation via reference types. Indeed, the reference_closure is -best implemented via a frame pointer, for which there is no standard -type. -

    -

    -The semantics of assignment are effectively obtained by use of the -default destructor and default copy assignment operator via -

    - -
    x.~reference_closure(); new (x) reference_closure(y);
-
    - -

    -So the copy assignment operator generates no significant real burden -to the implementation. -

    - - -

    Proposed resolution:

    -

    -In 20.6.17 [func.referenceclosure] Class template reference_closure, -replace the =delete in the copy assignment operator in the synopsis -with =default. -

    - -
    template<class R , class... ArgTypes > 
-  class reference_closure<R (ArgTypes...)> { 
-  public:
-     ...
-     reference_closure& operator=(const reference_closure&) = delete default;
-     ...
-
    - -

    -In 20.6.17.1 [func.referenceclosure.cons] Construct, copy, destroy, -add the member function description -

    - -
    -
    reference_closure& operator=(const reference_closure& f)
-
    -
    -

    -Postcondition: *this is a copy of f. -

    -

    -Returns: *this. -

    -
    -
    - - - - - - - -
    -

    844. complex pow return type is ambiguous

    -

    Section: 26.3.9 [cmplx.over] Status: Ready - Submitter: Howard Hinnant Date: 2008-06-03

    -

    View all issues with Ready status.

    -

    Discussion:

    -

    -The current working draft is in an inconsistent state. -

    - -

    -26.3.8 [complex.transcendentals] says that: -

    - -
    -pow(complex<float>(), int()) returns a complex<float>. -
    - -

    -26.3.9 [cmplx.over] says that: -

    - -
    -pow(complex<float>(), int()) returns a complex<double>. -
    - -

    [ -Sophia Antipolis: -]

    - - -
    -

    -Since int promotes to double, and C99 doesn't have an int-based -overload for pow, the C99 result is complex<double>, see also C99 -7.22, see also library issue 550. -

    -

    -Special note: ask P.J. Plauger. -

    -
    -Looks fine. -
    -
    - - -

    Proposed resolution:

    -

    -Strike this pow overload in 26.3.1 [complex.synopsis] and in 26.3.8 [complex.transcendentals]: -

    - -
    template<class T> complex<T> pow(const complex<T>& x, int y);
-
    - - - - - -
    -

    845. atomics cannot support aggregate initialization

    -

    Section: 29.3 [atomics.types] Status: New - Submitter: Alisdair Meredith Date: 2008-06-03

    -

    View other active issues in [atomics.types].

    -

    View all other issues in [atomics.types].

    -

    View all issues with New status.

    -

    Discussion:

    -

    -The atomic classes (and class templates) are required to support aggregate -initialization (29.3.1 [atomics.types.integral]p2 / 29.3.2 [atomics.types.address]p1) -yet also have user declared constructors, so cannot be aggregates. -

    -

    -This problem might be solved with the introduction of the proposed -initialization syntax at Antipolis, but the wording above should be altered. -Either strike the sentence as redundant with new syntax, or refer to 'brace -initialization'. -

    - -

    [ -Jens adds: -]

    - - -
    -

    -Note that -

    -
    atomic_itype a1 = { 5 };
-
    -

    -would be aggregate-initialization syntax (now coming under the disguise -of brace initialization), but would be ill-formed, because the corresponding -constructor for atomic_itype is explicit. This works, though: -

    -
    atomic_itype a2 { 6 };
-
    - -
    - - -

    Proposed resolution:

    -

    -In 29.3.1 [atomics.types.integral], strike the following sentence from paragraph 2: -

    - -
    -The atomic integral types shall have standard layout. They shall each have a trivial default constructor, a constexpr -explicit value constructor, a deleted copy constructor, a deleted copy assignment operator, and a trivial destructor. -They shall each support aggregate initialization syntax. -
    - -

    [ -2008-08-18, Lawrence adds: -]

    - -
    -The syntactic compatibility of initialization with C is important. -I suggest a different resolution; remove the explicit from the -constructor. For the same reasons we can have implicit conversions, -we can also have implicit constructors. -
    - - - - - -
    -

    846. No definition for constructor

    -

    Section: 29.3 [atomics.types] Status: New - Submitter: Alisdair Meredith Date: 2008-06-03

    -

    View other active issues in [atomics.types].

    -

    View all other issues in [atomics.types].

    -

    View all issues with New status.

    -

    Discussion:

    -

    -The atomic classes and class templates (29.3.1 [atomics.types.integral] / -29.3.2 [atomics.types.address]) have a constexpr -constructor taking a value of the appropriate type for that atomic. -However, neither clause provides semantics or a definition for this -constructor. I'm not sure if the initialization is implied by use of -constexpr keyword (which restricts the form of a constructor) but even if -that is the case, I think it is worth spelling out explicitly as the -inference would be far too subtle in that case. -

    - - -

    Proposed resolution:

    -

    -

    - - - - - -
    -

    847. string exception safety guarantees

    -

    Section: 21.3.1 [string.require] Status: New - Submitter: Hervé Brönnimann Date: 2008-06-05

    -

    View all other issues in [string.require].

    -

    View all issues with New status.

    -

    Discussion:

    -

    -In March, on comp.lang.c++.moderated, I asked what were the -string exception safety guarantees are, because I cannot see -*any* in the working paper, and any implementation I know offers -the strong exception safety guarantee (string unchanged if a -member throws exception). The closest the current draft comes to -offering any guarantees is 21.3 [basic.string], para 3: -

    - -
    -The class template basic_string conforms to the requirements -for a Sequence Container (23.1.1), for a Reversible Container (23.1), -and for an Allocator-aware container (91). The iterators supported by -basic_string are random access iterators (24.1.5). -
    - -

    -However, the chapter 23 only says, on the topic of exceptions: 23.1 [container.requirements], -para 10: -

    - -
    -

    -Unless otherwise specified (see 23.2.2.3 and 23.2.6.4) all container types defined in this clause meet the following -additional requirements: -

    - -
      -
    • if an exception is thrown by...
      • -
    -
    - -

    -I take it as saying that this paragraph has *no* implication on -std::basic_string, as basic_string isn't defined in Clause 23 and -this paragraph does not define a *requirement* of Sequence -nor Reversible Container, just of the models defined in Clause 23. -In addition, LWG Issue 718 proposes to remove 23.1 [container.requirements], para 3. -

    - -

    -Finally, the fact that no operation on Traits should throw -exceptions has no bearing, except to suggest (since the only -other throws should be allocation, out_of_range, or length_error) -that the strong exception guarantee can be achieved. -

    - -

    -The reaction in that group by Niels Dekker, Martin Sebor, and -Bo Persson, was all that this would be worth an LWG issue. -

    - -

    -A related issue is that erase() does not throw. This should be -stated somewhere (and again, I don't think that the 23.1 [container.requirements], para 1 -applies here). -

    - - - -

    Proposed resolution:

    -

    -Add a blanket statement in 21.3.1 [string.require]: -

    - -
    -

    -- if any member function or operator of basic_string<charT, traits, Allocator> -throws, that function or operator has no effect. -

    -

    -- no erase() or pop_back() function throws. -

    -
    - -

    -As far as I can tell, this is achieved by any implementation. If I made a -mistake and it is not possible to offer this guarantee, then -either state all the functions for which this is possible -(certainly at least operator+=, append, assign, and insert), -or add paragraphs to Effects clauses wherever appropriate. -

    - - - - - -
    -

    848. missing std::hash specializations for std::bitset/std::vector<bool>

    -

    Section: 20.6.16 [unord.hash] Status: Ready - Submitter: Thorsten Ottosen Date: 2008-06-05

    -

    View all issues with Ready status.

    -

    Discussion:

    -

    -In the current working draft, std::hash<T> is specialized for builtin -types and a few other types. Bitsets seems like one that is missing from -the list, not because it cannot not be done by the user, but because it -is hard or impossible to write an efficient implementation that works on -32bit/64bit chunks at a time. For example, std::bitset is too much -encapsulated in this respect. -

    - - -

    Proposed resolution:

    -

    -Add the following to the synopsis in 20.6 [function.objects]/2: -

    - -
    template<class Allocator> struct hash<std::vector<bool,Allocator>>;
-template<size_t N> struct hash<std::bitset<N>>;
-
    - -

    -Modify the last sentence of 20.6.16 [unord.hash]/1 to end with: -

    - -
    -... and std::string, std::u16string, std::u32string, std::wstring, -std::error_code, std::thread::id, std::bitset, and std::vector<bool>. -
    - - - - - - -
    -

    849. missing type traits to compute root class and derived class of types in a class hierachy

    -

    Section: 20.5.7 [meta.trans.other] Status: New - Submitter: Thorsten Ottosen Date: 2008-06-05

    -

    View other active issues in [meta.trans.other].

    -

    View all other issues in [meta.trans.other].

    -

    View all issues with New status.

    -

    Discussion:

    -

    -The type traits library contains various traits to dealt with -polymorphic types, e.g. std::has_virtual_destructor, std::is_polymorphic -and std::is_base_of. However, there is no way to compute the unique -public base class of a type if such one exists. Such a trait could be -very useful if one needs to instantiate a specialization made for the -root class whenever a derived class is passed as parameter. For example, -imagine that you wanted to specialize std::hash for a class -hierarchy---instead of specializing each class, you could specialize the -std::hash<root_class> and provide a partial specialization that worked -for all derived classes. -

    - -

    -This ability---to specify operations in terms of their equivalent in the -root class---can be done with e.g. normal functions, but there is, -AFAIK, no way to do it for class templates. Being able to access -compile-time information about the type-hierachy can be very powerful, -and I therefore also suggest traits that computes the directly derived -class whenever that is possible. -

    - -

    -If the computation can not be done, the traits should fall back on an -identity transformation. I expect this gives the best overall usability. -

    - - -

    Proposed resolution:

    -

    -Add the following to the synopsis in 20.5.2 [meta.type.synop] under "other transformations": -

    - -
    template< class T > struct direct_base_class;
-template< class T > struct direct_derived_class;
-template< class T > struct root_base_class;
-
    - -

    -Add three new entries to table 51 (20.5.7 [meta.trans.other]) with the following content -

    - -
    - - - - - - - - - - - - - - - - - - - -
    TemplateConditionComments
    template< class T > struct direct_base_class;T shall be a complete type.The member typedef type shall equal the accessible unambiguous direct base class of T. -If no such type exists, the member typedef type shall equal T.
    template< class T > struct direct_derived_class;T shall be a complete type.The member typedef type shall equal the unambiguous type which has T -as an accessible unambiguous direct base class. If no such type exists, the member typedef -type shall equal T.
    template< class T > struct root_base_class;T shall be a complete type.The member typedef type shall equal the accessible unambiguous most indirect base class of -T. If no such type exists, the member typedef type shall equal T.
    -
    - - - - - - -
    -

    850. Should shrink_to_fit apply to std::deque?

    -

    Section: 23.2.2.2 [deque.capacity] Status: Ready - Submitter: Niels Dekker Date: 2008-06-05

    -

    View other active issues in [deque.capacity].

    -

    View all other issues in [deque.capacity].

    -

    View all issues with Ready status.

    -

    Discussion:

    -

    -Issue 755 added a shrink_to_fit function to std::vector and std::string. -It did not yet deal with std::deque, because of the fundamental -difference between std::deque and the other two container types. The -need for std::deque may seem less evident, because one might think that -for this container, the overhead is a small map, and some number of -blocks that's bounded by a small constant. -

    -

    -The container overhead can in fact be arbitrarily large (i.e. is not -necessarily O(N) where N is the number of elements currently held by the -deque). As Bill Plauger noted in a reflector message, unless the map of -block pointers is shrunk, it must hold at least maxN/B pointers where -maxN is the maximum of N over the lifetime of the deque since its -creation. This is independent of how the map is implemented -(vector-like circular buffer and all), and maxN bears no relation to N, -the number of elements it currently holds. -

    -

    -Hervé Brönnimann reports a situation where a deque of requests grew very -large due to some temporary backup (the front request hanging), and the -map of the deque grew quite large before getting back to normal. Just -to put some color on it, assuming a deque with 1K pointer elements in -steady regime, that held, at some point in its lifetime, maxN=10M -pointers, with one block holding 128 elements, the spine must be at -least (maxN / 128), in that case 100K. In that case, shrink-to-fit -would allow to reuse about 100K which would otherwise never be reclaimed -in the lifetime of the deque. -

    -

    -An added bonus would be that it *allows* implementations to hang on to -empty blocks at the end (but does not care if they do or not). A -shrink_to_fit would take care of both shrinks, and guarantee that at -most O(B) space is used in addition to the storage to hold the N -elements and the N/B block pointers. -

    - - -

    Proposed resolution:

    -

    -To Class template deque 23.2.2 [deque] synopsis, add: -

    -
    void shrink_to_fit();
-
    - -

    -To deque capacity 23.2.2.2 [deque.capacity], add: -

    -
    void shrink_to_fit();
-
    - -
    -Remarks: shrink_to_fit is a non-binding request to reduce memory -use. [Note: The request is non-binding to allow latitude for -implementation-specific optimizations. -- end note] -
    -
    - - - - - -
    -

    851. simplified array construction

    -

    Section: 23.2.1 [array] Status: Review - Submitter: Benjamin Kosnik Date: 2008-06-05

    -

    View other active issues in [array].

    -

    View all other issues in [array].

    -

    View all issues with Review status.

    -

    Discussion:

    -

    -This is an issue that came up on the libstdc++ list, where a -discrepency between "C" arrays and C++0x's std::array was pointed -out. -

    - -

    -In "C," this array usage is possible: -

    - -
    int ar[] = {1, 4, 6};
-
    - -

    -But for C++, -

    - -
    std::array<int> a = { 1, 4, 6 }; // error
-
    - -

    -Instead, the second parameter of the array template must be -explicit, like so: -

    - -
    std::array<int, 3> a = { 1, 4, 6 };
-
    - -

    -Doug Gregor proposes the following solution, that assumes -generalized initializer lists. -

    - -
    template<typename T, typename... Args>
-inline array<T, sizeof...(Args)> 
-make_array(Args&&... args) 
-{ return { std::forward<Args>(args)... };  }
-
    - -

    -Then, the way to build an array from a list of unknown size is: -

    - -
    auto a = make_array<T>(1, 4, 6);
-
    - - - -

    Proposed resolution:

    -

    -Add to the array synopis in 23.2 [sequences]: -

    - -
    template<typename T, typename... Args>
-  requires Convertible<Args, T>...
-  array<T, sizeof...(Args)> 
-  make_array(Args&&... args);
-
    - -

    -Append after 23.2.1.6 [array.tuple] Tuple interface to class template array the -following new section. -

    - -
    -

    -23.2.1.7 Convenience interface to class template array [array.tuple] -

    - -
    template<typename T, typename... Args>
-  requires Convertible<Args, T>...
-  array<T, sizeof...(Args)> 
-  make_array(Args&&... args);
-
    - -
    -

    -Returns: {std::forward<Args>(args)...} -

    -
    -
    - - - - - -
    -

    852. unordered containers begin(n) mistakenly const

    -

    Section: 23.4 [unord] Status: Ready - Submitter: Robert Klarer Date: 2008-06-12

    -

    View other active issues in [unord].

    -

    View all other issues in [unord].

    -

    View all issues with Ready status.

    -

    Discussion:

    -

    -In 3 of the four unordered containers the local begin member is mistakenly declared const: -

    - -
    local_iterator begin(size_type n) const;
-
    - - -

    Proposed resolution:

    -

    -Change the synopsis in 23.4.1 [unord.map], 23.4.2 [unord.multimap], and 23.4.4 [unord.multiset]: -

    - -
    local_iterator begin(size_type n) const;
-
    - - - - - -
    -

    853. to_string needs updating with zero and one

    -

    Section: 23.3.5 [template.bitset] Status: New - Submitter: Howard Hinnant Date: 2008-06-18

    -

    View all other issues in [template.bitset].

    -

    View all issues with New status.

    -

    Discussion:

    -

    -Issue 396 adds defaulted arguments to the to_string member, but neglects to update -the three newer to_string overloads. -

    - - -

    Proposed resolution:

    -

    -Change the synopsis in 23.3.5 [template.bitset], and the signatures in 23.3.5.2 [bitset.members] to: -

    - -
    template <class charT, class traits> 
-  basic_string<charT, traits, allocator<charT> > to_string(charT zero = charT('0'), charT one = charT('1')) const; 
-template <class charT> 
-  basic_string<charT, char_traits<charT>, allocator<charT> > to_string(charT zero = charT('0'), charT one = charT('1')) const; 
-basic_string<char, char_traits<char>, allocator<char> > to_string(char zero = '0', char one = '1') const; 
-
    - - - - - -
    -

    854. default_delete converting constructor underspecified

    -

    Section: 20.7.11.1.1 [unique.ptr.dltr.dflt] Status: New - Submitter: Howard Hinnant Date: 2008-06-18

    -

    View all issues with New status.

    -

    Discussion:

    -

    -No relationship between U and T in the converting constructor for default_delete template. -

    -

    -Requirements: U* is convertible to T* and has_virtual_destructor<T>; -the latter should also become a concept. -

    -

    -Rules out cross-casting. -

    -

    -The requirements for unique_ptr conversions should be the same as those on the deleter. -

    - - -

    Proposed resolution:

    -

    -Change 20.7.11.1.1 [unique.ptr.dltr.dflt]: -

    - -
    namespace std { 
-  template <class T> struct default_delete { 
-    default_delete(); 
-    template <class U>
-      requires Convertible<U*, T*> && HasVirtualDestructor<T>
-      default_delete(const default_delete<U>&); 
-    void operator()(T*) const; 
-  }; 
-}
-
    - -

    -... -

    - -
    template <class U>
-  requires Convertible<U*, T*> && HasVirtualDestructor<T>
-  default_delete(const default_delete<U>& other);
-
    - - - - - - -
    -

    855. capacity() and reserve() for deque?

    -

    Section: 23.2.2.2 [deque.capacity] Status: New - Submitter: Hervé Brönnimann Date: 2008-06-11

    -

    View other active issues in [deque.capacity].

    -

    View all other issues in [deque.capacity].

    -

    View all issues with New status.

    -

    Discussion:

    -

    -The main point is that capacity can be viewed as a mechanism to -guarantee the validity of iterators when only push_back/pop_back -operations are used. For vector, this goes with reallocation. For -deque, this is a bit more subtle: capacity() of a deque may shrink, -whereas that of vector doesn't. In a circular buffer impl. of the -map, as Howard did, there is very similar notion of capacity: as long -as size() is less than B * (total size of the map - 2), it is -guaranteed that no iterator is invalidated after any number of -push_front/back and pop_front/back operations. But this does not -hold for other implementations. -

    -

    -Still, I believe, capacity() can be defined by size() + how many -push_front/back minus pop_front/back that can be performed before -terators are invalidated. In a classical impl., capacity() = size() -+ the min distance to either "physical" end of the deque (i.e., -counting the empty space in the last block plus all the blocks until -the end of the map of block pointers). In Howard's circular buffer -impl., capacity() = B * (total size of the map - 2) still works with -this definition, even though the guarantee could be made stronger. -

    -

    -A simple picture of a deque: -

    -
    A-----|----|-----|---F+|++++|++B--|-----|-----Z
-
    -

    -(A,Z mark the beginning/end, | the block boundaries, F=front, B=back, -and - are uninitialized, + are initialized) -In that picture: capacity = size() + min(dist(A,F),dist(B,Z)) = min -(dist(A,B),dist(F,Z)). -

    -

    -Reserve(n) can grow the map of pointers and add possibly a number of -empty blocks to it, in order to guarantee that the next n-size() -push_back/push_front operations will not invalidate iterators, and -also will not allocate (i.e. cannot throw). The second guarantee is -not essential and can be left as a QoI. I know well enough existing -implementations of deque (sgi/stl, roguewave, stlport, and -dinkumware) to know that either can be implemented with no change to -the existing class layout and code, and only a few modifications if -blocks are pre-allocated (instead of always allocating a new block, -check if the next entry in the map of block pointers is not zero). -

    -

    -Due to the difference with vector, wording is crucial. Here's a -proposed wording to make things concrete; I tried to be reasonably -careful but please double-check me: -

    - - - -

    Proposed resolution:

    - -

    -Add new signatures to synopsis in 23.2.2 [deque]: -

    - -
    size_type capacity() const;
-bool reserve(size_type n);
-
    - -

    -Add new signatures to 23.2.2.2 [deque.capacity]: -

    - -
    -
    size_type capacity() const;
-
    -
    -

    -1 Returns: An upper bound on n + max(n_f - m_f, n_b - m_b) such -that, for any sequence of n_f push_front, m_f pop_front, n_b -push_back, and m_b pop_back operations, interleaved in any order, -starting with the current deque of size n, the deque does not -invalidate any of its iterators except to the erased elements. -

    -

    -2 Remarks: Unlike a vector's capacity, the capacity of a deque can -decrease after a sequence of insertions at both ends, even if none of -the operations caused the deque to invalidate any of its iterators -except to the erased elements. -

    -
    -
    - -
    -
    bool reserve(size_type n);
-
    -
    -

    -2 Effects: A directive that informs a deque of a planned sequence of -push_front, pop_front, push_back, and pop_back operations, so that it -can manage iterator invalidation accordingly. After reserve(), -capacity() is greater or equal to the argument of reserve if this -operation returns true; and equal to the previous value of capacity() -otherwise. If an exception is thrown, there are no effects. -

    -

    -3 Returns: true if iterators are invalidated as a result of this -operation, and false otherwise. -

    -

    -4 Complexity: It does not change the size of the sequence and takes -at most linear time in n. -

    -

    -5 Throws: length_error if n > max_size(). -

    -

    -6 Remarks: It is guaranteed that no invalidation takes place during a -sequence of insert or erase operations at either end that happens -after a call to reserve() except to the erased elements, until the -time when an insertion would make max(n_f-m_f, n_b-m_b) larger than -capacity(), where n_f is the number of push_front, m_f of pop_front, -n_b of push_back, and m_b of pop_back operations since the call to -reserve(). -

    -

    -7 An implementation is free to pre-allocate buffers so as to -offer the additional guarantee that no exception will be thrown -during such a sequence other than by the element constructors. -

    -
    -
    - -

    -And 23.2.2.3 [deque.modifiers] para 1, can be enhanced: -

    - -
    -1 Effects: An insertion in the middle of the deque invalidates all the iterators and references to elements of the -deque. An insertion at either end of the deque invalidates all the iterators to the deque, -unless provisions have been made with reserve, -but has no effect on the validity of references to elements of the deque. -
    - - - - - -
    -

    856. Removal of aligned_union

    -

    Section: 20.5.7 [meta.trans.other] Status: New - Submitter: Jens Maurer Date: 2008-06-12

    -

    View other active issues in [meta.trans.other].

    -

    View all other issues in [meta.trans.other].

    -

    View all issues with New status.

    -

    Discussion:

    -

    -With the arrival of extended unions -(N2544), -there is no -known use of aligned_union that couldn't be handled by -the "extended unions" core-language facility. -

    - - -

    Proposed resolution:

    -

    -Remove the following signature from 20.5.2 [meta.type.synop]: -

    -
    template <std::size_t Len, class... Types> struct aligned_union;
-
    - -

    -Remove the second row from table 51 in 20.5.7 [meta.trans.other], -starting with: -

    - -
    template <std::size_t Len,
-class... Types>
-struct aligned_union;
-
    - - - - - -
    -

    857. condition_variable::time_wait return bool error prone

    -

    Section: 30.4.1 [thread.condition.condvar] Status: New - Submitter: Beman Dawes Date: 2008-06-13

    -

    View all issues with New status.

    -

    Discussion:

    -

    -The meaning of the bool returned by condition_variable::timed_wait is so -obscure that even the class' designer can't deduce it correctly. Several -people have independently stumbled on this issue. -

    -

    -It might be simpler to change the return type to a scoped enum: -

    -
    enum class timeout { not_reached, reached };
-
    - -

    -That's the same cost as returning a bool, but not subject to mistakes. Your example below would be: -

    - -
    if (cv.wait_until(lk, time_limit) == timeout::reached )
-  throw time_out();
-
    - -

    [ -Beman to supply exact wording. -]

    - - - -

    Proposed resolution:

    - - - - - -
    -

    858. Wording for Minimal Support for Garbage Collection

    -

    Section: X [garbage.collection] Status: New - Submitter: Pete Becker Date: 2008-06-21

    -

    View all issues with New status.

    -

    Discussion:

    -

    -The first sentence of the Effects clause for undeclare_reachable seems -to be missing some words. I can't parse -

    -
    -... for all non-null p referencing the argument is no longer declared reachable... -
    -

    -I take it the intent is that undeclare_reachable should be called only -when there has been a corresponding call to declare_reachable. In -particular, although the wording seems to allow it, I assume that code -shouldn't call declare_reachable once then call undeclare_reachable -twice. -

    -

    -I don't know what "shall be live" in the Requires clause means. -

    -

    -In the final Note for undeclare_reachable, what does "cannot be -deallocated" mean? Is this different from "will not be able to collect"? -

    - -

    -For the wording on nesting of declare_reachable and -undeclare_reachable, the words for locking and unlocking recursive -mutexes probably are a good model. -

    - - -

    Proposed resolution:

    -

    -

    - - - - - -
    -

    859. Monotonic Clock is Conditionally Supported?

    -

    Section: X [datetime] Status: New - Submitter: Pete Becker Date: 2008-06-23

    -

    View all issues with New status.

    -

    Discussion:

    -

    -N2661 -says that there is a class named monotonic_clock. It also says that this -name may be a synonym for system_clock, and that it's conditionally -supported. So the actual requirement is that it can be monotonic or not, -and you can tell by looking at is_monotonic, or it might not exist at -all (since it's conditionally supported). Okay, maybe too much -flexibility, but so be it. -

    -

    -A problem comes up in the threading specification, where several -variants of wait_for explicitly use monotonic_clock::now(). What is the -meaning of an effects clause that says -

    - -
    wait_until(lock, chrono::monotonic_clock::now() + rel_time)
-
    - -

    -when monotonic_clock is not required to exist? -

    - - -

    Proposed resolution:

    -

    -

    - - - - - -
    -

    860. Floating-Point State

    -

    Section: 26 [numerics] Status: New - Submitter: Lawrence Crowl Date: 2008-06-23

    -

    View all issues with New status.

    -

    Discussion:

    -

    -There are a number of functions that affect the floating point state. -These function need to be thread-safe, but I'm unsure of the right -approach in the standard, as we inherit them from C. -

    - - -

    Proposed resolution:

    -

    -

    - - - - - -
    -

    861. Incomplete specification of EqualityComparable for std::forward_list

    -

    Section: 23.1 [container.requirements] Status: New - Submitter: Daniel Krügler Date: 2008-06-24

    -

    View other active issues in [container.requirements].

    -

    View all other issues in [container.requirements].

    -

    View all issues with New status.

    -

    Discussion:

    -

    -Table 89, Container requirements, defines operator== in terms of the container -member function size() and the algorithm std::equal: -

    - -
    -== is an equivalence relation. a.size() == b.size() && -equal(a.begin(), a.end(), b.begin() -
    - -

    -The new container forward_list does not provide a size member function -by design but does provide operator== and operator!= without specifying it's semantic. -

    -

    -Other parts of the (sequence) container requirements do also depend on -size(), e.g. empty() -or clear(), but this issue explicitly attempts to solve the missing -EqualityComparable specification, -because of the special design choices of forward_list. -

    -

    -I propose to apply one of the following resolutions, which are described as: -

    - -
      -
    1. -Provide a definition, which is optimal for this special container without -previous size test. This choice prevents two O(N) calls of std::distance() -with the corresponding container ranges and instead uses a special -equals implementation which takes two container ranges instead of 1 1/2. -
      2. -
    2. -The simple fix where the usual test is adapted such that size() is replaced -by distance with corresponding performance disadvantages. -
      3. -
    -

    -Both proposal choices are discussed, the preferred choice of the author is -to apply (A). -

    - - -

    Proposed resolution:

    -

    -Common part: -

    -
      -
    • -

      -Just betwen 23.2.3.5 [forwardlist.ops] and 23.2.3.6 [forwardlist.spec] -add a new -section "forwardlist comparison operators" [forwardlist.compare] (and -also add the -new section number to 23.2.3 [forwardlist]/2 in front of "Comparison operators"): -

      -
      -forwardlist comparison operators [forwardlist.compare] -
      -
      • -
    - -

    -Option (A): -

    -
    -
      -
    • -

      -Add to the new section [forwardlist.compare] the following paragraphs: -

      - -
      -
      template <class T, class Allocator>
-bool operator==(const forward_list<T,Allocator>& x, const forward_list<T,Allocator>& y);
-
      -
      -

      -Requires: Type T is EqualityComparable ([equalitycomparable]). -

      -

      -Returns: true if -

      -
        -
      • -

        -for every iterator i in the range [x.begin(), E), where E == -x.begin() + M and M == - min(distance(x.begin(), x.end()), distance(y.begin(), y.end())), -the following condition holds: -

        -
        *i == *(y.begin() + (i - x.begin())).
-
        -
        • -
      • -if i == E then i == x.end() && (y.begin() + (i - x.begin())) == y.end(). -
        • -
      • -Otherwise, returns false. -
        • -
      -

      -Throws: Nothing unless an exception is thrown by the equality comparison. -

      -

      -Complexity: At most M comparisons. -

      -
      -
      template <class T, class Allocator>
-bool operator!=(const forward_list<T,Allocator>& x, const forward_list<T,Allocator>& y);
-
      -
      -Returns: !(x == y). -
      -
      -
      • -
    -
    - -

    -Option (B): -

    -
    -
      -
    • -

      -Add to the new section [forwardlist.compare] the following paragraphs: -

      -
      -
      template <class T, class Allocator>
-bool operator==(const forward_list<T,Allocator>& x, const forward_list<T,Allocator>& y);
-
      -
      -

      -Requires: Type T is EqualityComparable ([equalitycomparable]). -

      -

      -Returns: distance(x.begin(), x.end()) == distance(y.begin(), y.end()) -&& equal(x.begin(), x.end(), y.begin()). -

      -
      -
      template <class T, class Allocator>
-bool operator!=(const forward_list<T,Allocator>& x, const forward_list<T,Allocator>& y);
-
      -
      -Returns: !(x == y). -
      -
      -
      • -
    -
    - - - - - -
    -

    862. Impossible complexity for 'includes'

    -

    Section: 25.3.5.1 [includes] Status: New - Submitter: Alisdair Meredith Date: 2008-07-02

    -

    View all issues with New status.

    -

    Discussion:

    -

    -In 25.3.5.1 [includes] the complexity is "at most -1 comparisons" if passed -two empty ranges. I don't know how to perform a negative number of -comparisions! -

    - -

    -This same issue also applies to: -

    - -
      -
    • set_union
      • -
    • set_intersection
      • -
    • set_difference
      • -
    • set_symmetric_difference
      • -
    • merge
      • -
    - - -

    Proposed resolution:

    -

    -

    - - - - - -
    -

    863. What is the state of a stream after close() succeeds

    -

    Section: 27.8.1 [fstreams] Status: New - Submitter: Steve Clamage Date: 2008-07-08

    -

    View all other issues in [fstreams].

    -

    View all issues with New status.

    -

    Discussion:

    -

    -Suppose writing to an [o]fstream fails and you later close the stream. -The overflow() function is called to flush the buffer (if it exists). -Then the file is unconditionally closed, as if by calling flcose. -

    -

    -If either overflow or fclose fails, close() reports failure, and clearly -the stream should be in a failed or bad state. -

    -

    -Suppose the buffer is empty or non-existent (so that overflow() does not -fail), and fclose succeeds. The close() function reports success, but -what is the state of the stream? -

    - - -

    Proposed resolution:

    -

    -

    - - - - - -
    -

    864. Defect in atomic wording

    -

    Section: 29.4 [atomics.types.operations] Status: New - Submitter: Anthony Williams Date: 2008-07-10

    -

    View all other issues in [atomics.types.operations].

    -

    View all issues with New status.

    -

    Discussion:

    -

    -There's an error in 29.4 [atomics.types.operations]/p9: -

    - -
    -
    C atomic_load(const volatile A * object);
-C atomic_load_explicit(const volatile A * object, memory_order);
-C A ::load(memory_order order = memory_order_seq_cst) const volatile;
-
    -
    -

    -Requires: The order argument shall not be memory_order_acquire nor -memory_order_acq_rel. -

    -
    -
    - -

    -I believe that this should state -

    -
    -shall not be memory_order_release. -
    - -

    -There's also an error in 29.4 [atomics.types.operations]/p17: -

    - -
    -... When only one memory_order argument is supplied, the value of success -is order, and -the value of failure is order except that a value of -memory_order_acq_rel shall be replaced by the value -memory_order_require ... -
    -

    -I believe this should state -

    -
    -shall be replaced by the value memory_order_acquire ... -
    - - -

    Proposed resolution:

    -

    -Change 29.4 [atomics.types.operations]/p9: -

    - -
    -
    C atomic_load(const volatile A * object);
-C atomic_load_explicit(const volatile A * object, memory_order);
-C A ::load(memory_order order = memory_order_seq_cst) const volatile;
-
    -
    -

    -Requires: The order argument shall not be memory_order_acquire -memory_order_release nor memory_order_acq_rel. -

    -
    -
    - -

    -Change 29.4 [atomics.types.operations]/p17: -

    - -
    -... When only one memory_order argument is supplied, the value of success -is order, and -the value of failure is order except that a value of -memory_order_acq_rel shall be replaced by the value -memory_order_require memory_order_acquire ... -
    - - - - - - -
    -

    865. More algorithms that throw away information

    -

    Section: 25.2.6 [alg.fill], 25.2.7 [alg.generate] Status: New - Submitter: Daniel Krügler Date: 2008-07-13

    -

    View all issues with New status.

    -

    Discussion:

    -

    -In regard to library defect 488 I found some more algorithms which -unnecessarily throw away information. These are typically algorithms, -which sequentially write into an OutputIterator, but do not return the -final value of this output iterator. These cases are: -

    - -
      -
    1. -
      template<class OutputIterator, class Size, class T>
-void fill_n(OutputIterator first, Size n, const T& value);
      2. - -
    2. -
      template<class OutputIterator, class Size, class Generator>
-void generate_n(OutputIterator first, Size n, Generator gen);
      3. -
    -

    -In both cases the minimum requirements on the iterator are -OutputIterator, which means according to the requirements of -24.1.2 [output.iterators]/2 that only single-pass iterations are guaranteed. -So, if users of fill_n and generate_n have *only* an OutputIterator -available, they have no chance to continue pushing further values -into it, which seems to be a severe limitation to me. -

    - - -

    Proposed resolution:

    -
      -
    1. -

      -Replace the current declaration of fill_n in 25 [algorithms]/2, header -<algorithm> synopsis and in 25.2.6 [alg.fill] by -

      - -
      template<class OutputIterator, class Size, class T>
-void OutputIterator fill_n(OutputIterator first, Size n, const T& value);
-
      -

      -Just after the effects clause p.2 add a new returns clause saying: -

      -
      -Returns: first + n for fill_n. -
      -
      2. -
    2. -

      -Replace the current declaration of generate_n in 25 [algorithms]/2, header -<algorithm> synopsis and in 25.2.7 [alg.generate] by -

      -
      template<class OutputIterator, class Size, class Generator>
-void OutputIterator generate_n(OutputIterator first, Size n, Generator gen);
-
      -

      -Just after the effects clause p.1 add a new returns clause saying: -

      -
      -Returns: first + n for generate_n. -
      -
      3. -
    - - - - - -
    -

    866. Qualification of placement new-expressions

    -

    Section: 20.7.10 [specialized.algorithms], 20.7.12.2.6 [util.smartptr.shared.create] Status: New - Submitter: Alberto Ganesh Barbati Date: 2008-07-14

    -

    View all issues with New status.

    -

    Discussion:

    -

    -LWG issue 402 replaced "new" with "::new" in the placement -new-expression in 20.7.5.1 [allocator.members]. I believe the rationale -given in 402 applies also to the following other contexts: -

    -
      -
    • -

      -in 20.7.10 [specialized.algorithms], all four algorithms unitialized_copy, -unitialized_copy_n, unitialized_fill and unitialized_fill_n use -the unqualified placement new-expression in some variation of the form: -

      -
      new  (static_cast<void*>(&*result)) typename  iterator_traits<ForwardIterator>::value_type(*first);
-
      -
      • -
    • -

      -in 20.7.12.2.6 [util.smartptr.shared.create] there is a reference to the unqualified placement new-expression: -

      -
      new  (pv)  T(std::forward<Args>(args)...),
-
      -
      • -
    -

    -I suggest to add qualification in all those places. As far as I know, -these are all the remaining places in the whole library that explicitly -use a placement new-expression. Should other uses come out, they should -be qualified as well. -

    -

    -As an aside, a qualified placement new-expression does not need -additional requirements to be compiled in a constrained context. By -adding qualification, the HasPlacementNew concept introduced recently in -N2677 (Foundational Concepts) -would no longer be needed by library and -should therefore be removed. -

    - - -

    Proposed resolution:

    -

    -Replace "new" with "::new" in: -

    -
      -
    • -20.7.10.1 [uninitialized.copy], paragraphs 1 and 3 -
      • -
    • -20.7.10.2 [uninitialized.fill] paragraph 1 -
      • -
    • -20.7.10.3 [uninitialized.fill.n] paragraph 1 -
      • -
    • -20.7.12.2.6 [util.smartptr.shared.create] once in paragraph 1 and twice in paragraph 2. -
      • -
    - - - - - - -
    -

    867. Valarray and value-initialization

    -

    Section: 26.5.2.1 [valarray.cons] Status: New - Submitter: Alberto Ganesh Barbati Date: 2008-07-20

    -

    View other active issues in [valarray.cons].

    -

    View all other issues in [valarray.cons].

    -

    View all issues with New status.

    -

    Discussion:

    -

    -From 26.5.2.1 [valarray.cons], paragraph 2: -

    - -
    explicit  valarray(size_t);
-
    -
    -The array created by this constructor has a length equal to the value of the argument. The elements -of the array are constructed using the default constructor for the instantiating type T. -
    -
    - -

    -The problem is that the most obvious Ts for valarray are float -and double, they don't have a default constructor. I guess the intent is to value-initialize -the elements, so I suggest replacing: -

    - -
    -The elements of the array are constructed using the default constructor for the instantiating type T. -
    -

    -with -

    -
    -The elements of the array are value-initialized. -
    - -

    -There is another reference to the default constructor of T in the non-normative note in paragraph 9. -That reference should also be replaced. (The normative wording in paragraph 8 refers to T() -and so it doesn't need changes). -

    - - -

    Proposed resolution:

    -

    -Change 26.5.2.1 [valarray.cons], paragraph 2: -

    - -
    -
    explicit  valarray(size_t);
-
    -
    -The array created by this constructor has a length equal to the value of the argument. The elements -of the array are constructed using the default constructor for the instantiating type T -value-initialized (8.5 [dcl.init]). -
    -
    - -

    -Change 26.5.2.7 [valarray.members], paragraph 9: -

    - -
    -[Example: If the argument has the value -2, the first two elements of the result will be constructed using the -default constructor -value-initialized (8.5 [dcl.init]); -the third element of the result will be assigned the value of the first element of the argument; etc. -- end example] -
    - - - - - - -
    -

    868. default construction and value-initialization

    -

    Section: 23 [containers] Status: New - Submitter: Alberto Ganesh Barbati Date: 2008-07-22

    -

    View other active issues in [containers].

    -

    View all other issues in [containers].

    -

    View all issues with New status.

    -

    Discussion:

    -

    -The term "default constructed" is often used in wording that predates -the introduction of the concept of value-initialization. In a few such -places the concept of value-initialization is more correct than the -current wording (for example when the type involved can be a built-in) -so a replacement is in order. Two of such places are already covered by -issue 867. This issue deliberately addresses the hopefully -non-controversial changes in the attempt of being approved more quickly. -A few other occurrences (for example in std::tuple, -std::reverse_iterator and std::move_iterator) are left to separate -issues. For std::reverse_iterator, see also issue 408. This issue is -related with issue 724. -

    - - -

    Proposed resolution:

    -

    -Change 20.1.1 [utility.arg.requirements], paragraph 2: -

    - -
    -In general, a default constructor is not required. Certain container class member function signatures specify -the default constructor -T() -as a default argument. T() shall be a well-defined expression (8.5 [dcl.init]) if one of -those signatures is called using the default argument (8.3.6 [dcl.fct.default]). -
    - -

    -In all the following paragraphs in clause 23 [containers], replace "default constructed" with "value-initialized -(8.5 [dcl.init])": -

    - -
      -
    • 23.2.2.1 [deque.cons] para 2
      • -
    • 23.2.2.2 [deque.capacity] para 1
      • -
    • 23.2.3.1 [forwardlist.cons] para 3
      • -
    • 23.2.3.4 [forwardlist.modifiers] para 21
      • -
    • 23.2.4.1 [list.cons] para 3
      • -
    • 23.2.4.2 [list.capacity] para 1
      • -
    • 23.2.6.1 [vector.cons] para 3
      • -
    • 23.2.6.2 [vector.capacity] para 10
      • -
    - - - - - -
    -

    869. Bucket (local) iterators and iterating past end

    -

    Section: 23.1.5 [unord.req] Status: New - Submitter: Sohail Somani Date: 2008-07-22

    -

    View other active issues in [unord.req].

    -

    View all other issues in [unord.req].

    -

    View all issues with New status.

    -

    Discussion:

    -

    -Is there any language in the current draft specifying the behaviour of the following snippet? -

    - -
    unordered_set<int> s;
-unordered_set<int>::local_iterator it = s.end(0);
-
-// Iterate past end - the unspecified part
-it++;
-
    - -

    -I don't think there is anything about s.end(n) being considered an -iterator for the past-the-end value though (I think) it should be. -

    - - -

    Proposed resolution:

    -

    -Change Table 97 "Unordered associative container requirements" in 23.1.5 [unord.req]: -

    - -
    - - - - - - - - - - - - - - - - - -
    Table 97: Unordered associative container requirements
    expressionreturn typeassertion/note pre/post-conditioncomplexity
    b.begin(n)local_iterator
    const_local_iterator for const b.    		Pre: n shall be in the range [0,b.bucket_count()). Note: [b.begin(n), b.end(n)) is a -valid range containing all of the elements in the nth bucket. -b.begin(n) returns an iterator referring to the first element in the bucket. -If the bucket is empty, then b.begin(n) == b.end(n).Constant
    b.end(n)local_iterator
    const_local_iterator for const b.    		Pre: n shall be in the range [0, b.bucket_count()). -b.end(n) returns an iterator which is the past-the-end value for the bucket.Constant
    -
    - - - - - - -
    -

    870. Do unordered containers not support function pointers for predicate/hasher?

    -

    Section: 23.1.5 [unord.req] Status: New - Submitter: Daniel Krügler Date: 2008-08-17

    -

    View other active issues in [unord.req].

    -

    View all other issues in [unord.req].

    -

    View all issues with New status.

    -

    Discussion:

    -

    -Good ol' associative containers allow both function pointers and -function objects as feasible -comparators, as described in 23.1.4 [associative.reqmts]/2: -

    - -
    -Each associative container is parameterized on Key and an ordering -relation Compare that -induces a strict weak ordering (25.3) on elements of Key. [..]. The -object of type Compare is -called the comparison object of a container. This comparison object -may be a pointer to -function or an object of a type with an appropriate function call operator.[..] -
    - -

    -The corresponding wording for unordered containers is not so clear, -but I read it to disallow -function pointers for the hasher and I miss a clear statement for the -equality predicate, see -23.1.5 [unord.req]/3+4+5: -

    - -
    -

    -Each unordered associative container is parameterized by Key, by a -function object Hash that -acts as a hash function for values of type Key, and by a binary -predicate Pred that induces an -equivalence relation on values of type Key.[..] -

    -

    -A hash function is a function object that takes a single argument of -type Key and returns a -value of type std::size_t. -

    -

    -Two values k1 and k2 of type Key are considered equal if the -container's equality function object -returns true when passed those values.[..] -

    -
    - -

    -and table 97 says in the column "assertion...post-condition" for the -expression X::hasher: -

    - -
    -Hash shall be a unary function object type such that the expression -hf(k) has type std::size_t. -
    - -

    -Note that 20.6 [function.objects]/1 defines as "Function objects are -objects with an operator() defined.[..]" -

    -

    -Does this restriction exist by design or is it an oversight? If an -oversight, I suggest that to apply -the following -

    - - -

    Proposed resolution:

    -

    -In 23.1.5 [unord.req]/3, just after the second sentence which is written as -

    - -
    -Additionally, unordered_map and unordered_multimap associate an -arbitrary mapped type T with the Key. -
    - -

    -add one further sentence: -

    - -
    -Both Hash and Pred may be pointers to function or objects of a type -with an appropriate function call operator. -
    - -

    -[Note1: Since the detailed requirements for Pred and Hash are given in -p.4 and p.5, it an alternative resolution -would be to insert a new paragraph just after p.5, which contains the -above proposed sentence] -

    -

    -[Note2: I do not propose a change of above quoted element in table 97, -because the mis-usage of the -notion of "function object" seems already present in the standard at -several places, even if it includes -function pointers, see e.g. 25 [algorithms]/7. The important point is -that in those places a statement is -given that the actually used symbol, like "Predicate" applies for -function pointers as well] -

    - - - - - -
    -

    871. Iota's requirements on T are too strong

    -

    Section: 26.6.5 [numeric.iota] Status: New - Submitter: Daniel Krügler Date: 2008-08-20

    -

    View all issues with New status.

    -

    Discussion:

    -

    -According to the recent WP -N2691, -26.6.5 [numeric.iota]/1, the requires clause -of std::iota says: -

    - -
    -T shall meet the requirements of CopyConstructible and Assignable types, and -shall be convertible to ForwardIterator's value type.[..] -
    - -

    -Neither CopyConstructible nor Assignable is needed, instead MoveConstructible -seems to be the correct choice. I guess the current wording resulted as an -artifact from comparing it with similar numerical algorithms like accumulate. -

    - -

    -Note: If this function will be conceptualized, the here proposed -MoveConstructible -requirement can be removed, because this is an implied requirement of -function arguments, see -N2710/[temp.req.impl]/3, last bullet. -

    - - - -

    Proposed resolution:

    - -

    -Change the first sentence of 26.6.5 [numeric.iota]/1: -

    - -
    -Requires: T shall meet the requirements of -CopyConstructible and Assignable types, - -be MoveConstructible (Table 34) - -and shall be -convertible to ForwardIterator's value type. [..] -
    - - - - - - -
    -

    872. move_iterator::operator[] has wrong return type

    -

    Section: 24.4.3.3.12 [move.iter.op.index] Status: New - Submitter: Doug Gregor Date: 2008-08-21

    -

    View all issues with New status.

    -

    Discussion:

    -

    -move_iterator's operator[] is declared as: -

    - -
    reference operator[](difference_type n) const;
-
    - -

    -This has the same problem that reverse_iterator's operator[] used to -have: if the underlying iterator's operator[] returns a proxy, the -implicit conversion to value_type&& could end up referencing a temporary -that has already been destroyed. This is essentially the same issue that -we dealt with for reverse_iterator in DR 386. -

    - - -

    Proposed resolution:

    -

    -In 24.4.3.1 [move.iterator] and 24.4.3.3.12 [move.iter.op.index], change the declaration of -move_iterator's operator[] to: -

    - -
    reference unspecified operator[](difference_type n) const;
-
    - - - - - - -
    -

    873. signed integral type and unsigned integral type are not clearly defined

    -

    Section: 3.9.1 [basic.fundamental] Status: New - Submitter: Travis Vitek Date: 2008-06-30

    -

    View all issues with New status.

    -

    Discussion:

    -

    - Neither the term "signed integral type" nor the term "unsigned - integral type" is defined in the core language section of the - standard, therefore the library section should avoid its use. The - terms signed integer type and unsigned integer type are - indeed defined (in 3.9.1 [basic.fundamental]), thus the usages should be - replaced accordingly. -

    - -

    - Note that the key issue here is that "signed" + "integral type" != - "signed integral type". - - The types bool, char, char16_t, - char32_t and wchar_t are all listed as - integral types, but are neither of signed integer type or - unsigned integer type. According to 3.9 [basic.types] p7, a synonym for - integral type is integer type. - - Given this, one may choose to assume that an integral type that - can represent values less than zero is a signed integral type. - Unfortunately this can cause ambiguities. - - As an example, if T is unsigned char, the - expression make_signed<T>::type, is supposed to - name a signed integral type. There are potentially two types that - satisfy this requirement, namely signed char and - char (assuming CHAR_MIN < 0). -

    - - -

    Proposed resolution:

    -

    - I propose to use the terms "signed integer type" and "unsigned integer - type" in place of "signed integral type" and "unsigned integral type" - to eliminate such ambiguities. -

    - -

    - The proposed change makes it absolutely clear that the difference - between two pointers cannot be char or wchar_t, - but could be any of the signed integer types. - 5.7 [expr.add] paragraph 6... -

    -
    -

    -

      -
    1. - When two pointers to elements of the same array object are - subtracted, the result is the difference of the subscripts of - the two array elements. The type of the result is an - implementation-defined signed integral - typesigned integer type; this type shall be the - same type that is defined as std::ptrdiff_t in the - <cstdint> header (18.1)... -
      2. -
    - -
    - -

    - The proposed change makes it clear that X::size_type and - X::difference_type cannot be char or - wchar_t, but could be one of the signed or unsigned integer - types as appropriate. - 20.1.2 [allocator.requirements] table 40... -

    -
    - Table 40: Allocator requirements - - - - - - - - - - - - - - - - - - - - -
    expressionreturn typeassertion/note/pre/post-condition
    X::size_type - unsigned integral type - unsigned integer type - a type that can represent the size of the largest object in - the allocation model.
    X::difference_type - signed integral type - signed integer type - a type that can represent the difference between any two - pointers in the allocation model.
    -
    - -

    - The proposed change makes it clear that make_signed<T>::type - must be one of the signed integer types as defined in 3.9.1. Ditto for - make_unsigned<T>type and unsigned integer types. - 20.5.6.3 [meta.trans.sign] table 48... -

    -
    - Table 48: Sign modifications - - - - - - - - - - - - - - - - - -
    TemplateComments
    - template <class T> struct make_signed; - - If T names a (possibly cv-qualified) signed - integral typesigned integer type (3.9.1) then - the member typedef type shall name the type - T; otherwise, if T names a (possibly - cv-qualified) unsigned integral typeunsigned - integer type then type shall name the - corresponding signed integral typesigned - integer type, with the same cv-qualifiers as - T; otherwise, type shall name the - signed integral typesigned integer type - with the smallest rank (4.13) for which sizeof(T) == - sizeof(type), with the same cv-qualifiers as - T. - - Requires: T shall be a (possibly - cv-qualified) integral type or enumeration but not a - bool type. -
    - template <class T> struct make_unsigned; - - If T names a (possibly cv-qualified) - unsigned integral typeunsigned integer - type (3.9.1) then the member typedef type - shall name the type T; otherwise, if - T names a (possibly cv-qualified) signed - integral typesigned integer type then - type shall name the corresponding unsigned - integral typeunsigned integer type, with the - same cv-qualifiers as T; otherwise, - type shall name the unsigned integral - typeunsigned integer type with the smallest - rank (4.13) for which sizeof(T) == sizeof(type), - with the same cv-qualifiers as T. - - Requires: T shall be a (possibly - cv-qualified) integral type or enumeration but not a - bool type. -
    -
    - - -

    - Note: I believe that the basefield values should probably be - prefixed with ios_base:: as they are in 22.2.2.2.2 [facet.num.put.virtuals] - - The listed virtuals are all overloaded on signed and unsigned integer - types, the new wording just maintains consistency. - - 22.2.2.1.2 [facet.num.get.virtuals] table 78... -

    -
    - Table 78: Integer Conversions - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    Statestdio equivalent
    basefield == oct%o
    basefield == hex%X
    basefield == 0%i
    signed integral typesigned integer - type%d
    unsigned integral typeunsigned integer - type%u
    -
    - - - -

    - Rationale is same as above. - 22.2.2.2.2 [facet.num.put.virtuals] table 80... -

    -
    - Table 80: Integer Conversions - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    Statestdio equivalent
    basefield == ios_base::oct%o
    (basefield == ios_base::hex) && - !uppercase%x
    (basefield == ios_base::hex)%X
    basefield == 0%i
    for a signed integral typesigned integer - type%d
    for a unsigned integral typeunsigned integer - type%u
    -
    - - -

    - 23.1 [container.requirements] table 80... -

    -
    - Table 89: Container requirements - - - - - - - - - - - - - - - - - - - - - - - - - - -
    expressionreturn typeoperational semanticsassertion/note/pre/post-conditioncomplexity
    X::difference_typesigned integral typesigned integer type is identical to the difference type of X::iterator - and X::const_iteratorcompile time
    X::size_typeunsigned integral typeunsigned integer type size_type can represent any non-negative value of - difference_typecompile time
    -
    - -

    - 24.1 [iterator.requirements] paragraph 1... -

    -
    - Iterators are a generalization of pointers that allow a C++ program to - work with different data structures (containers) in a uniform manner. - To be able to construct template algorithms that work correctly and - efficiently on different types of data structures, the library - formalizes not just the interfaces but also the semantics and - complexity assumptions of iterators. All input iterators - i support the expression *i, resulting in a - value of some class, enumeration, or built-in type T, - called the value type of the iterator. All output iterators - support the expression *i = o where o is a - value of some type that is in the set of types that are - writable to the particular iterator type of i. All - iterators i for which the expression (*i).m - is well-defined, support the expression i->m with the - same semantics as (*i).m. For every iterator type - X for which equality is defined, there is a corresponding - signed integral type signed integer type called - the difference type of the iterator. -
    - -

    - I'm a little unsure of this change. Previously this paragraph would - allow instantiations of linear_congruential_engine on - char, wchar_t, bool, and other types. The - new wording prohibits this. - 26.4.3.1 [rand.eng.lcong] paragraph 2... -

    -
    - The template parameter UIntType shall denote an - unsigned integral typeunsigned integer type - large enough to store values as large as m - 1. If the - template parameter m is 0, the modulus m - used throughout this section 26.4.3.1 is - numeric_limits<result_type>::max() plus 1. [Note: - The result need not be representable as a value of type - result_type. --end note] Otherwise, the following - relations shall hold: a < m and c < - m. -
    - -

    - Same rationale as the previous change. - 26.4.4.4 [rand.adapt.xor] paragraph 6... -

    -
    - Both Engine1::result_type and - Engine2::result_type shall denote (possibly different) - unsigned integral typesunsigned integer types. - The member result_type shall denote either the type - Engine1::result_type or the type Engine2::result_type, - whichever provides the most storage according to clause 3.9.1. -
    - -

    - 26.4.7.1 [rand.util.seedseq] paragraph 7... -

    -
    - Requires:RandomAccessIterator shall meet the - requirements of a random access iterator (24.1.5) such that - iterator_traits<RandomAccessIterator>::value_type - shall denote an unsigned integral typeunsigned integer - type capable of accomodating 32-bit quantities. -
    - -

    - By making this change, integral types that happen to have a signed - representation, but are not signed integer types, would no longer be - required to use a two's complement representation. This may go against - the original intent, and should be reviewed. - 29.4 [atomics.types.operations] paragraph 24... -

    -
    - Remark: For signed integral typessigned integer - types, arithmetic is defined using two's complement - representation. There are no undefined results. For address types, the - result may be an undefined address, but the operations otherwise have - no undefined behavior. -
    - - - - - - -
    -

    874. Missing initializer_list constructor for discrete_distribution

    -

    Section: 26.4.8.5.1 [rand.dist.samp.discrete] Status: New - Submitter: Daniel Krügler Date: 2008-08-22

    -

    View other active issues in [rand.dist.samp.discrete].

    -

    View all other issues in [rand.dist.samp.discrete].

    -

    View all issues with New status.

    -

    Discussion:

    -

    -During the Sophia Antipolis meeting it was decided to separate from 793 a -subrequest that adds initializer list support to -discrete_distribution, specifically, -the issue proposed to add a c'tor taking a initializer_list<double>. -

    - - - -

    Proposed resolution:

    -
      -
    1. -

      -In 26.4.8.5.1 [rand.dist.samp.discrete]/1, class discrete_distribution, -just before the member declaration -

      - -
      explicit discrete_distribution(const param_type& parm);
-
      - -

      -insert -

      - -
      discrete_distribution(initializer_list<double> wl);
-
      -
      2. - -
    2. -

      -Between p.4 and p.5 of the same section insert a new -paragraph as part of the new member description: -

      - -
      discrete_distribution(initializer_list<double> wl);
-
      - -
      -Effects: Same as discrete_distribution(wl.begin(), wl.end()). -
      -
      -
      3. -
    - - - - - -
    -

    875. Missing initializer_list constructor for piecewise_constant_distribution

    -

    Section: 26.4.8.5.2 [rand.dist.samp.pconst] Status: New - Submitter: Daniel Krügler Date: 2008-08-22

    -

    View other active issues in [rand.dist.samp.pconst].

    -

    View all other issues in [rand.dist.samp.pconst].

    -

    View all issues with New status.

    -

    Discussion:

    -

    -During the Sophia Antipolis meeting it was decided to separate from -794 a subrequest that adds initializer list support to -piecewise_constant_distribution, specifically, the issue proposed -to add a c'tor taking a initializer_list<double> and a Callable to evaluate -weight values. For consistency with the remainder of this class and -the remainder of the initializer_list-aware library the author decided to -change the list argument type to the template parameter RealType -instead. For the reasoning to use Func instead of Func&& as c'tor -function argument see issue 793. -

    - - -

    Proposed resolution:

    -
      -
    1. -

      -In 26.4.8.5.2 [rand.dist.samp.pconst]/1, class piecewise_constant_distribution, -just before the member declaration -

      - -
      explicit piecewise_constant_distribution(const param_type& parm);
-
      - -

      -insert -

      - -
      template<typename Func>
-piecewise_constant_distribution(initializer_list<RealType> bl, Func fw);
-
      -
      2. - -
    2. -

      -Between p.4 and p.5 of the same section insert a series of -new paragraphs nominated below as [p5_1], [p5_2], and [p5_3] -as part of the new member description: -

      - -
      template<typename Func>
-piecewise_constant_distribution(initializer_list<RealType> bl, Func fw);
-
      - -
      - -

      -[p5_1] Complexity: Exactly nf = max(bl.size(), 1) - 1 invocations of fw. -

      - -

      -[p5_2] Requires: -

      - -
        -
      1. -fw shall be callable with one argument of type RealType, and shall - return values of a type convertible to double; -
        2. -
      2. -The relation 0 < S = w0+. . .+wn-1 shall hold. -For all sampled values xk defined below, fw(xk) shall return a weight - value wk that is non-negative, non-NaN, and non-infinity; -
        3. -
      3. -If nf > 0 let bk = *(bl.begin() + k), k = 0, . . . , bl.size()-1 and the -following relations shall hold for k = 0, . . . , nf-1: bk < bk+1. -
        4. -
      - -

      -[p5_3] Effects: -

      - -
        -
      1. -

        If nf == 0,

        -
          -
        1. -lets the sequence w have length n = 1 and consist of the single - value w0 = 1, and -
          2. -
        2. -lets the sequence b have length n+1 with b0 = 0 and b1 = 1. -
          3. -
        -
        2. - -
      2. -

        Otherwise,

        -
          -
        1. -sets n = nf, and [bl.begin(), bl.end()) shall form the sequence b of -length n+1, and -
          2. -
        2. -

          lets the sequences w have length n and for each k = 0, . . . ,n-1, - calculates:

          -
          xk = 0.5*(bk+1 + bk)
-wk = fw(xk)
-
          -
          3. -
        -
        3. - -
      3. -

        -Constructs a piecewise_constant_distribution object with -the above computed sequence b as the interval boundaries -and with the probability densities: -

        -
        ρk = wk/(S * (bk+1 - bk)) for k = 0, . . . , n-1.
-
        - -
        4. -
      - -
      -
      -
      3. -
    - - - - - -
    -

    876. basic_string access operations should give stronger guarantees

    -

    Section: 21.3 [basic.string] Status: New - Submitter: Daniel Krügler Date: 2008-08-22

    -

    View other active issues in [basic.string].

    -

    View all other issues in [basic.string].

    -

    View all issues with New status.

    -

    Discussion:

    -

    -During the Sophia Antipolis meeting it was decided to split-off some -parts of the -n2647 -("Concurrency modifications for basic_string") -proposal into a separate issue, because these weren't actually -concurrency-related. The here proposed changes refer to the recent -update document -n2668 -and attempt to take advantage of the -stricter structural requirements. -

    -

    -Indeed there exists some leeway for more guarantees that would be -very useful for programmers, especially if interaction with transactionary -or exception-unaware C API code is important. This would also allow -compilers to take advantage of more performance optimizations, because -more functions can have throw() specifications. This proposal uses the -form of "Throws: Nothing" clauses to reach the same effect, because -there already exists a different issue in progress to clean-up the current -existing "schizophrenia" of the standard in this regard. -

    -

    -Due to earlier support for copy-on-write, we find the following -unnecessary limitations for C++0x: -

    - -
      -
    1. -Missing no-throw guarantees: data() and c_str() simply return -a pointer to their guts, which is a non-failure operation. This should -be spelled out. It is also noteworthy to mention that the same -guarantees should also be given by the size query functions, -because the combination of pointer to content and the length is -typically needed during interaction with low-level API. -
      2. -
    2. -Missing complexity guarantees: data() and c_str() simply return -a pointer to their guts, which is guaranteed O(1). This should be -spelled out. -
      3. -
    3. -Missing reading access to the terminating character: Only the -const overload of operator[] allows reading access to the terminator -char. For more intuitive usage of strings, reading access to this -position should be extended to the non-const case. In contrast -to C++03 this reading access should now be homogeneously -an lvalue access. -
      4. -
    - -

    -The proposed resolution is split into a main part (A) and a -secondary part (B) (earlier called "Adjunct Adjunct Proposal"). -(B) extends (A) by also making access to index position -size() of the at() overloads a no-throw operation. This was -separated, because this part is theoretically observable in -specifically designed test programs. -

    - - -

    Proposed resolution:

    -
      -
    1. -
        -
      1. -

        In 21.3.4 [string.capacity], just after p. 1 add a new paragraph: -

        -
        -Throws: Nothing. -
        - -
        2. -
      2. -

        -In 21.3.5 [string.access] replace p. 1 by the following 4 paragraghs: -

        - -
        -

        -Requires: pos ≤ size(). -

        -

        -Returns: If pos < size(), returns *(begin() + pos). Otherwise, returns -a reference to a charT() that shall not be modified. -

        -

        -Throws: Nothing. -

        -

        -Complexity: Constant time. -

        -
        - -
        3. -
      3. -

        -In 21.3.7.1 [string.accessors] replace the now common returns -clause of c_str() and data() by the following three paragraphs: -

        -
        -

        -Returns: A pointer p such that p+i == &operator[](i) for each i -in [0, size()]. -

        -

        -Throws: Nothing. -

        -

        -Complexity: Constant time. -

        -
        -
        4. -
      -
      2. -
    2. -
        -
      1. -

        -In 21.3.5 [string.access] replace p.2 and p.3 by: -

        -
        -

        -Requires: pos ≤ size() -

        -

        -Throws: out_of_range if pos > size(). -

        -
        -
        2. -
      -
      3. -
    - - - - - - -
    -

    877. to throw() or to Throw: Nothing.

    -

    Section: 17 [library] Status: New - Submitter: Martin Sebor Date: 2008-08-23

    -

    View all other issues in [library].

    -

    View all issues with New status.

    -

    Discussion:

    -

    - -Recent changes to -the working -draft have introduced a gratuitous inconsistency with the C++ 2003 -version of the specification with respect to exception guarantees -provided by standard functions. While the C++ 2003 standard -consistenly uses the empty exception specification, throw(), -to declare functions that are guaranteed not to throw exceptions, the -current working draft contains a number of "Throws: Nothing." -clause to specify essentially the same requirement. The difference -between the two approaches is that the former specifies the behavior -of programs that violate the requirement (std::unexpected() -is called) while the latter leaves the behavior undefined. - -

    -

    - -A survey of the working draft reveals that there are a total of 209 -occurrences of throw() in the library portion of the spec, -the majority in clause 18, a couple (literally) in 19, a handful in -20, a bunch in 22, four in 24, one in 27, and about a dozen in D.9. - -

    -

    - -There are also 203 occurrences of "Throws: Nothing." scattered -throughout the spec. - -

    -

    - -While sometimes there are good reasons to use the "Throws: -Nothing." approach rather than making use of throw(), these -reasons do not apply in most of the cases where this new clause has -been introduced and the empty exception specification would be a -better approach. - -

    -

    - -First, functions declared with the empty exception specification -permit compilers to generate better code for calls to such -functions. In some cases, the compiler might even be able to eliminate -whole chunks of user-written code when instantiating a generic -template on a type whose operations invoked from the template -specialization are known not to throw. The prototypical example are -the std::uninitialized_copy() -and std::uninitialized_fill() algorithms where the -entire catch(...) block can be optimized away. - -

    -

    - -For example, given the following definition of -the std::uninitialized_copy function template and a -user-defined type SomeType: - -

    -
    - 
    template <class InputIterator, class ForwardIterator>
-ForwardIterator
-uninitialized_copy (InputIterator first, InputIterator last, ForwardIterator res)
-{
-   typedef iterator_traits<ForwardIterator>::value_type ValueType;
-
-   ForwardIterator start = res;
-
-   try {
-       for (; first != last; ++first, ++res)
-           ::new (&*res) ValueType (*first);
-   }
-   catch (...) {
-       for (; start != res; --start)
-           (&*start)->~ValueType ();
-       throw;
-   }
-   return res;
-}
-
-struct SomeType {
-   SomeType (const SomeType&) throw ();
-}
    -
    -

    - -compilers are able to emit the following efficient specialization -of std::uninitialized_copy<const SomeType*, SomeType*> -(note that the catch block has been optimized away): - -

    -
    - 
    template <> SomeType*
-uninitialized_copy (const SomeType *first, const SomeType *last, SomeType *res)
-{
-   for (; first != last; ++first, ++res)
-       ::new (res) SomeType (*first);
-
-   return res;
-}
    -
    -

    - -Another general example is default constructors which, when decorated -with throw(), allow the compiler to eliminate the -implicit try and catch blocks that it otherwise must -emit around each the invocation of the constructor -in new-expressions. - -

    -

    - -For example, given the following definitions of -class MayThrow and WontThrow and the two -statements below: - -

    -
    - 
    struct MayThrow {
-   MayThrow ();
-};
-
-struct WontThrow {
-   WontThrow () throw ();
-};
-
-MayThrow  *a = new MayThrow [N];
-WontThrow *b = new WontThrow [N];
    - -
    -

    - -the compiler generates the following code for the first statement: - -

    -
    - 
    MayThrow *a;
-{
-   MayThrow *first = operator new[] (N * sizeof (*a));
-   MayThrow *last  = first + N;
-   MayThrow *next  = first;
-   try {
-       for ( ; next != last; ++next)
-           new (next) MayThrow;
-   }
-   catch (...) {
-       for ( ; first != first; --next)
-           next->~MayThrow ();
-       operator delete[] (first);
-       throw;
-   }
-   a = first;
-}
    -
    -

    - -but it is can generate much more compact code for the second statement: - -

    -
    - 
    WontThrow *b    = operator new[] (N * sizeof (*b));
-WontThrow *last = b + N;
-for (WontThrow *next = b; next != last; ++next)
-   new (next) WontThrow;
-
    -
    -

    - -Second, in order for users to get the maximum benefit out of the new -std::has_nothrow_xxx traits when using standard library types -it will be important for implementations to decorate all non throwing -copy constructors and assignment operators with throw(). Note -that while an optimizer may be able to tell whether a function without -an explicit exception specification can throw or not based on its -definition, it can only do so when it can see the source code of the -definition. When it can't it must assume that the function may -throw. To prevent violating the One Definition Rule, -the std::has_nothrow_xxx trait must return the most -pessimistic guess across all translation units in the program, meaning -that std::has_nothrow_xxx<T>::value must evaluate to -false for any T whose xxx -(where xxx is default or copy ctor, or assignment operator) -is defined out-of-line. - -

    -

    - -Counterarguments: - -

    -

    - -During the discussion of this issue -on c++std-lib@accu.org -(starting with post c++std-lib-21950) the following arguments -in favor of the "Throws: Nothing." style have been made. - -

    -

    -

      -
    1. - -Decorating functions that cannot throw with the empty exception -specification can cause the compiler to generate suboptimal code for -the implementation of the function when it calls other functions that -aren't known to the compiler not to throw (i.e., that aren't decorated -with throw() even if they don't actually throw). This is a -common situation when the called function is a C or POSIX function. - -
      2. -
    2. - -Alternate, proprietary mechanisms exist (such as -GCC __attribute__((nothrow)) -or Visual -C++ __declspec(nothrow)) -that let implementers mark up non-throwing functions, often without -the penalty mentioned in (1) above. The C++ standard shouldn't -preclude the use of these potentially more efficient mechanisms. - -
      3. -
    3. - -There are functions, especially function templates, that invoke -user-defined functions that may or may not be -declared throw(). Declaring such functions with the empty -exception specification will cause compilers to generate suboptimal -code when the user-defined function isn't also declared not to throw. - -
      4. -
    - -

    - -The answer to point (1) above is that implementers can (and some have) -declare functions with throw() to indicate to the compiler -that calls to the function can safely be assumed not to throw in order -to allow it to generate efficient code at the call site without also -having to define the functions the same way and causing the compiler -to generate suboptimal code for the function definition. That is, the -function is declared with throw() in a header but it's -defined without it in the source file. The throw() -declaration is suppressed when compiling the definition to avoid -compiler errors. This technique, while strictly speaking no permitted -by the language, is safe and has been employed in practice. For -example, the GNU C library takes this approach. Microsoft Visual C++ -takes a similar approach by simply assuming that no function with C -language linkage can throw an exception unless it's explicitly -declared to do so using the language extension throw(...). - -

    -

    - -Our answer to point (2) above is that there is no existing practice -where C++ Standard Library implementers have opted to make use of the -proprietary mechanisms to declare functions that don't throw. The -language provides a mechanism specifically designed for this -purpose. Avoiding its use in the specification itself in favor of -proprietary mechanisms defeats the purpose of the feature. In -addition, making use of the empty exception specification -inconsistently, in some areas of the standard, while conspicuously -avoiding it and making use of the "Throws: Nothing." form in -others is confusing to users. - -

    -

    - -The answer to point (3) is simply to exercise caution when declaring -functions and especially function templates with the empty exception -specification. Functions that required not to throw but that may call -back into user code are poor candidates for the empty exception -specification and should instead be specified using "Throws: -Nothing." clause. - -

    - -

    Proposed resolution:

    -

    - -We propose two possible solutions. Our recommendation is to adopt -Option 1 below. - -

    -

    - -Option 1: - -

    -

    - -Except for functions or function templates that make calls back to -user-defined functions that may not be declared throw() -replace all occurrences of the "Throws: Nothing." clause with -the empty exception specification. Functions that are required not to -throw but that make calls back to user code should be specified to -"Throw: Nothing." - -

    -

    - -Option 2: - -

    -

    - -For consistency, replace all occurrences of the empty exception -specification with a "Throws: Nothing." clause. - -

    - - - - -
    -

    878. forward_list preconditions

    -

    Section: 23.2.3 [forwardlist] Status: New - Submitter: Martin Sebor Date: 2008-08-23

    -

    View all issues with New status.

    -

    Discussion:

    -

    - -forward_list member functions that take -a forward_list::iterator (denoted position in the -function signatures) argument have the following precondition: - -

    -
    - -Requires: position is dereferenceable or equal -to before_begin(). - -
    -

    - -I believe what's actually intended is this: - -

    -
    - -Requires: position is in the range -[before_begin(), end()). - -
    -

    - -That is, when it's dereferenceable, position must point -into *this, not just any forward_list object. - -

    - -

    Proposed resolution:

    -

    - -Change the Requires clause as follows: - -

    -
    - -Requires: position is in the range -[before_begin(), end()) dereferenceable -or equal to before_begin(). - -
    - - - - - \ No newline at end of file diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/lwg-closed.html b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/lwg-closed.html deleted file mode 100644 index a056c3ee2..000000000 --- a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/lwg-closed.html +++ /dev/null @@ -1,14016 +0,0 @@ - - - - - -C++ Standard Library Closed Issues List - - - - - - - - - - - - - - - - - - - -
    Doc. no.N2729=08-0239
    Date:2008-08-24
    Project:Programming Language C++
    Reply to:Howard Hinnant <howard.hinnant@gmail.com>
    -

    C++ Standard Library Closed Issues List (Revision R59)

    - -

    Reference ISO/IEC IS 14882:1998(E)

    -

    Also see:

    - - -

    This document contains only library issues which have been closed - by the Library Working Group as duplicates or not defects. That is, - issues which have a status of Dup or - NAD. See the Library Active Issues List active issues and more - information. See the Library Defect Reports List for issues considered - defects. The introductory material in that document also applies to - this document.

    - -

    Revision History

    -
      -
    • R59: -2008-08-22 pre-San Francisco mailing. -
        -
      • Summary:
          -
        • 192 open issues, up by 9.
          • -
        • 686 closed issues, up by 0.
          • -
        • 878 issues total, up by 9.
          • -
        • -
      • Details:
        • -
      -
      • -
    • R58: -2008-07-28 mid-term mailing. -
        -
      • Summary:
          -
        • 183 open issues, up by 12.
          • -
        • 686 closed issues, down by 4.
          • -
        • 869 issues total, up by 8.
          • -
        • -
      • Details:
          -
        • Added the following New issues: 862, 863, 864, 865, 866, 867, 868, 869.
          • -
        • Changed the following issues from Pending NAD Editorial to NAD Editorial: 393, 557, 592, 754, 757.
          • -
        • Changed the following issues from Pending WP to Open: 644.
          • -
        • Changed the following issues from WP to Ready: 387, 629.
          • -
        • Changed the following issues from Pending NAD Editorial to Review: 709.
          • -
        • -
      -
      • -
    • R57: -2008-06-27 post-Sophia Antipolis mailing. - -
      • -
    • R56: -2008-05-16 pre-Sophia Antipolis mailing. - -
      • -
    • R55: -2008-03-14 post-Bellevue mailing. - -
      • -
    • R54: -2008-02-01 pre-Bellevue mailing. -
        -
      • Summary:
          -
        • 206 open issues, up by 23.
          • -
        • 581 closed issues, up by 0.
          • -
        • 787 issues total, up by 23.
          • -
        • -
      • Details:
          -
        • Added the following New issues: 765, 766, 767, 768, 769, 770, 771, 772, 773, 774, 775, 776, 777, 778, 779, 780, 781, 782, 783, 784, 785, 786, 787.
          • -
        • Changed the following issues from NAD Future to Dup: 105, 348.
          • -
        • Changed the following issues from NAD Future to NAD Editorial: 353.
          • -
        • Changed the following issues from New to NAD Editorial: 697.
          • -
        • Changed the following issues from NAD Future to Open: 388.
          • -
        • Changed the following issues from Open to Tentatively Ready: 527.
          • -
        • -
      -
      • -
    • R53: -2007-12-09 mid-term mailing. -
        -
      • Summary:
          -
        • 183 open issues, up by 11.
          • -
        • 581 closed issues, down by 1.
          • -
        • 764 issues total, up by 10.
          • -
        • -
      • Details:
        • -
      -
      • -
    • R52: -2007-10-19 post-Kona mailing. - -
      • -
    • R51: -2007-09-09 pre-Kona mailing. - -
      • -
    • R50: -2007-08-05 post-Toronto mailing. -
        -
      • Summary:
          -
        • 153 open issues, down by 5.
          • -
        • 555 closed issues, up by 17.
          • -
        • 708 issues total, up by 12.
          • -
        • -
      • Details:
          -
        • Added the following New issues: 697, 698, 699, 700, 701, 702, 703, 704, 705, 706, 707, 708.
          • -
        • Changed the following issues from New to NAD: 583, 584, 662.
          • -
        • Changed the following issues from Open to NAD: 528.
          • -
        • Changed the following issues from New to NAD Editorial: 637, 647, 658, 690.
          • -
        • Changed the following issues from Open to NAD Editorial: 525.
          • -
        • Changed the following issues from Pending NAD Editorial to NAD Editorial: 553, 571, 591, 633, 636, 641, 642, 648, 649, 656.
          • -
        • Changed the following issues from New to Open: 579, 631, 680.
          • -
        • Changed the following issues from Pending WP to Open: 258.
          • -
        • Changed the following issues from Ready to Pending WP: 644.
          • -
        • Changed the following issues from New to Ready: 577, 660.
          • -
        • Changed the following issues from Open to Ready: 488.
          • -
        • Changed the following issues from Open to Review: 518.
          • -
        • Changed the following issues from Ready to TRDec: 604.
          • -
        • Changed the following issues from DR to WP: 453.
          • -
        • Changed the following issues from Ready to WP: 531, 551, 566, 628, 640, 643, 646.
          • -
        • -
      -
      • -
    • R49: -2007-06-23 pre-Toronto mailing. -
        -
      • Summary:
          -
        • 158 open issues, up by 13.
          • -
        • 538 closed issues, up by 7.
          • -
        • 696 issues total, up by 20.
          • -
        • -
      • Details:
          -
        • Added the following New issues: 677, 678, 679, 680, 681, 682, 684, 685, 686, 687, 688, 689, 690, 691, 692, 693, 694, 695, 696.
          • -
        • Added the following Pending NAD Editorial issues: 683.
          • -
        • Changed the following issues from New to NAD Editorial: 587.
          • -
        • Changed the following issues from Open to NAD Editorial: 590.
          • -
        • Changed the following issues from New to Pending NAD Editorial: 636, 642, 648, 649.
          • -
        • -
      -
      • -
    • R48: -2007-05-06 post-Oxford mailing. - -
      • -
    • R47: -2007-03-09 pre-Oxford mailing. - -
      • -
    • R46: -2007-01-12 mid-term mailing. -
        -
      • Summary:
          -
        • 141 open issues, up by 11.
          • -
        • 478 closed issues, down by 1.
          • -
        • 619 issues total, up by 10.
          • -
        • -
      • Details:
        • -
      -
      • -
    • R45: -2006-11-03 post-Portland mailing. - -
      • -
    • R44: -2006-09-08 pre-Portland mailing. -
        -
      • Summary:
          -
        • 130 open issues, up by 6.
          • -
        • 462 closed issues, down by 1.
          • -
        • 592 issues total, up by 5.
          • -
        • -
      • Details:
        • -
      -
      • -
    • R43: -2006-06-23 mid-term mailing. -
        -
      • Summary:
          -
        • 124 open issues, up by 14.
          • -
        • 463 closed issues, down by 1.
          • -
        • 587 issues total, up by 13.
          • -
        • -
      • Details:
        • -
      -
      • -
    • R42: -2006-04-21 post-Berlin mailing. - -
      • -
    • R41: -2006-02-24 pre-Berlin mailing. -
        -
      • Summary:
          -
        • 126 open issues, up by 31.
          • -
        • 440 closed issues, up by 0.
          • -
        • 566 issues total, up by 31.
          • -
        • -
      • Details:
          -
        • Added new issues 536-566.
          • -
        • Moved 342 from Ready to Open.
          • -
        • Reopened 309.
          • -
        • -
      -
      • -
    • R40: -2005-12-16 mid-term mailing. -
        -
      • Summary:
          -
        • 95 open issues.
          • -
        • 440 closed issues.
          • -
        • 535 issues total.
          • -
        • -
      • Details:
        • -
      -
      • -
    • R39: -2005-10-14 post-Mont Tremblant mailing. -Added new issues 526-528. -Moved issues 280, 461, 464, 465, 467, 468, 474, 496 from Ready to WP as per the vote from Mont Tremblant. -Moved issues 247, 294, 342, 362, 369, 371, 376, 384, 475, 478, 495, 497 from Review to Ready. -Moved issues 498, 504, 506, 509, 510, 511, 512, 513, 514 from New to Open. -Moved issues 505, 507, 508, 519 from New to Ready. -Moved issue 500 from New to NAD. -Moved issue 518 from New to Review. -
      • -
    • R38: -2005-07-03 pre-Mont Tremblant mailing. -Merged open TR1 issues in 504-522. -Added new issues 523-523 -
      • -
    • R37: -2005-06 mid-term mailing. -Added new issues 498-503. -
      • -
    • R36: -2005-04 post-Lillehammer mailing. All issues in "ready" status except -for 454 were moved to "DR" status, and all issues -previously in "DR" status were moved to "WP". -
      • -
    • R35: -2005-03 pre-Lillehammer mailing. -
      • -
    • R34: -2005-01 mid-term mailing. Added new issues 488-494. -
      • -
    • R33: -2004-11 post-Redmond mailing. Reflects actions taken in Redmond. -
      • -
    • R32: -2004-09 pre-Redmond mailing: reflects new proposed resolutions and -new issues received after the 2004-07 mailing. Added -new issues 479-481. -
      • -
    • R31: -2004-07 mid-term mailing: reflects new proposed resolutions and -new issues received after the post-Sydney mailing. Added -new issues 463-478. -
      • -
    • R30: -Post-Sydney mailing: reflects decisions made at the Sydney meeting. -Voted all "Ready" issues from R29 into the working paper. -Added new issues 460-462. -
      • -
    • R29: -Pre-Sydney mailing. Added new issues 441-457. -
      • -
    • R28: -Post-Kona mailing: reflects decisions made at the Kona meeting. -Added new issues 432-440. -
      • -
    • R27: -Pre-Kona mailing. Added new issues 404-431. -
      • -
    • R26: -Post-Oxford mailing: reflects decisions made at the Oxford meeting. -All issues in Ready status were voted into DR status. All issues in -DR status were voted into WP status. -
      • -
    • R25: -Pre-Oxford mailing. Added new issues 390-402. -
      • -
    • R24: -Post-Santa Cruz mailing: reflects decisions made at the Santa Cruz -meeting. All Ready issues from R23 with the exception of 253, which has been given a new proposed resolution, were -moved to DR status. Added new issues 383-389. (Issues 387-389 were discussed -at the meeting.) Made progress on issues 225, 226, 229: 225 and 229 have been moved to Ready status, and the only remaining -concerns with 226 involve wording. -
      • -
    • R23: -Pre-Santa Cruz mailing. Added new issues 367-382. -Moved issues in the TC to TC status. -
      • -
    • R22: -Post-Curaçao mailing. Added new issues 362-366. -
      • -
    • R21: -Pre-Curaçao mailing. Added new issues 351-361. -
      • -
    • R20: -Post-Redmond mailing; reflects actions taken in Redmond. Added -new issues 336-350, of which issues -347-350 were added since Redmond, hence -not discussed at the meeting. - -All Ready issues were moved to DR status, with the exception of issues -284, 241, and 267. - -Noteworthy issues discussed at Redmond include -120 202, 226, 233, -270, 253, 254, 323. -
      • -
    • R19: -Pre-Redmond mailing. Added new issues -323-335. -
      • -
    • R18: -Post-Copenhagen mailing; reflects actions taken in Copenhagen. -Added new issues 312-317, and discussed -new issues 271-314. - -Changed status of issues -103 118 136 153 -165 171 183 184 -185 186 214 221 -234 237 243 248 -251 252 256 260 -261 262 263 265 -268 -to DR. - -Changed status of issues -49 109 117 182 -228 230 232 235 -238 241 242 250 -259 264 266 267 -271 272 273 275 -281 284 285 286 -288 292 295 297 -298 301 303 306 -307 308 312 -to Ready. - -Closed issues -111 277 279 287 -289 293 302 313 -314 -as NAD. - -
      • -
    • R17: -Pre-Copenhagen mailing. Converted issues list to XML. Added proposed -resolutions for issues 49, 76, 91, 235, 250, 267. -Added new issues 278-311. -
      • -
    • R16: -post-Toronto mailing; reflects actions taken in Toronto. Added new -issues 265-277. Changed status of issues -3, 8, 9, 19, -26, 31, 61, -63, 86, 108, -112, 114, 115, -122, 127, 129, -134, 137, 142, -144, 146, 147, -159, 164, 170, -181, 199, 208, -209, 210, 211, -212, 217, 220, -222, 223, 224, -227 to "DR". Reopened issue 23. Reopened -issue 187. Changed issues 2 and -4 to NAD. Fixed a typo in issue 17. Fixed -issue 70: signature should be changed both places it -appears. Fixed issue 160: previous version didn't fix -the bug in enough places. -
      • -
    • R15: -pre-Toronto mailing. Added issues -233-264. Some small HTML formatting -changes so that we pass Weblint tests. -
      • -
    • R14: -post-Tokyo II mailing; reflects committee actions taken in -Tokyo. Added issues 228 to 232. (00-0019R1/N1242) -
      • -
    • R13: -pre-Tokyo II updated: Added issues 212 to 227. -
      • -
    • R12: -pre-Tokyo II mailing: Added issues 199 to -211. Added "and paragraph 5" to the proposed resolution -of issue 29. Add further rationale to issue -178. -
      • -
    • R11: -post-Kona mailing: Updated to reflect LWG and full committee actions -in Kona (99-0048/N1224). Note changed resolution of issues -4 and 38. Added issues 196 -to 198. Closed issues list split into "defects" and -"closed" documents. Changed the proposed resolution of issue -4 to NAD, and changed the wording of proposed resolution -of issue 38. -
      • -
    • R10: -pre-Kona updated. Added proposed resolutions 83, -86, 91, 92, -109. Added issues 190 to -195. (99-0033/D1209, 14 Oct 99) -
      • -
    • R9: -pre-Kona mailing. Added issues 140 to -189. Issues list split into separate "active" and -"closed" documents. (99-0030/N1206, 25 Aug 99) -
      • -
    • R8: -post-Dublin mailing. Updated to reflect LWG and full committee actions -in Dublin. (99-0016/N1193, 21 Apr 99) -
      • -
    • R7: -pre-Dublin updated: Added issues 130, 131, -132, 133, 134, -135, 136, 137, -138, 139 (31 Mar 99) -
      • -
    • R6: -pre-Dublin mailing. Added issues 127, 128, -and 129. (99-0007/N1194, 22 Feb 99) -
      • -
    • R5: -update issues 103, 112; added issues -114 to 126. Format revisions to prepare -for making list public. (30 Dec 98) -
      • -
    • R4: -post-Santa Cruz II updated: Issues 110, -111, 112, 113 added, several -issues corrected. (22 Oct 98) -
      • -
    • R3: -post-Santa Cruz II: Issues 94 to 109 -added, many issues updated to reflect LWG consensus (12 Oct 98) -
      • -
    • R2: -pre-Santa Cruz II: Issues 73 to 93 added, -issue 17 updated. (29 Sep 98) -
      • -
    • R1: -Correction to issue 55 resolution, 60 code -format, 64 title. (17 Sep 98) -
      • -
    - -

    Closed Issues

    -
    -

    2. Auto_ptr conversions effects incorrect

    -

    Section: D.9.1.3 [auto.ptr.conv] Status: NAD - Submitter: Nathan Myers Date: 1997-12-04

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    Paragraph 1 in "Effects", says "Calls -p->release()" where it clearly must be "Calls -p.release()". (As it is, it seems to require using -auto_ptr<>::operator-> to refer to X::release, assuming that -exists.)

    - - -

    Proposed resolution:

    -

    Change 20.5.4.3 [meta.unary.prop] paragraph 1 Effects from -"Calls p->release()" to "Calls p.release()".

    - - -

    Rationale:

    -

    Not a defect: the proposed change is already found in the standard. -[Originally classified as a defect, later reclassified.]

    - - - - - -
    -

    4. Basic_string size_type and difference_type should be implementation defined

    -

    Section: 21.3 [basic.string] Status: NAD - Submitter: Beman Dawes Date: 1997-11-16

    -

    View other active issues in [basic.string].

    -

    View all other issues in [basic.string].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    In Morristown we changed the size_type and difference_type typedefs -for all the other containers to implementation defined with a -reference to 23.1 [container.requirements]. This should probably also have been -done for strings.

    - - -

    Rationale:

    -

    Not a defect. [Originally classified as a defect, later -reclassified.] basic_string, unlike the other standard library -template containers, is severely constrained by its use of -char_traits. Those types are dictated by the traits class, and are far -from implementation defined.

    - - - - - -
    -

    6. File position not an offset unimplementable

    -

    Section: 27.4.3 [fpos] Status: NAD - Submitter: Matt Austern Date: 1997-12-15

    -

    View all other issues in [fpos].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    Table 88, in I/O, is too strict; it's unimplementable on systems -where a file position isn't just an offset. It also never says just -what fpos<> is really supposed to be. [Here's my summary, which -Jerry agrees is more or less accurate. "I think I now know what -the class really is, at this point: it's a magic cookie that -encapsulates an mbstate_t and a file position (possibly represented as -an fpos_t), it has syntactic support for pointer-like arithmetic, and -implementors are required to have real, not just syntactic, support -for arithmetic." This isn't standardese, of course.]

    - - -

    Rationale:

    -

    Not a defect. The LWG believes that the Standard is already clear, -and that the above summary is what the Standard in effect says.

    - - - - - -
    -

    10. Codecvt<>::do unclear

    -

    Section: 22.2.1.5 [locale.codecvt.byname] Status: Dup - Submitter: Matt Austern Date: 1998-01-14

    -

    View all other issues in [locale.codecvt.byname].

    -

    View all issues with Dup status.

    -

    Duplicate of: 19

    -

    Discussion:

    -

    Section 22.2.1.5.2 says that codecvt<>::do_in and do_out -should return the value noconv if "no conversion was -needed". However, I don't see anything anywhere that defines what -it means for a conversion to be needed or not needed. I can think of -several circumstances where one might plausibly think that a -conversion is not "needed", but I don't know which one is -intended here.

    - - -

    Rationale:

    - - - - - - -
    -

    12. Way objects hold allocators unclear

    -

    Section: 20.1.2 [allocator.requirements] Status: NAD - Submitter: Angelika Langer Date: 1998-02-23

    -

    View other active issues in [allocator.requirements].

    -

    View all other issues in [allocator.requirements].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    I couldn't find a statement in the standard saying whether the allocator object held by -a container is held as a copy of the constructor argument or whether a pointer of -reference is maintained internal. There is an according statement for compare objects and -how they are maintained by the associative containers, but I couldn't find anything -regarding allocators.

    - -

    Did I overlook it? Is it an open issue or known defect? Or is it deliberately left -unspecified?

    - - -

    Rationale:

    -

    Not a defect. The LWG believes that the Standard is already -clear.  See 23.1 [container.requirements], paragraph 8.

    - - - - - -
    -

    43. Locale table correction

    -

    Section: 22.2.1.5 [locale.codecvt.byname] Status: Dup - Submitter: Brendan Kehoe Date: 1998-06-01

    -

    View all other issues in [locale.codecvt.byname].

    -

    View all issues with Dup status.

    -

    Duplicate of: 33

    -

    Discussion:

    - - -

    Rationale:

    - - - - - - -
    -

    45. Stringstreams read/write pointers initial position unclear

    -

    Section: 27.7.3 [ostringstream] Status: NAD - Submitter: Matthias Mueller Date: 1998-05-27

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    In a comp.lang.c++.moderated Matthias Mueller wrote:

    - -

    "We are not sure how to interpret the CD2 (see 27.2 -[iostream.forward], 27.7.3.1 [ostringstream.cons], 27.7.1.1 -[stringbuf.cons]) -with respect to the question as to what the correct initial positions -of the write and  read pointers of a stringstream should -be."

    - -

    "Is it the same to output two strings or to initialize the stringstream with the -first and to output the second?"

    - -

    [PJ Plauger, Bjarne Stroustrup, Randy Smithey, Sean Corfield, and -Jerry Schwarz have all offered opinions; see reflector messages -lib-6518, 6519, 6520, 6521, 6523, 6524.]

    - - - - -

    Rationale:

    -

    The LWG believes the Standard is correct as written. The behavior -of stringstreams is consistent with fstreams, and there is a -constructor which can be used to obtain the desired effect. This -behavior is known to be different from strstreams.

    - - - - - -
    -

    58. Extracting a char from a wide-oriented stream

    -

    Section: 27.6.1.2.3 [istream::extractors] Status: NAD - Submitter: Matt Austern Date: 1998-07-01

    -

    View all other issues in [istream::extractors].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    27.6.1.2.3 has member functions for extraction of signed char and -unsigned char, both singly and as strings. However, it doesn't say -what it means to extract a char from a -basic_streambuf<charT, Traits>.

    - -

    basic_streambuf, after all, has no members to extract a char, so -basic_istream must somehow convert from charT to signed char or -unsigned char. The standard doesn't say how it is to perform that -conversion.

    - - -

    Rationale:

    -

    The Standard is correct as written. There is no such extractor and -this is the intent of the LWG.

    - - - - -
    -

    65. Underspecification of strstreambuf::seekoff

    -

    Section: D.7.1.3 [depr.strstreambuf.virtuals] Status: NAD - Submitter: Matt Austern Date: 1998-08-18

    -

    View all other issues in [depr.strstreambuf.virtuals].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    The standard says how this member function affects the current -stream position. (gptr or pptr) However, it does not -say how this member function affects the beginning and end of the -get/put area.

    - -

    This is an issue when seekoff is used to position the get pointer -beyond the end of the current read area. (Which is legal. This is -implicit in the definition of seekhigh in D.7.1, paragraph 4.) -

    - - -

    Rationale:

    -

    The LWG agrees that seekoff() is underspecified, but does not wish -to invest effort in this deprecated feature.

    - - - - - -
    -

    67. Setw useless for strings

    -

    Section: 21.3.8.9 [string.io] Status: Dup - Submitter: Steve Clamage Date: 1998-07-09

    -

    View all other issues in [string.io].

    -

    View all issues with Dup status.

    -

    Duplicate of: 25

    -

    Discussion:

    -

    In a comp.std.c++ posting Michel Michaud wrote: What -should be output by:

    - -
       string text("Hello");
-   cout << '[' << setw(10) << right << text << ']';
-
    - -

    Shouldn't it be:

    - -
       [     Hello]
    - -

    Another person replied: Actually, according to the FDIS, the width -of the field should be the minimum of width and the length of the -string, so the output shouldn't have any padding. I think that this is -a typo, however, and that what is wanted is the maximum of the -two. (As written, setw is useless for strings. If that had been the -intent, one wouldn't expect them to have mentioned using its value.) -

    - -

    It's worth pointing out that this is a recent correction anyway; -IIRC, earlier versions of the draft forgot to mention formatting -parameters whatsoever.

    - - -

    Rationale:

    - - - - - - -
    -

    72. Do_convert phantom member function

    -

    Section: 22.2.1.4 [locale.codecvt] Status: Dup - Submitter: Nathan Myers Date: 1998-08-24

    -

    View all other issues in [locale.codecvt].

    -

    View all issues with Dup status.

    -

    Duplicate of: 24

    -

    Discussion:

    -

    In 22.2.1.4 [locale.codecvt] par 3, and in 22.2.1.4.2 [locale.codecvt.virtuals] par 8, a nonexistent member function -"do_convert" is mentioned. This member was replaced with -"do_in" and "do_out", the proper referents in the -contexts above.

    - - -

    Rationale:

    - - - - - -
    -

    73. is_open should be const

    -

    Section: 27.8.1 [fstreams] Status: NAD - Submitter: Matt Austern Date: 1998-08-27

    -

    View all other issues in [fstreams].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    Classes basic_ifstream, basic_ofstream, and -basic_fstream all have a member function is_open. It -should be a const member function, since it does nothing but -call one of basic_filebuf's const member functions.

    - - -

    Rationale:

    -

    Not a defect. This is a deliberate feature; const streams would be -meaningless.

    - - - - -
    -

    77. Valarray operator[] const returning value

    -

    Section: 26.5.2.3 [valarray.access] Status: Dup - Submitter: Levente Farkas Date: 1998-09-09

    -

    View all other issues in [valarray.access].

    -

    View all issues with Dup status.

    -

    Duplicate of: 389

    -

    Discussion:

    -

    valarray:
    -
    -    T operator[] (size_t) const;
    -
    -why not
    -
    -    const T& operator[] (size_t) const;
    -
    -as in vector ???
    -
    -One can't copy even from a const valarray eg:
    -
    -    memcpy(ptr, &v[0], v.size() * sizeof(double));
    -
    -[I] find this bug in valarray is very difficult.

    - - -

    Rationale:

    -

    The LWG believes that the interface was deliberately designed that -way. That is what valarray was designed to do; that's where the -"value array" name comes from. LWG members further comment -that "we don't want valarray to be a full STL container." -26.5.2.3 [valarray.access] specifies properties that indicate "an -absence of aliasing" for non-constant arrays; this allows -optimizations, including special hardware optimizations, that are not -otherwise possible.

    - - - - - -
    -

    81. Wrong declaration of slice operations

    -

    Section: 26.5.5 [template.slice.array], 26.5.7 [template.gslice.array], 26.5.8 [template.mask.array], 26.5.9 [template.indirect.array] Status: NAD - Submitter: Nico Josuttis Date: 1998-09-29

    -

    View all other issues in [template.slice.array].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    Isn't the definition of copy constructor and assignment operators wrong? -       Instead of

    - -
          slice_array(const slice_array&); 
-      slice_array& operator=(const slice_array&);
    - -

    IMHO they have to be

    - -
          slice_array(const slice_array<T>&); 
-      slice_array& operator=(const slice_array<T>&);
    - -

    Same for gslice_array.

    - - -

    Rationale:

    -

    Not a defect. The Standard is correct as written.

    - - - - -
    -

    82. Missing constant for set elements

    -

    Section: 23.1.4 [associative.reqmts] Status: NAD - Submitter: Nico Josuttis Date: 1998-09-29

    -

    View all other issues in [associative.reqmts].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    Paragraph 5 specifies:

    - -

    -For set and multiset the value type is the same as the key type. For -map and multimap it is equal to pair<const Key, T>. -

    - -

    Strictly speaking, this is not correct because for set and multiset -the value type is the same as the constant key type.

    - - -

    Rationale:

    -

    Not a defect. The Standard is correct as written; it uses a -different mechanism (const &) for set and -multiset. See issue 103 for a related -issue.

    - - - - -
    -

    84. Ambiguity with string::insert()

    -

    Section: 21.3.5 [string.access] Status: NAD - Submitter: Nico Josuttis Date: 1998-09-29

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    If I try

    -
        s.insert(0,1,' ');
    - -

      I get an nasty ambiguity. It might be

    -
        s.insert((size_type)0,(size_type)1,(charT)' ');
    - -

    which inserts 1 space character at position 0, or

    -
        s.insert((char*)0,(size_type)1,(charT)' ')
    - -

    which inserts 1 space character at iterator/address 0 (bingo!), or

    -
        s.insert((char*)0, (InputIterator)1, (InputIterator)' ')
    - -

    which normally inserts characters from iterator 1 to iterator ' -'. But according to 23.1.1.9 (the "do the right thing" fix) -it is equivalent to the second. However, it is still ambiguous, -because of course I mean the first!

    - - -

    Rationale:

    -

    Not a defect. The LWG believes this is a "genetic -misfortune" inherent in the design of string and thus not a -defect in the Standard as such .

    - - - - -
    -

    85. String char types

    -

    Section: 21 [strings] Status: NAD - Submitter: Nico Josuttis Date: 1998-09-29

    -

    View all other issues in [strings].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    The standard seems not to require that charT is equivalent to -traits::char_type. So, what happens if charT is not equivalent to -traits::char_type?

    - - -

    Rationale:

    -

    There is already wording in 21.1 [char.traits] paragraph 3 that -requires them to be the same.

    - - - - -
    -

    87. Error in description of string::compare()

    -

    Section: 21.3.6.8 [string::swap] Status: Dup - Submitter: Nico Josuttis Date: 1998-09-29

    -

    View all other issues in [string::swap].

    -

    View all issues with Dup status.

    -

    Duplicate of: 5

    -

    Discussion:

    -

    The following compare() description is obviously a bug:

    - -
    int compare(size_type pos, size_type n1, 
-            charT *s, size_type n2 = npos) const;
-
    - -

    because without passing n2 it should compare up to the end of the -string instead of comparing npos characters (which throws an -exception)

    - - -

    Rationale:

    - - - - - -
    -

    88. Inconsistency between string::insert() and string::append()

    -

    Section: 21.3.6.4 [string::insert], 21.3.6.2 [string::append] Status: NAD - Submitter: Nico Josuttis Date: 1998-09-29

    -

    View all other issues in [string::insert].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    Why does

    -
      template<class InputIterator> 
-       basic_string& append(InputIterator first, InputIterator last);
    - -

    return a string, while

    -
      template<class InputIterator> 
-       void insert(iterator p, InputIterator first, InputIterator last);
    - -

    returns nothing ?

    - - -

    Rationale:

    -

    The LWG believes this stylistic inconsistency is not sufficiently -serious to constitute a defect.

    - - - - -
    -

    89. Missing throw specification for string::insert() and string::replace()

    -

    Section: 21.3.6.4 [string::insert], 21.3.6.6 [string::replace] Status: Dup - Submitter: Nico Josuttis Date: 1998-09-29

    -

    View all other issues in [string::insert].

    -

    View all issues with Dup status.

    -

    Duplicate of: 83

    -

    Discussion:

    -

    All insert() and replace() members for strings with an iterator as -first argument lack a throw specification. The throw -specification should probably be: length_error if size exceeds -maximum.

    - - -

    Rationale:

    -

    Considered a duplicate because it will be solved by the resolution -of issue 83.

    - - - - - -
    -

    93. Incomplete Valarray Subset Definitions

    -

    Section: 26.5 [numarray] Status: NAD - Submitter: Nico Josuttis Date: 1998-09-29

    -

    View all other issues in [numarray].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    You can easily create subsets, but you can't easily combine them -with other subsets. Unfortunately, you almost always needs an -explicit type conversion to valarray. This is because the standard -does not specify that valarray subsets provide the same operations as -valarrays.

    - -

    For example, to multiply two subsets and assign the result to a third subset, you can't -write the following:

    - -
    va[slice(0,4,3)] = va[slice(1,4,3)] * va[slice(2,4,3)];
    - -

    Instead, you have to code as follows:

    - -
    va[slice(0,4,3)] = static_cast<valarray<double> >(va[slice(1,4,3)]) * 
-                   static_cast<valarray<double> >(va[slice(2,4,3)]);
    - -

    This is tedious and error-prone. Even worse, it costs performance because each cast -creates a temporary objects, which could be avoided without the cast.

    - - -

    Proposed resolution:

    -

    Extend all valarray subset types so that they offer all valarray operations.

    - - -

    Rationale:

    -

    This is not a defect in the Standard; it is a request for an extension.

    - - - - -
    -

    94. May library implementors add template parameters to Standard Library classes?

    -

    Section: 17.4.4 [conforming] Status: NAD - Submitter: Matt Austern Date: 1998-01-22

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    Is it a permitted extension for library implementors to add template parameters to -standard library classes, provided that those extra parameters have defaults? For example, -instead of defining template <class T, class Alloc = allocator<T> > class -vector; defining it as template <class T, class Alloc = allocator<T>, -int N = 1> class vector;

    - -

    The standard may well already allow this (I can't think of any way that this extension -could break a conforming program, considering that users are not permitted to -forward-declare standard library components), but it ought to be explicitly permitted or -forbidden.

    - -

    comment from Steve Cleary via comp.std.c++:

    -
    -

    I disagree [with the proposed resolution] for the following reason: -consider user library code with template template parameters. For -example, a user library object may be templated on the type of -underlying sequence storage to use (deque/list/vector), since these -classes all take the same number and type of template parameters; this -would allow the user to determine the performance tradeoffs of the -user library object. A similar example is a user library object -templated on the type of underlying set storage (set/multiset) or map -storage (map/multimap), which would allow users to change (within -reason) the semantic meanings of operations on that object.

    -

    I think that additional template parameters should be forbidden in -the Standard classes. Library writers don't lose any expressive power, -and can still offer extensions because additional template parameters -may be provided by a non-Standard implementation class:

    -
     
-   template <class T, class Allocator = allocator<T>, int N = 1>
-   class __vector
-   { ... };
-   template <class T, class Allocator = allocator<T> >
-   class vector: public __vector<T, Allocator>
-   { ... };
-
    - -
    - - - -

    Proposed resolution:

    -

    Add a new subclause [presumably 17.4.4.9] following 17.4.4.9 [res.on.exception.handling]:

    - -
    -

    17.4.4.9 Template Parameters

    A specialization of a - template class described in the C++ Standard Library behaves the - same as if the implementation declares no additional template - parameters.

    Footnote: Additional template parameters with - default values are thus permitted.

    -
    - -

    Add "template parameters" to the list of subclauses at -the end of 17.4.4 [conforming] paragraph 1.

    - -

    [Kona: The LWG agreed the standard needs clarification. After -discussion with John Spicer, it seems added template parameters can be -detected by a program using template-template parameters. A straw vote -- "should implementors be allowed to add template -parameters?" found no consensus ; 5 - yes, 7 - no.]

    - - - - -

    Rationale:

    -

    -There is no ambiguity; the standard is clear as written. Library -implementors are not permitted to add template parameters to standard -library classes. This does not fall under the "as if" rule, -so it would be permitted only if the standard gave explicit license -for implementors to do this. This would require a change in the -standard. -

    - -

    -The LWG decided against making this change, because it would break -user code involving template template parameters or specializations -of standard library class templates. -

    - - - - - -
    -

    95. Members added by the implementation

    -

    Section: 17.4.4.4 [member.functions] Status: NAD - Submitter: AFNOR Date: 1998-10-07

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    In 17.3.4.4/2 vs 17.3.4.7/0 there is a hole; an implementation could add virtual -members a base class and break user derived classes.

    - -

    Example:

    - -
    - 
    // implementation code:
-struct _Base { // _Base is in the implementer namespace
-        virtual void foo ();
-};
-class vector : _Base // deriving from a class is allowed
-{ ... };
-
-// user code:
-class vector_checking : public vector 
-{
-        void foo (); // don't want to override _Base::foo () as the 
-                     // user doesn't know about _Base::foo ()
-};
    -
    - - -

    Proposed resolution:

    -

    Clarify the wording to make the example illegal.

    - - -

    Rationale:

    -

    This is not a defect in the Standard.  The example is already -illegal.  See 17.4.4.4 [member.functions] paragraph 2.

    - - - - -
    -

    97. Insert inconsistent definition

    -

    Section: 23 [containers] Status: NAD - Submitter: AFNOR Date: 1998-10-07

    -

    View other active issues in [containers].

    -

    View all other issues in [containers].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    insert(iterator, const value_type&) is defined both on -sequences and on set, with unrelated semantics: insert here (in -sequences), and insert with hint (in associative containers). They -should have different names (B.S. says: do not abuse overloading).

    - - -

    Rationale:

    -

    This is not a defect in the Standard. It is a genetic misfortune of -the design, for better or for worse.

    - - - - -
    -

    99. Reverse_iterator comparisons completely wrong

    -

    Section: 24.4.1.3.13 [reverse.iter.op==] Status: NAD - Submitter: AFNOR Date: 1998-10-07

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    The <, >, <=, >= comparison operator are wrong: they -return the opposite of what they should.

    - -

    Note: same problem in CD2, these were not even defined in CD1. SGI -STL code is correct; this problem is known since the Morristown -meeting but there it was too late

    - - -

    Rationale:

    -

    This is not a defect in the Standard. A careful reading shows the Standard is correct -as written. A review of several implementations show that they implement -exactly what the Standard says.

    - - - - -
    -

    100. Insert iterators/ostream_iterators overconstrained

    -

    Section: 24.4.2 [insert.iterators], 24.5.4 [ostreambuf.iterator] Status: NAD - Submitter: AFNOR Date: 1998-10-07

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    Overspecified For an insert iterator it, the expression *it is -required to return a reference to it. This is a simple possible -implementation, but as the SGI STL documentation says, not the only -one, and the user should not assume that this is the case.

    - - -

    Rationale:

    -

    The LWG believes this causes no harm and is not a defect in the -standard. The only example anyone could come up with caused some -incorrect code to work, rather than the other way around.

    - - - - - -
    -

    101. No way to free storage for vector and deque

    -

    Section: 23.2.6 [vector], 23.2.1 [array] Status: NAD - Submitter: AFNOR Date: 1998-10-07

    -

    View all other issues in [vector].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    Reserve can not free storage, unlike string::reserve

    - - -

    Rationale:

    -

    This is not a defect in the Standard. The LWG has considered this -issue in the past and sees no need to change the Standard. Deque has -no reserve() member function. For vector, shrink-to-fit can be -expressed in a single line of code (where v is -vector<T>): -

    - -
    -

    vector<T>(v).swap(v);  // shrink-to-fit v

    -
    - - - - - -
    -

    102. Bug in insert range in associative containers

    -

    Section: 23.1.4 [associative.reqmts] Status: Dup - Submitter: AFNOR Date: 1998-10-07

    -

    View all other issues in [associative.reqmts].

    -

    View all issues with Dup status.

    -

    Duplicate of: 264

    -

    Discussion:

    -

    Table 69 of Containers say that a.insert(i,j) is linear if [i, j) is ordered. It seems -impossible to implement, as it means that if [i, j) = [x], insert in an associative -container is O(1)!

    - - -

    Proposed resolution:

    -

    N+log (size()) if [i,j) is sorted according to value_comp()

    - - -

    Rationale:

    -

    Subsumed by issue 264.

    - - - - - -
    -

    104. Description of basic_string::operator[] is unclear

    -

    Section: 21.3.4 [string.capacity] Status: NAD - Submitter: AFNOR Date: 1998-10-07

    -

    View all other issues in [string.capacity].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    It is not clear that undefined behavior applies when pos == size () -for the non const version.

    - - -

    Proposed resolution:

    -

    Rewrite as: Otherwise, if pos > size () or pos == size () and -the non-const version is used, then the behavior is undefined.

    - - -

    Rationale:

    -

    The Standard is correct. The proposed resolution already appears in -the Standard.

    - - - - -
    -

    105. fstream ctors argument types desired

    -

    Section: 27.8 [file.streams] Status: Dup - Submitter: AFNOR Date: 1998-10-07

    -

    View all issues with Dup status.

    -

    Duplicate of: 454

    -

    Discussion:

    - - -

    fstream ctors take a const char* instead of string.
    -fstream ctors can't take wchar_t

    - -

    An extension to add a const wchar_t* to fstream would make the -implementation non conforming.

    - - -

    Rationale:

    -

    This is not a defect in the Standard. It might be an -interesting extension for the next Standard.

    - - - - -
    -

    107. Valarray constructor is strange

    -

    Section: 26.5.2 [template.valarray] Status: NAD - Submitter: AFNOR Date: 1998-10-07

    -

    View all other issues in [template.valarray].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    The order of the arguments is (elem, size) instead of the normal -(size, elem) in the rest of the library. Since elem often has an -integral or floating point type, both types are convertible to each -other and reversing them leads to a well formed program.

    - - -

    Proposed resolution:

    -

    Inverting the arguments could silently break programs. Introduce -the two signatures (const T&, size_t) and (size_t, const T&), -but make the one we do not want private so errors result in a -diagnosed access violation. This technique can also be applied to STL -containers.

    - - -

    Rationale:

    -

    The LWG believes that while the order of arguments is unfortunate, -it does not constitute a defect in the standard. The LWG believes that -the proposed solution will not work for valarray<size_t> and -perhaps other cases.

    - - - - -
    -

    111. istreambuf_iterator::equal overspecified, inefficient

    -

    Section: 24.5.3.5 [istreambuf.iterator::equal] Status: NAD Future - Submitter: Nathan Myers Date: 1998-10-15

    -

    View all issues with NAD Future status.

    -

    Discussion:

    -

    The member istreambuf_iterator<>::equal is specified to be -unnecessarily inefficient. While this does not affect the efficiency -of conforming implementations of iostreams, because they can -"reach into" the iterators and bypass this function, it does -affect users who use istreambuf_iterators.

    - -

    The inefficiency results from a too-scrupulous definition, which -requires a "true" result if neither iterator is at eof. In -practice these iterators can only usefully be compared with the -"eof" value, so the extra test implied provides no benefit, -but slows down users' code.

    - -

    The solution is to weaken the requirement on the function to return -true only if both iterators are at eof.

    - - -

    Proposed resolution:

    -

    Replace 24.5.3.5 [istreambuf.iterator::equal], -paragraph 1,

    - -
    -

    -1- Returns: true if and only if both iterators are at end-of-stream, or neither is at - end-of-stream, regardless of what streambuf object they use.

    -
    - -

    with

    - -
    -

    -1- Returns: true if and only if both iterators are at - end-of-stream, regardless of what streambuf object they use.

    -
    - - - -

    Rationale:

    -

    It is not clear that this is a genuine defect. Additionally, the -LWG was reluctant to make a change that would result in -operator== not being a equivalence relation. One consequence of -this change is that an algorithm that's passed the range [i, i) -would no longer treat it as an empty range.

    - - - - - -
    -

    113. Missing/extra iostream sync semantics

    -

    Section: 27.6.1.1 [istream], 27.6.1.3 [istream.unformatted] Status: NAD - Submitter: Steve Clamage Date: 1998-10-13

    -

    View all other issues in [istream].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    In 27.6.1.1, class basic_istream has a member function sync, described in 27.6.1.3, -paragraph 36.

    - -

    Following the chain of definitions, I find that the various sync functions have defined -semantics for output streams, but no semantics for input streams. On the other hand, -basic_ostream has no sync function.

    - -

    The sync function should at minimum be added to basic_ostream, for internal -consistency.

    - -

    A larger question is whether sync should have assigned semantics for input streams.

    - -

    Classic iostreams said streambuf::sync flushes pending output and attempts to return -unread input characters to the source. It is a protected member function. The filebuf -version (which is public) has that behavior (it backs up the read pointer). Class -strstreambuf does not override streambuf::sync, and so sync can't be called on a -strstream.

    - -

    If we can add corresponding semantics to the various sync functions, we should. If not, -we should remove sync from basic_istream.

    - - -

    Rationale:

    -

    A sync function is not needed in basic_ostream because the flush function provides the -desired functionality.

    - -

    As for the other points, the LWG finds the standard correct as written.

    - - - - - -
    -

    116. bitset cannot be constructed with a const char*

    -

    Section: 23.3.5 [template.bitset] Status: Dup - Submitter: Judy Ward Date: 1998-11-06

    -

    View all other issues in [template.bitset].

    -

    View all issues with Dup status.

    -

    Duplicate of: 778

    -

    Discussion:

    - - - -

    The following code does not compile with the EDG compiler:

    - -
    - 
    #include <bitset>
-using namespace std;
-bitset<32> b("111111111");
    -
    - -

    If you cast the ctor argument to a string, i.e.:

    - -
    - 
    bitset<32> b(string("111111111"));
    -
    - -

    then it will compile. The reason is that bitset has the following templatized -constructor:

    - -
    - 
    template <class charT, class traits, class Allocator>
-explicit bitset (const basic_string<charT, traits, Allocator>& str, ...);
    -
    - -

    According to the compiler vendor, Steve Adamcyk at EDG, the user -cannot pass this template constructor a const char* and -expect a conversion to basic_string. The reason is -"When you have a template constructor, it can get used in -contexts where type deduction can be done. Type deduction basically -comes up with exact matches, not ones involving conversions." -

    - -

    I don't think the intention when this constructor became -templatized was for construction from a const char* to no -longer work.

    - - -

    Proposed resolution:

    -

    Add to 23.3.5 [template.bitset] a bitset constructor declaration

    - -
    - 
    explicit bitset(const char*);
    -
    - -

    and in Section 23.3.5.1 [bitset.cons] add:

    - -
    - 
    explicit bitset(const char* str);
    -

    Effects:
    -     Calls bitset((string) str, 0, string::npos);

    -
    - - -

    Rationale:

    -

    Although the problem is real, the standard is designed that way so -it is not a defect. Education is the immediate workaround. A future -standard may wish to consider the Proposed Resolution as an -extension.

    - - - - - -
    -

    121. Detailed definition for ctype<wchar_t> specialization

    -

    Section: 22.1.1.1.1 [locale.category] Status: NAD - Submitter: Judy Ward Date: 1998-12-15

    -

    View all other issues in [locale.category].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    Section 22.1.1.1.1 has the following listed in Table 51: ctype<char> , -ctype<wchar_t>.

    - -

    Also Section 22.2.1.1 [locale.ctype] says:

    - -
    -

    The instantiations required in Table 51 (22.1.1.1.1) namely ctype<char> and - ctype<wchar_t> , implement character classing appropriate to the implementation's - native character set.

    -
    - -

    However, Section 22.2.1.3 [facet.ctype.special] -only has a detailed description of the ctype<char> specialization, not the -ctype<wchar_t> specialization.

    - - -

    Proposed resolution:

    -

    Add the ctype<wchar_t> detailed class description to Section -22.2.1.3 [facet.ctype.special].

    - - -

    Rationale:

    -

    Specialization for wchar_t is not needed since the default is acceptable.

    - - - - - -
    -

    131. list::splice throws nothing

    -

    Section: 23.2.4.4 [list.ops] Status: NAD - Submitter: Howard Hinnant Date: 1999-03-06

    -

    View all other issues in [list.ops].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    What happens if a splice operation causes the size() of a list to grow -beyond max_size()?

    - - -

    Rationale:

    -

    Size() cannot grow beyond max_size(). 

    - - - - - -
    -

    135. basic_iostream doubly initialized

    -

    Section: 27.6.1.5.1 [iostream.cons] Status: NAD - Submitter: Howard Hinnant Date: 1999-03-06

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    -1- Effects Constructs an object of class basic_iostream, assigning -initial values to the base classes by calling -basic_istream<charT,traits>(sb) (lib.istream) and -basic_ostream<charT,traits>(sb) (lib.ostream)

    - -

    The called for basic_istream and basic_ostream constructors call -init(sb). This means that the basic_iostream's virtual base class is -initialized twice.

    - - -

    Proposed resolution:

    -

    Change 27.6.1.5.1, paragraph 1 to:

    - -

    -1- Effects Constructs an object of class basic_iostream, assigning -initial values to the base classes by calling -basic_istream<charT,traits>(sb) (lib.istream).

    - - -

    Rationale:

    -

    The LWG agreed that the init() function is called -twice, but said that this is harmless and so not a defect in the -standard.

    - - - - -
    -

    138. Class ctype_byname<char> redundant and misleading

    -

    Section: 22.2.1.4 [locale.codecvt] Status: NAD Future - Submitter: Angelika Langer Date: 1999-03-18

    -

    View all other issues in [locale.codecvt].

    -

    View all issues with NAD Future status.

    -

    Discussion:

    -

    Section 22.2.1.4 [locale.codecvt] specifies that -ctype_byname<char> must be a specialization of the ctype_byname -template.

    - -

    It is common practice in the standard that specializations of class templates are only -mentioned where the interface of the specialization deviates from the interface of the -template that it is a specialization of. Otherwise, the fact whether or not a required -instantiation is an actual instantiation or a specialization is left open as an -implementation detail.

    - -

    Clause 22.2.1.4 deviates from that practice and for that reason is misleading. The -fact, that ctype_byname<char> is specified as a specialization suggests that there -must be something "special" about it, but it has the exact same interface as the -ctype_byname template. Clause 22.2.1.4 does not have any explanatory value, is at best -redundant, at worst misleading - unless I am missing anything.

    - -

    Naturally, an implementation will most likely implement ctype_byname<char> as a -specialization, because the base class ctype<char> is a specialization with an -interface different from the ctype template, but that's an implementation detail and need -not be mentioned in the standard.

    - - -

    Rationale:

    -

    The standard as written is mildly misleading, but the correct fix -is to deal with the underlying problem in the ctype_byname base class, -not in the specialization. See issue 228.

    - - - - -
    -

    140. map<Key, T>::value_type does not satisfy the assignable requirement

    -

    Section: 23.3.1 [map] Status: NAD Editorial - Submitter: Mark Mitchell Date: 1999-04-14

    -

    View all other issues in [map].

    -

    View all issues with NAD Editorial status.

    -

    Discussion:

    -
    -

    23.1 [container.requirements]
    -
    - expression         return type -      pre/post-condition
    - -------------     -----------      - -------------------
    - X::value_type    T -                    - T is assignable
    -
    - 23.3.1 [map]
    -
    - A map satisfies all the requirements of a container.
    -
    - For a map<Key, T> ... the value_type is pair<const Key, T>.

    -
    - -

    There's a contradiction here. In particular, `pair<const Key, -T>' is not assignable; the `const Key' cannot be assigned -to. So,  map<Key, T>::value_type does not satisfy the -assignable requirement imposed by a container.

    - -

    [See issue 103 for the slightly related issue of -modification of set keys.]

    - - - -

    Rationale:

    -

    The LWG believes that the standard is inconsistent, but that this -is a design problem rather than a strict defect. May wish to -reconsider for the next standard.

    - - - - -
    -

    143. C .h header wording unclear

    -

    Section: D.5 [depr.c.headers] Status: NAD - Submitter: Christophe de Dinechin Date: 1999-05-04

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    [depr.c.headers] paragraph 2 reads:

    - -
    - -

    Each C header, whose name has the form name.h, behaves as if each -name placed in the Standard library namespace by the corresponding -cname header is also placed within the namespace scope of the -namespace std and is followed by an explicit using-declaration -(_namespace.udecl_)

    - -
    - -

    I think it should mention the global name space somewhere...  -Currently, it indicates that name placed in std is also placed in -std...

    - -

    I don't know what is the correct wording. For instance, if struct -tm is defined in time.h, ctime declares std::tm. However, the current -wording seems ambiguous regarding which of the following would occur -for use of both ctime and time.h:

    - -
    - 
    // version 1:
-namespace std {
-        struct tm { ... };
-}
-using std::tm;
-
-// version 2:
-struct tm { ... };
-namespace std {
-        using ::tm;
-}
-
-// version 3:
-struct tm { ... };
-namespace std {
-        struct tm { ... };
-}
    -
    - -

    I think version 1 is intended.

    - -

    [Kona: The LWG agreed that the wording is not clear. It also -agreed that version 1 is intended, version 2 is not equivalent to -version 1, and version 3 is clearly not intended. The example below -was constructed by Nathan Myers to illustrate why version 2 is not -equivalent to version 1.

    - -

    Although not equivalent, the LWG is unsure if (2) is enough of -a problem to be prohibited. Points discussed in favor of allowing -(2):

    - -
    -
      -
    • It may be a convenience to implementors.
      • -
    • The only cases that fail are structs, of which the C library - contains only a few.
      • -
    -
    - -

    ]

    - -

    Example:

    - -
    - -
    #include <time.h>
-#include <utility>
-
-int main() {
-    std::tm * t;
-    make_pair( t, t ); // okay with version 1 due to Koenig lookup
-                       // fails with version 2; make_pair not found
-    return 0;
-}
    - -
    - - -

    Proposed resolution:

    - -

    Replace D.5 [depr.c.headers] paragraph 2 with:

    - -
    - -

    Each C header, whose name has the form name.h, behaves as if each -name placed in the Standard library namespace by the corresponding -cname header is also placed within the namespace scope of the -namespace std by name.h and is followed by an explicit -using-declaration (_namespace.udecl_) in global scope.

    - -
    - - - -

    Rationale:

    -

    The current wording in the standard is the result of a difficult -compromise that averted delay of the standard. Based on discussions -in Tokyo it is clear that there is no still no consensus on stricter -wording, so the issue has been closed. It is suggested that users not -write code that depends on Koenig lookup of C library functions.

    - - - - -
    -

    145. adjustfield lacks default value

    -

    Section: 27.4.4.1 [basic.ios.cons] Status: NAD - Submitter: Angelika Langer Date: 1999-05-12

    -

    View all other issues in [basic.ios.cons].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    There is no initial value for the adjustfield defined, although -many people believe that the default adjustment were right. This is a -common misunderstanding. The standard only defines that, if no -adjustment is specified, all the predefined inserters must add fill -characters before the actual value, which is "as if" the -right flag were set. The flag itself need not be set.

    - -

    When you implement a user-defined inserter you cannot rely on right -being the default setting for the adjustfield. Instead, you must be -prepared to find none of the flags set and must keep in mind that in -this case you should make your inserter behave "as if" the -right flag were set. This is surprising to many people and complicates -matters more than necessary.

    - -

    Unless there is a good reason why the adjustfield should not be -initialized I would suggest to give it the default value that -everybody expects anyway.

    - - - -

    Rationale:

    -

    This is not a defect. It is deliberate that the default is no bits -set. Consider Arabic or Hebrew, for example. See 22.2.2.2.2 [facet.num.put.virtuals] paragraph 19, Table 61 - Fill padding.

    - - - - -
    -

    149. Insert should return iterator to first element inserted

    -

    Section: 23.1.3 [sequence.reqmts] Status: NAD Future - Submitter: Andrew Koenig Date: 1999-06-28

    -

    View all other issues in [sequence.reqmts].

    -

    View all issues with NAD Future status.

    -

    Discussion:

    -

    Suppose that c and c1 are sequential containers and i is an -iterator that refers to an element of c. Then I can insert a copy of -c1's elements into c ahead of element i by executing

    - -
    - -
    c.insert(i, c1.begin(), c1.end());
    - -
    - -

    If c is a vector, it is fairly easy for me to find out where the -newly inserted elements are, even though i is now invalid:

    - -
    - -
    size_t i_loc = i - c.begin();
-c.insert(i, c1.begin(), c1.end());
    - -
    - -

    and now the first inserted element is at c.begin()+i_loc and one -past the last is at c.begin()+i_loc+c1.size().
    -
    -But what if c is a list? I can still find the location of one past the -last inserted element, because i is still valid. To find the location -of the first inserted element, though, I must execute something like

    - -
    - -
    for (size_t n = c1.size(); n; --n)
-   --i;
    - -
    - -

    because i is now no longer a random-access iterator.
    -
    -Alternatively, I might write something like

    - -
    - -
    bool first = i == c.begin();
-list<T>::iterator j = i;
-if (!first) --j;
-c.insert(i, c1.begin(), c1.end());
-if (first)
-   j = c.begin();
-else
-   ++j;
    - -
    - -

    which, although wretched, requires less overhead.
    -
    -But I think the right solution is to change the definition of insert -so that instead of returning void, it returns an iterator that refers -to the first element inserted, if any, and otherwise is a copy of its -first argument. 

    - - -

    Rationale:

    -

    The LWG believes this was an intentional design decision and so is -not a defect. It may be worth revisiting for the next standard.

    - - - - -
    -

    157. Meaningless error handling for pword() and iword()

    -

    Section: 27.4.2.5 [ios.base.storage] Status: Dup - Submitter: Dietmar Kühl Date: 1999-07-20

    -

    View all other issues in [ios.base.storage].

    -

    View all issues with Dup status.

    -

    Duplicate of: 41

    -

    Discussion:

    -

    According to paragraphs 2 and 4 of 27.4.2.5 [ios.base.storage], the -functions iword() and pword() "set the -badbit (which might throw an exception)" on -failure. ... but what does it mean for ios_base to set the -badbit? The state facilities of the IOStream library are -defined in basic_ios, a derived class! It would be possible -to attempt a down cast but then it would be necessary to know the -character type used...

    - - -

    Rationale:

    - - - - - -
    -

    162. Really "formatted input functions"?

    -

    Section: 27.6.1.2.3 [istream::extractors] Status: Dup - Submitter: Dietmar Kühl Date: 1999-07-20

    -

    View all other issues in [istream::extractors].

    -

    View all issues with Dup status.

    -

    Duplicate of: 60

    -

    Discussion:

    -

    It appears to be somewhat nonsensical to consider the functions -defined in the paragraphs 1 to 5 to be "Formatted input -function" but since these functions are defined in a section -labeled "Formatted input functions" it is unclear to me -whether these operators are considered formatted input functions which -have to conform to the "common requirements" from 27.6.1.2.1 -[istream.formatted.reqmts]: If this is the case, all manipulators, not -just -ws, would skip whitespace unless noskipws is set -(... but setting noskipws using the manipulator syntax would -also skip whitespace :-)

    - -

    See also issue 166 for the same problem in formatted -output

    - - -

    Rationale:

    - - - - - -
    -

    163. Return of gcount() after a call to gcount

    -

    Section: 27.6.1.3 [istream.unformatted] Status: Dup - Submitter: Dietmar Kühl Date: 1999-07-20

    -

    View all other issues in [istream.unformatted].

    -

    View all issues with Dup status.

    -

    Duplicate of: 60

    -

    Discussion:

    -

    It is not clear which functions are to be considered unformatted -input functions. As written, it seems that all functions in 27.6.1.3 -[istream.unformatted] are unformatted input functions. However, it does -not -really make much sense to construct a sentry object for -gcount(), sync(), ... Also it is unclear what -happens to the gcount() if eg. gcount(), -putback(), unget(), or sync() is called: -These functions don't extract characters, some of them even -"unextract" a character. Should this still be reflected in -gcount()? Of course, it could be read as if after a call to -gcount() gcount() return 0 (the last -unformatted input function, gcount(), didn't extract any -character) and after a call to putback() gcount() -returns -1 (the last unformatted input function -putback() did "extract" back into the -stream). Correspondingly for unget(). Is this what is -intended? If so, this should be clarified. Otherwise, a corresponding -clarification should be used.

    - - -

    Rationale:

    - - - - - -
    -

    166. Really "formatted output functions"?

    -

    Section: 27.6.2.6.3 [ostream.inserters] Status: Dup - Submitter: Dietmar Kühl Date: 1999-07-20

    -

    View all issues with Dup status.

    -

    Duplicate of: 60

    -

    Discussion:

    -

    From 27.6.2.6.1 [ostream.formatted.reqmts] it appears that all the functions -defined in 27.6.2.6.3 [ostream.inserters] have to construct a -sentry object. Is this really intended?

    - -

    This is basically the same problem as issue 162 but -for output instead of input.

    - - -

    Rationale:

    - - - - - -
    -

    177. Complex operators cannot be explicitly instantiated

    -

    Section: 26.3.6 [complex.ops] Status: NAD - Submitter: Judy Ward Date: 1999-07-02

    -

    View all other issues in [complex.ops].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    A user who tries to explicitly instantiate a complex non-member operator will -get compilation errors. Below is a simplified example of the reason why. The -problem is that iterator_traits cannot be instantiated on a non-pointer type -like float, yet when the compiler is trying to decide which operator+ needs to -be instantiated it must instantiate the declaration to figure out the first -argument type of a reverse_iterator operator.

    -
    namespace std {
-template <class Iterator> 
-struct iterator_traits
-{
-    typedef typename Iterator::value_type value_type;
-};
-
-template <class T> class reverse_iterator;
-
-// reverse_iterator operator+
-template <class T> 
-reverse_iterator<T> operator+
-(typename iterator_traits<T>::difference_type, const reverse_iterator<T>&);
-
-template <class T> struct complex {};
-
-// complex operator +
-template <class T>
-complex<T> operator+ (const T& lhs, const complex<T>& rhs) 
-{ return complex<T>();} 
-}
-
-// request for explicit instantiation
-template std::complex<float> std::operator+<float>(const float&, 
-     const std::complex<float>&);
    -

    See also c++-stdlib reflector messages: lib-6814, 6815, 6816.

    - - -

    Rationale:

    -

    Implementors can make minor changes and the example will -work. Users are not affected in any case.

    According to John -Spicer, It is possible to explicitly instantiate these operators using -different syntax: change "std::operator+<float>" to -"std::operator+".

    - -

    The proposed resolution of issue 120 is that users will not be able -to explicitly instantiate standard library templates. If that -resolution is accepted then library implementors will be the only ones -that will be affected by this problem, and they must use the indicated -syntax.

    - - - - -
    -

    178. Should clog and cerr initially be tied to cout?

    -

    Section: 27.3.1 [narrow.stream.objects] Status: NAD - Submitter: Judy Ward Date: 1999-07-02

    -

    View all other issues in [narrow.stream.objects].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    -Section 27.3.1 says "After the object cerr is initialized, -cerr.flags() & unitbuf is nonzero. Its state is otherwise the same as -required for ios_base::init (lib.basic.ios.cons). It doesn't say -anything about the the state of clog. So this means that calling -cerr.tie() and clog.tie() should return 0 (see Table 89 for -ios_base::init effects). -

    -

    -Neither of the popular standard library implementations -that I tried does this, they both tie cerr and clog -to &cout. I would think that would be what users expect. -

    - - -

    Rationale:

    -

    The standard is clear as written.

    -

    27.3.1/5 says that "After the object cerr is initialized, cerr.flags() -& unitbuf is nonzero. Its state is otherwise the same as required for -ios_base::init (27.4.4.1)." Table 89 in 27.4.4.1, which gives the -postconditions of basic_ios::init(), says that tie() is 0. (Other issues correct -ios_base::init to basic_ios::init().)

    - - - - -
    -

    188. valarray helpers missing augmented assignment operators

    -

    Section: 26.5.2.6 [valarray.cassign] Status: NAD - Submitter: Gabriel Dos Reis Date: 1999-08-15

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    26.5.2.6 defines augmented assignment operators -valarray<T>::op=(const T&), but fails to provide -corresponding versions for the helper classes. Thus making the -following illegal:

    -
    -
    #include <valarray>
-
-int main()
-{
-std::valarray<double> v(3.14, 1999);
-
-v[99] *= 2.0; // Ok
-
-std::slice s(0, 50, 2);
-
-v[s] *= 2.0; // ERROR
-}
    -
    -

    I can't understand the intent of that omission. It makes the -valarray library less intuitive and less useful.

    - - -

    Rationale:

    -

    Although perhaps an unfortunate -design decision, the omission is not a defect in the current -standard.  A future standard may wish to add the missing -operators.

    - - - - -
    -

    191. Unclear complexity for algorithms such as binary search

    -

    Section: 25.3.3 [alg.binary.search] Status: NAD - Submitter: Nico Josuttis Date: 1999-10-10

    -

    View all other issues in [alg.binary.search].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    The complexity of binary_search() is stated as "At most -log(last-first) + 2 comparisons", which seems to say that the -algorithm has logarithmic complexity. However, this algorithms is -defined for forward iterators. And for forward iterators, the need to -step element-by-element results into linear complexity. But such a -statement is missing in the standard. The same applies to -lower_bound(), upper_bound(), and equal_range(). 
    -
    -However, strictly speaking the standard contains no bug here. So this -might considered to be a clarification or improvement. -

    - - -

    Rationale:

    -

    The complexity is expressed in terms of comparisons, and that -complexity can be met even if the number of iterators accessed is -linear. Paragraph 1 already says exactly what happens to -iterators.

    - - - - -
    -

    192. a.insert(p,t) is inefficient and overconstrained

    -

    Section: 23.1.4 [associative.reqmts] Status: NAD - Submitter: Ed Brey Date: 1999-06-06

    -

    View all other issues in [associative.reqmts].

    -

    View all issues with NAD status.

    -

    Duplicate of: 233

    -

    Discussion:

    -

    As defined in 23.1.2, paragraph 7 (table 69), a.insert(p,t) suffers from -several problems:

    - - - - - - - - - - - - - -
    expressionreturn typepre/post-conditioncomplexity
    a.insert(p,t)iteratorinserts t if and only if there is no element with key equivalent to the key of - t in containers with unique keys; always inserts t in containers with equivalent - keys. always returns the iterator pointing to the element with key equivalent to - the key of t . iterator p is a hint pointing to where the insert should start to search.logarithmic in general, but amortized constant if t is inserted right after p .
    -

    1. For a container with unique keys, only logarithmic complexity is -guaranteed if no element is inserted, even though constant complexity is always -possible if p points to an element equivalent to t.

    -

    2. For a container with equivalent keys, the amortized constant complexity -guarantee is only useful if no key equivalent to t exists in the container. -Otherwise, the insertion could occur in one of multiple locations, at least one -of which would not be right after p.

    -

    3. By guaranteeing amortized constant complexity only when t is inserted -after p, it is impossible to guarantee constant complexity if t is inserted at -the beginning of the container. Such a problem would not exist if amortized -constant complexity was guaranteed if t is inserted before p, since there is -always some p immediately before which an insert can take place.

    -

    4. For a container with equivalent keys, p does not allow specification of -where to insert the element, but rather only acts as a hint for improving -performance. This negates the added functionality that p would provide if it -specified where within a sequence of equivalent keys the insertion should occur. -Specifying the insert location provides more control to the user, while -providing no disadvantage to the container implementation.

    - - -

    Proposed resolution:

    -

    In 23.1.4 [associative.reqmts] paragraph 7, replace the row in table 69 -for a.insert(p,t) with the following two rows:

    - - - - - - - - - - - - - - - - - - - -
    expressionreturn typepre/post-conditioncomplexity
    a_uniq.insert(p,t)iteratorinserts t if and only if there is no element with key equivalent to the - key of t. returns the iterator pointing to the element with key equivalent - to the key of t.logarithmic in general, but amortized constant if t is inserted right - before p or p points to an element with key equivalent to t.
    a_eq.insert(p,t)iteratorinserts t and returns the iterator pointing to the newly inserted - element. t is inserted right before p if doing so preserves the container - ordering.logarithmic in general, but amortized constant if t is inserted right - before p.
    - - - -

    Rationale:

    -

    Too big a change.  Furthermore, implementors report checking -both before p and after p, and don't want to change this behavior.

    - - - - - -
    -

    194. rdbuf() functions poorly specified

    -

    Section: 27.4.4 [ios] Status: NAD - Submitter: Steve Clamage Date: 1999-09-07

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    In classic iostreams, base class ios had an rdbuf function that returned a -pointer to the associated streambuf. Each derived class had its own rdbuf -function that returned a pointer of a type reflecting the actual type derived -from streambuf. Because in ARM C++, virtual function overrides had to have the -same return type, rdbuf could not be virtual.

    -

    In standard iostreams, we retain the non-virtual rdbuf function design, and -in addition have an overloaded rdbuf function that sets the buffer pointer. -There is no need for the second function to be virtual nor to be implemented in -derived classes.

    -

    Minor question: Was there a specific reason not to make the original rdbuf -function virtual?

    -

    Major problem: Friendly compilers warn about functions in derived classes -that hide base-class overloads. Any standard implementation of iostreams will -result in such a warning on each of the iostream classes, because of the -ill-considered decision to overload rdbuf only in a base class.

    -

    In addition, users of the second rdbuf function must use explicit -qualification or a cast to call it from derived classes. An explicit -qualification or cast to basic_ios would prevent access to any later overriding -version if there was one.

    -

    What I'd like to do in an implementation is add a using- declaration for the -second rdbuf function in each derived class. It would eliminate warnings about -hiding functions, and would enable access without using explicit qualification. -Such a change I don't think would change the behavior of any valid program, but -would allow invalid programs to compile:

    -
    - 
     filebuf mybuf;
- fstream f;
- f.rdbuf(mybuf); // should be an error, no visible rdbuf
    -
    -

    I'd like to suggest this problem as a defect, with the proposed resolution to -require the equivalent of a using-declaration for the rdbuf function that is not -replaced in a later derived class. We could discuss whether replacing the -function should be allowed.

    - - -

    Rationale:

    -

    For historical reasons, the standard is correct as written. There is a subtle difference between the base -class rdbuf() and derived class rdbuf(). The derived -class rdbuf() always returns the original streambuf, whereas the base class - rdbuf() will return the "current streambuf" if that has been changed by the variant you mention.

    - -

    Permission is not required to add such an extension. See -17.4.4.4 [member.functions].

    - - - - -
    -

    196. Placement new example has alignment problems

    -

    Section: 18.5.1.3 [new.delete.placement] Status: Dup - Submitter: Herb Sutter Date: 1998-12-15

    -

    View all other issues in [new.delete.placement].

    -

    View all issues with Dup status.

    -

    Duplicate of: 114

    -

    Discussion:

    -

    The example in 18.5.1.3 [new.delete.placement] paragraph 4 reads:

    - -
    - -

    [Example: This can be useful for constructing an object at a known address:
    -
    -   char place[sizeof(Something)];
    -   Something* p = new (place) Something();
    -
    -    end example]

    - -
    - -

    This example has potential alignment problems.

    - - -

    Rationale:

    - - - - - -
    -

    197. max_size() underspecified

    -

    Section: 20.1.2 [allocator.requirements], 23.1 [container.requirements] Status: NAD - Submitter: Andy Sawyer Date: 1999-10-21

    -

    View other active issues in [allocator.requirements].

    -

    View all other issues in [allocator.requirements].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    Must the value returned by max_size() be unchanged from call to call?

    - -

    Must the value returned from max_size() be meaningful?

    - -

    Possible meanings identified in lib-6827:

    - -

    1) The largest container the implementation can support given "best -case" conditions - i.e. assume the run-time platform is "configured to -the max", and no overhead from the program itself. This may possibly -be determined at the point the library is written, but certainly no -later than compile time.
    -
    -2) The largest container the program could create, given "best case" -conditions - i.e. same platform assumptions as (1), but take into -account any overhead for executing the program itself. (or, roughly -"storage=storage-sizeof(program)"). This does NOT include any resource -allocated by the program. This may (or may not) be determinable at -compile time.
    -
    -3) The largest container the current execution of the program could -create, given knowledge of the actual run-time platform, but again, -not taking into account any currently allocated resource. This is -probably best determined at program start-up.
    -
    -4) The largest container the current execution program could create at -the point max_size() is called (or more correctly at the point -max_size() returns :-), given it's current environment (i.e. taking -into account the actual currently available resources). This, -obviously, has to be determined dynamically each time max_size() is -called.

    - - -

    Proposed resolution:

    - - -

    Rationale:

    -

    max_size() isn't useful for very many things, and the existing - wording is sufficiently clear for the few cases that max_size() can - be used for. None of the attempts to change the existing wording - were an improvement.

    - -

    It is clear to the LWG that the value returned by max_size() can't - change from call to call.

    - - - - - - -
    -

    203. basic_istream::sentry::sentry() is uninstantiable with ctype<user-defined type>

    -

    Section: 27.6.1.1.3 [istream::sentry] Status: NAD - Submitter: Matt McClure and Dietmar Kühl Date: 2000-01-01

    -

    View all other issues in [istream::sentry].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    27.6.1.1.2 Paragraph 4 states:

    -
    -

    To decide if the character c is a whitespace character, the constructor - performs ''as if'' it executes the following code fragment: 

    - 
    const ctype<charT>& ctype = use_facet<ctype<charT> >(is.getloc());
-if (ctype.is(ctype.space,c)!=0)
-// c is a whitespace character.
    -
    - -

    But Table 51 in 22.1.1.1.1 only requires an implementation to -provide specializations for ctype<char> and -ctype<wchar_t>. If sentry's constructor is implemented using -ctype, it will be uninstantiable for a user-defined character type -charT, unless the implementation has provided non-working (since it -would be impossible to define a correct ctype<charT> specialization -for an arbitrary charT) definitions of ctype's virtual member -functions.

    - -

    -It seems the intent the standard is that sentry should behave, in -every respect, not just during execution, as if it were implemented -using ctype, with the burden of providing a ctype specialization -falling on the user. But as it is written, nothing requires the -translation of sentry's constructor to behave as if it used the above -code, and it would seem therefore, that sentry's constructor should be -instantiable for all character types. -

    - -

    -Note: If I have misinterpreted the intent of the standard with -respect to sentry's constructor's instantiability, then a note should -be added to the following effect: -

    - -

    -An implementation is forbidden from using the above code if it renders -the constructor uninstantiable for an otherwise valid character -type. -

    - -

    In any event, some clarification is needed.

    - - - -

    Rationale:

    -

    It is possible but not easy to instantiate on types other than char -or wchar_t; many things have to be done first. That is by intention -and is not a defect.

    - - - - -
    -

    204. distance(first, last) when "last" is before "first"

    -

    Section: 24.3.4 [iterator.operations] Status: NAD - Submitter: Rintala Matti Date: 2000-01-28

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    Section 24.3.4 describes the function distance(first, last) (where first and -last are iterators) which calculates "the number of increments or -decrements needed to get from 'first' to 'last'".

    -

    The function should work for forward, bidirectional and random access -iterators, and there is a requirement 24.3.4.5 which states that "'last' -must be reachable from 'first'".

    -

    With random access iterators the function is easy to implement as "last -- first".

    -

    With forward iterators it's clear that 'first' must point to a place before -'last', because otherwise 'last' would not be reachable from 'first'.

    -

    But what about bidirectional iterators? There 'last' is reachable from -'first' with the -- operator even if 'last' points to an earlier position than -'first'. However, I cannot see how the distance() function could be implemented -if the implementation does not know which of the iterators points to an earlier -position (you cannot use ++ or -- on either iterator if you don't know which -direction is the "safe way to travel").

    -

    The paragraph 24.3.4.1 states that "for ... bidirectional iterators they -use ++ to provide linear time implementations". However, the ++ operator is -not mentioned in the reachability requirement. Furthermore 24.3.4.4 explicitly -mentions that distance() returns the number of increments _or decrements_, -suggesting that it could return a negative number also for bidirectional -iterators when 'last' points to a position before 'first'.

    -

    Is a further requirement is needed to state that for forward and -bidirectional iterators "'last' must be reachable from 'first' using the ++ -operator". Maybe this requirement might also apply to random access -iterators so that distance() would work the same way for every iterator -category?

    - - -

    Rationale:

    -

    "Reachable" is defined in the standard in 24.1 [iterator.requirements] paragraph 6. -The definition is only in terms of operator++(). The LWG sees no defect in -the standard.

    - - - - -
    -

    205. numeric_limits unclear on how to determine floating point types

    -

    Section: 18.2.1.2 [numeric.limits.members] Status: NAD - Submitter: Steve Cleary Date: 2000-01-28

    -

    View all other issues in [numeric.limits.members].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    In several places in 18.2.1.2 [numeric.limits.members], a member is -described as "Meaningful for all floating point types." -However, no clear method of determining a floating point type is -provided.

    - -

    In 18.2.1.5 [numeric.special], paragraph 1 states ". . . (for -example, epsilon() is only meaningful if is_integer is -false). . ." which suggests that a type is a floating point type -if is_specialized is true and is_integer is false; however, this is -unclear.

    - -

    When clarifying this, please keep in mind this need of users: what -exactly is the definition of floating point? Would a fixed point or -rational representation be considered one? I guess my statement here -is that there could also be types that are neither integer or -(strictly) floating point.

    - - -

    Rationale:

    -

    It is up to the implementor of a user define type to decide if it is a -floating point type.

    - - - - -
    -

    207. ctype<char> members return clause incomplete

    -

    Section: 22.2.1.3.2 [facet.ctype.char.members] Status: Dup - Submitter: Robert Klarer Date: 1999-11-02

    -

    View all other issues in [facet.ctype.char.members].

    -

    View all issues with Dup status.

    -

    Duplicate of: 153

    -

    Discussion:

    -

    -The widen and narrow member functions are described -in 22.2.1.3.2, paragraphs 9-11. In each case we have two overloaded -signatures followed by a Returns clause. The Returns -clause only describes one of the overloads. -

    - - -

    Proposed resolution:

    -

    Change the returns clause in 22.2.1.3.2 [facet.ctype.char.members] -paragraph 10 from:

    -

        Returns: do_widen(low, high, to).

    - -

    to:

    -

        Returns: do_widen(c) or do_widen(low, high, to), -respectively.

    - -

    Change the returns clause in 22.2.1.3.2 [facet.ctype.char.members] paragraph 11 -from:

    -

        Returns: do_narrow(low, high, to).

    - -

    to:

    -

        Returns: do_narrow(c) or do_narrow(low, high, to), -respectively.

    - - -

    Rationale:

    -

    Subsumed by issue 153, which addresses the same -paragraphs.

    - - - - - - -
    -

    213. Math function overloads ambiguous

    -

    Section: 26.7 [c.math] Status: NAD - Submitter: Nico Josuttis Date: 2000-02-26

    -

    View all other issues in [c.math].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    Due to the additional overloaded versions of numeric functions for -float and long double according to Section 26.5, calls such as int x; -std::pow (x, 4) are ambiguous now in a standard conforming -implementation. Current implementations solve this problem very -different (overload for all types, don't overload for float and long -double, use preprocessor, follow the standard and get -ambiguities).

    This behavior should be standardized or at least -identified as implementation defined.

    - - -

    Rationale:

    -

    These math issues are an -understood and accepted consequence of the design. They have -been discussed several times in the past. Users must write casts -or write floating point expressions as arguments.

    - - - - -
    -

    215. Can a map's key_type be const?

    -

    Section: 23.1.4 [associative.reqmts] Status: NAD - Submitter: Judy Ward Date: 2000-02-29

    -

    View all other issues in [associative.reqmts].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    A user noticed that this doesn't compile with the Rogue Wave library because -the rb_tree class declares a key_allocator, and allocator<const int> is -not legal, I think:

    -
    - 
    map < const int, ... > // legal?
    -
    -

    which made me wonder whether it is legal for a map's key_type to be const. In -email from Matt Austern he said:

    -
    -

    I'm not sure whether it's legal to declare a map with a const key type. I -hadn't thought about that question until a couple weeks ago. My intuitive -feeling is that it ought not to be allowed, and that the standard ought to say -so. It does turn out to work in SGI's library, though, and someone in the -compiler group even used it. Perhaps this deserves to be written up as an issue -too.

    -
    - - -

    Rationale:

    -

    The "key is assignable" requirement from table 69 in -23.1.4 [associative.reqmts] already implies the key cannot be const.

    - - - - -
    -

    216. setbase manipulator description flawed

    -

    Section: 27.6.3 [std.manip] Status: Dup - Submitter: Hyman Rosen Date: 2000-02-29

    -

    View all other issues in [std.manip].

    -

    View all issues with Dup status.

    -

    Duplicate of: 193

    -

    Discussion:

    -

    27.6.3 [std.manip] paragraph 5 says:

    -
    -
    smanip setbase(int base);
    -

    Returns: An object s of unspecified type such that if out is an -(instance of) basic_ostream then the expression out<<s behaves -as if f(s) were called, in is an (instance of) basic_istream then the -expression in>>s behaves as if f(s) were called. Where f can be -defined as:

    -
    ios_base& f(ios_base& str, int base)
-{
-  // set basefield
-  str.setf(n == 8 ? ios_base::oct :
-                n == 10 ? ios_base::dec :
-                n == 16 ? ios_base::hex :
-                  ios_base::fmtflags(0), ios_base::basefield);
-  return str;
-}
    -
    -

    There are two problems here. First, f takes two parameters, so the -description needs to say that out<<s and in>>s behave as if f(s,base) -had been called. Second, f is has a parameter named base, but is written as if -the parameter was named n.

    -

    Actually, there's a third problem. The paragraph has grammatical errors. -There needs to be an "and" after the first comma, and the "Where -f" sentence fragment needs to be merged into its preceding sentence. You -may also want to format the function a little better. The formatting above is -more-or-less what the Standard contains.

    - - -

    Rationale:

    -

    The resolution of this defect is subsumed by the proposed resolution for -issue 193.

    - -

    [Tokyo: The LWG agrees that this is a defect and notes that it -occurs additional places in the section, all requiring fixes.]

    - - - - - - - - -
    -

    218. Algorithms do not use binary predicate objects for default comparisons

    -

    Section: 25.3 [alg.sorting] Status: NAD - Submitter: Pablo Halpern Date: 2000-03-06

    -

    View all other issues in [alg.sorting].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    Many of the algorithms take an argument, pred, of template parameter type -BinaryPredicate or an argument comp of template parameter type Compare. These -algorithms usually have an overloaded version that does not take the predicate -argument. In these cases pred is usually replaced by the use of operator== and -comp is replaced by the use of operator<.

    -

    This use of hard-coded operators is inconsistent with other parts of the -library, particularly the containers library, where equality is established -using equal_to<> and ordering is established using less<>. Worse, -the use of operator<, would cause the following innocent-looking code to have -undefined behavior:

    -
    - 
    vector<string*> vec;
-sort(vec.begin(), vec.end());
    -
    -

    The use of operator< is not defined for pointers to unrelated objects. If -std::sort used less<> to compare elements, then the above code would be -well-defined, since less<> is explicitly specialized to produce a total -ordering of pointers.

    - - -

    Rationale:

    -

    This use of operator== and operator< was a very deliberate, conscious, and -explicitly made design decision; these operators are often more efficient. The -predicate forms are available for users who don't want to rely on operator== and -operator<.

    - - - - -
    -

    219. find algorithm missing version that takes a binary predicate argument

    -

    Section: 25.1.5 [alg.find] Status: NAD Future - Submitter: Pablo Halpern Date: 2000-03-06

    -

    View all other issues in [alg.find].

    -

    View all issues with NAD Future status.

    -

    Discussion:

    -

    The find function always searches for a value using operator== to compare the -value argument to each element in the input iterator range. This is inconsistent -with other find-related functions such as find_end and find_first_of, which -allow the caller to specify a binary predicate object to be used for determining -equality. The fact that this can be accomplished using a combination of find_if -and bind_1st or bind_2nd does not negate the desirability of a consistent, -simple, alternative interface to find.

    - - -

    Proposed resolution:

    -
    -

    In section 25.1.5 [alg.find], add a second prototype for find -(between the existing prototype and the prototype for find_if), as -follows:

    -
        template<class InputIterator, class T, class BinaryPredicate>
-      InputIterator find(InputIterator first, InputIterator last,
-                         const T& value, BinaryPredicate bin_pred);
    -

    Change the description of the return from:

    -
    -

    Returns: The first iterator i in the range [first, last) for which the following corresponding - conditions hold: *i == value, pred(*i) != false. Returns last if no such iterator is found.

    -
    -

     to:

    -
    -

    Returns: The first iterator i in the range [first, last) for which the following  - corresponding condition holds: *i == value, bin_pred(*i,value) != false, pred(*) - != false. Return last if no such iterator is found.

    -
    -
    - - -

    Rationale:

    -

    This is request for a pure extension, so it is not a defect in the -current standard.  As the submitter pointed out, "this can -be accomplished using a combination of find_if and bind_1st or -bind_2nd".

    - - - - -
    -

    236. ctype<char>::is() member modifies facet

    -

    Section: 22.2.1.3.2 [facet.ctype.char.members] Status: Dup - Submitter: Dietmar Kühl Date: 2000-04-24

    -

    View all other issues in [facet.ctype.char.members].

    -

    View all issues with Dup status.

    -

    Duplicate of: 28

    -

    Discussion:

    -

    The description of the is() member in paragraph 4 of 22.2.1.3.2 [facet.ctype.char.members] is broken: According to this description, the -second form of the is() method modifies the masks in the -ctype object. The correct semantics if, of course, to obtain -an array of masks. The corresponding method in the general case, -ie. the do_is() method as described in 22.2.1.1.2 [locale.ctype.virtuals] paragraph 1 does the right thing.

    - - -

    Proposed resolution:

    -

    Change paragraph 4 from

    -

    - The second form, for all *p in the range [low, high), assigns - vec[p-low] to table()[(unsigned char)*p]. -

    -

    to become

    -

    - The second form, for all *p in the range [low, high), assigns - table()[(unsigned char)*p] to vec[p-low]. -

    - - -

    Rationale:

    - - - - - -
    -

    244. Must find's third argument be CopyConstructible?

    -

    Section: 25.1.5 [alg.find] Status: NAD - Submitter: Andrew Koenig Date: 2000-05-02

    -

    View all other issues in [alg.find].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    Is the following implementation of find acceptable?

    - -
            template<class Iter, class X>
-        Iter find(Iter begin, Iter end, const X& x)
-        {
-            X x1 = x;           // this is the crucial statement
-            while (begin != end && *begin != x1)
-                ++begin;
-            return begin;
-        }
-
    - -

    If the answer is yes, then it is implementation-dependent as to -whether the following fragment is well formed:

    - -
            vector<string> v;
-
-        find(v.begin(), v.end(), "foo");
-
    - -

    At issue is whether there is a requirement that the third argument -of find be CopyConstructible. There may be no problem here, but -analysis is necessary.

    - - -

    Rationale:

    -

    There is no indication in the standard that find's third argument -is required to be Copy Constructible. The LWG believes that no such -requirement was intended. As noted above, there are times when a user -might reasonably pass an argument that is not Copy Constructible.

    - - - - -
    -

    245. Which operations on istream_iterator trigger input operations?

    -

    Section: 24.5.1 [istream.iterator] Status: NAD - Submitter: Andrew Koenig Date: 2000-05-02

    -

    View other active issues in [istream.iterator].

    -

    View all other issues in [istream.iterator].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    I do not think the standard specifies what operation(s) on istream -iterators trigger input operations. So, for example:

    - -
            istream_iterator<int> i(cin);
-
-        int n = *i++;
-
    - -

    I do not think it is specified how many integers have been read -from cin. The number must be at least 1, of course, but can it be 2? -More?

    - - -

    Rationale:

    -

    The standard is clear as written: the stream is read every time -operator++ is called, and it is also read either when the iterator is -constructed or when operator* is called for the first time. In the -example above, exactly two integers are read from cin.

    - -

    There may be a problem with the interaction between istream_iterator -and some STL algorithms, such as find. There are no guarantees about -how many times find may invoke operator++.

    - - - - -
    -

    246. a.insert(p,t) is incorrectly specified

    -

    Section: 23.1.4 [associative.reqmts] Status: Dup - Submitter: Mark Rodgers Date: 2000-05-19

    -

    View all other issues in [associative.reqmts].

    -

    View all issues with Dup status.

    -

    Duplicate of: 233

    -

    Discussion:

    -

    Closed issue 192 raised several problems with the specification of -this function, but was rejected as Not A Defect because it was too big -a change with unacceptable impacts on existing implementations. -However, issues remain that could be addressed with a smaller change -and with little or no consequent impact.

    - -
      -

    1. The specification is inconsistent with the original - proposal and with several implementations.

      - -

      The initial implementation by Hewlett Packard only ever looked - immediately before p, and I do not believe there was any - intention to standardize anything other than this behavior. - Consequently, current implementations by several leading - implementors also look immediately before p, and will only insert - after p in logarithmic time. I am only aware of one implementation - that does actually look after p, and it looks before p as well. It - is therefore doubtful that existing code would be relying on the - behavior defined in the standard, and it would seem that fixing - this defect as proposed below would standardize existing - practice.

      2. - -

    2. - The specification is inconsistent with insertion for sequence - containers.

      - -

      This is difficult and confusing to teach to newcomers. All - insert operations that specify an iterator as an insertion location - should have a consistent meaning for the location represented by - that iterator.

      3. - -

    3. As specified, there is no way to hint that the insertion - should occur at the beginning of the container, and the way to hint - that it should occur at the end is long winded and unnatural.

      - -

      For a container containing n elements, there are n+1 possible - insertion locations and n+1 valid iterators. For there to be a - one-to-one mapping between iterators and insertion locations, the - iterator must represent an insertion location immediately before - the iterator.

      4. - -

    4. When appending sorted ranges using insert_iterators, - insertions are guaranteed to be sub-optimal.

      - -

      In such a situation, the optimum location for insertion is - always immediately after the element previously inserted. The - mechanics of the insert iterator guarantee that it will try and - insert after the element after that, which will never be correct. - However, if the container first tried to insert before the hint, - all insertions would be performed in amortized constant - time.

      5. -
    - - -

    Proposed resolution:

    -

    In 23.1.2 [lib.associative.reqmts] paragraph 7, table 69, make -the following changes in the row for a.insert(p,t):

    - -

    assertion/note pre/post condition: -
    Change the last sentence from

    -

    - "iterator p is a hint pointing to where the insert should - start to search." -

    -

    to

    -

    - "iterator p is a hint indicating that immediately before p - may be a correct location where the insertion could occur." -

    - -

    complexity:
    -Change the words "right after" to "immediately before".

    - - -

    Rationale:

    - - - - - -
    -

    249. Return Type of auto_ptr::operator=

    -

    Section: D.9.1 [auto.ptr] Status: NAD - Submitter: Joseph Gottman Date: 2000-06-30

    -

    View all other issues in [auto.ptr].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    According to section 20.4.5, the function -auto_ptr::operator=() returns a reference to an auto_ptr. -The reason that operator=() usually returns a reference is to -facilitate code like

    - -
        int x,y,z;
-    x = y = z = 1;
-
    - -

    However, given analogous code for auto_ptrs,

    -
        auto_ptr<int> x, y, z;
-    z.reset(new int(1));
-    x = y = z;
-
    - -

    the result would be that z and y would both be set to -NULL, instead of all the auto_ptrs being set to the same value. -This makes such cascading assignments useless and counterintuitive for -auto_ptrs.

    - - -

    Proposed resolution:

    -

    Change auto_ptr::operator=() to return void instead -of an auto_ptr reference.

    - - -

    Rationale:

    -

    The return value has uses other than cascaded assignments: a user can -call an auto_ptr member function, pass the auto_ptr to a -function, etc. Removing the return value could break working user -code.

    - - - - -
    -

    257. STL functional object and iterator inheritance.

    -

    Section: 20.6.3 [base], 24.3.2 [iterator.basic] Status: NAD - Submitter: Robert Dick Date: 2000-08-17

    -

    View all other issues in [base].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    -According to the November 1997 Draft Standard, the results of deleting an -object of a derived class through a pointer to an object of its base class are -undefined if the base class has a non-virtual destructor. Therefore, it is -potentially dangerous to publicly inherit from such base classes. -

    - -

    Defect: -
    -The STL design encourages users to publicly inherit from a number of classes -which do nothing but specify interfaces, and which contain non-virtual -destructors. -

    - -

    Attribution: -
    -Wil Evers and William E. Kempf suggested this modification for functional -objects. -

    - - -

    Proposed resolution:

    -

    -When a base class in the standard library is useful only as an interface -specifier, i.e., when an object of the class will never be directly -instantiated, specify that the class contains a protected destructor. This -will prevent deletion through a pointer to the base class without performance, -or space penalties (on any implementation I'm aware of). -

    - -

    -As an example, replace... -

    - -
        template <class Arg, class Result>
-    struct unary_function {
-            typedef Arg    argument_type;
-            typedef Result result_type;
-    };
-
    - -

    -... with... -

    - -
        template <class Arg, class Result>
-    struct unary_function {
-            typedef Arg    argument_type;
-            typedef Result result_type;
-    protected:
-            ~unary_function() {}
-    };
-
    - -

    -Affected definitions: -
    -  20.3.1 [lib.function.objects] -- unary_function, binary_function -
    -  24.3.2 [lib.iterator.basic] -- iterator -

    - - -

    Rationale:

    -

    -The standard is clear as written; this is a request for change, not a -defect in the strict sense. The LWG had several different objections -to the proposed change. One is that it would prevent users from -creating objects of type unary_function and -binary_function. Doing so can sometimes be legitimate, if users -want to pass temporaries as traits or tag types in generic code. -

    - - - - - -
    -

    267. interaction of strstreambuf::overflow() and seekoff()

    -

    Section: D.7.1.3 [depr.strstreambuf.virtuals] Status: NAD - Submitter: Martin Sebor Date: 2000-10-05

    -

    View all other issues in [depr.strstreambuf.virtuals].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    -It appears that the interaction of the strstreambuf members overflow() -and seekoff() can lead to undefined behavior in cases where defined -behavior could reasonably be expected. The following program -demonstrates this behavior: -

    - -
        #include <strstream>
-
-    int main ()
-    {
-         std::strstreambuf sb;
-         sb.sputc ('c');
-
-         sb.pubseekoff (-1, std::ios::end, std::ios::in);
-         return !('c' == sb.sgetc ());
-    }
-
    - -

    -D.7.1.1, p1 initializes strstreambuf with a call to basic_streambuf<>(), -which in turn sets all pointers to 0 in 27.5.2.1, p1. -

    - -

    -27.5.2.2.5, p1 says that basic_streambuf<>::sputc(c) calls -overflow(traits::to_int_type(c)) if a write position isn't available (it -isn't due to the above). -

    - -

    -D.7.1.3, p3 says that strstreambuf::overflow(off, ..., ios::in) makes at -least one write position available (i.e., it allows the function to make -any positive number of write positions available). -

    - -

    -D.7.1.3, p13 computes newoff = seekhigh - eback(). In D.7.1, p4 we see -seekhigh = epptr() ? epptr() : egptr(), or seekhigh = epptr() in this -case. newoff is then epptr() - eback(). -

    - -

    -D.7.1.4, p14 sets gptr() so that gptr() == eback() + newoff + off, or -gptr() == epptr() + off holds. -

    - -

    -If strstreambuf::overflow() made exactly one write position available -then gptr() will be set to just before epptr(), and the program will -return 0. Buf if the function made more than one write position -available, epptr() and gptr() will both point past pptr() and the -behavior of the program is undefined. -

    - - -

    Proposed resolution:

    - - -

    Change the last sentence of D.7.1 [depr.strstreambuf] paragraph 4 from

    - -

    - Otherwise, seeklow equals gbeg and seekhigh is either pend, if - pend is not a null pointer, or gend. -

    - -

    to become

    - -

    - Otherwise, seeklow equals gbeg and seekhigh is either gend if - 0 == pptr(), or pbase() + max where max is the maximum value of - pptr() - pbase() ever reached for this stream. -

    - -

    [ - pre-Copenhagen: Dietmar provided wording for proposed resolution. -]

    - - -

    [ - post-Copenhagen: Fixed a typo: proposed resolution said to fix - 4.7.1, not D.7.1. -]

    - - - - -

    Rationale:

    -

    This is related to issue 65: it's not clear what it -means to seek beyond the current area. Without resolving issue 65 we can't resolve this. As with issue 65, -the library working group does not wish to invest time nailing down -corner cases in a deprecated feature.

    - - - - - -
    -

    269. cstdarg and unnamed parameters

    -

    Section: 18.7 [support.exception] Status: NAD - Submitter: J. Stephen Adamczyk Date: 2000-10-10

    -

    View all other issues in [support.exception].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    -One of our customers asks whether this is valid C++: -

    - -
       #include <cstdarg>
-
-   void bar(const char *, va_list);
-
-   void
-   foo(const char *file, const char *, ...)
-   {
-     va_list ap;
-     va_start(ap, file);
-     bar(file, ap);
-     va_end(ap);
-   }
-
    - -

    -The issue being whether it is valid to use cstdarg when the final -parameter before the "..." is unnamed. cstdarg is, as far -as I can tell, inherited verbatim from the C standard. and the -definition there (7.8.1.1 in the ISO C89 standard) refers to "the -identifier of the rightmost parameter". What happens when there -is no such identifier? -

    - -

    -My personal opinion is that this should be allowed, but some tweak -might be required in the C++ standard. -

    - - -

    Rationale:

    -

    -Not a defect, the C and C++ standards are clear. It is impossible to -use varargs if the parameter immediately before "..." has no -name, because that is the parameter that must be passed to va_start. -The example given above is broken, because va_start is being passed -the wrong parameter. -

    - -

    -There is no support for extending varargs to provide additional -functionality beyond what's currently there. For reasons of C/C++ -compatibility, it is especially important not to make gratuitous -changes in this part of the C++ standard. The C committee has already -been requested not to touch this part of the C standard unless -necessary. -

    - - - - -
    -

    277. Normative encouragement in allocator requirements unclear

    -

    Section: 20.1.2 [allocator.requirements] Status: NAD - Submitter: Matt Austern Date: 2000-11-07

    -

    View other active issues in [allocator.requirements].

    -

    View all other issues in [allocator.requirements].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    -In 20.1.5, paragraph 5, the standard says that "Implementors are -encouraged to supply libraries that can accept allocators that -encapsulate more general memory models and that support non-equal -instances." This is intended as normative encouragement to -standard library implementors. However, it is possible to interpret -this sentence as applying to nonstandard third-party libraries. -

    - - -

    Proposed resolution:

    -

    -In 20.1.5, paragraph 5, change "Implementors" to -"Implementors of the library described in this International -Standard". -

    - - -

    Rationale:

    -

    The LWG believes the normative encouragement is already -sufficiently clear, and that there are no important consequences -even if it is misunderstood.

    - - - - - -
    -

    279. const and non-const iterators should have equivalent typedefs

    -

    Section: 23.1 [container.requirements] Status: NAD - Submitter: Steve Cleary Date: 2000-11-27

    -

    View other active issues in [container.requirements].

    -

    View all other issues in [container.requirements].

    -

    View all issues with NAD status.

    -

    Discussion:

    - -

    -This came from an email from Steve Cleary to Fergus in reference to -issue 179. The library working group briefly discussed -this in Toronto and believes it should be a separate issue. -

    - -

    -Steve said: "We may want to state that the const/non-const iterators must have -the same difference type, size_type, and category." -

    - -

    -(Comment from Judy) -I'm not sure if the above sentence should be true for all -const and non-const iterators in a particular container, or if it means -the container's iterator can't be compared with the container's -const_iterator unless the above it true. I suspect the former. -

    - - -

    Proposed resolution:

    -

    -In Section: 23.1 [container.requirements], -table 65, in the assertion/note pre/post condition for X::const_iterator, -add the following: -

    - -
    -

    -typeid(X::const_iterator::difference_type) == typeid(X::iterator::difference_type) -

    - -

    -typeid(X::const_iterator::size_type) == typeid(X::iterator::size_type) -

    - -

    -typeid(X::const_iterator::category) == typeid(X::iterator::category) -

    -
    - - -

    Rationale:

    -

    Going through the types one by one: Iterators don't have a -size_type. We already know that the difference types are -identical, because the container requirements already say that the -difference types of both X::iterator and X::const_iterator are both -X::difference_type. The standard does not require that X::iterator -and X::const_iterator have the same iterator category, but the LWG -does not see this as a defect: it's possible to imagine cases in which -it would be useful for the categories to be different.

    - -

    It may be desirable to require X::iterator and X::const_iterator to -have the same value type, but that is a new issue. (Issue 322.)

    - - - - - - -
    -

    287. conflicting ios_base fmtflags

    -

    Section: 27.4.2.2 [fmtflags.state] Status: NAD - Submitter: Judy Ward Date: 2000-12-30

    -

    View all other issues in [fmtflags.state].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    -The Effects clause for ios_base::setf(fmtflags fmtfl) says -"Sets fmtfl in flags()". What happens if the user first calls -ios_base::scientific and then calls ios_base::fixed or vice-versa? -This is an issue for all of the conflicting flags, i.e. ios_base::left -and ios_base::right or ios_base::dec, ios_base::hex and ios_base::oct. -

    - -

    -I see three possible solutions: -

    - -
      -
    1. Set ios_base::failbit whenever the user specifies a conflicting -flag with one previously explicitly set. If the constructor is -supposed to set ios_base::dec (see discussion below), then -the user setting hex or oct format after construction will not -set failbit.
      2. -
    2. The last call to setf "wins", i.e. it clears any conflicting -previous setting.
      3. -
    3. All the flags that the user specifies are set, but when actually -interpreting them, fixed always override scientific, right always -overrides left, dec overrides hex which overrides oct.
      4. -
    - -

    -Most existing implementations that I tried seem to conform to resolution #3, -except that when using the iomanip manipulator hex or oct then that always -overrides dec, but calling setf(ios_base::hex) doesn't. -

    - -

    -There is a sort of related issue, which is that although the ios_base -constructor says that each ios_base member has an indeterminate value -after construction, all the existing implementations I tried explicitly set -ios_base::dec. -

    - - -

    Proposed resolution:

    - - -

    Rationale:

    -

    -adjustfield, basefield, and floatfield -are each multi-bit fields. It is possible to set multiple bits within -each of those fields. (For example, dec and -oct). These fields are used by locale facets. The LWG -reviewed the way in which each of those three fields is used, and -believes that in each case the behavior is well defined for any -possible combination of bits. See for example Table 58, in 22.2.2.2.2 -[facet.num.put.virtuals], noting the requirement in paragraph 6 of that -section. -

    -

    -Users are advised to use manipulators, or else use the two-argument -version of setf, to avoid unexpected behavior. -

    - - - - - -
    -

    289. <cmath> requirements missing C float and long double versions

    -

    Section: 26.7 [c.math] Status: NAD - Submitter: Judy Ward Date: 2000-12-30

    -

    View all other issues in [c.math].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    - In ISO/IEC 9899:1990 Programming Languages C we find the following - concerning <math.h>: -

    - -

    - 7.13.4 Mathematics <math.h> -
    - The names of all existing functions declared in the <math.h> - header, suffixed with f or l, are reserved respectively for - corresponding functions with float and long double arguments - are return values. -

    - -

    - For example, float sinf(float) - is reserved. -

    - -

    - In the C99 standard, <math.h> must contain declarations - for these functions. -

    - -

    -So, is it acceptable for an implementor to add these prototypes to the -C++ versions of the math headers? Are they required? -

    - - -

    Proposed resolution:

    -

    -Add these Functions to Table 80, section 26.5 and to Table 99, -section C.2: -

    - -
        acosf asinf atanf atan2f ceilf cosf coshf 
-    expf fabsf floorf fmodf frexpf ldexpf 
-    logf log10f modff powf sinf sinhf sqrtf 
-    tanf tanhf 
-    acosl asinl atanl atan2l ceill cosl coshl 
-    expl fabsl floorl fmodl frexpl ldexpl 
-    logl log10l modfl powl sinl sinhl sqrtl 
-    tanl tanhl
-
    - -

    -There should probably be a note saying that these functions -are optional and, if supplied, should match the description in -the 1999 version of the C standard. In the next round -of C++ standardization they can then become mandatory. -

    - - -

    Rationale:

    -

    The C90 standard, as amended, already permits (but does not -require) these functions, and the C++ standard incorporates the -C90 standard by reference. C99 is not an issue, because it is -never referred to by the C++ standard.

    - - - - - -
    -

    293. Order of execution in transform algorithm

    -

    Section: 25.2.4 [alg.transform] Status: NAD - Submitter: Angelika Langer Date: 2001-01-04

    -

    View all other issues in [alg.transform].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    This issue is related to issue 242. In case that the resolution -proposed for issue 242 is accepted, we have have the following -situation: The 4 numeric algorithms (accumulate and consorts) as well -as transform would allow a certain category of side effects. The -numeric algorithms specify that they invoke the functor "for -every iterator i in the range [first, last) in order". transform, -in contrast, would not give any guarantee regarding order of -invocation of the functor, which means that the functor can be invoked -in any arbitrary order. -

    - -

    Why would that be a problem? Consider an example: say the -transformator that is a simple enumerator ( or more generally -speaking, "is order-sensitive" ). Since a standard -compliant implementation of transform is free to invoke the enumerator -in no definite order, the result could be a garbled enumeration. -Strictly speaking this is not a problem, but it is certainly at odds -with the prevalent understanding of transform as an algorithms that -assigns "a new _corresponding_ value" to the output -elements. -

    - -

    All implementations that I know of invoke the transformator in -definite order, namely starting from first and proceeding to last - -1. Unless there is an optimization conceivable that takes advantage of -the indefinite order I would suggest to specify the order, because it -eliminate the uncertainty that users would otherwise have regarding -the order of execution of their potentially order-sensitive function -objects. -

    - - -

    Proposed resolution:

    -

    In section 25.2.3 - Transform [lib.alg.transform] change:

    -

    --1- Effects: Assigns through every iterator i in the range [result, -result + (last1 - first1)) a new corresponding -value equal to op(*(first1 + (i - result)) or binary_op(*(first1 + -(i - result), *(first2 + (i - result))). -

    -

    to:

    -

    --1- Effects: Computes values by invoking the operation op or binary_op -for every iterator in the range [first1, last1) in order. Assigns through -every iterator i in the range [result, result + (last1 - first1)) a new -corresponding -value equal to op(*(first1 + (i - result)) or binary_op(*(first1 + -(i - result), *(first2 + (i - result))). -

    - - -

    Rationale:

    -

    For Input Iterators an order is already guaranteed, because -only one order is possible. If a user who passes a Forward -Iterator to one of these algorithms really needs a specific -order of execution, it's possible to achieve that effect by -wrapping it in an Input Iterator adaptor.

    - - - - - -
    -

    296. Missing descriptions and requirements of pair operators

    -

    Section: 20.2.3 [pairs] Status: NAD - Submitter: Martin Sebor Date: 2001-01-14

    -

    View all other issues in [pairs].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    The synopsis of the header <utility> in 20.2 [utility] -lists the complete set of equality and relational operators for pair -but the section describing the template and the operators only describes -operator==() and operator<(), and it fails to mention -any requirements on the template arguments. The remaining operators are -not mentioned at all. -

    - - -

    Rationale:

    -

    20.2.1 [operators] paragraph 10 already specifies the semantics. -That paragraph says that, if declarations of operator!=, operator>, -operator<=, and operator>= appear without definitions, they are -defined as specified in 20.2.1 [operators]. There should be no user -confusion, since that paragraph happens to immediately precede the -specification of pair.

    - - - - - -
    -

    302. Need error indication from codecvt<>::do_length

    -

    Section: 22.2.1.5 [locale.codecvt.byname] Status: NAD - Submitter: Gregory Bumgardner Date: 2001-01-25

    -

    View all other issues in [locale.codecvt.byname].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    -The effects of codecvt<>::do_length() are described in -22.2.1.5.2, paragraph 10. As implied by that paragraph, and clarified -in issue 75, codecvt<>::do_length() must -process the source data and update the stateT argument just -as if the data had been processed by codecvt<>::in(). -However, the standard does not specify how do_length() would -report a translation failure, should the source sequence contain -untranslatable or illegal character sequences. -

    - -

    -The other conversion methods return an "error" result value -to indicate that an untranslatable character has been encountered, but -do_length() already has a return value (the number of source -characters that have been processed by the method). -

    - - -

    Proposed resolution:

    -

    -This issue cannot be resolved without modifying the interface. An exception -cannot be used, as there would be no way to determine how many characters -have been processed and the state object would be left in an indeterminate -state. -

    - -

    -A source compatible solution involves adding a fifth argument to length() -and do_length() that could be used to return position of the offending -character sequence. This argument would have a default value that would -allow it to be ignored: -

    - -
      int length(stateT& state, 
-             const externT* from, 
-             const externT* from_end, 
-             size_t max,
-             const externT** from_next = 0);
-
-  virtual
-  int do_length(stateT& state, 
-                const externT* from, 
-                const externT* from_end, 
-                size_t max,
-                const externT** from_next);
-
    - -

    -Then an exception could be used to report any translation errors and -the from_next argument, if used, could then be used to retrieve the -location of the offending character sequence. -

    - - -

    Rationale:

    -

    The standard is already clear: the return value is the number of -"valid complete characters". If it encounters an invalid sequence of -external characters, it stops.

    - - - - - -
    -

    304. Must *a return an lvalue when a is an input iterator?

    -

    Section: 24.1 [iterator.requirements] Status: NAD - Submitter: Dave Abrahams Date: 2001-02-05

    -

    View other active issues in [iterator.requirements].

    -

    View all other issues in [iterator.requirements].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    -We all "know" that input iterators are allowed to produce -values when dereferenced of which there is no other in-memory copy. -

    - -

    -But: Table 72, with a careful reading, seems to imply that this can only be -the case if the value_type has no members (e.g. is a built-in type). -

    - -

    The problem occurs in the following entry:

    - -
      a->m     pre: (*a).m is well-defined
-           Equivalent to (*a).m
-
    - -

    -*a.m can be well-defined if *a is not a reference -type, but since operator->() must return a pointer for -a->m to be well-formed, it needs something to return a -pointer to. This seems to indicate that *a must be -buffered somewhere to make a legal input iterator. -

    - -

    I don't think this was intentional.

    - - -

    Rationale:

    -

    The current standard is clear and consistent. Input iterators that - return rvalues are in fact implementable. They may in some cases - require extra work, but it is still possible to define an operator-> - in such cases: it doesn't have to return a T*, but may return a - proxy type. No change to the standard is justified.

    - - - - - -
    -

    313. set_terminate and set_unexpected question

    -

    Section: 18.7.3.3 [terminate] Status: NAD - Submitter: Judy Ward Date: 2001-04-03

    -

    View all other issues in [terminate].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    -According to section 18.7.3.3 of the standard, std::terminate() is -supposed to call the terminate_handler in effect immediately after -evaluating the throw expression. -

    - -

    -Question: what if the terminate_handler in effect is itself -std::terminate? -

    - -

    For example:

    - -
      #include <exception>
-
-  int main () {
-      std::set_terminate(std::terminate);
-      throw 5;
-      return 0;
-  }
-
    - -

    -Is the implementation allowed to go into an infinite loop? -

    - -

    -I think the same issue applies to std::set_unexpected. -

    - - -

    Proposed resolution:

    - - -

    Rationale:

    -

    Infinite recursion is to be expected: users who set the terminate -handler to terminate are explicitly asking for terminate -to call itself.

    - - - - - -
    -

    314. Is the stack unwound when terminate() is called?

    -

    Section: 18.7.3.3 [terminate] Status: NAD - Submitter: Detlef Vollmann Date: 2001-04-11

    -

    View all other issues in [terminate].

    -

    View all issues with NAD status.

    -

    Discussion:

    - -

    -The standard appears to contradict itself about whether the stack is -unwound when the implementation calls terminate(). -

    - -

    From 18.7.3.3p2:

    -

    - Calls the terminate_handler function in effect immediately - after evaluating the throw-expression (lib.terminate.handler), - if called by the implementation [...] -

    - -

    So the stack is guaranteed not to be unwound.

    - -

    But from 15.3p9:

    -

    - [...]whether or not the stack is unwound before this call - to terminate() is implementation-defined (except.terminate). -

    - -

    -And 15.5.1 actually defines that in most cases the stack is unwound. -

    - - -

    Proposed resolution:

    - - -

    Rationale:

    -

    There is definitely no contradiction between the core and library -clauses; nothing in the core clauses says that stack unwinding happens -after terminate is called. 18.7.3.3p2 does not say anything -about when terminate() is called; it merely specifies which -terminate_handler is used.

    - - - - - -
    -

    323. abs() overloads in different headers

    -

    Section: 26.7 [c.math] Status: NAD - Submitter: Dave Abrahams Date: 2001-06-04

    -

    View all other issues in [c.math].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    Currently the standard mandates the following overloads of -abs():

    - -
        abs(long), abs(int) in <cstdlib>
-
-    abs(float), abs(double), abs(long double) in <cmath>
-
-    template<class T> T abs(const complex<T>&) in <complex>
-
-    template<class T> valarray<T> abs(const valarray<T>&); in <valarray>
-
    - -

    -The problem is that having only some overloads visible of a function -that works on "implicitly inter-convertible" types is dangerous in -practice. The headers that get included at any point in a translation -unit can change unpredictably during program -development/maintenance. The wrong overload might be unintentionally -selected. -

    - -

    -Currently, there is nothing that mandates the simultaneous visibility -of these overloads. Indeed, some vendors have begun fastidiously -reducing dependencies among their (public) headers as a QOI issue: it -helps people to write portable code by refusing to compile unless all -the correct headers are #included. -

    - -

    The same issue may exist for other functions in the library.

    - -

    Redmond: PJP reports that C99 adds two new kinds of abs: complex, -and int_max_abs.

    - -

    Related issue: 343.

    - -

    [ -Bellevue: -]

    - - -
    -The situation is not sufficiently severe to warrant a change. -
    - - - - -

    Rationale:

    -

    The programs that could potentially be broken by this situation are - already fragile, and somewhat contrived: For example, a user-defined - class that has conversion overloads both to long and - to float. If x is a value of such a class, then - abs(x) would give the long version if the user - included <cstdlib>, the float version if the user - included <cmath>, and would be diagnosed as ambiguous at - compile time if the user included both headers. The LWG couldn't - find an example of a program whose meaning would be changed (as - opposed to changing it from well-formed to ill-formed) simply by - adding another standard header.

    - -

    Since the harm seems minimal, and there don't seem to be any simple - and noninvasive solutions, this is being closed as NAD. It is - marked as "Future" for two reasons. First, it might be useful to - define an <all> header that would include all - Standard Library headers. Second, we should at least make sure that - future library extensions don't make this problem worse.

    - - - - - -
    -

    326. Missing typedef in moneypunct_byname

    -

    Section: 22.2.6.4 [locale.moneypunct.byname] Status: NAD - Submitter: Martin Sebor Date: 2001-07-05

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    The definition of the moneypunct facet contains the typedefs char_type -and string_type. Only one of these names, string_type, is defined in -the derived facet, moneypunct_byname.

    - - -

    Proposed resolution:

    -

    For consistency with the numpunct facet, add a typedef for -char_type to the definition of the moneypunct_byname facet in -22.2.6.4 [locale.moneypunct.byname].

    - - -

    Rationale:

    -

    The absence of the typedef is irrelevant. Users can still access -the typedef, because it is inherited from the base class.

    - - - - - -
    -

    330. Misleading "exposition only" value in class locale definition

    -

    Section: 22.1.1 [locale] Status: NAD - Submitter: Martin Sebor Date: 2001-07-15

    -

    View all other issues in [locale].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    -The "exposition only" value of the std::locale::none constant shown in -the definition of class locale is misleading in that it on many -systems conflicts with the value assigned to one if the LC_XXX -constants (specifically, LC_COLLATE on AIX, LC_ALL on HP-UX, LC_CTYPE -on Linux and SunOS). This causes incorrect behavior when such a -constant is passed to one of the locale member functions that accept a -locale::category argument and interpret it as either the C LC_XXX -constant or a bitmap of locale::category values. At least three major -implementations adopt the suggested value without a change and -consequently suffer from this problem. -

    - -

    -For instance, the following code will (presumably) incorrectly copy facets -belonging to the collate category from the German locale on AIX: -

    - -
      std::locale l (std::locale ("C"), "de_DE", std::locale::none);
-
    - - -

    Rationale:

    -

    The LWG agrees that it may be difficult to implement locale member -functions in such a way that they can take either category -arguments or the LC_ constants defined in <cctype>. In light of -this requirement (22.1.1.1.1 [locale.category], paragraph 2), and in light -of the requirement in the preceding paragraph that it is possible to -combine category bitmask elements with bitwise operations, -defining the category elements is delicate, -particularly if an implementor is constrained to work with a -preexisting C library. (Just using the existing LC_ constants would -not work in general.) There's no set of "exposition only" values that -could give library implementors proper guidance in such a delicate -matter. The non-normative example we're giving is no worse than -any other choice would be.

    - -

    See issue 347.

    - - - - - -
    -

    332. Consider adding increment and decrement operators to std::fpos< T >

    -

    Section: 27.4.3 [fpos] Status: NAD - Submitter: PremAnand M. Rao Date: 2001-08-27

    -

    View all other issues in [fpos].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    -Increment and decrement operators are missing from -Table 88 -- Position type requirements in 27.4.3 [fpos]. -

    - - -

    Proposed resolution:

    -

    -Table 88 (section 27.4.3) -- Position type requirements -be updated to include increment and decrement operators. -

    - -
    expression        return type     operational    note
-
-++p               fpos&           p += O(1)
-p++               fpos            { P tmp = p;
-                                    ++p;
-                                    return tmp; }
---p               fpos&           p -= O(1)
-p--               fpos            { P tmp = p;
-                                    --p;
-                                    return tmp; }
-
    - - - -

    Rationale:

    -

    The LWG believes this is a request for extension, not a defect -report. Additionally, nobody saw a clear need for this extension; -fpos is used only in very limited ways.

    - - - - - -
    -

    344. grouping + showbase

    -

    Section: 22.2.2 [category.numeric] Status: NAD - Submitter: Howard Hinnant Date: 2001-10-13

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    -When both grouping and showbase are active and the basefield is octal, -does the leading 0 participate in the grouping or not? For example, -should one format as: 0,123,456 or 0123,456? -

    -

    -An analogy can be drawn with hexadecimal. It appears that 0x123,456 is -preferred over 0x,123,456. However, this analogy is not universally -accepted to apply to the octal base. The standard is not clear on how -to format (or parse) in this manner. -

    - -

    Proposed resolution:

    -

    -Insert into 22.2.3.1.2 [facet.numpunct.virtuals] paragraph 3, just before the last -sentence: -

    -

    -The leading hexadecimal base specifier "0x" does not participate in -grouping. The leading '0' octal base specifier may participate in -grouping. It is unspecified if the leading '0' participates in -formatting octal numbers. In parsing octal numbers, the implementation -is encouraged to accept both the leading '0' participating in the -grouping, and not participating (e.g. 0123,456 or 0,123,456). -

    - -

    Rationale:

    -

    -The current behavior may be unspecified, but it's not clear that it -matters. This is an obscure corner case, since grouping is usually -intended for the benefit of humans and oct/hex prefixes are usually -intended for the benefit of machines. There is not a strong enough -consensus in the LWG for action. -

    - - - - -
    -

    348. Minor issue with std::pair operator<

    -

    Section: 20.2.3 [pairs] Status: Dup - Submitter: Andy Sawyer Date: 2001-10-23

    -

    View all other issues in [pairs].

    -

    View all issues with Dup status.

    -

    Duplicate of: 532

    -

    Discussion:

    - - -

    -The current wording of 20.2.2 [lib.pairs] p6 precludes the use of -operator< on any pair type which contains a pointer. -

    - - -

    Proposed resolution:

    -

    In 20.2.3 [pairs] paragraph 6, replace:

    -
        Returns: x.first < y.first || (!(y.first < x.first) && x.second <
-        y.second).
-
    -

    With:

    -
        Returns: std::less<T1>()( x.first, y.first ) ||
-             (!std::less<T1>()( y.first, x.first) && 
-             std::less<T2>()( x.second, y.second ) )
-
    - - - -

    Rationale:

    -

    This is an instance of a much more general problem. If we want - operator< to translate to std::less for pairs of pointers, where - do we draw the line? The same issue applies to individual - pointers, smart pointer wrappers, std::vector<T*>, and so - on.

    - -

    Andy Koenig suggests that the real issue here is that we aren't - distinguishing adequately between two different orderings, a - "useful ordering" and a "canonical ordering" that's used just - because we sometimes need some ordering without caring much - which ordering it is. Another example of the later is typeinfo's - before.

    - - - - - - -
    -

    350. allocator<>::address

    -

    Section: 20.7.5.1 [allocator.members], 20.1.2 [allocator.requirements], 17.4.1.1 [contents] Status: Dup - Submitter: Nathan Myers Date: 2001-10-25

    -

    View all other issues in [allocator.members].

    -

    View all issues with Dup status.

    -

    Duplicate of: 634

    -

    Discussion:

    -

    See c++std-lib-9006 and c++std-lib-9007. This issue is taken -verbatim from -9007.

    - -

    -The core language feature allowing definition of operator&() applied -to any non-builtin type makes that operator often unsafe to use in -implementing libraries, including the Standard Library. The result -is that many library facilities fail for legal user code, such as -the fragment

    -
      class A { private: A* operator&(); };
-  std::vector<A> aa;
-
-  class B { };
-  B* operator&(B&) { return 0; }
-  std::vector<B> ba;
-
    - -

    -In particular, the requirements table for Allocator (Table 32) specifies -no semantics at all for member address(), and allocator<>::address is -defined in terms of unadorned operator &. -

    - - - -

    Proposed resolution:

    -

    -In 20.6.1.1, Change the definition of allocator<>::address from:

    -

    - Returns: &x -

    - -

    to:

    - -

    - Returns: The value that the built in operator&(x) would return if not - overloaded. -

    - -

    -In 20.1.6, Table 32, add to the Notes column of the a.address(r) and -a.address(s) lines, respectively: -

    - -
      allocator<T>::address(r)
-  allocator<T>::address(s)
-
    - -

    In addition, in clause 17.4.1.1, add a statement:

    - -

    - The Standard Library does not apply operator& to any type for which - operator& may be overloaded. -

    - - - -

    Rationale:

    -

    The LWG believes both examples are ill-formed. The contained type -is required to be CopyConstructible (20.1.1 [utility.arg.requirements]), and that -includes the requirement that &t return the usual types and -values. Since allocators are intended to be used in conjunction with -containers, and since the CopyConstructible requirements appear to -have been written to deal with the concerns of this issue, the LWG -feels it is NAD unless someone can come up with a well-formed example -exhibiting a problem.

    - -

    It may well be that the CopyConstructible requirements are too - restrictive and that either the container requirements or the - CopyConstructive requirements should be relaxed, but that's a far - larger issue. Marking this issue as "future" as a pointer to that - larger issue.

    - - - - - -
    -

    351. unary_negate and binary_negate: struct or class?

    -

    Section: 20.6 [function.objects] Status: NAD Editorial - Submitter: Dale Riley Date: 2001-11-12

    -

    View all other issues in [function.objects].

    -

    View all issues with NAD Editorial status.

    -

    Discussion:

    -

    -In 20.6 [function.objects] the header <functional> synopsis declares -the unary_negate and binary_negate function objects as struct. -However in 20.6.10 [negators] the unary_negate and binary_negate -function objects are defined as class. Given the context, they are -not "basic function objects" like negate, so this is either a typo or -an editorial oversight. -

    - -

    [Taken from comp.std.c++]

    - - - -

    Proposed resolution:

    -

    Change the synopsis to reflect the useage in 20.6.10 [negators]

    - -

    [Curaçao: Since the language permits "struct", the LWG -views this as NAD. They suggest, however, that the Project Editor -might wish to make the change as editorial.]

    - - - - - - - -
    -

    353. std::pair missing template assignment

    -

    Section: 20.2.3 [pairs] Status: NAD Editorial - Submitter: Martin Sebor Date: 2001-12-02

    -

    View all other issues in [pairs].

    -

    View all issues with NAD Editorial status.

    -

    Discussion:

    -

    -The class template std::pair defines a template ctor (20.2.2, p4) but -no template assignment operator. This may lead to inefficient code since -assigning an object of pair<C, D> to pair<A, B> -where the types C and D are distinct from but convertible to -A and B, respectively, results in a call to the template copy -ctor to construct an unnamed temporary of type pair<A, B> -followed by an ordinary (perhaps implicitly defined) assignment operator, -instead of just a straight assignment. -

    - - -

    Proposed resolution:

    -

    -Add the following declaration to the definition of std::pair: -

    -
        template<class U, class V>
-    pair& operator=(const pair<U, V> &p);
-
    -

    -And also add a paragraph describing the effects of the function template to the -end of 20.2.2: -

    -
        template<class U, class V>
-    pair& operator=(const pair<U, V> &p);
-
    -

    - Effects: first = p.first; - second = p.second; - Returns: *this -

    - -

    [Curaçao: There is no indication this is was anything other than -a design decision, and thus NAD.  May be appropriate for a future -standard.]

    - - -

    [ -Pre Bellevue: It was recognized that this was taken care of by -N1856, -and thus moved from NAD Future to NAD Editorial. -]

    - - - - - - -
    -

    356. Meaning of ctype_base::mask enumerators

    -

    Section: 22.2.1 [category.ctype] Status: NAD - Submitter: Matt Austern Date: 2002-01-23

    -

    View all other issues in [category.ctype].

    -

    View all issues with NAD status.

    -

    Discussion:

    - -

    What should the following program print?

    - -
      #include <locale>
-  #include <iostream>
-
-  class my_ctype : public std::ctype<char>
-  {
-    typedef std::ctype<char> base;
-  public:
-    my_ctype(std::size_t refs = 0) : base(my_table, false, refs)
-    {
-      std::copy(base::classic_table(), base::classic_table() + base::table_size,
-                my_table);
-      my_table[(unsigned char) '_'] = (base::mask) (base::print | base::space);
-    }
-  private:
-    mask my_table[base::table_size];
-  };
-
-  int main()
-  {
-    my_ctype ct;
-    std::cout << "isspace: " << ct.is(std::ctype_base::space, '_') << "    "
-              << "isalpha: " << ct.is(std::ctype_base::alpha, '_') << std::endl;
-  }
-
    - -

    The goal is to create a facet where '_' is treated as whitespace.

    - -

    On gcc 3.0, this program prints "isspace: 1 isalpha: 0". On -Microsoft C++ it prints "isspace: 1 isalpha: 1".

    - -

    -I believe that both implementations are legal, and the standard does not -give enough guidance for users to be able to use std::ctype's -protected interface portably.

    - -

    -The above program assumes that ctype_base::mask enumerators like -space and print are disjoint, and that the way to -say that a character is both a space and a printing character is to or -those two enumerators together. This is suggested by the "exposition -only" values in 22.2.1 [category.ctype], but it is nowhere specified in -normative text. An alternative interpretation is that the more -specific categories subsume the less specific. The above program -gives the results it does on the Microsoft compiler because, on that -compiler, print has all the bits set for each specific -printing character class. -

    - -

    From the point of view of std::ctype's public interface, there's no -important difference between these two techniques. From the point of -view of the protected interface, there is. If I'm defining a facet -that inherits from std::ctype<char>, I'm the one who defines the -value that table()['a'] returns. I need to know what combination of -mask values I should use. This isn't so very esoteric: it's exactly -why std::ctype has a protected interface. If we care about users -being able to write their own ctype facets, we have to give them a -portable way to do it. -

    - -

    -Related reflector messages: -lib-9224, lib-9226, lib-9229, lib-9270, lib-9272, lib-9273, lib-9274, -lib-9277, lib-9279. -

    - -

    Issue 339 is related, but not identical. The -proposed resolution if issue 339 says that -ctype_base::mask must be a bitmask type. It does not say that the -ctype_base::mask elements are bitmask elements, so it doesn't -directly affect this issue.

    - -

    More comments from Benjamin Kosnik, who believes that -that C99 compatibility essentially requires what we're -calling option 1 below.

    - -
    -
    I think the C99 standard is clear, that isspace -> !isalpha.
---------
-
-#include <locale>
-#include <iostream>
-
-class my_ctype : public std::ctype<char>
-{
-private:
-  typedef std::ctype<char> base;
-  mask my_table[base::table_size];
-
-public:
-  my_ctype(std::size_t refs = 0) : base(my_table, false, refs)
-  {
-    std::copy(base::classic_table(), base::classic_table() + base::table_size,
-              my_table);
-    mask both = base::print | base::space;
-    my_table[static_cast<mask>('_')] = both;
-  }
-};
-
-int main()
-{
-  using namespace std;
-  my_ctype ct;
-  cout << "isspace: " << ct.is(ctype_base::space, '_') << endl;
-  cout << "isprint: " << ct.is(ctype_base::print, '_') << endl;
-
-  // ISO C99, isalpha iff upper | lower set, and !space.
-  // 7.5, p 193
-  // -> looks like g++ behavior is correct.
-  // 356 -> bitmask elements are required for ctype_base
-  // 339 -> bitmask type required for mask
-  cout << "isalpha: " << ct.is(ctype_base::alpha, '_') << endl;
-}
-
    -
    - - - -

    Proposed resolution:

    -

    Informally, we have three choices:

    -
      -
    1. Require that the enumerators are disjoint (except for alnum and -graph)
      2. -
    2. Require that the enumerators are not disjoint, and specify which -of them subsume which others. (e.g. mandate that lower includes alpha -and print)
      3. -
    3. Explicitly leave this unspecified, which the result that the above -program is not portable.
      4. -
    - -

    Either of the first two options is just as good from the standpoint -of portability. Either one will require some implementations to -change.

    - - -

    Rationale:

    -

    The LWG agrees that this is a real ambiguity, and that both -interpretations are conforming under the existing standard. However, -there's no evidence that it's causing problems for real users. Users -who want to define ctype facets portably can test the ctype_base masks -to see which interpretation is being used.

    - - - - - -
    -

    357. <cmath> float functions cannot return HUGE_VAL

    -

    Section: 26.7 [c.math] Status: NAD Editorial - Submitter: Ray Lischner Date: 2002-02-26

    -

    View all other issues in [c.math].

    -

    View all issues with NAD Editorial status.

    -

    Discussion:

    -

    -The float versions of the math functions have no meaningful value to return -for a range error. The long double versions have a value they can return, -but it isn't necessarily the most reasonable value. -

    - -

    -Section 26.5 [lib.c.math], paragraph 5, says that C++ "adds float and long -double overloaded versions of these functions, with the same semantics," -referring to the math functions from the C90 standard. -

    - -

    -The C90 standard, in section 7.5.1, paragraph 3, says that functions return -"the value of the macro HUGE_VAL" when they encounter a range error. -Section 7.5, paragraph 2, defines HUGE_VAL as a macro that "expands to a -positive double expression, not necessarily representable as a float." -

    - -

    -Therefore, the float versions of the math functions have no way to -signal a range error. [Curaçao: The LWG notes that this isn't -strictly correct, since errno is set.] The semantics require that they -return HUGE_VAL, but they cannot because HUGE_VAL might not be -representable as a float. -

    - -

    -The problem with long double functions is less severe because HUGE_VAL is -representable as a long double. On the other hand, it might not be a "huge" -long double value, and might fall well within the range of normal return -values for a long double function. Therefore, it does not make sense for a -long double function to return a double (HUGE_VAL) for a range error. -

    - - -

    Proposed resolution:

    -

    Curaçao: C99 was faced with a similar problem, which they fixed by -adding HUGE_VALF and HUGE_VALL in addition to HUGE_VAL.

    - -

    C++ must also fix, but it should be done in the context of the -general C99 based changes to C++, not via DR. Thus the LWG in Curaçao -felt the resolution should be NAD, FUTURE, but the issue is being held -open for one more meeting to ensure LWG members not present during the -discussion concur.

    - - -

    Rationale:

    -

    Will be fixed as part of more general work in the TR.

    - - - - - -
    -

    361. num_get<>::do_get (..., void*&) checks grouping

    -

    Section: 22.2.2.2.2 [facet.num.put.virtuals] Status: NAD - Submitter: Martin Sebor Date: 2002-03-12

    -

    View all other issues in [facet.num.put.virtuals].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    -22.2.2.2.2, p12 specifies that thousands_sep is to be inserted only -for integral types (issue 282 suggests that this should be done for -all arithmetic types). -

    - -

    -22.2.2.1.2, p12 requires that grouping be checked for all extractors -including that for void*. -

    - -

    -I don't think that's right. void* values should not be checked for -grouping, should they? (Although if they should, then num_put needs -to write them out, otherwise their extraction will fail.) -

    - - -

    Proposed resolution:

    -

    -Change the first sentence of 22.2.2.2.2, p12 from -

    -

    - Digit grouping is checked. That is, the positions of discarded - separators is examined for consistency with - use_facet<numpunct<charT> >(loc).grouping(). - If they are not consistent then ios_base::failbit is assigned - to err. -

    - -

    to

    -

    - Except for conversions to void*, digit grouping is checked... -

    - - - -

    Rationale:

    -

    This would be a change: as it stands, the standard clearly - specifies that grouping applies to void*. A survey of existing - practice shows that most existing implementations do that, as they - should.

    - - - - - -
    -

    366. Excessive const-qualification

    -

    Section: 27 [input.output] Status: NAD - Submitter: Walter Brown, Marc Paterno Date: 2002-05-10

    -

    View all other issues in [input.output].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    -The following member functions are declared const, yet return non-const -pointers. We believe they are should be changed, because they allow code -that may surprise the user. See document N1360 for details and -rationale. -

    - -

    [Santa Cruz: the real issue is that we've got const member -functions that return pointers to non-const, and N1360 proposes -replacing them by overloaded pairs. There isn't a consensus about -whether this is a real issue, since we've never said what our -constness policy is for iostreams. N1360 relies on a distinction -between physical constness and logical constness; that distinction, or -those terms, does not appear in the standard.]

    - - - - -

    Proposed resolution:

    -

    In 27.4.4 and 27.4.4.2

    -

    Replace

    -
      basic_ostream<charT,traits>* tie() const;
-
    -

    with

    -
      basic_ostream<charT,traits>* tie();
-  const basic_ostream<charT,traits>* tie() const;
-
    - -

    and replace

    -
      basic_streambuf<charT,traits>* rdbuf() const;
-
    -

    with

    -
      basic_streambuf<charT,traits>* rdbuf();
-  const basic_streambuf<charT,traits>* rdbuf() const;
-
    - -

    In 27.5.2 and 27.5.2.3.1

    -

    Replace

    -
      char_type* eback() const;
-
    -

    with

    -
      char_type* eback();
-  const char_type* eback() const;
-
    - -

    Replace

    -
      char_type gptr() const;
-
    -

    with

    -
      char_type* gptr();
-  const char_type* gptr() const;
-
    - -

    Replace

    -
      char_type* egptr() const;
-
    -

    with

    -
      char_type* egptr();
-  const char_type* egptr() const;
-
    - -

    In 27.5.2 and 27.5.2.3.2

    -

    Replace

    -
      char_type* pbase() const;
-
    -

    with

    -
      char_type* pbase();
-  const char_type* pbase() const;
-
    - -

    Replace

    -
      char_type* pptr() const;
-
    -

    with

    -
      char_type* pptr();
-  const char_type* pptr() const;
-
    - -

    Replace

    -
      char_type* epptr() const;
-
    -

    with

    -
      char_type* epptr();
-  const char_type* epptr() const;
-
    - -

    In 27.7.2, 27.7.2.2, 27.7.3 27.7.3.2, 27.7.4, and 27.7.6

    -

    Replace

    -
      basic_stringbuf<charT,traits,Allocator>* rdbuf() const;
-
    -

    with

    -
      basic_stringbuf<charT,traits,Allocator>* rdbuf();
-  const basic_stringbuf<charT,traits,Allocator>* rdbuf() const;
-
    - -

    In 27.8.1.5, 27.8.1.7, 27.8.1.8, 27.8.1.10, 27.8.1.11, and 27.8.1.13

    -

    Replace

    -
      basic_filebuf<charT,traits>* rdbuf() const;
-
    -

    with

    -
      basic_filebuf<charT,traits>* rdbuf();
-  const basic_filebuf<charT,traits>* rdbuf() const;
-
    - - -

    Rationale:

    -

    The existing specification is a bit sloppy, but there's no - particular reason to change this other than tidiness, and there are - a number of ways in which streams might have been designed - differently if we were starting today. There's no evidence that the - existing constness policy is harming users. We might consider - a different constness policy as part of a full stream redesign.

    - - - - - -
    -

    367. remove_copy/remove_copy_if and Input Iterators

    -

    Section: 25.2.8 [alg.remove] Status: NAD - Submitter: Anthony Williams Date: 2002-05-13

    -

    View all other issues in [alg.remove].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    -remove_copy and remove_copy_if (25.2.8 [alg.remove]) permit their -input range to be marked with Input Iterators. However, since two -operations are required against the elements to copy (comparison and -assigment), when the input range uses Input Iterators, a temporary -copy must be taken to avoid dereferencing the iterator twice. This -therefore requires the value type of the InputIterator to be -CopyConstructible. If the iterators are at least Forward Iterators, -then the iterator can be dereferenced twice, or a reference to the -result maintained, so the temporary is not required. -

    - - -

    Proposed resolution:

    -

    -Add "If InputIterator does not meet the requirements of forward -iterator, then the value type of InputIterator must be copy -constructible. Otherwise copy constructible is not required." to -25.2.8 [alg.remove] paragraph 6. -

    - - -

    Rationale:

    -

    The assumption is that an input iterator can't be dereferenced - twice. There's no basis for that assumption in the Standard.

    - - - - - -
    -

    368. basic_string::replace has two "Throws" paragraphs

    -

    Section: 21.3.6.6 [string::replace] Status: NAD Editorial - Submitter: Beman Dawes Date: 2002-06-03

    -

    View all issues with NAD Editorial status.

    -

    Discussion:

    -

    -21.3.6.6 [string::replace] basic_string::replace, second -signature, given in paragraph 1, has two "Throws" paragraphs (3 and -5). -

    - -

    -In addition, the second "Throws" paragraph (5) includes specification -(beginning with "Otherwise, the function replaces ...") that should be -part of the "Effects" paragraph. -

    - - -

    Proposed resolution:

    - - -

    Rationale:

    -

    This is editorial. Both "throws" statements are true. The bug is - just that the second one should be a sentence, part of the "Effects" - clause, not a separate "Throws". The project editor has been - notified.

    - - - - - -
    -

    372. Inconsistent description of stdlib exceptions

    -

    Section: 17.4.4.9 [res.on.exception.handling], 18.6.1 [type.info] Status: NAD - Submitter: Randy Maddox Date: 2002-07-22

    -

    View all other issues in [res.on.exception.handling].

    -

    View all issues with NAD status.

    -

    Discussion:

    - -

    Paragraph 3 under clause 17.4.4.9 [res.on.exception.handling], Restrictions on -Exception Handling, states that "Any other functions defined in the -C++ Standard Library that do not have an exception-specification may -throw implementation-defined exceptions unless otherwise specified." -This statement is followed by a reference to footnote 178 at the -bottom of that page which states, apparently in reference to the C++ -Standard Library, that "Library implementations are encouraged (but -not required) to report errors by throwing exceptions from (or derived -from) the standard exceptions."

    - -

    These statements appear to be in direct contradiction to clause -18.6.1 [type.info], which states "The class exception defines the -base class for the types of objects thrown as exceptions by the C++ -Standard library components ...".

    - -

    Is this inconsistent?

    - - - -

    Proposed resolution:

    - - -

    Rationale:

    -

    Clause 17 is setting the overall library requirements, and it's - clear and consistent. This sentence from Clause 18 is descriptive, - not setting a requirement on any other class. -

    - - - - - -
    -

    374. moneypunct::frac_digits returns int not unsigned

    -

    Section: 22.2.6.3.1 [locale.moneypunct.members], 22.2.6.3.2 [locale.moneypunct.virtuals] Status: NAD - Submitter: Ray Lischner Date: 2002-08-08

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    -In section 22.2.6.3.1 [locale.moneypunct.members], frac_digits() returns type -"int". This implies that frac_digits() might return a negative value, -but a negative value is nonsensical. It should return "unsigned". -

    - -

    -Similarly, in section 22.2.6.3.2 [locale.moneypunct.virtuals], do_frac_digits() -should return "unsigned". -

    - - - -

    Proposed resolution:

    - - -

    Rationale:

    -

    Regardless of whether the return value is int or unsigned, it's -always conceivable that frac_digits might return a nonsensical -value. (Is 4294967295 really any better than -1?) The clients of -moneypunct, the get and put facets, can and do perform range -checks.

    - - - - - -
    -

    377. basic_string::insert and length_error

    -

    Section: 21.3.6.4 [string::insert] Status: NAD - Submitter: Ray Lischner Date: 2002-08-16

    -

    View all other issues in [string::insert].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    -Section 21.3.6.4 [string::insert], paragraph 4, contains the following, -"Then throws length_error if size() >= npos - rlen." -

    - -

    -Related to DR 83, this sentence should probably be removed. -

    - - -

    Proposed resolution:

    - - -

    Rationale:

    This requirement is redundant but correct. No change is -needed.

    - - - - -
    -

    378. locale immutability and locale::operator=()

    -

    Section: 22.1.1 [locale] Status: Dup - Submitter: Martin Sebor Date: 2002-09-06

    -

    View all other issues in [locale].

    -

    View all issues with Dup status.

    -

    Duplicate of: 31

    -

    Discussion:

    -

    -I think there is a problem with 22.1.1, p6 which says that -

    -
        -6- An instance of locale is immutable; once a facet reference
-        is obtained from it, that reference remains usable as long
-        as the locale value itself exists.
-
    -

    -and 22.1.1.2, p4: -

    -
        const locale& operator=(const locale& other) throw();
-
-    -4- Effects: Creates a copy of other, replacing the current value.
-
    -

    -How can a reference to a facet obtained from a locale object remain -valid after an assignment that clearly must replace all the facets -in the locale object? Imagine a program such as this -

    -
        std::locale loc ("de_DE");
-    const std::ctype<char> &r0 = std::use_facet<std::ctype<char> >(loc);
-    loc = std::locale ("en_US");
-    const std::ctype<char> &r1 = std::use_facet<std::ctype<char> >(loc);
-
    -

    -Is r0 really supposed to be preserved and destroyed only when loc goes -out of scope? -

    - - -

    Proposed resolution:

    -

    [Summer '04 mid-meeting mailing: Martin and Dietmar believe this - is a duplicate of issue 31 and recommend that it be - closed. -]

    - - - - - - -
    -

    385. Does call by value imply the CopyConstructible requirement?

    -

    Section: 17 [library] Status: NAD - Submitter: Matt Austern Date: 2002-10-23

    -

    View all other issues in [library].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    -Many function templates have parameters that are passed by value; -a typical example is find_if's pred parameter in -25.1.5 [alg.find]. Are the corresponding template parameters -(Predicate in this case) implicitly required to be -CopyConstructible, or does that need to be spelled out explicitly? -

    - -

    -This isn't quite as silly a question as it might seem to be at first -sight. If you call find_if in such a way that template -argument deduction applies, then of course you'll get call by value -and you need to provide a copy constructor. If you explicitly provide -the template arguments, however, you can force call by reference by -writing something like find_if<my_iterator, -my_predicate&>. The question is whether implementation -are required to accept this, or whether this is ill-formed because -my_predicate& is not CopyConstructible. -

    - -

    -The scope of this problem, if it is a problem, is unknown. Function -object arguments to generic algorithms in clauses 25 [algorithms] -and 26 [numerics] are obvious examples. A review of the whole -library is necessary. -

    -

    [ -This is really two issues. First, predicates are typically passed by -value but we don't say they must be Copy Constructible. They should -be. Second: is specialization allowed to transform value arguments -into references? References aren't copy constructible, so this should -not be allowed. -]

    - -

    [ -2007-01-12, Howard: First, despite the note above, references are -copy constructible. They just aren't assignable. Second, this is very -closely related to 92 and should be consistent with that. -That issue already says that implementations are allowed to copy -function objects. If one passes in a reference, it is copyable, but -susceptible to slicing if one passes in a reference to a base. Third, -with rvalue reference in the language one only needs to satisfy -MoveConstructible to pass an rvalue "by value". Though the function -might still copy the function object internally (requiring -CopyConstructible). Finally (and fwiw), if we wanted to, it is easy to -code all of the std::algorithms such that they do not copy function -objects internally. One merely passes them by reference internally if -desired (this has been fully implemented and shipped for several years). - If this were mandated, it would reverse 92, allowing -function objects to reliably maintain state. E.g. the example in 92 would reliably remove only the third element. -]

    - - - -

    Proposed resolution:

    -

    -Recommend NAD. -

    - - -

    Rationale:

    -

    -Generic algorithms will be marked with concepts and these will imply a requirement -of MoveConstructible (not CopyConstructible). The signature of the function will -then precisely describe and enforce the precise requirements. -

    - - - - - -
    -

    388. Use of complex as a key in associative containers

    -

    Section: 26.3 [complex.numbers] Status: NAD - Submitter: Gabriel Dos Reis Date: 2002-11-08

    -

    View all other issues in [complex.numbers].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    -Practice with std::complex<> and the associative containers -occasionally reveals artificial and distracting issues with constructs -resembling: std::set<std::complex<double> > s; -

    - -

    -The main reason for the above to fail is the absence of an approriate -definition for std::less<std::complex<T> >. That in turn comes from -the definition of the primary template std::less<> in terms of -operator<. -

    - -

    -The usual argument goes as follows: Since there is no ordering over -the complex field compatible with field operations it makes little -sense to define a function operator< operating on the datatype -std::complex<T>. That is fine. However, that reasoning does not carry -over to std::less<T> which is used, among other things, by associative -containers as an ordering useful to meet complexity requirements. -

    - -

    Related issue: 348.

    - -

    [ -Pre Bellevue: Reopened at the request of Alisdair. -]

    - - -

    [ -Bellevue: -]

    - - -
    -This is a request for a design change, and not a defect in the standard. -It is in scope to consider, but the group feels that it is not a change -that we need to do. Is there a total ordering for floating point values, -including NaN? There is not a clear enough solution or big enough -problem for us to solve. Solving this problem would require solving the -problem for floating point, which is equally unclear. The LWG noted that -users who want to put objects into an associative container for which -operator< isn't defined can simply provide their own comparison function -object. NAD -
    - - -

    Proposed resolution:

    -

    Informally: Add a specialization of std::less for std::complex.

    - - -

    Rationale:

    -

    Discussed in Santa Cruz. An overwhelming majority of the LWG -believes this should not be treated a DR: it's a request for a design -change, not a defect in the existing standard. Most people (10-3) -believed that we probably don't want this change, period: as with -issue 348, it's hard to know where to draw the line. -The LWG noted that users who want to put objects into an associative -container for which operator< isn't defined can simply -provide their own comparison function object.

    - - - - - -
    -

    390. CopyConstructible requirements too strict

    -

    Section: 20.1.1 [utility.arg.requirements] Status: NAD Editorial - Submitter: Doug Gregor Date: 2002-10-24

    -

    View other active issues in [utility.arg.requirements].

    -

    View all other issues in [utility.arg.requirements].

    -

    View all issues with NAD Editorial status.

    -

    Discussion:

    -

    -The CopyConstructible requirements in Table 30 state that for an -object t of type T (where T is CopyConstructible), the expression &t -returns the address of t (with type T*). This requirement is overly -strict, in that it disallows types that overload operator& to not -return a value of type T*. This occurs, for instance, in the Boost.Lambda library, where -operator& is overloaded for a Boost.Lambda function object to return -another function object. -

    - -

    Example:

    - -
      std::vector<int> u, v;
-  int x;
-  // ...
-  std::transform(u.begin(), u.end(), std::back_inserter(v), _1 * x);
-
    - -

    -_1 * x returns an unnamed function object with operator& overloaded to -not return T* , therefore rendering the std::transform call ill-formed. -However, most standard library implementations will compile this code -properly, and the viability of such binder libraries is severely hindered -by the unnecessary restriction in the CopyConstructible requirements. -

    - -

    -For reference, the address of an object can be retrieved without using -the address-of operator with the following function template: -

    - -
      template <typename T> T* addressof(T& v)
-  {
-    return reinterpret_cast<T*>(
-         &const_cast<char&>(reinterpret_cast<const volatile char &>(v)));
-  }
-
    - -

    -Note: this relates directly to library issue 350, which -will need to be reexamined if the CopyConstructible requirements -change. -

    - - -

    Proposed resolution:

    -

    -Remove the last two rows of Table 30, eliminating the requirements -that &t and &u return the address of t and u, respectively. -

    - - -

    Rationale:

    -

    This was a deliberate design decision. Perhaps it should be - reconsidered for C++0x.

    - - - - - -
    -

    392. 'equivalence' for input iterators

    -

    Section: 24.1.1 [input.iterators] Status: NAD - Submitter: Corwin Joy Date: 2002-12-11

    -

    View all other issues in [input.iterators].

    -

    View all issues with NAD status.

    -

    Discussion:

    - -

    -In section 24.1.1 [input.iterators] table 72 - -'Input Iterator Requirements' we have as a postcondition of *a: -"If a==b and (a, b) is in the domain of == then *a is equivalent to *b". -

    - -

    -In section 24.5.3.5 [istreambuf.iterator::equal] it states that -"istreambuf_iterator::equal returns true if and only if both iterators -are at end-of-stream, or neither is at end-of-stream, regardless of -what streambuf object they use." (My emphasis). -

    - -

    -The defect is that either 'equivalent' needs to be more precisely -defined or the conditions for equality in 24.5.3.5 [istreambuf.iterator::equal] -are incorrect. (Or both). -

    - -

    Consider the following example:

    -
       #include <iostream>
-   #include <fstream>
-   #include <iterator>
-   using namespace std;
-
-   int main() {
-    ifstream file1("file1.txt"), file2("file2.txt");
-    istreambuf_iterator<char> f1(file1), f2(file2);
-    cout << "f1 == f2 : " << boolalpha << (f1 == f2) << endl;
-    cout << "f1 = " << *f1 << endl;
-    cout << "f2 = " << *f2 << endl;
-    return 0;
-   }
-
    - -

    Now assuming that neither f1 or f2 are at the end-of-stream then -f1 == f2 by 24.5.3.5 [istreambuf.iterator::equal].

    - -

    However, it is unlikely that *f1 will give the same value as *f2 except -by accident.

    - -

    So what does *f1 'equivalent' to *f2 mean? I think the standard should -be clearer on this point, or at least be explicit that this does not -mean that *f1 and *f2 are required to have the same value in the case -of input iterators.

    - - -

    Proposed resolution:

    - - -

    Rationale:

    The two iterators aer not in the domain of ==

    - - - - - - -
    -

    393. do_in/do_out operation on state unclear

    -

    Section: 22.2.1.4.2 [locale.codecvt.virtuals] Status: NAD Editorial - Submitter: Alberto Barbati Date: 2002-12-24

    -

    View all other issues in [locale.codecvt.virtuals].

    -

    View all issues with NAD Editorial status.

    -

    Discussion:

    -

    -this DR follows the discussion on the previous thread "codecvt::do_in -not consuming external characters". It's just a clarification issue -and not a request for a change. -

    -

    -Can do_in()/do_out() produce output characters without consuming input -characters as a result of operation on state? -

    - - -

    Proposed resolution:

    -

    -Add a note at the end of 22.2.1.4.2 [locale.codecvt.virtuals], -paragraph 3: -

    - -

    -[Note: As a result of operations on state, it can return ok or partial -and set from_next == from and to_next != to. --end note] -

    - - -

    Rationale:

    -

    -The submitter believes that standard already provides an affirmative -answer to the question. However, the current wording has induced a few -library implementors to make the incorrect assumption that -do_in()/do_out() always consume at least one internal character when -they succeed. -

    - -

    -The submitter also believes that the proposed resolution is not in -conflict with the related issue 76. Moreover, by explicitly allowing -operations on state to produce characters, a codecvt implementation -may effectively implement N-to-M translations without violating the -"one character at a time" principle described in such issue. On a side -note, the footnote in the proposed resolution of issue 76 that -informally rules out N-to-M translations for basic_filebuf should be -removed if this issue is accepted as valid. -

    - - -

    [ -Kona (2007): The proposed resolution is to add a note. Since this is -non-normative, the issue is editorial, but we believe that the note is -correct. Proposed Disposition: NAD, Editorial -]

    - - - - - - -
    -

    399. volations of unformatted input function requirements

    -

    Section: 27.6.1.3 [istream.unformatted] Status: NAD - Submitter: Martin Sebor Date: 2003-01-05

    -

    View all other issues in [istream.unformatted].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    -The Effects clauses for the two functions below violate the -general requirements on unformatted input functions outlined -in 27.6.1.3: they do not begin by constructing a sentry object. -Instead, they begin by calling widen ('\n'), which may throw -an exception. The exception is then allowed to propagate from -the unformatted input function irrespective of the setting of -exceptions(). -

    -

    -Note that in light of 27.6.1.1, p3 and p4, the fact that the -functions allow exceptions thrown from widen() to propagate -may not strictly speaking be a defect (but the fact that the -functions do not start by constructing a sentry object still -is). However, since an exception thrown from ctype<charT> -::widen() during any other input operation (say, from within -a call to num_get<charT>::get()) will be caught and cause -badbit to be set, these two functions should not be treated -differently for the sake of consistency. -

    - - -

    Proposed resolution:

    - - -

    Rationale:

    -

    -Not a defect. The standard is consistent, and the behavior required -by the standard is unambiguous. Yes, it's theoretically possible for -widen to throw. (Not that this will happen for the default ctype -facet or for most real-world replacement ctype facets.) Users who -define ctype facets that can throw, and who care about this behavior, -can use alternative signatures that don't call widen. -

    - - - - - - -
    -

    424. normative notes

    -

    Section: 17.3.1.1 [structure.summary] Status: Pending NAD Editorial - Submitter: Martin Sebor Date: 2003-09-18

    -

    View all issues with Pending NAD Editorial status.

    -

    Discussion:

    - -

    -The text in 17.3.1.1, p1 says: -
    - -"Paragraphs labelled "Note(s):" or "Example(s):" are informative, other -paragraphs are normative." -
    - -The library section makes heavy use of paragraphs labeled "Notes(s)," -some of which are clearly intended to be normative (see list 1), while -some others are not (see list 2). There are also those where the intent -is not so clear (see list 3). -

    - -List 1 -- Examples of (presumably) normative Notes: -
    - -20.7.5.1 [allocator.members], p3,
    -20.7.5.1 [allocator.members], p10,
    -21.3.2 [string.cons], p11,
    -22.1.1.2 [locale.cons], p11,
    -23.2.2.3 [deque.modifiers], p2,
    -25.3.7 [alg.min.max], p3,
    -26.3.6 [complex.ops], p15,
    -27.5.2.4.3 [streambuf.virt.get], p7.
    -
    - -List 2 -- Examples of (presumably) informative Notes: -
    - -18.5.1.3 [new.delete.placement], p3,
    -21.3.6.6 [string::replace], p14,
    -22.2.1.4.2 [locale.codecvt.virtuals], p3,
    -25.1.4 [alg.foreach], p4,
    -26.3.5 [complex.member.ops], p1,
    -27.4.2.5 [ios.base.storage], p6.
    -
    - -List 3 -- Examples of Notes that are not clearly either normative -or informative: -
    - -22.1.1.2 [locale.cons], p8,
    -22.1.1.5 [locale.statics], p6,
    -27.5.2.4.5 [streambuf.virt.put], p4.
    -
    - -None of these lists is meant to be exhaustive. -

    - -

    [Definitely a real problem. The big problem is there's material - that doesn't quite fit any of the named paragraph categories - (e.g. Effects). Either we need a new kind of named - paragraph, or we need to put more material in unnamed paragraphs - jsut after the signature. We need to talk to the Project Editor - about how to do this. -]

    - - -

    [ -Bellevue: Specifics of list 3: First 2 items correct in std (22.1.1.2, -22.1.1.5) Third item should be non-normative (27.5.2.4.5), which Pete -will handle editorially. -]

    - - - -

    Proposed resolution:

    -

    [Pete: I changed the paragraphs marked "Note" and "Notes" to use "Remark" and "Remarks". -Fixed as editorial. This change has been in the WD since the post-Redmond mailing, in 2004. -Recommend NAD.]

    - -

    [ -Batavia: We feel that the references in List 2 above should be changed from Remarks -to Notes. We also feel that those items in List 3 need to be double checked for -the same change. Alan and Pete to review. -]

    - - - - - -
    -

    429. typo in basic_ios::clear(iostate)

    -

    Section: 27.4.4.3 [iostate.flags] Status: Dup - Submitter: Martin Sebor Date: 2003-09-18

    -

    View all other issues in [iostate.flags].

    -

    View all issues with Dup status.

    -

    Duplicate of: 412

    -

    Discussion:

    -

    - -The Effects clause in 27.4.4.3, p5 describing the effects of a call to -the ios_base member function clear(iostate state) says that the function -only throws if the respective bits are already set prior to the function -call. That's obviously not the intent. If it was, a call to clear(badbit) -on an object for which (rdstate() == goodbit && exceptions() == badbit) -holds would not result in an exception being thrown. - -

    - -

    Proposed resolution:

    -

    - -The text ought to be changed from -
    - -"If (rdstate() & exceptions()) == 0, returns. ..." -
    - -to -
    - -"If (state & exceptions()) == 0, returns. ..." -

    - - -

    Rationale:

    - - - - - - -
    -

    433. Contradiction in specification of unexpected()

    -

    Section: 18.7.2.4 [unexpected] Status: NAD - Submitter: Vyatcheslav Sysoltsev Date: 2003-09-29

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    -Clause 15.5.2 [except.unexpected] paragraph 1 says that "void unexpected(); -is called (18.7.2) immediately after completing the stack unwinding -for the former function", but 18.7.2.4 (Effects) says that "void -unexpected(); . . . Calls the unexpected_handler function in effect -immediately after evaluating the throwexpression (18.7.2.2),". Isn't -here a contradiction: 15.5.2 requires stack have been unwound when in -void unexpected() and therefore in unexpected_handler but 18.7.2.4 -claims that unexpected_handler is called "in effect immediately" after -evaluation of throw expression is finished, so there is no space left -for stack to be unwound therefore? I think the phrase "in effect -immediately" should be removed from the standard because it brings -ambiguity in understanding. -

    - - -

    Proposed resolution:

    - - -

    Rationale:

    -

    There is no contradiction. The phrase "in effect immediately" is - just to clarify which handler is to be called.

    - - - - - -
    -

    437. Formatted output of function pointers is confusing

    -

    Section: 27.6.2.6.2 [ostream.inserters.arithmetic] Status: NAD - Submitter: Ivan Godard Date: 2003-10-24

    -

    View all other issues in [ostream.inserters.arithmetic].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    -Given: -

    -
    void f(int) {}
-void(*g)(int) = f;
-cout << g;
-
    - -

    -(with the expected #include and usings), the value printed is a rather -surprising "true". Rather useless too. -

    - -

    The standard defines:

    - -
    ostream& operator<<(ostream&, void*);
    - -

    which picks up all data pointers and prints their hex value, but does -not pick up function pointers because there is no default conversion -from function pointer to void*. Absent that, we fall back to legacy -conversions from C and the function pointer is converted to bool. -

    - -

    There should be an analogous inserter that prints the address of a - function pointer.

    - - -

    Proposed resolution:

    - - -

    Rationale:

    -

    This is indeed a wart, but there is no good way to solve it. C - doesn't provide a portable way of outputting the address of a - function point either.

    - - - - - -
    -

    439. Should facets be copyable?

    -

    Section: 22.2 [locale.categories] Status: NAD - Submitter: Matt Austern Date: 2003-11-02

    -

    View other active issues in [locale.categories].

    -

    View all other issues in [locale.categories].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    The following facets classes have no copy constructors described in - the standard, which, according to the standard, means that they are - supposed to use the compiler-generated defaults. Default copy - behavior is probably inappropriate. We should either make these - classes uncopyable or else specify exactly what their constructors do.

    - -

    Related issue: 421.

    - -
            ctype_base
-        ctype
-        ctype_byname
-        ctype<char>
-        ctype_byname<char>
-        codecvt_base
-        codecvt
-        codecvt_byname
-        num_get
-        num_put
-        numpunct
-        numpunct_byname
-        collate
-        collate_byname
-        time_base
-        time_get
-        time_get_byname
-        time_put
-        time_put_byname
-        money_get
-        money_put
-        money_base
-        moneypunct
-        moneypunct_byname
-        messages_base
-        messages
-        messages_byname
-
    - - - -

    Proposed resolution:

    - - -

    Rationale:

    -

    The copy constructor in the base class is private.

    - - - - - -
    -

    440. Should std::complex use unqualified transcendentals?

    -

    Section: 26.3.8 [complex.transcendentals] Status: NAD - Submitter: Matt Austern Date: 2003-11-05

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    -Operations like pow and exp on -complex<T> are typically implemented in terms of -operations like sin and cos on T. -Should implementations write this as std::sin, or as plain -unqualified sin? -

    - -

    The issue, of course, is whether we want to use -argument-dependent lookup in the case where T is a -user-defined type. This is similar to the issue of valarray -transcendentals, as discussed in issue 226.

    - -

    This issue differs from valarray transcendentals in two important -ways. First, "the effect of instantiating the template -complex for types other than float, double or long double is -unspecified." (26.3.1 [complex.synopsis]) Second, the standard does not -dictate implementation, so there is no guarantee that a particular -real math function is used in the implementation of a particular -complex function.

    - - - -

    Proposed resolution:

    - - -

    Rationale:

    -

    If you instantiate std::complex for user-defined types, all bets -are off.

    - - - - - -
    -

    447. Wrong template argument for time facets

    -

    Section: 22.1.1.1.1 [locale.category] Status: Dup - Submitter: Pete Becker Date: 2003-12-26

    -

    View all other issues in [locale.category].

    -

    View all issues with Dup status.

    -

    Duplicate of: 327

    -

    Discussion:

    -

    -22.1.1.1.1/4, table 52, "Required Instantiations", lists, among others: -

    -
        time_get<char,InputIterator>
-    time_get_byname<char,InputIterator>
-    time_get<wchar_t,OutputIterator>
-    time_get_byname<wchar_t,OutputIterator>
-
    - -

    -The second argument to the last two should be InputIterator, not -OutputIterator. -

    - - -

    Proposed resolution:

    -

    -Change the second template argument to InputIterator. -

    - - -

    Rationale:

    - - - - - - -
    -

    450. set::find is inconsistent with associative container requirements

    -

    Section: 23.3.3 [set] Status: Dup - Submitter: Bill Plauger Date: 2004-01-30

    -

    View all other issues in [set].

    -

    View all issues with Dup status.

    -

    Duplicate of: 214

    -

    Discussion:

    -

    map/multimap have:

    - -
    	iterator find(const key_type& x) const;
-	const_iterator find(const key_type& x) const;
-
    - -

    -which is consistent with the table of associative container requirements. -But set/multiset have: -

    -
    	iterator find(const key_type&) const;
-
    - -

    -set/multiset should look like map/multimap, and honor the requirements -table, in this regard. -

    - - -

    Proposed resolution:

    - - -

    Rationale:

    - - - - - - -
    -

    451. Associative erase should return an iterator

    -

    Section: 23.1.4 [associative.reqmts], 23.3 [associative] Status: Dup - Submitter: Bill Plauger Date: 2004-01-30

    -

    View all other issues in [associative.reqmts].

    -

    View all issues with Dup status.

    -

    Duplicate of: 130

    -

    Discussion:

    -

    map/multimap/set/multiset have:

    -
    	void erase(iterator);
-	void erase(iterator, iterator);
-
    - -

    But there's no good reason why these can't return an iterator, as for -vector/deque/list:

    -
    	iterator erase(iterator);
-	iterator erase(iterator, iterator);
-
    - - - -

    Proposed resolution:

    -

    -Informally: The table of associative container requirements, and the -relevant template classes, should return an iterator designating the -first element beyond the erased subrange. -

    - - -

    Rationale:

    - - - - - - -
    -

    452. locale::combine should be permitted to generate a named locale

    -

    Section: 22.1.1.3 [locale.members] Status: NAD - Submitter: Bill Plauger Date: 2004-01-30

    -

    View all other issues in [locale.members].

    -

    View all issues with NAD status.

    -

    Discussion:

    -
    template<class Facet>
-	locale::combine(const locale&) const;
-
    -

    -is obliged to create a locale that has no name. This is overspecification -and overkill. The resulting locale should follow the usual rules -- it -has a name if the locale argument has a name and Facet is one of the -standard facets. -

    - -

    [ - Sydney and post-Sydney (see c++std-lib-13439, c++std-lib-13440, - c++std-lib-13443): agreed that it's overkill to say that the locale - is obligated to be nameless. However, we also can't require it to - have a name. At the moment, locale names are based on categories - and not on individual facets. If a locale contains two different - facets of different names from the same category, then this would - not fit into existing naming schemes. We need to give - implementations more freedom. Bill will provide wording. -]

    - - - - -

    Rationale:

    -

    After further discussion the LWG decided to close this as NAD. - The fundamental problem is that names right now are per-category, - not per-facet. The combine member function works at the - wrong level of granularity.

    - - - - - -
    -

    462. Destroying objects with static storage duration

    -

    Section: 3.6.3 [basic.start.term], 18.3 [cstdint] Status: NAD - Submitter: Bill Plauger Date: 2004-03-23

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    -3.6.3 Termination spells out in detail the interleaving of static -destructor calls and calls to functions registered with atexit. To -match this behavior requires intimate cooperation between the code -that calls destructors and the exit/atexit machinery. The former -is tied tightly to the compiler; the latter is a primitive mechanism -inherited from C that traditionally has nothing to do with static -construction and destruction. The benefits of intermixing destructor -calls with atexit handler calls is questionable at best, and very -difficult to get right, particularly when mixing third-party C++ -libraries with different third-party C++ compilers and C libraries -supplied by still other parties. -

    - -

    -I believe the right thing to do is defer all static destruction -until after all atexit handlers are called. This is a change in -behavior, but one that is likely visible only to perverse test -suites. At the very least, we should permit deferred destruction -even if we don't require it. -

    - -

    [If this is to be changed, it should probably be changed by CWG. - At this point, however, the LWG is leaning toward NAD. Implementing - what the standard says is hard work, but it's not impossible and - most vendors went through that pain years ago. Changing this - behavior would be a user-visible change, and would break at least - one real application.]

    - - -

    [ -Batavia: Send to core with our recommendation that we should permit deferred -destruction but not require it. -]

    - - -

    [ -Howard: The course of action recommended in Batavia would undo LWG -issue 3 and break current code implementing the "phoenix -singleton". Search the net for "phoenix singleton atexit" to get a feel -for the size of the adverse impact this change would have. Below is -sample code which implements the phoenix singleton and would break if -atexit is changed in this way: -]

    - - -
    #include <cstdlib>
-#include <iostream>
-#include <type_traits>
-#include <new>
-
-class A
-{
-    bool alive_;
-    A(const A&);
-    A& operator=(const A&);
-public:
-    A() : alive_(true) {std::cout << "A()\n";}
-    ~A() {alive_ = false; std::cout << "~A()\n";}
-    void use()
-    {
-        if (alive_)
-            std::cout << "A is alive\n";
-        else
-            std::cout << "A is dead\n";
-    }
-};
-
-void deallocate_resource();
-
-// This is the phoenix singleton pattern
-A& get_resource(bool create = true)
-{
-    static std::aligned_storage<sizeof(A), std::alignment_of<A>::value>::type buf;
-    static A* a;
-    if (create)
-    {
-        if (a != (A*)&buf)
-        {
-            a = ::new (&buf) A;
-            std::atexit(deallocate_resource);
-        }
-    }
-    else
-    {
-        a->~A();
-        a = (A*)&buf + 1;
-    }
-    return *a;
-}
-
-void deallocate_resource()
-{
-    get_resource(false);
-}
-
-void use_A(const char* message)
-{
-    A& a = get_resource();
-    std::cout << "Using A " << message << "\n";
-    a.use();
-}
-
-struct B
-{
-    ~B() {use_A("from ~B()");}
-};
-
-B b;
-
-int main()
-{
-    use_A("from main()");
-}
-
    - -

    -The correct output is: -

    - -
    A()
-Using A from main()
-A is alive
-~A()
-A()
-Using A from ~B()
-A is alive
-~A()
-
    - -

    [ -Bellevue: Confirmed no interaction with quick_exit. -Strong feeling against mandating the change. Leaning towards NAD rather than permitting the change, -as this would make common implementations of pheonix-singleton pattern implementation defined, as noted by Howard. -Bill agrees issue is no longer serious, and accepts NAD. -]

    - - - - -

    Proposed resolution:

    -

    -

    - - - - - -
    -

    466. basic_string ctor should prevent null pointer error

    -

    Section: 21.3.1 [string.require] Status: NAD - Submitter: Daniel Frey Date: 2004-06-10

    -

    View all other issues in [string.require].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    -Today, my colleagues and me wasted a lot of time. After some time, I -found the problem. It could be reduced to the following short example: -

    - -
      #include <string>
-  int main() { std::string( 0 ); }
-
    - -

    The problem is that the tested compilers (GCC 2.95.2, GCC 3.3.1 and -Comeau online) compile the above without errors or warnings! The -programs (at least for the GCC) resulted in a SEGV.

    - -

    I know that the standard explicitly states that the ctor of string -requires a char* which is not zero. STLs could easily detect the above -case with a private ctor for basic_string which takes a single 'int' -argument. This would catch the above code at compile time and would not -ambiguate any other legal ctors.

    - -

    [Redmond: No great enthusiasm for doing this. If we do, - however, we want to do it for all places that take charT* - pointers, not just the single-argument constructor. The other - question is whether we want to catch this at compile time (in which - case we catch the error of a literal 0, but not an expression whose - value is a null pointer), at run time, or both.]

    - - - - -

    Proposed resolution:

    - - -

    Rationale:

    -

    -Recommend NAD. Relegate this functionality to debugging implementations. -

    - - - - - -
    -

    470. accessing containers from their elements' special functions

    -

    Section: 23 [containers] Status: NAD - Submitter: Martin Sebor Date: 2004-06-28

    -

    View other active issues in [containers].

    -

    View all other issues in [containers].

    -

    View all issues with NAD status.

    -

    Discussion:

    - -

    -The standard doesn't prohibit the destructors (or any other special -functions) of containers' elements invoked from a member function -of the container from "recursively" calling the same (or any other) -member function on the same container object, potentially while the -container is in an intermediate state, or even changing the state -of the container object while it is being modified. This may result -in some surprising (i.e., undefined) behavior. -

    - -

    Read email thread starting with c++std-lib-13637 for more.

    - - - -

    Proposed resolution:

    - -

    Add to Container Requirements the following new paragraph:

    - -
        Unless otherwise specified, the behavior of a program that
-    invokes a container member function f from a member function
-    g of the container's value_type on a container object c that
-    called g from its mutating member function h, is undefined.
-    I.e., if v is an element of c, directly or indirectly calling
-    c.h() from v.g() called from c.f(), is undefined.
-
    - -

    [Redmond: This is a real issue, but it's probably a clause 17 - issue, not clause 23. We get the same issue, for example, if we - try to destroy a stream from one of the stream's callback functions.]

    - - - - -

    Rationale:

    -

    -Recommend NAD. We agree this is an issue, but not a defect. -We believe that there is no wording we can put in the standard -that will cover all cases without introducing unfortunate -corner cases. -

    - - - - - -
    -

    472. Missing "Returns" clause in std::equal_range

    -

    Section: 25.3.3.3 [equal.range] Status: Dup - Submitter: Prateek R Karandikar Date: 2004-06-30

    -

    View all other issues in [equal.range].

    -

    View all issues with Dup status.

    -

    Duplicate of: 270

    -

    Discussion:

    -

    -There is no "Returns:" clause for std::equal_range, which returns non-void. -

    - - -

    Proposed resolution:

    - - -

    Rationale:

    -

    Fixed as part of issue 270.

    - - - - - - -
    -

    476. Forward Iterator implied mutability

    -

    Section: 24.1.3 [forward.iterators] Status: NAD - Submitter: Dave Abrahams Date: 2004-07-09

    -

    View all other issues in [forward.iterators].

    -

    View all issues with NAD status.

    -

    Discussion:

    - -

    24.1/3 says:

    -

    - Forward iterators satisfy all the requirements of the input and - output iterators and can be used whenever either kind is specified -

    - -

    -The problem is that satisfying the requirements of output iterator -means that you can always assign *something* into the result of -dereferencing it. That makes almost all non-mutable forward -iterators non-conforming. I think we need to sever the refinement -relationship between forward iterator and output iterator. -

    - -

    Related issue: 200. But this is not a dup.

    - - - -

    Proposed resolution:

    - - -

    Rationale:

    -

    Yes, 24.1/3 does say that. But it's introductory material. The -precise specification is in 24.1.3, and the requrements table there is -right. We don't need to fine-tune introductory wording. (Especially -since this wording is likely to be changed as part of the iterator -overhaul.)

    - - - - - -
    -

    477. Operator-> for const forward iterators

    -

    Section: 24.1.3 [forward.iterators] Status: Dup - Submitter: Dave Abrahams Date: 2004-07-11

    -

    View all other issues in [forward.iterators].

    -

    View all issues with Dup status.

    -

    Duplicate of: 478

    -

    Discussion:

    -

    -The Forward Iterator requirements table contains the following: -

    -
     expression  return type         operational  precondition
-                                  semantics
-  ==========  ==================  ===========  ==========================
-  a->m        U& if X is mutable, (*a).m       pre: (*a).m is well-defined.
-              otherwise const U&
-
-  r->m        U&                  (*r).m       pre: (*r).m is well-defined.
-
    - -

    -The first line is exactly right. The second line is wrong. Basically -it implies that the const-ness of the iterator affects the const-ness -of referenced members. But Paragraph 11 of [lib.iterator.requirements] says: -

    - -

    - In the following sections, a and b denote values of type const X, n - denotes a value of the difference type Distance, u, tmp, and m - denote identifiers, r denotes a value of X&, t denotes a value of - value type T, o denotes a value of some type that is writable to - the output iterator. -

    - -

    AFAICT if we need the second line at all, it should read the same -as the first line.

    - -

    Related issue: 478

    - - -

    Proposed resolution:

    - - -

    Rationale:

    -

    The LWG agrees that this is a real problem. Marked as a DUP - because the LWG chose to adopt the solution proposed in - 478. -

    - - - - - -
    -

    479. Container requirements and placement new

    -

    Section: 23.1 [container.requirements] Status: Dup - Submitter: Herb Sutter Date: 2004-08-01

    -

    View other active issues in [container.requirements].

    -

    View all other issues in [container.requirements].

    -

    View all issues with Dup status.

    -

    Duplicate of: 580

    -

    Discussion:

    -

    Nothing in the standard appears to make this program ill-formed:

    - -
      struct C {
-    void* operator new( size_t s ) { return ::operator new( s ); }
-    // NOTE: this hides in-place and nothrow new
-  };
-
-  int main() {
-    vector<C> v;
-    v.push_back( C() );
-  }
-
    - -

    Is that intentional? We should clarify whether or not we intended - to require containers to support types that define their own special - versions of operator new.

    - -

    [ -Lillehammer: A container will definitely never use this overridden -operator new, but whether it will fail to compile is unclear from the -standard. Are containers supposed to use qualified or unqualified -placement new? 20.4.1.1 is somewhat relevant, but the standard -doesn't make it completely clear whether containers have to use -Allocator::construct(). If containers don't use it, the details of how -containers use placement new are unspecified. That is the real bug, -but it needs to be fixed as part of the allocator overhaul. Weak -support that the eventual solution should make this code well formed. -]

    - - - - -

    Proposed resolution:

    - - - - - - - -
    -

    480. unary_function and binary_function should have protected nonvirtual destructors

    -

    Section: 20.6.3 [base] Status: NAD - Submitter: Joe Gottman Date: 2004-08-19

    -

    View all other issues in [base].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    The classes std::unary_function and std::binary_function are both -designed to be inherited from but contain no virtual functions. This -makes it too easy for a novice programmer to write code like -binary_function<int, int, int> *p = new plus<int>; delete p;

    - -

    There are two common ways to prevent this source of undefined -behavior: give the base class a public virtual destructor, or give it -a protected nonvirtual destructor. Since unary_function and -binary_function have no other virtual functions, (note in particular -the absence of an operator()() ), it would cost too much to give them -public virtual destructors. Therefore, they should be given protected -nonvirtual destructors.

    - - -

    Proposed resolution:

    -

    Change Paragraph 20.3.1 of the Standard from

    -
        template <class Arg, class Result>
-    struct unary_function {
-        typedef Arg argument_type;
-        typedef Result result_type;
-    };
-
-    template <class Arg1, class Arg2, class Result>
-    struct binary_function {
-        typedef Arg1 first_argument_type;
-        typedef Arg2 second_argument_type;
-        typedef Result result_type;
-    };
-
    - -

    to

    -
        template <class Arg, class Result>
-        struct unary_function {
-        typedef Arg argument_type;
-        typedef Result result_type;
-    protected:
-        ~unary_function() {}
-    };
-
-    template <class Arg1, class Arg2, class Result>
-    struct binary_function {
-        typedef Arg1 first_argument_type;
-        typedef Arg2 second_argument_type;
-        typedef Result result_type;
-    protected:
-        ~binary_function() {}
-    };
-
    - - -

    Rationale:

    -

    The LWG doesn't believe the existing definition causes anybody any - concrete harm.

    - - - - - -
    -

    481. unique's effects on the range [result, last)

    -

    Section: 25.2.9 [alg.unique] Status: NAD - Submitter: Andrew Koenig Date: 2004-08-30

    -

    View all other issues in [alg.unique].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    -The standard says that unique(first, last) "eliminates all but the -first element from every consecutive group of equal elements" in -[first, last) and returns "the end of the resulting range". So a -postcondition is that [first, result) is the same as the old [first, -last) except that duplicates have been eliminated. -

    - -

    What postconditions are there on the range [result, last)? One - might argue that the standard says nothing about those values, so - they can be anything. One might also argue that the standard - doesn't permit those values to be changed, so they must not be. - Should the standard say something explicit one way or the other?

    - - - -

    Proposed resolution:

    -

    -

    - - -

    Rationale:

    -

    We don't want to make many guarantees about what's in [result, -end). Maybe we aren't being quite explicit enough about not being -explicit, but it's hard to think that's a major problem.

    - - - - - -
    -

    482. Swapping pairs

    -

    Section: 20.2.3 [pairs], 20.4 [tuple] Status: NAD Editorial - Submitter: Andrew Koenig Date: 2004-09-14

    -

    View all other issues in [pairs].

    -

    View all issues with NAD Editorial status.

    -

    Discussion:

    -

    (Based on recent comp.std.c++ discussion)

    - -

    Pair (and tuple) should specialize std::swap to work in terms of -std::swap on their components. For example, there's no obvious reason -why swapping two objects of type pair<vector<int>, -list<double> > should not take O(1).

    - -

    [Lillehammer: We agree it should be swappable. Howard will - provide wording.]

    - - -

    [ -Post Oxford: We got swap for pair but accidently -missed tuple. tuple::swap is being tracked by 522. -]

    - - - - -

    Proposed resolution:

    -

    -Wording provided in -N1856. -

    - -

    Rationale:

    -

    -Recommend NAD, fixed by -N1856. -

    - - - - - -
    -

    483. Heterogeneous equality and EqualityComparable

    -

    Section: 25.1 [alg.nonmodifying], 25.2 [alg.modifying.operations] Status: Dup - Submitter: Peter Dimov Date: 2004-09-20

    -

    View all issues with Dup status.

    -

    Duplicate of: 283

    -

    Discussion:

    -

    c++std-lib-14262

    - -

    [lib.alg.find] requires T to be EqualityComparable:

    - -
    template <class InputIterator, class T>
-   InputIterator find(InputIterator first, InputIterator last,
-                      const T& value);
-
    - -

    -However the condition being tested, as specified in the Effects -clause, is actually *i == value, where i is an InputIterator. -

    - -

    -The two clauses are in agreement only if the type of *i is T, but this -isn't necessarily the case. *i may have a heterogeneous comparison -operator that takes a T, or a T may be convertible to the type of *i. -

    - -

    Further discussion (c++std-lib-14264): this problem affects a - number of algorithsm in clause 25, not just find. We - should try to resolve this problem everywhere it appears.

    - - -

    Proposed resolution:

    - -

    [lib.alg.find]:

    -

    - Remove [lib.alg.find]/1. -

    - -

    [lib.alg.count]:

    -

    - Remove [lib.alg.count]/1. -

    - -

    [lib.alg.search]:

    -

    - Remove "Type T is EqualityComparable (20.1.1), " from [lib.alg.search]/4. -

    - -

    [lib.alg.replace]:

    - -
    -

    - Remove [lib.alg.replace]/1. - Replace [lb.alg.replace]/2 with: -

    - -

    - For every iterator i in the range [first, last) for which *i == value - or pred(*i) holds perform *i = new_value. -

    - -

    - Remove the first sentence of /4. - Replace the beginning of /5 with: -

    - -

    - For every iterator i in the range [result, result + (last - - first)), assign to *i either... -

    - -

    (Note the defect here, current text says assign to i, not *i).

    -
    - -

    [lib.alg.fill]:

    - -
    -

    - Remove "Type T is Assignable (23.1), " from /1. - Replace /2 with: -

    - -

    - For every iterator i in the range [first, last) or [first, first + n), - perform *i = value. -

    -
    - -

    [lib.alg.remove]:

    -

    - Remove /1. - Remove the first sentence of /6. -

    - - - -

    Rationale:

    -

    Duplicate of (a subset of) issue 283.

    - - - - - - -
    -

    486. min/max CopyConstructible requirement is too strict

    -

    Section: 25.3.7 [alg.min.max] Status: Dup - Submitter: Dave Abrahams Date: 2004-10-13

    -

    View all other issues in [alg.min.max].

    -

    View all issues with Dup status.

    -

    Duplicate of: 281

    -

    Discussion:

    -

    A straightforward implementation of these algorithms does not need to -copy T.

    - - -

    Proposed resolution:

    -

    drop the the words "and CopyConstructible" from paragraphs 1 and 4

    - - -

    Rationale:

    - - - - - - -
    -

    487. Allocator::construct is too limiting

    -

    Section: 20.1.2 [allocator.requirements] Status: NAD - Submitter: Dhruv Matani Date: 2004-10-17

    -

    View other active issues in [allocator.requirements].

    -

    View all other issues in [allocator.requirements].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    -The standard's version of allocator::construct(pointer, -const_reference) severely limits what you can construct using this -function. Say you can construct a socket from a file descriptor. Now, -using this syntax, I first have to manually construct a socket from -the fd, and then pass the constructed socket to the construct() -function so it will just to an uninitialized copy of the socket I -manually constructed. Now it may not always be possible to copy -construct a socket eh! So, I feel that the changes should go in the -allocator::construct(), making it: -

    -
        template<typename T>
-    struct allocator{
-      template<typename T1>
-      void construct(pointer T1 const& rt1);
-    };
-
    - -

    -Now, the ctor of the class T which matches the one that takes a T1 can -be called! Doesn't that sound great? -

    - - -

    Proposed resolution:

    - - -

    Rationale:

    -

    NAD. STL uses copying all the time, and making it possible for - allocators to construct noncopyable objects is useless in the - absence of corresponding container changes. We might consider this - as part of a larger redesign of STL.

    - - - - - -
    -

    489. std::remove / std::remove_if wrongly specified

    -

    Section: 25.2.8 [alg.remove] Status: NAD - Submitter: Thomas Mang Date: 2004-12-12

    -

    View all other issues in [alg.remove].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    In Section 25.2.7 [lib.alg.remove], paragraphs 1 to 5 describe the -behavior of the mutating sequence operations std::remove and -std::remove_if. However, the wording does not reflect the intended -behavior [Note: See definition of intended behavior below] of these -algorithms, as it is known to the C++ community [1]. -

    - - - -

    1) Analysis of current wording:

    - - -

    25.2.7 [lib.alg.remove], paragraph 2:

    - -

    Current wording says: -"Effects: Eliminates all the elements referred to by iterator i in the -range [first, last) for which the following corresponding conditions -hold: *i == value, pred(*i) != false."

    - -

    -This sentences expresses specifically that all elements denoted by the -(original) range [first, last) for which the corresponding condition -hold will be eliminated. Since there is no formal definition of the term -"eliminate" provided, the meaning of "eliminate" in everyday language -implies that as postcondition, no element in the range denoted by -[first, last) will hold the corresponding condition on reiteration over -the range [first, last). -

    - -

    -However, this is neither the intent [Note: See definition of intended -behavior below] nor a general possible approach. It can be easily proven -that if all elements of the original range[first, last) will hold the -condition, it is not possible to substitute them by an element for which -the condition will not hold. -

    - - -

    25.2.7 [lib.alg.remove], paragraph 3:

    - -

    -Current wording says: -"Returns: The end of the resulting range." -

    - -

    -The resulting range is not specified. In combination with 25.2.7 -[lib.alg.remove], paragraph 2, the only reasonable interpretation of -this so-called resulting range is the range [first,last) - thus -returning always the ForwardIterator 'last' parameter. -

    - - -

    -25.2.7 [lib.alg.remove], paragraph 4: -

    - -

    -Current wording says: -"Notes: Stable: the relative order of the elements that are not removed -is the same as their relative order in the original range" -

    - -

    -This sentences makes use of the term "removed", which is neither -specified, nor used in a previous paragraph (which uses the term -"eliminate"), nor unamgiuously separated from the name of the algorithm. -

    - - -

    2) Description of intended behavior:

    - -

    -For the rest of this Defect Report, it is assumed that the intended -behavior was that all elements of the range [first, last) which do not -hold the condition *i == value (std::remove) or pred(*i) != false -(std::remove_if)], call them s-elements [Note: s...stay], will be placed -into a contiguous subrange of [first, last), denoted by the iterators -[first, return value). The number of elements in the resulting range -[first, return value) shall be equal to the number of s-elements in the -original range [first, last). The relative order of the elements in the -resulting subrange[first, return value) shall be the same as the -relative order of the corresponding elements in the original range. It -is undefined whether any elements in the resulting subrange [return -value, last) will hold the corresponding condition, or not. -

    - -

    -All implementations known to the author of this Defect Report comply -with this intent. Since the intent of the behavior (contrary to the -current wording) is also described in various utility references serving -the C++ community [1], it is not expected that fixing the paragraphs -will influence current code - unless the code relies on the behavior as -it is described by current wording and the implementation indeed -reflects the current wording, and not the intent. -

    - - - -

    3) Proposed fixes:

    - - -

    Change 25.2.7 [lib.alg.remove], paragraph 2 to:

    - -

    -"Effect: Places all the elements referred to by iterator i in the range -[first, last) for which the following corresponding conditions hold : -!(*i == value), pred(*i) == false into the subrange [first, k) of the -original range, where k shall denote a value of type ForwardIterator. It -is undefined whether any elements in the resulting subrange [k, last) -will hold the corresponding condition, or not." -

    - -

    Comments to the new wording:

    - -

    -a) "Places" has no special meaning, and the everyday language meaning -should fit. -b) The corresponding conditions were negated compared to the current -wording, becaue the new wording requires it. -c) The wording "of the original range" might be redundant, since any -subrange starting at 'first' and containing no more elements than the -original range is implicitly a subrange of the original range [first, -last). -d) The iterator k was introduced instead of "return value" in order to -avoid a cyclic dependency on 25.2.7/3. The wording ", where k shall -denote a value of type ForwardIterator" might be redundant, because it -follows implicitly by 25.2.7/3. -e) "Places" does, in the author's opinion, explicitly forbid duplicating -any element holding the corresponding condition in the original range -[first, last) within the resulting range [first, k). If there is doubt -this term might be not unambiguous regarding this, it is suggested that -k is specified more closely by the following wording: "k shall denote a -value of type ForwardIterator [Note: see d)] so that k - first is equal -to the number of elements in the original range [first, last) for which -the corresponding condition did hold". This could also be expressed as a -separate paragraph "Postcondition:" -f) The senctence "It is undefined whether any elements in the resulting -subrange [k, last) will hold the corresponding condition, or not." was -added consciously so the term "Places" does not imply if the original -range [first, last) contains n elements holding the corresponding -condition, the identical range[first, last) will also contain exactly n -elements holding the corresponding condition after application of the -algorithm. -

    - -

    -Change 25.2.7 [lib.alg.remove], paragraph 3 to: - -"Returns: The iterator k." -

    - -

    -Change 25.2.7 [lib.alg.remove], paragraph 4 to: - -"Notes: Stable: the relative order of the elements that are placed into -the subrange [first, return value) shall be the same as their relative -order was in the original range [first, last) prior to application of -the algorithm." -

    - -

    -Comments to the new wording: -

    - -

    -a) the wording "was ... prior to application of the algorithm" is used -to explicitly distinguish the original range not only by means of -iterators, but also by a 'chronological' factor from the resulting range -[first, return value). It might be redundant. -

    - -

    -[1]: -The wording of these references is not always unambiguous, and provided -examples partially contradict verbal description of the algorithms, -because the verbal description resembles the problematic wording of -ISO/IEC 14882:2003. -

    - - -

    Proposed resolution:

    - - -

    Rationale:

    -

    The LWG believes that the standard is sufficiently clear, and that - there is no evidence of any real-world confusion about this point.

    - - - - - -
    -

    490. std::unique wrongly specified

    -

    Section: 25.2.9 [alg.unique] Status: NAD - Submitter: Thomas Mang Date: 2004-12-12

    -

    View all other issues in [alg.unique].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    In Section 25.2.8 [lib.alg.unique], paragraphs 1 to 3 describe the -behavior of the mutating sequence operation std::unique. However, the -wording does not reflect the intended behavior [Note: See definition of -intended behavior below] of these algorithms, as it is known to the C++ -community [1].

    - - - -

    1) Analysis of current wording:

    - - -

    25.2.8 [lib.alg.unique], paragraph 1:

    - -

    -Current wording says: -"Effects: Eliminates all but the first element from every consecutive -group of equal elements referred to by the iterator i in the range -[first, last) for which the following corresponding conditions hold: *i -== *(i - 1) or pred(*i, *(i -1)) != false" -

    - -

    -This sentences expresses specifically that all elements denoted by the -(original) range [first, last) which are not but the first element from -a consecutive group of equal elements (where equality is defined as *i -== *(i - 1) or pred(*i, *(i - 1)) ! = false) [Note: See DR 202], call -them r-elements [Note: r...remove], will be eliminated. Since there is -no formal definition of the term "eliminate" provided, it is undefined -how this "elimination" takes place. But the meaning of "eliminate" in -everyday language seems to disallow explicitly that after application of -the algorithm, any r-element will remain at any position of the range -[first, last) [2]. -

    - -

    -Another defect in the current wording concerns the iterators used to -compare two elements for equality: The current wording contains the -expression "(i - 1)", which is not covered by 25/9 [Note: See DR -submitted by Thomas Mang regarding invalid iterator arithmetic -expressions]. -

    - - -

    -25.2.8 [lib.alg.unique], paragraph 2: -

    -

    Current wording says: -"Returns: The end of the resulting range."

    - -

    -The resulting range is not specified. In combination with 25.2.8 -[lib.alg.unique], paragraph 1, one reasonable interpretation (in the -author's opinion even the only possible interpretation) of this -so-called resulting range is the range [first, last) - thus returning -always the ForwardIterator 'last' parameter. -

    - -

    2) Description of intended behavior:

    - -

    -For the rest of this Defect Report, it is assumed that the intended -behavior was that all elements denoted by the original range [first, -last) which are the first element from a consecutive group of elements -for which the corresponding conditions: *(i-1) == *i (for the version of -unique without a predicate argument) or pred(*(i-1), *i) ! = false (for -the version of unique with a predicate argument) [Note: If such a group -of elements consists of only a single element, this is also considered -the first element] [Note: See resolutions of DR 202], call them -s-elements [Note: s...stay], will be placed into a contiguous subrange -of [first, last), denoted by the iterators [first, return value). The -number of elements in the resulting range [first, return value) shall be -equal to the number of s-elements in the original range [first, last). -Invalid iterator arithmetic expressions are expected to be resolved as -proposed in DR submitted by Thomas Mang regarding invalid iterator -arithmetic expressions. It is also assumed by the author that the -relative order of the elements in the resulting subrange [first, return -value) shall be the same as the relative order of the corresponding -elements (the s-elements) in the original range [Note: If this was not -intended behavior, the additional proposed paragraph about stable order -will certainly become obsolete]. -Furthermore, the resolutions of DR 202 are partially considered. -

    - -

    -All implementations known to the author of this Defect Report comply -with this intent [Note: Except possible effects of DR 202]. Since this -intent of the behavior (contrary to the current wording) is also -described in various utility references serving the C++ community [1], -it is not expected that fixing the paragraphs will influence current -code [Note: Except possible effects of DR 202] - unless the code relies -on the behavior as it is described by current wording and the -implementation indeed reflects the current wording, and not the intent. -

    - - - -

    3) Proposed fixes:

    - -

    -Change 25.2.8 [lib.alg.unique], paragraph 1 to: -

    - -

    -"Effect: Places the first element from every consecutive group of -elements, referred to by the iterator i in the range [first, last), for -which the following conditions hold: *(i-1) == *i (for the version of -unique without a predicate argument) or pred(*(i -1), *i) != false (for -the version of unique with a predicate argument), into the subrange -[first, k) of the original range, where k shall denote a value of type -ForwardIterator." -

    - -

    Comments to the new wording:

    - -

    -a) The new wording was influenced by the resolutions of DR 202. If DR -202 is resolved in another way, the proposed wording need also -additional review. -b) "Places" has no special meaning, and the everyday language meaning -should fit. -c) The expression "(i - 1)" was left, but is expected that DR submitted -by Thomas Mang regarding invalid iterator arithmetic expressions will -take this into account. -d) The wording "(for the version of unique without a predicate -argument)" and "(for the version of unique with a predicate argument)" -was added consciously for clarity and is in resemblence with current -23.2.2.4 [lib.list.ops], paragraph 19. It might be considered redundant. -e) The wording "of the original range" might be redundant, since any -subrange starting at first and containing no more elements than the -original range is implicitly a subrange of the original range [first, -last). -f) The iterator k was introduced instead of "return value" in order to -avoid a cyclic dependency on 25.2.8 [lib.alg.unique], paragraph 2. The -wording ", where k shall denote a value of type ForwardIterator" might -be redundant, because it follows implicitly by 25.2.8 [lib.alg.unique], -paragraph 2. -g) "Places" does, in the author's opinion, explicitly forbid duplicating -any s-element in the original range [first, last) within the resulting -range [first, k). If there is doubt this term might be not unambiguous -regarding this, it is suggested that k is specified more closely by the -following wording: "k shall denote a value of type ForwardIterator -[Note: See f)] so that k - first is equal to the number of elements in -the original range [first, last) being the first element from every -consecutive group of elements for which the corresponding condition did -hold". This could also be expressed as a separate paragraph -"Postcondition:". -h) If it is considered that the wording is unclear whether it declares -the element of a group which consists of only a single element -implicitly to be the first element of this group [Note: Such an -interpretation could eventually arise especially in case last - first == -1] , the following additional sentence is proposed: "If such a group of -elements consists of only a single element, this element is also -considered the first element." -

    - -

    -Change 25.2.8 [lib.alg.unique], paragraph 2 to: -"Returns: The iterator k." -

    - -

    -Add a separate paragraph "Notes:" as 25.2.8 [lib.alg.unique], paragraph -2a or 3a, or a separate paragraph "Postcondition:" before 25.2.8 -[lib.alg.unique], paragraph 2 (wording inside {} shall be eliminated if -the preceding expressions are used, or the preceding expressions shall -be eliminated if wording inside {} is used): -

    - -

    -"Notes:{Postcondition:} Stable: the relative order of the elements that -are placed into the subrange [first, return value {k}) shall be the same -as their relative order was in the original range [first, last) prior to -application of the algorithm." -

    - -

    Comments to the new wording:

    - -

    -a) It is assumed by the author that the algorithm was intended to be -stable. -In case this was not the intent, this paragraph becomes certainly -obsolete. -b) The wording "was ... prior to application of the algorithm" is used -to explicitly distinguish the original range not only by means of -iterators, but also by a 'chronological' factor from the resulting range -[first, return value). It might be redundant. -

    - -

    -25.2.8 [lib.alg.unique], paragraph 3: -

    -

    See DR 239.

    - -

    -4) References to other DRs: -

    - -

    -See DR 202, but which does not address any of the problems described in -this Defect Report [Note: This DR is supposed to complement DR 202]. -See DR 239. -See DR submitted by Thomas Mang regarding invalid iterator arithmetic -expressions. -

    - -

    -[1]: -The wording of these references is not always unambiguous, and provided -examples partially contradict verbal description of the algorithms, -because the verbal description resembles the problematic wording of -ISO/IEC 14882:2003. -

    - -

    -[2]: -Illustration of conforming implementations according to current wording: -

    - -

    -One way the author of this DR considers how this "elimination" could be -achieved by a conforming implementation according to current wording is -by substituting each r-element by _any_ s-element [Note: s...stay; any -non-r-element], since all r-elements are "eliminated". -

    - -

    -In case of a sequence consisting of elements being all 'equal' [Note: -See DR 202], substituting each r-element by the single s-element is the -only possible solution according to current wording. -

    - - -

    Proposed resolution:

    - - -

    Rationale:

    -

    The LWG believes the standard is sufficiently clear. No -implementers get it wrong, and changing it wouldn't cause any code to -change, so there is no real-world harm here.

    - - - - - -
    -

    491. std::list<>::unique incorrectly specified

    -

    Section: 23.2.4.4 [list.ops] Status: NAD - Submitter: Thomas Mang Date: 2004-12-12

    -

    View all other issues in [list.ops].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    In Section 23.2.4.4 [list.ops], paragraphs 19 to 21 describe the -behavior of the std::list<T, Allocator>::unique operation. However, the -current wording is defective for various reasons.

    - - - -

    -1) Analysis of current wording: -

    - -

    23.2.4.4 [list.ops], paragraph 19:

    - -

    -Current wording says: -"Effects: Eliminates all but the first element from every consecutive -group of equal elements referred to by the iterator i in the range -[first + 1, last) for which *i == *(i - 1) (for the version of unique -with no argument) or pred(*i, *(i -1)) (for the version of unique with a -predicate argument) holds."

    - -

    -This sentences makes use of the undefined term "Eliminates". Although it -is, to a certain degree, reasonable to consider the term "eliminate" -synonymous with "erase", using "Erase" in the first place, as the -wording of 23.2.4.4 [list.ops], paragraph 15 does, would be clearer.

    - -

    -The range of the elements referred to by iterator i is "[first + 1, -last)". However, neither "first" nor "last" is defined.

    - -

    -The sentence makes three times use of iterator arithmetic expressions ( -"first + 1", "*i == *(i - 1)", "pred(*i, *(i -1))" ) which is not -defined for bidirectional iterator [see DR submitted by Thomas Mang -regarding invalid iterator arithmetic expressions].

    - -

    -The same problems as pointed out in DR 202 (equivalence relation / order -of arguments for pred()) apply to this paragraph.

    - -

    -23.2.4.4 [list.ops], paragraph 20: -

    - -

    -Current wording says: -"Throws: Nothing unless an exception in thrown by *i == *(i-1) or -pred(*i, *(i - 1))"

    - -

    -The sentence makes two times use of invalid iterator arithmetic -expressions ( "*i == *(i - 1)", "pred(*i, *(i -1))" ). -

    -

    -[Note: Minor typos: "in" / missing dot at end of sentence.] -

    - -

    -23.2.4.4 [list.ops], paragraph 21:

    - -

    -Current wording says: -"Complexity: If the range (last - first) is not empty, exactly (last - -first) - 1 applications of the corresponding predicate, otherwise no -application of the predicate.

    - -

    -See DR 315 regarding "(last - first)" not yielding a range.

    - -

    -Invalid iterator arithmetic expression "(last - first) - 1" left .

    - - -

    2) Description of intended behavior:

    - -

    -For the rest of this Defect Report, it is assumed that "eliminate" is -supposed to be synonymous to "erase", that "first" is equivalent to an -iterator obtained by a call to begin(), "last" is equivalent to an -iterator obtained by a call to end(), and that all invalid iterator -arithmetic expressions are resolved as described in DR submitted by -Thomas Mang regarding invalid iterator arithmetic expressions.

    - -

    -Furthermore, the resolutions of DR 202 are considered regarding -equivalence relation and order of arguments for a call to pred.

    - -

    -All implementations known to the author of this Defect Report comply -with these assumptions, apart from the impact of the alternative -resolution of DR 202. Except for the changes implied by the resolutions -of DR 202, no impact on current code is expected.

    - -

    -3) Proposed fixes:

    - -

    -Change 23.2.4.4 [list.ops], paragraph 19 to:

    - -

    -"Effect: Erases all but the first element from every consecutive group -of elements, referred to by the iterator i in the range [begin(), -end()), for which the following conditions hold: *(i-1) == *i (for the -version of unique with no argument) or pred(*(i-1), *i) != false (for -the version of unique with a predicate argument)."

    - -

    -Comments to the new wording:

    - -

    -a) The new wording was influenced by DR 202 and the resolutions -presented there. If DR 202 is resolved in another way, the proposed -wording need also additional review. -b) "Erases" refers in the author's opinion unambiguously to the member -function "erase". In case there is doubt this might not be unamgibuous, -a direct reference to the member function "erase" is suggested [Note: -This would also imply a change of 23.2.4.4 [list.ops], paragraph -15.]. -c) The expression "(i - 1)" was left, but is expected that DR submitted -by Thomas Mang regarding invalid iterator arithmetic expressions will -take this into account. -d) The wording "(for the version of unique with no argument)" and "(for -the version of unique with a predicate argument)" was kept consciously -for clarity. -e) "begin()" substitutes "first", and "end()" substitutes "last". The -range need adjustment from "[first + 1, last)" to "[begin(), end())" to -ensure a valid range in case of an empty list. -f) If it is considered that the wording is unclear whether it declares -the element of a group which consists of only a single element -implicitly to be the first element of this group [Note: Such an -interpretation could eventually arise especially in case size() == 1] , -the following additional sentence is proposed: "If such a group of -elements consists of only a single element, this element is also -considered the first element."

    - -

    -Change 23.2.4.4 [list.ops], paragraph 20 to:

    - -

    -"Throws: Nothing unless an exception is thrown by *(i-1) == *i or -pred(*(i-1), *i)."

    - -

    -Comments to the new wording:

    - -

    -a) The wording regarding the conditions is identical to proposed -23.2.4.4 [list.ops], paragraph 19. If 23.2.4.4 [list.ops], -paragraph 19 is resolved in another way, the proposed wording need also -additional review. -b) The expression "(i - 1)" was left, but is expected that DR submitted -by Thomas Mang regarding invalid iterator arithmetic expressions will -take this into account. -c) Typos fixed.

    - -

    -Change 23.2.4.4 [list.ops], paragraph 21 to:

    - -

    -"Complexity: If empty() == false, exactly size() - 1 applications of the -corresponding predicate, otherwise no applications of the corresponding -predicate."

    - -

    -Comments to the new wording:

    - -

    -a) The new wording is supposed to also replace the proposed resolution -of DR 315, which suffers from the problem of undefined "first" / "last". -

    - -

    -5) References to other DRs:

    - -

    See DR 202. -See DR 239. -See DR 315. -See DR submitted by Thomas Mang regarding invalid iterator arithmetic -expressions.

    - - - -

    Proposed resolution:

    - - -

    Rationale:

    -

    "All implementations known to the author of this Defect Report -comply with these assumption", and "no impact on current code is -expected", i.e. there is no evidence of real-world confusion or -harm.

    - - - - - -
    -

    493. Undefined Expression in Input Iterator Note Title

    -

    Section: 24.1.1 [input.iterators] Status: NAD - Submitter: Chris Jefferson Date: 2004-12-13

    -

    View all other issues in [input.iterators].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    1) In 24.1.1/3, the following text is currently present.

    - -

    "Note: For input iterators, a==b does not imply ++a=++b (Equality does -not guarantee the substitution property or referential transparency)."

    - -

    However, when in Table 72, part of the definition of ++r is given as:

    - -

    "pre: r is dereferenceable. -post: any copies of the previous value of r are no longer required -either to be dereferenceable ..."

    - -

    While a==b does not imply that b is a copy of a, this statement should -perhaps still be made more clear.

    - -

    2) There are no changes to intended behaviour

    - -

    -3) This Note should be altered to say "Note: For input iterators a==b, -when its behaviour is defined ++a==++b may still be false (Equality does -not guarantee the substitution property or referential transparency).

    - - - -

    Proposed resolution:

    - - -

    Rationale:

    -

    This is descriptive text, not normative, and the meaning is clear.

    - - - - - -
    -

    494. Wrong runtime complexity for associative container's insert and delete

    -

    Section: 23.1.4 [associative.reqmts] Status: NAD - Submitter: Hans B os Date: 2004-12-19

    -

    View all other issues in [associative.reqmts].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    According to [lib.associative.reqmts] table 69, the runtime comlexity -of insert(p, t) and erase(q) can be done in amortized constant time.

    - -

    It was my understanding that an associative container could be -implemented as a balanced binary tree.

    - -

    For inser(p, t), you 'll have to iterate to p's next node to see if t -can be placed next to p. Furthermore, the insertion usually takes -place at leaf nodes. An insert next to the root node will be done at -the left of the root next node

    - -

    So when p is the root node you 'll have to iterate from the root to -its next node, which takes O(log(size)) time in a balanced tree.

    - -

    If you insert all values with insert(root, t) (where root is the -root of the tree before insertion) then each insert takes O(log(size)) -time. The amortized complexity per insertion will be O(log(size)) -also.

    - -

    For erase(q), the normal algorithm for deleting a node that has no -empty left or right subtree, is to iterate to the next (or previous), -which is a leaf node. Then exchange the node with the next and delete -the leaf node. Furthermore according to DR 130, erase should return -the next node of the node erased. Thus erasing the root node, -requires iterating to the next node.

    - -

    Now if you empty a map by deleting the root node until the map is -empty, each operation will take O(log(size)), and the amortized -complexity is still O(log(size)).

    - -

    The operations can be done in amortized constant time if iterating -to the next node can be done in (non amortized) constant time. This -can be done by putting all nodes in a double linked list. This -requires two extra links per node. To me this is a bit overkill since -you can already efficiently insert or erase ranges with erase(first, -last) and insert(first, last).

    - - - -

    Proposed resolution:

    - - -

    Rationale:

    -

    Only "amortized constant" in special circumstances, and we believe - that's implementable. That is: doing this N times will be O(N), not - O(log N).

    - - - - - -
    -

    499. Std. doesn't seem to require stable_sort() to be stable!

    -

    Section: 25.3.1.2 [stable.sort] Status: NAD Editorial - Submitter: Prateek Karandikar Date: 2005-04-12

    -

    View all issues with NAD Editorial status.

    -

    Discussion:

    -

    -17.3.1.1 Summary

    - -

    -1 The Summary provides a synopsis of the category, and introduces the -first-level subclauses. Each subclause also provides a summary, listing -the headers specified in the subclause and the library entities -provided in each header. -

    -

    -2 Paragraphs labelled "Note(s):" or "Example(s):" are informative, -other paragraphs are normative. -

    - -

    So this means that a "Notes" paragraph wouldn't be normative.

    - -

    -25.3.1.2 stable_sort -

    -
    template<class RandomAccessIterator> 
-void stable_sort(RandomAccessIterat or first, RandomAccessIterator last); 
-
-template<class RandomAccessIterator, class Compare> 
-void stable_sort(RandomAccessIterat or first, RandomAccessIterator last, Compare comp);
-
    -

    -1 Effects: Sorts the elements in the range [first, last). -

    -

    -2 Complexity: It does at most N(log N)^2 (where N == last - first) -comparisons; if enough extra memory is available, it is N log N. -

    -

    -3 Notes: Stable: the relative order of the equivalent elements is -preserved. -

    - -

    -The Notes para is informative, and nowhere else is stability mentioned above. -

    - -

    -Also, I just searched for the word "stable" in my copy of the Standard. -and the phrase "Notes: Stable: the relative order of the elements..." -is repeated several times in the Standard library clauses for -describing various functions. How is it that stability is talked about -in the informative paragraph? Or am I missing something obvious? -

    - - -

    Proposed resolution:

    -

    -

    - - -

    Rationale:

    -

    -This change has already been made. -

    - - - - - -
    -

    500. do_length cannot be implemented correctly

    -

    Section: 22.2.1.5 [locale.codecvt.byname] Status: NAD - Submitter: Krzysztof Żelechowski Date: 2005-05-24

    -

    View all other issues in [locale.codecvt.byname].

    -

    View all issues with NAD status.

    -

    Discussion:

    -
      -
    1. codecvt::do_length is of type int;
      2. -
    2. it is assumed to be sort-of returning from_next - from of type ptrdiff_t;
      3. -
    3. ptrdiff_t cannot be cast to an int without data loss.
      4. -
    -

    -Contradiction. -

    - - -

    Proposed resolution:

    -

    -

    - - - - - -
    -

    501. Proposal: strengthen guarantees of lib.comparisons

    -

    Section: 20.6.3 [base] Status: NAD - Submitter: Me <anti_spam_email2003@yahoo.com> Date: 2005-06-07

    -

    View all other issues in [base].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    -"For templates greater, less, greater_equal, and less_equal, -the specializations for any pointer type yield a total order, even if -the built-in operators <, >, <=, >= do not." -

    - -

    -The standard should do much better than guarantee that these provide a -total order, it should guarantee that it can be used to test if memory -overlaps, i.e. write a portable memmove. You can imagine a platform -where the built-in operators use a uint32_t comparison (this tests for -overlap on this platform) but the less<T*> functor is allowed to be -defined to use a int32_t comparison. On this platform, if you use -std::less with the intent of making a portable memmove, comparison on -an array that straddles the 0x7FFFFFFF/0x8000000 boundary can give -incorrect results. -

    - - -

    Proposed resolution:

    -

    -Add a footnote to 20.5.3/8 saying: -

    - -

    -Given a p1 and p2 such that p1 points to N objects of type T and p2 -points to M objects of type T. If [p1,p1+N) does not overlap [p2,p2+M), -less returns the same value when comparing all pointers in [p1,p1+N) to -all pointers in [p2,p2+M). Otherwise, there is a value Q and a value R -such that less returns the same value when comparing all pointers in -[p1,p1+Q) to all pointers in [p2,p2+R) and an opposite value when -comparing all pointers in [p1+Q,p1+N) to all pointers in [p2+R,p2+M). -For the sake of completeness, the null pointer value (4.10) for T is -considered to be an array of 1 object that doesn't overlap with any -non-null pointer to T. less_equal, greater, greater_equal, equal_to, -and not_equal_to give the expected results based on the total ordering -semantics of less. For T of void, treat it as having similar semantics -as T of char i.e. less<cv T*>(a, b) gives the same results as less<cv -void*>(a, b) which gives the same results as less<cv char*>((cv -char*)(cv void*)a, (cv char*)(cv void*)b). -

    - -

    -I'm also thinking there should be a footnote to 20.5.3/1 saying that if -A and B are similar types (4.4/4), comp<A>(a,b) returns the same value -as comp<B>(a,b) (where comp is less, less_equal, etc.). But this might -be problematic if there is some really funky operator overloading going -on that does different things based on cv (that should be undefined -behavior if somebody does that though). This at least should be -guaranteed for all POD types (especially pointers) that use the -built-in comparison operators. -

    - - - -

    Rationale:

    -

    -less is already required to provide a strict weak ordering which is good enough -to detect overlapping memory situations. -

    - - - - - -
    -

    504. Integer types in pseudo-random number engine requirements

    -

    Section: 26.4.1 [rand.req], TR1 5.1.1 [tr.rand.req] Status: NAD Editorial - Submitter: Walter Brown Date: 2005-07-03

    -

    View all other issues in [rand.req].

    -

    View all issues with NAD Editorial status.

    -

    Discussion:

    -

    -In [tr.rand.req], Paragraph 2 states that "... s is a value of integral type, -g is an ... object returning values of unsigned integral type ..." -

    - - -

    Proposed resolution:

    -

    -In 5.1.1 [tr.rand.req], Paragraph 2 replace -

    - -

    -... s is a value of integral type, g is an lvalue of a type other than X that -defines a zero-argument function object returning values of unsigned integral type -unsigned long int, -... -

    - -

    -In 5.1.1 [tr.rand.seq], Table 16, replace in the line for X(s) -

    - -

    -creates an engine with the initial internal state -determined by static_cast<unsigned long>(s) -

    - -

    [ -Mont Tremblant: Both s and g should be unsigned long. -This should refer to the constructor signatures. Jens provided wording post Mont Tremblant. -]

    - - -

    [ -Berlin: N1932 adopts the proposed resolution: see 26.3.1.3/1e and Table 3 row 2. Moved -to Ready. -]

    - - - - -

    Rationale:

    -

    -Jens: Just requiring X(unsigned long) still makes it possible -for an evil library writer to also supply a X(int) that does something -unexpected. The wording above requires that X(s) always performs -as if X(unsigned long) would have been called. I believe that is -sufficient and implements our intentions from Mont Tremblant. I -see no additional use in actually requiring a X(unsigned long) -signature. u.seed(s) is covered by its reference to X(s), same -arguments. -

    - - -

    [ -Portland: Subsumed by N2111. -]

    - - - - - -
    -

    506. Requirements of Distribution parameter for variate_generator

    -

    Section: 26.4 [rand], TR1 5.1.3 [tr.rand.var] Status: NAD - Submitter: Walter Brown Date: 2005-07-03

    -

    View all other issues in [rand].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    -Paragraph 3 requires that template argument U (which corresponds to template -parameter Engine) satisfy all uniform random number generator requirements. -However, there is no analogous requirement regarding the template argument -that corresponds to template parameter Distribution. We believe there should -be, and that it should require that this template argument satisfy all random -distribution requirements. -

    - - -

    Proposed resolution:

    -

    -Consequence 1: Remove the precondition clauses [tr.rand.var]/16 and /18. -

    -

    -Consequence 2: Add max() and min() functions to those distributions that -do not already have them. -

    - -

    [ -Mont Tremblant: Jens reccommends NAD, min/max not needed everywhere. -Marc supports having min and max to satisfy generic programming interface. -]

    - - - - -

    Rationale:

    -

    Berlin: N1932 makes this moot: variate_generator has been eliminated.

    - - - - - -
    -

    509. Uniform_int template parameters

    -

    Section: 26.4.8.1 [rand.dist.uni], TR1 5.1.7.1 [tr.rand.dist.iunif] Status: NAD - Submitter: Walter Brown Date: 2005-07-03

    -

    View all other issues in [rand.dist.uni].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    -In [tr.rand.dist.iunif] the uniform_int distribution currently has a single -template parameter, IntType, used as the input_type and as the result_type -of the distribution. We believe there is no reason to conflate these types -in this way. -

    - - -

    Proposed resolution:

    -

    -We recommend that there be a second template parameter to -reflect the distribution's input_type, and that the existing first template -parameter continue to reflect (solely) the result_type: -

    -
    template< class IntType = int, UIntType = unsigned int >
-class uniform_int
-{
-public:
-  // types
-  typedef  UIntType  input_type;
-  typedef  IntType   result_type;
-
    - -

    [ -Berlin: Moved to NAD. N1932 makes this moot: the input_type template parameter has been -eliminated. -]

    - - - - - - - -
    -

    510. Input_type for bernoulli_distribution

    -

    Section: 26.4.8.2 [rand.dist.bern], TR1 5.1.7.2 [tr.rand.dist.bern] Status: NAD - Submitter: Walter Brown Date: 2005-07-03

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    -In [tr.rand.dist.bern] the distribution currently requires; -

    -
    typedef  int  input_type;
-
    - - -

    Proposed resolution:

    -

    -We believe this is an unfortunate choice, and recommend instead: -

    -
    typedef  unsigned int  input_type;
-
    - -

    [ -Berlin: Moved to NAD. N1932 makes this moot: the input_type template parameter has been -eliminated. -]

    - - - - - - - -
    -

    511. Input_type for binomial_distribution

    -

    Section: 26.4.8 [rand.dist], TR1 5.1.7.5 [tr.rand.dist.bin] Status: NAD - Submitter: Walter Brown Date: 2005-07-03

    -

    View all other issues in [rand.dist].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    -Unlike all other distributions in TR1, this binomial_distribution has an -implementation-defined input_type. We believe this is an unfortunate choice, -because it hinders users from writing portable code. It also hinders the -writing of compliance tests. We recommend instead: -

    -
    typedef  RealType  input_type;
-
    -

    -While this choice is somewhat arbitrary (as it was for some of the other -distributions), we make this particular choice because (unlike all other -distributions) otherwise this template would not publish its RealType -argument and so users could not write generic code that accessed this -second template parameter. In this respect, the choice is consistent with -the other distributions in TR1. -

    -

    -We have two reasons for recommending that a real type be specified instead. -One reason is based specifically on characteristics of binomial distribution -implementations, while the other is based on mathematical characteristics of -probability distribution functions in general. -

    -

    -Implementations of binomial distributions commonly use Stirling approximations -for values in certain ranges. It is far more natural to use real values to -represent these approximations than it would be to use integral values to do -so. In other ranges, implementations reply on the Bernoulli distribution to -obtain values. While TR1's bernoulli_distribution::input_type is specified as -int, we believe this would be better specified as double. -

    -

    -This brings us to our main point: The notion of a random distribution rests -on the notion of a cumulative distribution function, which in turn mathematically -depends on a continuous dependent variable. Indeed, such a distribution function -would be meaningless if it depended on discrete values such as integers - and this -remains true even if the distribution function were to take discrete steps. -

    -

    -Although this note is specifically about binomial_distribution::input_type, -we intend to recommend that all of the random distributions input_types be -specified as a real type (either a RealType template parameter, or double, -as appropriate). -

    -

    -Of the nine distributions in TR1, four already have this characteristic -(uniform_real, exponential_distribution, normal_distribution, and -gamma_distribution). We have already argued the case for the binomial the -remaining four distributions. -

    -

    -In the case of uniform_int, we believe that the calculations to produce an -integer result in a specified range from an integer in a different specified -range is best done using real arithmetic. This is because it involves a -product, one of whose terms is the ratio of the extents of the two ranges. -Without real arithmetic, the results become less uniform: some numbers become -more (or less) probable that they should be. This is, of course, undesireable -behavior in a uniform distribution. -

    -

    -Finally, we believe that in the case of the bernoulli_distribution (briefly -mentioned earlier), as well as the cases of the geometric_distribution and the -poisson_distribution, it would be far more natural to have a real input_type. -This is because the most natural computation involves the random number -delivered and the distribution's parameter p (in the case of bernoulli_distribution, -for example, the computation is a comparison against p), and p is already specified -in each case as having some real type. -

    - - -

    Proposed resolution:

    -
    typedef  RealType  input_type;
-
    - -

    [ -Berlin: Moved to NAD. N1932 makes this moot: the input_type template parameter has been -eliminated. -]

    - - - - - - -
    -

    512. Seeding subtract_with_carry_01 from a single unsigned long

    -

    Section: 26.4.3 [rand.eng], TR1 5.1.4.4 [tr.rand.eng.sub1] Status: NAD Editorial - Submitter: Walter Brown Date: 2005-07-03

    -

    View all other issues in [rand.eng].

    -

    View all issues with NAD Editorial status.

    -

    Discussion:

    -

    -Paragraph 8 specifies the algorithm by which a subtract_with_carry_01 engine -is to be seeded given a single unsigned long. This algorithm is seriously -flawed in the case where the engine parameter w (also known as word_size) -exceeds 31 [bits]. The key part of the paragraph reads: -

    -

    -sets x(-r) ... x(-1) to (lcg(1)*2**(-w)) mod 1 -

    -

    -and so forth. -

    -

    -Since the specified linear congruential engine, lcg, delivers numbers with -a maximum of 2147483563 (just a shade under 31 bits), then when w is, for -example, 48, each of the x(i) will be less than 2**-17. The consequence -is that roughly the first 400 numbers delivered will be conspicuously -close to either zero or one. -

    -

    -Unfortunately, this is not an innocuous flaw: One of the predefined engines -in [tr.rand.predef], namely ranlux64_base_01, has w = 48 and would exhibit -this poor behavior, while the original N1378 proposal states that these -pre-defined engines are intended to be of "known good properties." -

    - - -

    Proposed resolution:

    -

    -In 5.1.4.4 [tr.rand.eng.sub1], replace the "effects" clause for -void seed(unsigned long value = 19780503) by -

    - -

    -Effects: If value == 0, sets value to 19780503. In any -case, with a linear congruential generator lcg(i) having parameters -mlcg = 2147483563, alcg = 40014, -clcg = 0, and lcg(0) = value, -sets carry(-1) and x(-r) … x(-1) -as if executing

    - -
    
-linear_congruential<unsigned long, 40014, 0, 2147483563> lcg(value);
-seed(lcg);
-
    - -

    -to (lcg(1) · 2-w) mod 1 -… (lcg(r) · 2-w) mod 1, -respectively. If x(-1) == 0, sets carry(-1) = 2-w, -else sets carry(-1) = 0.

    -
    - -

    [ -Jens provided revised wording post Mont Tremblant. -]

    - - -

    [ -Berlin: N1932 adopts the originally-proposed resolution of the issue. -Jens's supplied wording is a clearer description of what is -intended. Moved to Ready. -]

    - - - - -

    Rationale:

    -

    -Jens: I'm using an explicit type here, because fixing the -prose would probably not qualify for the (with issue 504 even -stricter) requirements we have for seed(Gen&). -

    - -

    [ -Portland: Subsumed by N2111. -]

    - - - - - - -
    -

    513. Size of state for subtract_with_carry_01

    -

    Section: 26.4.3 [rand.eng], TR1 5.1.4.4 [tr.rand.eng.sub1] Status: NAD Editorial - Submitter: Walter Brown Date: 2005-07-03

    -

    View all other issues in [rand.eng].

    -

    View all issues with NAD Editorial status.

    -

    Discussion:

    -

    -Paragraph 3 begins: -

    -

    -The size of the state is r. -

    -

    -However, this is not quite consistent with the remainder of the paragraph -which specifies a total of nr+1 items in the textual representation of -the state. We recommend the sentence be corrected to match: -

    -

    -The size of the state is nr+1. -

    -

    -To give meaning to the coefficient n, it may be also desirable to move -n's definition from later in the paragraph. Either of the following -seem reasonable formulations: -

    -

    -With n=..., the size of the state is nr+1. -

    -

    -The size of the state is nr+1, where n=... . -

    - - - -

    Proposed resolution:

    -

    [ -Jens: I plead for "NAD" on the grounds that "size of state" is only -used as an argument for big-O complexity notation, thus -constant factors and additions don't count. -]

    - - -

    [ -Berlin: N1932 adopts the proposed NAD. -]

    - - - - - - - -
    -

    514. Size of state for subtract_with_carry

    -

    Section: 26.4.3.3 [rand.eng.sub], TR1 5.1.4.3 [tr.rand.eng.sub] Status: NAD Editorial - Submitter: Walter Brown Date: 2005-07-03

    -

    View all issues with NAD Editorial status.

    -

    Discussion:

    -

    -Paragraph 2 begins: -

    -

    -The size of the state is r. -

    -

    -However, the next sentence specifies a total of r+1 items in the textual -representation of the state, r specific x's as well as a specific carry. -This makes a total of r+1 items that constitute the size of the state, -rather than r. -

    - - -

    Proposed resolution:

    -

    -We recommend the sentence be corrected to match: -

    -

    - The size of the state is r+1. -

    - -

    [ -Jens: I plead for "NAD" on the grounds that "size of state" is only -used as an argument for big-O complexity notation, thus -constant factors and additions don't count. -]

    - - -

    [ -Berlin: N1932 adopts the proposed NAD. -]

    - - - - - - - -
    -

    515. Random number engine traits

    -

    Section: 26.4.2 [rand.synopsis], TR1 5.1.2 [tr.rand.synopsis] Status: NAD - Submitter: Walter Brown Date: 2005-07-03

    -

    View all other issues in [rand.synopsis].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    -To accompany the concept of a pseudo-random number engine as defined in Table 17, -we propose and recommend an adjunct template, engine_traits, to be declared in -[tr.rand.synopsis] as: -

    -
    template< class PSRE >
-class engine_traits;
-
    -

    -This template's primary purpose would be as an aid to generic programming involving -pseudo-random number engines. Given only the facilities described in tr1, it would -be very difficult to produce any algorithms involving the notion of a generic engine. -The intent of this proposal is to provide, via engine_traits<>, sufficient -descriptive information to allow an algorithm to employ a pseudo-random number engine -without regard to its exact type, i.e., as a template parameter. -

    -

    -For example, today it is not possible to write an efficient generic function that -requires any specific number of random bits. More specifically, consider a -cryptographic application that internally needs 256 bits of randomness per call: -

    -
    template< class Eng, class InIter, class OutIter >
-void crypto( Eng& e, InIter in, OutIter out );
-
    -

    -Without knowning the number of bits of randomness produced per call to a provided -engine, the algorithm has no means of determining how many times to call the engine. -

    -

    -In a new section [tr.rand.eng.traits], we proposed to define the engine_traits -template as: -

    -
    template< class PSRE >
-class engine_traits
-{
-  static  std::size_t  bits_of_randomness = 0u;
-  static  std::string  name()  { return "unknown_engine"; }
-  // TODO: other traits here
-};
-
    -

    -Further, each engine described in [tr.rand.engine] would be accompanied by a -complete specialization of this new engine_traits template. -

    - - - -

    Proposed resolution:

    -

    [ -Berlin: Walter: While useful for implementation per TR1, N1932 has no need for this -feature. Recommend close as NAD. -]

    - - - -

    Rationale:

    -

    -Recommend NAD, -N1932, -N2111 -covers this. Already in WP. -

    - - - - - -
    -

    516. Seeding subtract_with_carry_01 using a generator

    -

    Section: 26.4.3 [rand.eng], TR1 5.1.4.4 [tr.rand.eng.sub1] Status: NAD Editorial - Submitter: Walter Brown Date: 2005-07-03

    -

    View all other issues in [rand.eng].

    -

    View all issues with NAD Editorial status.

    -

    Discussion:

    -

    -Paragraph 6 says: -

    -

    -... obtained by successive invocations of g, ... -

    -

    -We recommend instead: -

    -

    -... obtained by taking successive invocations of g mod 2**32, ... -

    -

    -as the context seems to require only 32-bit quantities be used here. -

    - - -

    Proposed resolution:

    -

    -Berlin: N1932 adopts the proposed resultion: see 26.3.3.4/7. Moved to Ready. -

    - -

    [ -Portland: Subsumed by N2111. -]

    - - - - - - -
    -

    517. Should include name in external representation

    -

    Section: 26.4.1 [rand.req], TR1 5.1.1 [tr.rand.req] Status: NAD - Submitter: Walter Brown Date: 2005-07-03

    -

    View all other issues in [rand.req].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    -The last two rows of Table 16 deal with the i/o requirements of an engine, -specifying that the textual representation of an engine's state, -appropriately formatted, constitute the engine's external representation. -

    -

    -This seems adequate when an engine's type is known. However, it seems -inadequate in the context of generic code, where it becomes useful and -perhaps even necessary to determine an engine's type via input. -

    -

    -

    - - -

    Proposed resolution:

    -

    -We therefore recommend that, in each of these two rows of Table 16, the -text "textual representation" be expanded so as to read "engine name -followed by the textual representation." -

    - -

    [ -Berlin: N1932 considers this NAD. This is a QOI issue. -]

    - - - - - - - -
    -

    525. type traits definitions not clear

    -

    Section: 20.5.4 [meta.unary], TR1 4.5 [tr.meta.unary] Status: NAD Editorial - Submitter: Robert Klarer Date: 2005-07-11

    -

    View all issues with NAD Editorial status.

    -

    Discussion:

    -

    -It is not completely clear how the primary type traits deal with -cv-qualified types. And several of the secondary type traits -seem to be lacking a definition. -

    - -

    [ -Berlin: Howard to provide wording. -]

    - - - -

    Proposed resolution:

    -

    -Wording provided in N2028. -A -revision (N2157) -provides more detail for motivation. -

    - - -

    Rationale:

    -Solved by revision (N2157) -in the WP. - - - - - -
    -

    526. Is it undefined if a function in the standard changes in parameters?

    -

    Section: 23.1.3 [sequence.reqmts] Status: NAD - Submitter: Chris Jefferson Date: 2005-09-14

    -

    View all other issues in [sequence.reqmts].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    -Problem: There are a number of places in the C++ standard library where -it is possible to write what appear to be sensible ways of calling -functions, but which can cause problems in some (or all) -implementations, as they cause the values given to the function to be -changed in a way not specified in standard (and therefore not coded to -correctly work). These fall into two similar categories. -

    - -

    -1) Parameters taken by const reference can be changed during execution -of the function -

    - -

    -Examples: -

    - -

    -Given std::vector<int> v: -

    -

    -v.insert(v.begin(), v[2]); -

    -

    -v[2] can be changed by moving elements of vector -

    - - -

    -Given std::list<int> l: -

    -

    -l.remove(*l.begin()); -

    -

    -Will delete the first element, and then continue trying to access it. -This is particularily vicious, as it will appear to work in almost all -cases. -

    - -

    -2) A range is given which changes during the execution of the function: -Similarly, -

    - -

    -v.insert(v.begin(), v.begin()+4, v.begin()+6); -

    - -

    -This kind of problem has been partly covered in some cases. For example -std::copy(first, last, result) states that result cannot be in the range -[first, last). However, does this cover the case where result is a -reverse_iterator built from some iterator in the range [first, last)? -Also, std::copy would still break if result was reverse_iterator(last + -1), yet this is not forbidden by the standard -

    - -

    -Solution: -

    - -

    -One option would be to try to more carefully limit the requirements of -each function. There are many functions which would have to be checked. -However as has been shown in the std::copy case, this may be difficult. -A simpler, more global option would be to somewhere insert text similar to: -

    - -

    -If the execution of any function would change either any values passed -by reference or any value in any range passed to a function in a way not -defined in the definition of that function, the result is undefined. -

    - -

    -Such code would have to at least cover chapters 23 and 25 (the sections -I read through carefully). I can see no harm on applying it to much of -the rest of the standard. -

    - -

    -Some existing parts of the standard could be improved to fit with this, -for example the requires for 25.2.1 (Copy) could be adjusted to: -

    - -

    -Requires: For each non-negative integer n < (last - first), assigning to -*(result + n) must not alter any value in the range [first + n, last). -

    - -

    -However, this may add excessive complication. -

    - -

    -One other benefit of clearly introducing this text is that it would -allow a number of small optimisations, such as caching values passed -by const reference. -

    - -

    -Matt Austern adds that this issue also exists for the insert and -erase members of the ordered and unordered associative containers. -

    - -

    [ -Berlin: Lots of controversey over how this should be solved. Lots of confusion -as to whether we're talking about self referencing iterators or references. -Needs a good survey as to the cases where this matters, for which -implementations, and how expensive it is to fix each case. -]

    - - - - -

    Proposed resolution:

    - - -

    Rationale:

    -

    -Recommend NAD. -

    -
      -
    • vector::insert(iter, value) is required to work because the standard -doesn't give permission for it not to work.
      • -
    • list::remove(value) is required to work because the standard -doesn't give permission for it not to work.
      • -
    • vector::insert(iter, iter, iter) is not required to work because -23.1.3 [sequence.reqmts], p4 says so.
      • -
    • copy has to work, except where 25.2.1 [alg.copy] says -it doesn't have to work. While a language lawyer can tear this wording apart, -it is felt that the wording is not prone to accidental interpretation.
      • -
    • The current working draft provide exceptions for the unordered associative -containers similar to the containers requirements which exempt the member -template insert functions from self referencing.
      • -
    - - - - - -
    -

    528. const_iterator iterator issue when they are the same type

    -

    Section: 23.4 [unord], TR1 6.3.4 [tr.unord.unord] Status: NAD - Submitter: Paolo Carlini Date: 2005-10-12

    -

    View other active issues in [unord].

    -

    View all other issues in [unord].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    -while implementing the resolution of issue 6.19 I'm noticing the -following: according to 6.3.4.3/2 (and 6.3.4.5/2), for unordered_set and -unordered_multiset: -

    - -

    - "The iterator and const_iterator types are both const types. It is -unspecified whether they are the same type" -

    - -

    -Now, according to the resolution of 6.19, we have overloads of insert -with hint and erase (single and range) both for iterator and -const_iterator, which, AFAICS, can be meaningful at the same time *only* -if iterator and const_iterator *are* in fact different types. -

    -

    -Then, iterator and const_iterator are *required* to be different types? -Or that is an unintended consequence? Maybe the overloads for plain -iterators should be added only to unordered_map and unordered_multimap? -Or, of course, I'm missing something? -

    - - - -

    Proposed resolution:

    -

    -Add to 6.3.4.3p2 (and 6.3.4.5p2): -

    -

    -2 ... The iterator and const_iterator types are both const -constant iterator types. -It is unspecified whether they are the same type. -

    - -

    -Add a new subsection to 17.4.4 [lib.conforming]: -

    - -
    -

    -An implementation shall not supply an overloaded function - signature specified in any library clause if such a signature - would be inherently ambiguous during overload resolution - due to two library types referring to the same type. -

    -

    - [Note: For example, this occurs when a container's iterator - and const_iterator types are the same. -- end note] -

    -
    - -

    [ -Post-Berlin: Beman supplied wording. -]

    - - - - -

    Rationale:

    -Toronto: The first issue has been fixed by N2350 (the insert and erase members -are collapsed into one signature). Alisdair to open a separate issue on the -chapter 17 wording. - - - - - -
    -

    529. The standard encourages redundant and confusing preconditions

    -

    Section: 17.4.3.10 [res.on.required] Status: NAD Editorial - Submitter: David Abrahams Date: 2005-10-25

    -

    View all issues with NAD Editorial status.

    -

    Discussion:

    -

    -17.4.3.8/1 says: -

    - -

    -Violation of the preconditions specified in a function's -Required behavior: paragraph results in undefined behavior unless the -function's Throws: paragraph specifies throwing an exception when the -precondition is violated. -

    - -

    -This implies that a precondition violation can lead to defined -behavior. That conflicts with the only reasonable definition of -precondition: that a violation leads to undefined behavior. Any other -definition muddies the waters when it comes to analyzing program -correctness, because precondition violations may be routinely done in -correct code (e.g. you can use std::vector::at with the full -expectation that you'll get an exception when your index is out of -range, catch the exception, and continue). Not only is it a bad -example to set, but it encourages needless complication and redundancy -in the standard. For example: -

    - -
      21 Strings library 
-  21.3.3 basic_string capacity
-
-  void resize(size_type n, charT c);
-
-  5 Requires: n <= max_size()
-  6 Throws: length_error if n > max_size().
-  7 Effects: Alters the length of the string designated by *this as follows:
-
    - -

    -The Requires clause is entirely redundant and can be dropped. We -could make that simplifying change (and many others like it) even -without changing 17.4.3.8/1; the wording there just seems to encourage -the redundant and error-prone Requires: clause. -

    - -

    [ -Batavia: Alan and Pete to work. -]

    - - -

    [ -Bellevue: NAD Editorial, this group likes -N2121, -Pete agrees, accepting it is Pete's business. -General agreement that precondition violations are synonymous with UB. -]

    - - - -

    Proposed resolution:

    -

    -1. Change 17.4.3.8/1 to read: -

    - -

    -Violation of the preconditions specified in a function's -Required behavior: paragraph results in undefined behavior -unless the function's Throws: paragraph specifies throwing -an exception when the precondition is violated. -

    - -

    -2. Go through and remove redundant Requires: clauses. Specifics to be - provided by Dave A. -

    - -

    [ -Berlin: The LWG requests a detailed survey of part 2 of the proposed resolution. -]

    - - -

    [ -Alan provided the survey -N2121. -]

    - - - - - - - -
    -

    532. Tuple comparison

    -

    Section: 20.4.1.6 [tuple.rel], TR1 6.1.3.5 [tr.tuple.rel] Status: Pending NAD Editorial - Submitter: David Abrahams Date: 2005-11-29

    -

    View all issues with Pending NAD Editorial status.

    -

    Duplicate of: 348

    -

    Discussion:

    -

    -Where possible, tuple comparison operators <,<=,=>, and > ought to be -defined in terms of std::less rather than operator<, in order to -support comparison of tuples of pointers. -

    - - -

    Proposed resolution:

    -

    -change 6.1.3.5/5 from: -

    - -

    - Returns: The result of a lexicographical comparison between t and - u. The result is defined as: (bool)(get<0>(t) < get<0>(u)) || - (!(bool)(get<0>(u) < get<0>(t)) && ttail < utail), where rtail for - some tuple r is a tuple containing all but the first element of - r. For any two zero-length tuples e and f, e < f returns false. -

    - -

    -to: -

    - -
    -

    - Returns: The result of a lexicographical comparison between t and - u. For any two zero-length tuples e and f, e < f returns false. - Otherwise, the result is defined as: cmp( get<0>(t), get<0>(u)) || - (!cmp(get<0>(u), get<0>(t)) && ttail < utail), where rtail for some - tuple r is a tuple containing all but the first element of r, and - cmp(x,y) is an unspecified function template defined as follows. -

    -

    - Where T is the type of x and U is the type of y: -

    - -

    - if T and U are pointer types and T is convertible to U, returns - less<U>()(x,y) -

    - -

    - otherwise, if T and U are pointer types, returns less<T>()(x,y) -

    - -

    - otherwise, returns (bool)(x < y) -

    -
    - -

    [ -Berlin: This issue is much bigger than just tuple (pair, containers, -algorithms). Dietmar will survey and work up proposed wording. -]

    - - - - -

    Rationale:

    -

    -Recommend NAD. This will be fixed with the next revision of concepts. -

    - - - - - -
    -

    536. Container iterator constructor and explicit convertibility

    -

    Section: 23.1 [container.requirements] Status: Dup - Submitter: Joaquín M López Muñoz Date: 2005-12-17

    -

    View other active issues in [container.requirements].

    -

    View all other issues in [container.requirements].

    -

    View all issues with Dup status.

    -

    Duplicate of: 589

    -

    Discussion:

    -

    -The iterator constructor X(i,j) for containers as defined in 23.1.1 and -23.2.2 does only require that i and j be input iterators but -nothing is said about their associated value_type. There are three -sensible -options: -

    -
      -
    1. iterator's value_type is exactly X::value_type (modulo cv).
      2. -
    2. iterator's value_type is *implicitly* convertible to X::value_type.
      3. -
    3. iterator's value_type is *explicitly* convertible to X::value_type.
      4. -
    -

    -The issue has practical implications, and stdlib vendors have -taken divergent approaches to it: Dinkumware follows 2, -libstdc++ follows 3. -

    -

    -The same problem applies to the definition of insert(p,i,j) for -sequences and insert(i,j) for associative contianers, as well as -assign. -

    - -

    [ -The following added by Howard and the example code was originally written by -Dietmar. -]

    - -

    -Valid code below? -

    - -
    #include <vector> 
-#include <iterator> 
-#include <iostream> 
-
-struct foo 
-{ 
-    explicit foo(int) {} 
-}; 
-
-int main() 
-{ 
-    std::vector<int> v_int; 
-    std::vector<foo> v_foo1(v_int.begin(), v_int.end()); 
-    std::vector<foo> v_foo2((std::istream_iterator<int>(std::cin)), 
-                             std::istream_iterator<int>()); 
-} 
-
    -

    [ -Berlin: Some support, not universal, for respecting the explicit qualifier. -]

    - - - - -

    Proposed resolution:

    - - - - - - -
    -

    544. minor NULL problems in C.2

    -

    Section: C.2 [diff.library] Status: NAD Editorial - Submitter: Martin Sebor Date: 2005-11-25

    -

    View all issues with NAD Editorial status.

    -

    Discussion:

    -

    -According to C.2.2.3, p1, "the macro NULL, defined in any of <clocale>, -<cstddef>, <cstdio>, <cstdlib>, <cstring>, <ctime>, -or <cwchar>." This is consistent with the C standard. -

    -

    -However, Table 95 in C.2 fails to mention <clocale> and <cstdlib>. -

    -

    -In addition, C.2, p2 claims that "The C++ Standard library provides -54 standard macros from the C library, as shown in Table 95." While -table 95 does have 54 entries, since a couple of them (including the -NULL macro) are listed more than once, the actual number of macros -defined by the C++ Standard Library may not be 54. -

    - - -

    Proposed resolution:

    -

    -I propose we add <clocale> and <cstdlib> to Table 96 and remove the -number of macros from C.2, p2 and reword the sentence as follows: -

    -

    -The C++ Standard library provides 54 standard macros from -defines a number macros corresponding to those defined by the C -Standard library, as shown in Table 96. -

    - -

    [ -Portland: Resolution is considered editorial. It will be incorporated into the WD. -]

    - - - - - - - -
    -

    547. division should be floating-point, not integer

    -

    Section: 26.4 [rand], TR1 5.1 [tr.rand] Status: NAD - Submitter: Matt Austern Date: 2006-01-10

    -

    View all other issues in [rand].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    -Paragraph 10 describes how a variate generator uses numbers produced by an -engine to pass to a generator. The sentence that concerns me is: "Otherwise, if -the value for engine_value_type::result_type is true and the value for -Distribution::input_type is false [i.e. if the engine produces integers and the -engine wants floating-point values], then the numbers in s_eng are divided by -engine().max() - engine().min() + 1 to obtain the numbers in s_e." Since the -engine is producing integers, both the numerator and the denominator are -integers and we'll be doing integer division, which I don't think is what we -want. Shouldn't we be performing a conversion to a floating-point type first? -

    - - -

    Proposed resolution:

    - - -

    Rationale:

    -

    -Recommend NAD as the affected section is now gone and so the issue is moot. -N2111. -

    - - - - - -
    -

    548. May random_device block?

    -

    Section: 26.4.6 [rand.device], TR1 5.1.6 [tr.rand.device] Status: NAD - Submitter: Matt Austern Date: 2006-01-10

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    -Class random_device "produces non-deterministic random numbers", using some -external source of entropy. In most real-world systems, the amount of available -entropy is limited. Suppose that entropy has been exhausted. What is an -implementation permitted to do? In particular, is it permitted to block -indefinitely until more random bits are available, or is the implementation -required to detect failure immediately? This is not an academic question. On -Linux a straightforward implementation would read from /dev/random, and "When -the entropy pool is empty, reads to /dev/random will block until additional -environmental noise is gathered." Programmers need to know whether random_device -is permitted to (or possibly even required to?) behave the same way. -

    - -

    [ -Berlin: Walter: N1932 considers this NAD. Does the standard specify whether std::cin -may block? -]

    - - -

    -See N2391 and -N2423 -for some further discussion. -

    - - -

    Proposed resolution:

    -

    -Adopt the proposed resolution in -N2423 (NAD). -

    - - - - - -
    -

    549. Undefined variable in binomial_distribution

    -

    Section: 26.4.8 [rand.dist], TR1 5.1.7.5 [tr.rand.dist.bin] Status: NAD Editorial - Submitter: Matt Austern Date: 2006-01-10

    -

    View all other issues in [rand.dist].

    -

    View all issues with NAD Editorial status.

    -

    Discussion:

    -

    -Paragraph 1 says that "A binomial distributon random distribution produces -integer values i>0 with p(i) = (n choose i) * p*i * (1-p)^(t-i), where t and -p are the parameters of the distribution. OK, that tells us what t, p, and i -are. What's n? -

    - - -

    Proposed resolution:

    -

    -Berlin: Typo: "n" replaced by "t" in N1932: see 26.3.7.2.2/1. -

    - -

    [ -Portland: Subsumed by N2111. -]

    - - - - - - -
    -

    553. very minor editorial change intptr_t / uintptr_t

    -

    Section: 18.3.1 [cstdint.syn], TR1 8.22.1 [tr.c99.cstdint.syn] Status: NAD Editorial - Submitter: Paolo Carlini Date: 2006-01-30

    -

    View all other issues in [cstdint.syn].

    -

    View all issues with NAD Editorial status.

    -

    Discussion:

    -

    -In the synopsis, some types are identified as optional: int8_t, int16_t, -and so on, consistently with C99, indeed. -

    -

    -On the other hand, intptr_t and uintptr_t, are not marked as such and -probably should, consistently with C99, 7.18.1.4. -

    - - -

    Proposed resolution:

    -

    -Change 18.3.1 [cstdint.syn]: -

    - -
    ...
-typedef signed integer type intptr_t;    // optional
-...
-typedef unsigned integer type uintptr_t;    // optional
-...
-
    - - - -

    Rationale:

    -Recommend NAD and fix as editorial with the proposed resolution. - - - - - -
    -

    554. Problem with lwg DR 184 numeric_limits<bool>

    -

    Section: 18.2.1.5 [numeric.special] Status: NAD - Submitter: Howard Hinnant Date: 2006-01-29

    -

    View all other issues in [numeric.special].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    -I believe we have a bug in the resolution of: -lwg 184 -(WP status). -

    - -

    -The resolution spells out each member of numeric_limits<bool>. -The part I'm having a little trouble with is: -

    -
    static const bool traps = false;
-
    - -

    -Should this not be implementation defined? Given: -

    - -
    int main()
-{
-     bool b1 = true;
-     bool b2 = false;
-     bool b3 = b1/b2;
-}
-
    - -

    -If this causes a trap, shouldn't numeric_limits<bool>::traps be -true? -

    - - -

    Proposed resolution:

    -

    -Change 18.2.1.5p3: -

    - -

    --3- The specialization for bool shall be provided as follows:

    -
    namespace std { 
-   template <> class numeric_limits<bool> {
-      ...
-      static const bool traps = false implementation-defined;
-      ...
-   };
-}
-
    -
    - -

    [ -Redmond: NAD because traps refers to values, not operations. There is no bool -value that will trap. -]

    - - - - - - - -
    -

    555. TR1, 8.21/1: typo

    -

    Section: TR1 8.21 [tr.c99.boolh] Status: NAD Editorial - Submitter: Paolo Carlini Date: 2006-02-02

    -

    View all issues with NAD Editorial status.

    -

    Discussion:

    -

    -This one, if nobody noticed it yet, seems really editorial: -s/cstbool/cstdbool/ -

    - - -

    Proposed resolution:

    -

    -Change 8.21p1: -

    -

    --1- The header behaves as if it defines the additional macro defined in -<cstdbool> by including the header <cstdbool>. -

    - -

    [ -Redmond: Editorial. -]

    - - - - - - - -
    -

    557. TR1: div(_Longlong, _Longlong) vs div(intmax_t, intmax_t)

    -

    Section: 18.3 [cstdint], TR1 8.22 [tr.c99.cstdint] Status: NAD Editorial - Submitter: Paolo Carlini Date: 2006-02-06

    -

    View all other issues in [cstdint].

    -

    View all issues with NAD Editorial status.

    -

    Discussion:

    -

    -I'm seeing a problem with such overloads: when, _Longlong == intmax_t == -long long we end up, essentially, with the same arguments and different -return types (lldiv_t and imaxdiv_t, respectively). Similar issue with -abs(_Longlong) and abs(intmax_t), of course. -

    -

    -Comparing sections 8.25 and 8.11, I see an important difference, -however: 8.25.3 and 8.25.4 carefully describe div and abs for _Longlong -types (rightfully, because not moved over directly from C99), whereas -there is no equivalent in 8.11: the abs and div overloads for intmax_t -types appear only in the synopsis and are not described anywhere, in -particular no mention in 8.11.2 (at variance with 8.25.2). -

    -

    -I'm wondering whether we really, really, want div and abs for intmax_t... -

    - - - -

    Proposed resolution:

    - - - -

    [ -Portland: no consensus. -]

    - - -

    Rationale:

    -

    [ -Batavia, Bill: The <cstdint> synopsis in TR1 8.11.1 [tr.c99.cinttypes.syn] contains: -]

    - -
    intmax_t imaxabs(intmax_t i);
-intmax_t abs(intmax_t i);
-
-imaxdiv_t imaxdiv(intmax_t numer, intmax_t denom);
-imaxdiv_t div(intmax_t numer, intmax_t denom);
-
    - -

    [ -and in TR1 8.11.2 [tr.c99.cinttypes.def]: -]

    - - -

    -The header defines all functions, types, and macros the same as C99 -subclause 7.8. -

    - -

    [ -This is as much definition as we give for most other C99 functions, -so nothing need change. We might, however, choose to add the footnote: -]

    - - -

    -[Note: These overloads for abs and div may well be equivalent to -those that take long long arguments. If so, the implementation is -responsible for avoiding conflicting declarations. -- end note] -

    - -

    [ -Bellevue: NAD Editorial. Pete must add a footnote, as described below. -]

    - - -
    -

    [ -Looks like a real problem. Dietmar suggests div() return a template -type. Matt: looks like imaxdiv_t is loosly defined. Can it be a typedef -for lldiv_t when _Longlong == intmax_t? PJP seems to agree. We would -need a non-normative note declaring that the types lldiv_t and imaxdiv_t -may not be unique if intmax_t==_longlong. -]

    - -
    - - - - - - -
    -

    558. lib.input.iterators Defect

    -

    Section: 24.1.1 [input.iterators] Status: NAD Editorial - Submitter: David Abrahams Date: 2006-02-09

    -

    View all other issues in [input.iterators].

    -

    View all issues with NAD Editorial status.

    -

    Discussion:

    -
    -

    - 24.1.1 Input iterators [lib.input.iterators] -

    -

    - 1 A class or a built-in type X satisfies the requirements of an - input iterator for the value type T if the following expressions are - valid, where U is the type of any specified member of type T, as - shown in Table 73. -

    -
    -

    -There is no capital U used in table 73. There is a lowercase u, but -that is clearly not meant to denote a member of type T. Also, there's -no description in 24.1.1 of what lowercase a means. IMO the above -should have been...Hah, a and b are already covered in 24.1/11, so maybe it -should have just been: -

    - - -

    Proposed resolution:

    -

    -Change 24.1.1p1: -

    -

    --1- A class or a built-in type X satisfies the requirements of an -input iterator for the value type T if the following expressions -are valid, where U is the type of any specified member of type -T, as shown in Table 73. -

    - -

    [ -Portland: Editorial. -]

    - - - - - - - -
    -

    560. User-defined allocators without default constructor

    -

    Section: 20.1.2 [allocator.requirements] Status: NAD - Submitter: Sergey P. Derevyago Date: 2006-02-17

    -

    View other active issues in [allocator.requirements].

    -

    View all other issues in [allocator.requirements].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    1. The essence of the problem.

    -

    -User-defined allocators without default constructor are not explicitly -supported by the standard but they can be supported just like std::vector -supports elements without default constructor. -

    -

    -As a result, there exist implementations that work well with such allocators -and implementations that don't. -

    - -

    2. The cause of the problem.

    -

    -1) The standard doesn't explicitly state this intent but it should. In -particular, 20.1.5p5 explicitly state the intent w.r.t. the allocator -instances that compare non-equal. So it can similarly state the intent w.r.t. -the user-defined allocators without default constructor. -

    -

    -2) Some container operations are obviously underspecified. In particular, -21.3.7.1p2 tells: -

    -
    template<class charT, class traits, class Allocator>
-  basic_string<charT,traits,Allocator> operator+(
-    const charT* lhs,
-    const basic_string<charT,traits,Allocator>& rhs
-  );
-
    -

    -Returns: basic_string<charT,traits,Allocator>(lhs) + rhs. -

    -
    -

    -That leads to the basic_string<charT,traits,Allocator>(lhs, Allocator()) call. -Obviously, the right requirement is: -

    -

    -Returns: basic_string<charT,traits,Allocator>(lhs, rhs.get_allocator()) + rhs. -

    -

    -It seems like a lot of DRs can be submitted on this "Absent call to -get_allocator()" topic. -

    - -

    3. Proposed actions.

    -

    -1) Explicitly state the intent to allow for user-defined allocators without -default constructor in 20.1.5 Allocator requirements. -

    -

    -2) Correct all the places, where a correct allocator object is available -through the get_allocator() call but default Allocator() gets passed instead. -

    -

    4. Code sample.

    -

    -Let's suppose that the following memory pool is available: -

    -
    class mem_pool {
-      // ...
-      void* allocate(size_t size);
-      void deallocate(void* ptr, size_t size);
-};
-
    -

    -So the following allocator can be implemented via this pool: -

    -
    class stl_allocator {
-      mem_pool& pool;
-
- public:
-      explicit stl_allocator(mem_pool& mp) : pool(mp) {}
-      stl_allocator(const stl_allocator& sa) : pool(sa.pool) {}
-      template <class U>
-      stl_allocator(const stl_allocator<U>& sa)  : pool(sa.get_pool()) {}
-      ~stl_allocator() {}
-
-      pointer allocate(size_type n, std::allocator<void>::const_pointer = 0)
-      {
-       return (n!=0) ? static_cast<pointer>(pool.allocate(n*sizeof(T))) : 0;
-      }
-
-      void deallocate(pointer p, size_type n)
-      {
-       if (n!=0) pool.deallocate(p, n*sizeof(T));
-      }
-
-      // ...
-};
-
    -

    -Then the following code works well on some implementations and doesn't work on -another: -

    -
    typedef basic_string<char, char_traits<char>, stl_allocator<char> > 
-  tl_string;
-mem_pool mp;
-tl_string s1("abc", stl_allocator<int>(mp));
-printf("(%s)\n", ("def"+s1).c_str());
-
    -

    -In particular, on some implementations the code can't be compiled without -default stl_allocator() constructor. -

    -

    -The obvious way to solve the compile-time problems is to intentionally define -a NULL pointer dereferencing default constructor -

    -
    stl_allocator() : pool(*static_cast<mem_pool*>(0)) {}
-
    -

    -in a hope that it will not be called. The problem is that it really gets -called by operator+(const char*, const string&) under the current 21.3.7.1p2 -wording. -

    - - -

    Proposed resolution:

    -

    -

    - - -

    Rationale:

    -

    -Recommend NAD. operator+() with string already requires the desired -semantics of copying the allocator from one of the strings (lhs when there is a choice). -

    - - - - - -
    -

    569. Postcondition for basic_ios::clear(iostate) incorrectly stated

    -

    Section: 27.4.4.3 [iostate.flags] Status: Dup - Submitter: Seungbeom Kim Date: 2006-03-10

    -

    View all other issues in [iostate.flags].

    -

    View all issues with Dup status.

    -

    Duplicate of: 272

    -

    Discussion:

    -

    -Section: 27.4.4.3 [lib.iostate.flags] -

    -

    -Paragraph 4 says: -

    -
    -
    void clear(iostate state = goodbit);
-
    -

    -Postcondition: If rdbuf()!=0 then state == rdstate(); -otherwise rdstate()==state|ios_base::badbit. -

    -
    - -

    -The postcondition "rdstate()==state|ios_base::badbit" is parsed as -"(rdstate()==state)|ios_base::badbit", which is probably what the -committee meant. -

    - - - - -

    Rationale:

    - - - - - - -
    -

    570. Request adding additional explicit specializations of char_traits

    -

    Section: 21.1 [char.traits] Status: NAD - Submitter: Jack Reeves Date: 2006-04-06

    -

    View all other issues in [char.traits].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    -Currently, the Standard Library specifies only a declaration for template class -char_traits<> and requires the implementation provide two explicit -specializations: char_traits<char> and char_traits<wchar_t>. I feel the Standard -should require explicit specializations for all built-in character types, i.e. -char, wchar_t, unsigned char, and signed char. -

    -

    -I have put together a paper -(N1985) -that describes this in more detail and -includes all the necessary wording. -

    -

    [ -Portland: Jack will rewrite -N1985 -to propose a primary template that will work with other integral types. -]

    - -

    [ -Toronto: issue has grown with addition of char16_t and char32_t. -]

    - - -

    [ -post Bellevue: -]

    - - -
    -

    -We suggest that Jack be asked about the status of his paper, and if it -is not forthcoming, the work-item be assigned to someone else. If no one -steps forward to do the paper before the next meeting, we propose to -make this NAD without further discussion. We leave this Open for now, -but our recommendation is NAD. -

    -

    -Note: the issue statement should be updated, as the Toronto comment has -already been resolved. E.g., char_traits specializations for char16_t -and char32_t are now in the working paper. -

    -
    - -

    [ -Sophia Antipolis: -]

    - - -
    -Nobody has submitted the requested paper, so we move to NAD, as suggested by the decision at the last meeting. -
    - - -

    Proposed resolution:

    - - - - - -
    -

    571. Update C90 references to C99?

    -

    Section: 1.2 [intro.refs] Status: NAD Editorial - Submitter: Beman Dawes Date: 2006-04-08

    -

    View all other issues in [intro.refs].

    -

    View all issues with NAD Editorial status.

    -

    Discussion:

    -

    -1.2 Normative references [intro.refs] of the WP currently refers to ISO/IEC -9899:1990, Programming languages - C. Should that be changed to ISO/IEC -9899:1999? -

    -

    -What impact does this have on the library? -

    - - -

    Proposed resolution:

    -

    -In 1.2/1 [intro.refs] of the WP, change: -

    -
    -
      -
    • ISO/IEC 9899:19901999 + TC1 + TC2, Programming languages - C
      • -
    -
    - - - -

    Rationale:

    -Recommend NAD, fixed editorially. - - - - - -
    -

    572. Oops, we gave 507 WP status

    -

    Section: 26.4 [rand], TR1 5.1 [tr.rand] Status: NAD - Submitter: Howard Hinnant Date: 2006-04-11

    -

    View all other issues in [rand].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    -In Berlin, as a working group, we voted in favor of N1932 which makes issue 507 moot: -variate_generator has been eliminated. Then in full committee we voted to give -this issue WP status (mistakenly). -

    - - -

    Proposed resolution:

    -

    -Strike the proposed resolution of issue 507. -

    -

    [ -post-Portland: Walter and Howard recommend NAD. The proposed resolution of 507 no longer -exists in the current WD. -]

    - - - -

    Rationale:

    -

    -NAD. Will be moot once -N2135 -is adopted. -

    - - - - - -
    -

    579. erase(iterator) for unordered containers should not return an iterator

    -

    Section: 23.1.5 [unord.req] Status: NAD - Submitter: Joaquín M López Muñoz Date: 2006-06-13

    -

    View other active issues in [unord.req].

    -

    View all other issues in [unord.req].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    -See -N2023 -for full discussion. -

    - - -

    Proposed resolution:

    -

    -Option 1: -

    - -

    -The problem can be eliminated by omitting the requirement that a.erase(q) return an -iterator. This is, however, in contrast with the equivalent requirements for other -standard containers. -

    - -

    -Option 2: -

    - -

    -a.erase(q) can be made to compute the next iterator only when explicitly requested: -the technique consists in returning a proxy object implicitly convertible to iterator, so -that -

    - -
    iterator q1=a.erase(q);
-
    - -

    -works as expected, while -

    - -
    a.erase(q);
-
    - -

    -does not ever invoke the conversion-to-iterator operator, thus avoiding the associated -computation. To allow this technique, some sections of TR1 along the line "return value -is an iterator..." should be changed to "return value is an unspecified object implicitly -convertible to an iterator..." Although this trick is expected to work transparently, it can -have some collateral effects when the expression a.erase(q) is used inside generic -code. -

    - - - -

    Rationale:

    -

    -N2023 -was discussed in Portland and the consensus was that there appears to be -no need for either change proposed in the paper. The consensus opinion -was that since the iterator could serve as its own proxy, there appears -to be no need for the change. In general, "converts to" is undesirable -because it interferes with template matching. -

    - -

    -Post Toronto: There does not at this time appear to be consensus with the Portland consensus. -

    - -

    [ -Bellevue: -]

    - - -
    -The Bellevue review of this issue reached consensus with the Portland -consensus, in contravention of the Toronto non-consensus. Common -implementations have the iterator readily available, and most common -uses depend on the iterator being returned. -
    - - - - - - -
    -

    583. div() for unsigned integral types

    -

    Section: 26.7 [c.math] Status: NAD - Submitter: Beman Dawes Date: 2006-06-15

    -

    View all other issues in [c.math].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    -There is no div() function for unsigned integer types. -

    -

    -There are several possible resolutions. The simplest one is noted below. Other -possibilities include a templated solution. -

    - - -

    Proposed resolution:

    -

    -Add to 26.7 [lib.c.math] paragraph 8: -

    - -
    struct udiv_t div(unsigned, unsigned);
-struct uldiv_t div(unsigned long, unsigned long);
-struct ulldiv_t div(unsigned long long, unsigned long long);
-
    - - - -

    Rationale:

    -Toronto: C99 does not have these unsigned versions because -the signed version exist just to define the implementation-defined behavior -of signed integer division. Unsigned integer division has no implementation-defined -behavior and thus does not need this treatment. - - - - - -
    -

    584. missing int pow(int,int) functionality

    -

    Section: 26.7 [c.math] Status: NAD - Submitter: Beman Dawes Date: 2006-06-15

    -

    View all other issues in [c.math].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    -There is no pow() function for any integral type. -

    - - -

    Proposed resolution:

    -

    -Add something like: -

    - -
    template< typename T>
-T power( T x, int n );
-// requires: n >=0
-
    - - -

    Rationale:

    -Toronto: We already have double pow(integral, integral) from 26.7 [c.math] p11. - - - - - -
    -

    587. iststream ctor missing description

    -

    Section: D.7.2.1 [depr.istrstream.cons] Status: NAD Editorial - Submitter: Martin Sebor Date: 2006-06-22

    -

    View all issues with NAD Editorial status.

    -

    Discussion:

    -

    - -The iststream(char*, streamsize) ctor is in the class -synopsis in D.7.2 but its signature is missing in the description -below (in D.7.2.1). - -

    - - -

    Proposed resolution:

    -

    - -This seems like a simple editorial issue and the missing signature can -be added to the one for const char* in paragraph 2. - -

    - -

    [ -post Oxford: Noted that it is already fixed in -N2284 -]

    - - - - - - -
    -

    590. Type traits implementation latitude should be removed for C++0x

    -

    Section: 20.5 [meta], TR1 4.9 [tr.meta.req] Status: NAD Editorial - Submitter: Beman Dawes Date: 2006-08-10

    -

    View all other issues in [meta].

    -

    View all issues with NAD Editorial status.

    -

    Discussion:

    -

    -20.4.9 [lib.meta.req], Implementation requirements, provides latitude for type -traits implementers that is not needed in C++0x. It includes the wording: -

    - -

    -[Note: the latitude granted to implementers in this clause is temporary, -and is expected to be removed in future revisions of this document. -- end note] -

    - -

    -Note: -N2157: Minor Modifications to the type traits Wording -also has the intent of removing this wording from the WP. -

    - - - -

    Proposed resolution:

    -

    -Remove 20.4.9 [lib.meta.req] in its entirety from the WP. -

    - -

    [ -post-Oxford: Recommend NAD Editorial. This resolution is now in the -current working draft. -]

    - - - - - - - -
    -

    591. Misleading "built-in

    -

    Section: 18.2.1.2 [numeric.limits.members] Status: NAD Editorial - Submitter: whyglinux Date: 2006-08-08

    -

    View all other issues in [numeric.limits.members].

    -

    View all issues with NAD Editorial status.

    -

    Discussion:

    -

    -18.2.1.2 numeric_limits members [lib.numeric.limits.members] -Paragraph 7: -

    -

    -"For built-in integer types, the number of non-sign bits in the -representation." -

    - -

    -26.1 Numeric type requirements [lib.numeric.requirements] -Footnote: -

    - -

    -"In other words, value types. These include built-in arithmetic types, -pointers, the library class complex, and instantiations of valarray for -value types." -

    - -

    -Integer types (which are bool, char, wchar_t, and the signed and -unsigned integer types) and arithmetic types (which are integer and -floating types) are all built-in types and thus there are no -non-built-in (that is, user-defined) integer or arithmetic types. Since -the redundant "built-in" in the above 2 sentences can mislead that -there may be built-in or user-defined integer and arithmetic types -(which is not correct), the "built-in" should be removed. -

    - - -

    Proposed resolution:

    -

    -18.2.1.2 numeric_limits members [lib.numeric.limits.members] -Paragraph 7: -

    -

    -"For built-in integer types, the number of non-sign bits in the -representation." -

    - -

    -26.1 Numeric type requirements [lib.numeric.requirements] -Footnote: -

    - -

    -"In other words, value types. These include built-in arithmetic types, -pointers, the library class complex, and instantiations of valarray for -value types." -

    - - -

    Rationale:

    -

    -Recommend NAD / Editorial. The proposed resolution is accepted as editorial. -

    - - - - - -
    -

    592. Incorrect treatment of rdbuf()->close() return type

    -

    Section: 27.8.1.9 [ifstream.members] Status: NAD Editorial - Submitter: Christopher Kohlhoff Date: 2006-08-17

    -

    View all other issues in [ifstream.members].

    -

    View all issues with NAD Editorial status.

    -

    Discussion:

    -

    -I just spotted a minor problem in 27.8.1.7 -[lib.ifstream.members] para 4 and also 27.8.1.13 -[lib.fstream.members] para 4. In both places it says: -

    -
    -
    void close();
-
    -

    -Effects: Calls rdbuf()->close() and, if that function returns false, ... -

    -
    -

    -However, basic_filebuf::close() (27.8.1.2) returns a pointer to the -filebuf on success, null on failure, so I think it is meant to -say "if that function returns a null pointer". Oddly, it is -correct for basic_ofstream. -

    - - -

    Proposed resolution:

    -

    -Change 27.8.1.9 [ifstream.members], p5: -

    - -

    -Effects: Calls rdbuf()->close() and, if that function -fails (returns false a null pointer), -calls setstate(failbit) (which may throw ios_base::failure -(27.4.4.3)). -

    - -

    -Change 27.8.1.17 [fstream.members], p5: -

    - -

    -Effects: Calls rdbuf()->close() and, if that function -fails (returns false a null pointer), -calls setstate(failbit) (which may throw ios_base::failure -(27.4.4.3)). -

    - - - -

    [ -Kona (2007): Proposed Disposition: NAD, Editorial -]

    - - - - - -
    -

    594. Disadvantages of defining Swappable in terms of CopyConstructible and Assignable

    -

    Section: 20.1.1 [utility.arg.requirements] Status: Pending NAD Editorial - Submitter: Niels Dekker Date: 2006-11-02

    -

    View other active issues in [utility.arg.requirements].

    -

    View all other issues in [utility.arg.requirements].

    -

    View all issues with Pending NAD Editorial status.

    -

    Discussion:

    -

    -It seems undesirable to define the Swappable requirement in terms of -CopyConstructible and Assignable requirements. And likewise, once the -MoveConstructible and MoveAssignable requirements (N1860) have made it -into the Working Draft, it seems undesirable to define the Swappable -requirement in terms of those requirements. Instead, it appears -preferable to have the Swappable requirement defined exclusively in -terms of the existence of an appropriate swap function. -

    -

    -Section 20.1.4 [lib.swappable] of the current Working Draft (N2009) -says: -

    -

    -The Swappable requirement is met by satisfying one or more of the -following conditions:

    -
      -
    • -T is Swappable if T satisfies the CopyConstructible requirements -(20.1.3) and the Assignable requirements (23.1); -
      • -
    • -T is Swappable if a namespace scope function named swap exists in the -same namespace as the definition of T, such that the expression -swap(t,u) is valid and has the semantics described in Table 33. -
      • -
    -
    -I can think of three disadvantages of this definition: -
      -
    1. -If a client's type T satisfies the first condition (T is both -CopyConstructible and Assignable), the client cannot stop T from -satisfying the Swappable requirement without stopping T from -satisfying the first condition. -

      -A client might want to stop T from satisfying the Swappable -requirement, because swapping by means of copy construction and -assignment might throw an exception, and she might find a throwing -swap unacceptable for her type. On the other hand, she might not feel -the need to fully implement her own swap function for this type. In -this case she would want to be able to simply prevent algorithms that -would swap objects of type T from being used, e.g., by declaring a -swap function for T, and leaving this function purposely undefined. -This would trigger a link error, if an attempt would be made to use -such an algorithm for this type. For most standard library -implementations, this practice would indeed have the effect of -stopping T from satisfying the Swappable requirement. -

      -
      2. -
    2. -A client's type T that does not satisfy the first condition can not be -made Swappable by providing a specialization of std::swap for T. -

      -While I'm aware about the fact that people have mixed feelings about -providing a specialization of std::swap, it is well-defined to do so. -It sounds rather counter-intuitive to say that T is not Swappable, if -it has a valid and semantically correct specialization of std::swap. -Also in practice, providing such a specialization will have the same -effect as satisfying the Swappable requirement. -

      -
      3. -
    3. -For a client's type T that satisfies both conditions of the Swappable -requirement, it is not specified which of the two conditions prevails. -After reading section 20.1.4 [lib.swappable], one might wonder whether -objects of T will be swapped by doing copy construction and -assignments, or by calling the swap function of T. -

      -I'm aware that the intention of the Draft is to prefer calling the -swap function of T over doing copy construction and assignments. Still -in my opinion, it would be better to make this clear in the wording of -the definition of Swappable. -

      -
      4. -
    -

    -I would like to have the Swappable requirement defined in such a way -that the following code fragment will correctly swap two objects of a -type T, if and only if T is Swappable: -

    -
       using std::swap;
-   swap(t, u);  // t and u are of type T.
-
    -

    -This is also the way Scott Meyers recommends calling a swap function, -in Effective C++, Third Edition, item 25. -

    -

    -Most aspects of this issue have been dealt with in a discussion on -comp.std.c++ about the Swappable requirement, from 13 September to 4 -October 2006, including valuable input by David Abrahams, Pete Becker, -Greg Herlihy, Howard Hinnant and others. -

    - -

    Proposed resolution:

    -

    -Change section 20.1.4 [lib.swappable] as follows: -

    -

    -The Swappable requirement is met by satisfying -one or more of the following conditions: -the following condition:

    -
      - -
    • -T is Swappable if T satisfies the CopyConstructible requirements -(20.1.3) and the Assignable requirements (23.1); -
      • -
    • - -T is Swappable if a namespace scope function named swap exists in the -same namespace as the definition of T, such that the expression -swap(t,u) is valid and has the semantics described in Table 33. - -T is Swappable if an unqualified function call swap(t,u) is valid -within the namespace std, and has the semantics described in Table 33. -
      • -
    -
    - - -

    Rationale:

    -

    -Recommend NAD. Concepts, specifically -N2082 -and -N2084, -will essentially rewrite this section and provide the desired semantics. -

    - - - - - -
    -

    615. Inconsistencies in Section 21.4

    -

    Section: 21.5 [c.strings] Status: NAD Editorial - Submitter: Bo Persson Date: 2006-12-11

    -

    View all other issues in [c.strings].

    -

    View all issues with NAD Editorial status.

    -

    Discussion:

    -

    -In the current draft N2134, 21.4/1 says -

    -

    -"Tables 59,228) 60, 61, 62,and 63 229) 230) describe headers <cctype>, -<cwctype>, <cstring>, <cwchar>, and <cstdlib> (character conversions), -respectively." -

    -

    -Here footnote 229 applies to table 62, not table 63. -

    -

    -Also, footnote 230 lists the new functions in table 63, "atoll, strtoll, -strtoull, strtof, and strtold added by TR1". However, strtof is not present -in table 63. -

    - - -

    Proposed resolution:

    -

    -

    - - -

    Rationale:

    -

    -Recommend NAD, editorial. Send to Pete. -

    - - - - - -
    -

    625. mixed up Effects and Returns clauses

    -

    Section: 17 [library] Status: Pending NAD Editorial - Submitter: Martin Sebor Date: 2007-01-20

    -

    View all other issues in [library].

    -

    View all issues with Pending NAD Editorial status.

    -

    Discussion:

    -

    - -Many member functions of basic_string are overloaded, -with some of the overloads taking a string argument, -others value_type*, others size_type, and -others still iterators. Often, the requirements on one of -the overloads are expressed in the form of Effects, -Throws, and in the Working Paper -(N2134) -also Remark clauses, while those on the rest of the overloads -via a reference to this overload and using a Returns clause. - -

    -

    - -The difference between the two forms of specification is that per -17.3.1.3 [structure.specifications], p3, an Effects clause specifies -"actions performed by the functions," i.e., its observable -effects, while a Returns clause is "a description of the -return value(s) of a function" that does not impose any -requirements on the function's observable effects. - -

    -

    - -Since only Notes are explicitly defined to be informative and -all other paragraphs are explicitly defined to be normative, like -Effects and Returns, the new Remark clauses also -impose normative requirements. - -

    -

    - -So by this strict reading of the standard there are some member -functions of basic_string that are required to throw an -exception under some conditions or use specific traits members while -many other otherwise equivalent overloads, while obliged to return the -same values, aren't required to follow the exact same requirements -with regards to the observable effects. - -

    -

    - -Here's an example of this problem that was precipitated by the change -from informative Notes to normative Remarks (presumably made to -address 424): - -

    -

    - -In the Working Paper, find(string, size_type) contains a -Remark clause (which is just a Note in the current -standard) requiring it to use traits::eq(). - -

    -

    - -find(const charT *s, size_type pos) is specified to -return find(string(s), pos) by a Returns clause -and so it is not required to use traits::eq(). However, -the Working Paper has replaced the original informative Note -about the function using traits::length() with a -normative requirement in the form of a Remark. Calling -traits::length() may be suboptimal, for example when the -argument is a very long array whose initial substring doesn't appear -anywhere in *this. - -

    -

    - -Here's another similar example, one that existed even prior to the -introduction of Remarks: - -

    -

    - - insert(size_type pos, string, size_type, size_type) is -required to throw out_of_range if pos > -size(). - -

    -

    - -insert(size_type pos, string str) is specified to return -insert(pos, str, 0, npos) by a Returns clause and -so its effects when pos > size() are strictly speaking -unspecified. - - -

    - -I believe a careful review of the current Effects and -Returns clauses is needed in order to identify all such -problematic cases. In addition, a review of the Working Paper should -be done to make sure that the newly introduced normative Remark -clauses do not impose any undesirable normative requirements in place -of the original informative Notes. - -

    -

    [ -Batavia: Alan and Pete to work. -]

    - - -

    [ -Bellevue: Marked as NAD Editorial. -]

    - - -

    [ -Post-Sophia Antipolis: Martin indicates there is still work to be done on this issue. -Reopened. -]

    - - - - -

    Proposed resolution:

    -

    -

    - - - - - -
    -

    626. new Remark clauses not documented

    -

    Section: 17.3.1.3 [structure.specifications] Status: NAD Editorial - Submitter: Martin Sebor Date: 2007-01-20

    -

    View all other issues in [structure.specifications].

    -

    View all issues with NAD Editorial status.

    -

    Discussion:

    -

    - -The Remark clauses newly introduced into the Working Paper -(N2134) -are not mentioned in 17.3.1.3 [structure.specifications] where we list the -meaning of Effects, Requires, and other clauses (with -the exception of Notes which are documented as informative in -17.3.1.1 [structure.summary], p2, and which they replace in many cases). - -

    -

    - -Propose add a bullet for Remarks along with a brief description. - -

    -

    [ -Batavia: Alan and Pete to work. -]

    - - -

    [ -Bellevue: Already resolved in current working paper. -]

    - - - -

    Proposed resolution:

    -

    -

    - - - - - -
    -

    627. Low memory and exceptions

    -

    Section: 18.5.1.1 [new.delete.single] Status: NAD - Submitter: P.J. Plauger Date: 2007-01-23

    -

    View all other issues in [new.delete.single].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    -I recognize the need for nothrow guarantees in the exception reporting -mechanism, but I strongly believe that implementors also need an escape hatch -when memory gets really low. (Like, there's not enough heap to construct and -copy exception objects, or not enough stack to process the throw.) I'd like to -think we can put this escape hatch in 18.5.1.1 [new.delete.single], -operator new, but I'm not sure how to do it. We need more than a -footnote, but the wording has to be a bit vague. The idea is that if -new can't allocate something sufficiently small, it has the right to -abort/call terminate/call unexpected. -

    - -

    [ -Bellevue: NAD. 1.4p2 specifies a program must behave correctly "within -its resource limits", so no further escape hatch is necessary. -]

    - - - -

    Proposed resolution:

    -

    -

    - - - - - -
    -

    633. Return clause mentions undefined "type()"

    -

    Section: 20.6.15.2.5 [func.wrap.func.targ] Status: NAD Editorial - Submitter: Daniel Krügler Date: 2007-02-03

    -

    View all issues with NAD Editorial status.

    -

    Discussion:

    -

    -20.6.15.2.5 [func.wrap.func.targ], p4 says: -

    -

    -Returns: If type() == typeid(T), a pointer to the stored -function target; otherwise a null pointer. -

    - -
      -
    1. -There exists neither a type, a typedef type, nor member -function type() in class template function nor in the global or -std namespace. -
      2. -
    2. -Assuming that type should have been target_type(), -this description would lead to false results, if T = cv -void due to returns clause 20.6.15.2.5 [func.wrap.func.targ], p1. -
      3. -
    - - - -

    Proposed resolution:

    -

    -Change 20.6.15.2.5 [func.wrap.func.targ], p4: -

    - -

    -Returns: If type() target_type() == typeid(T) && typeid(T) != -typeid(void), a pointer to the stored function target; -otherwise a null pointer. -

    - -

    [ -Pete: Agreed. It's editorial, so I'll fix it. -]

    - - - - - - - -
    -

    636. 26.5.2.3 valarray::operator[]

    -

    Section: 26.5.2.3 [valarray.access] Status: NAD Editorial - Submitter: Bo Persson Date: 2007-02-11

    -

    View all other issues in [valarray.access].

    -

    View all issues with NAD Editorial status.

    -

    Discussion:

    -

    -The signature of the const operator[] has been changed to return a const -reference. -

    -

    -The description in paragraph 1 still says that the operator returns by -value. -

    -

    [ -Pete recommends editorial fix. -]

    - - - -

    Proposed resolution:

    -

    -

    - - - - - -
    -

    637. [c.math]/10 inconsistent return values

    -

    Section: 26.7 [c.math] Status: NAD Editorial - Submitter: Bo Persson Date: 2007-02-13

    -

    View all other issues in [c.math].

    -

    View all issues with NAD Editorial status.

    -

    Discussion:

    -

    -26.7 [c.math], paragraph 10 has long lists of added signatures for float and long double -functions. All the signatures have float/long double return values, which is -inconsistent with some of the double functions they are supposed to -overload. -

    - - -

    Proposed resolution:

    -

    -Change 26.7 [c.math], paragraph 10, -

    - -
    float int ilogb(float);
-float long lrint(float);
-float long lround(float);
-float long long llrint(float);
-float long long llround(float);
-
-long double int ilogb(long double);
-long double long lrint(long double);
-long double long lround(long double);
-long double long long llrint(long double);
-long double long long llround(long double);
-
    - - - - - -
    -

    639. Still problems with exceptions during streambuf IO

    -

    Section: 27.6.1.2.3 [istream::extractors], 27.6.2.6.3 [ostream.inserters] Status: NAD - Submitter: Daniel Krügler Date: 2007-02-17

    -

    View all other issues in [istream::extractors].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    -There already exist two active DR's for the wording of 27.6.1.2.3 [istream::extractors]/13 -from 14882:2003(E), namely 64 and 413. -

    - -

    -Even with these proposed corrections, already maintained in N2134, -I have the feeling, that the current wording does still not properly -handle the "exceptional" situation. The combination of para 14 -

    - -

    -"[..] Characters are extracted and inserted until -any of the following occurs: -

    -

    -[..] -

    -

    -- an exception occurs (in which case the exception is caught)." -

    - -

    -and 15 -

    - -

    -"If the function inserts no characters, it calls setstate(failbit), -which -may throw ios_base::failure (27.4.4.3). If it inserted no characters -because it caught an exception thrown while extracting characters -from *this and failbit is on in exceptions() (27.4.4.3), then the -caught -exception is rethrown." -

    - -

    -both in N2134 seems to imply that any exception, which occurs -*after* at least one character has been inserted is caught and lost -for -ever. It seems that even if failbit is on in exceptions() rethrow is -not -allowed due to the wording "If it inserted no characters because it -caught an exception thrown while extracting". -

    - -

    -Is this behaviour by design? -

    - -

    -I would like to add that its output counterpart in 27.6.2.6.3 [ostream.inserters]/7-9 -(also -N2134) does not demonstrate such an exception-loss-behaviour. -On the other side, I wonder concerning several subtle differences -compared to input:: -

    -

    -1) Paragraph 8 says at its end: -

    - -

    -"- an exception occurs while getting a character from sb." -

    - -

    -Note that there is nothing mentioned which would imply that such -an exception will be caught compared to 27.6.1.2.3 [istream::extractors]/14. -

    - -

    -2) Paragraph 9 says: -

    - -

    -"If the function inserts no characters, it calls setstate(failbit) -(which -may throw ios_base::failure (27.4.4.3)). If an exception was thrown -while extracting a character, the function sets failbit in error -state, -and if failbit is on in exceptions() the caught exception is -rethrown." -

    - -

    -The sentence starting with "If an exception was thrown" seems to -imply that such an exception *should* be caught before. -

    - - -

    Proposed resolution:

    -

    -(a) In 27.6.1.2.3 [istream::extractors]/15 (N2134) change the sentence -

    - -

    -If the function inserts no characters, it calls -setstate(failbit), which may throw ios_base::failure -(27.4.4.3). If it inserted no characters because it caught an -exception thrown while extracting characters from *this -an exception was thrown while extracting a character from -*this, the function sets failbit in error state, -and failbit is on in exceptions() (27.4.4.3), then the -caught exception is rethrown. -

    - -

    -(b) In 27.6.2.6.3 [ostream.inserters]/8 (N2134) change the sentence: -

    - -
    -

    -Gets characters from sb and inserts them in *this. -Characters are read from sb and inserted until any of the -following occurs: -

    -
      -
    • end-of-file occurs on the input sequence;
      • -
    • inserting in the output sequence fails (in which case the character to be inserted is not extracted);
      • -
    • an exception occurs while getting a character from sb (in which -case the exception is caught).
      • -
    -
    - - - -

    Rationale:

    -This extractor is described as a formatted input function so the -exception behavior is already specified. There is additional behavior -described in this section that applies to the case in which failbit is -set. This doesn't contradict the usual exception behavior for formatted -input functions because that applies to the case in which badbit is set. - - - - - -
    -

    641. Editorial fix for 27.6.4 (N2134)

    -

    Section: 27.6.4 [ext.manip] Status: NAD Editorial - Submitter: Daniel Krügler Date: 2007-02-18

    -

    View other active issues in [ext.manip].

    -

    View all other issues in [ext.manip].

    -

    View all issues with NAD Editorial status.

    -

    Discussion:

    -

    -The function f in para 4 (27.6.4 [ext.manip]) references an unknown strm -in the following line: -

    - -
    mg.get(Iter(str.rdbuf()), Iter(), intl, strm, err, mon);
-
    - - -

    Proposed resolution:

    -

    -Change 27.6.4 [ext.manip], p4: -

    - -
    mg.get(Iter(str.rdbuf()), Iter(), intl, strm, err, mon);
-
    - -

    [ -Oxford: Editorial. -]

    - - - - - - - -
    -

    642. Invalidated fstream footnotes in N2134

    -

    Section: 27.8.1.9 [ifstream.members], 27.8.1.13 [ofstream.members] Status: NAD Editorial - Submitter: Daniel Krügler Date: 2007-02-20

    -

    View all other issues in [ifstream.members].

    -

    View all issues with NAD Editorial status.

    -

    Discussion:

    -

    -The standard wording of N2134 has extended the 14882:2003(E) -wording for the ifstream/ofstream/fstream open function to fix -a long standing problem, see 409. -

    - -

    -Now it's properly written as -

    - -

    -"If that function does not return a null pointer calls clear(), -otherwise -calls setstate(failbit)[..]" -

    - -

    -instead of the previous -

    - -

    -"If that function returns a null pointer, calls setstate(failbit)[..] -

    - -

    -While the old footnotes saying -

    - -

    -"A successful open does not change the error state." -

    - -

    -where correct and important, they are invalid now for ifstream and -ofstream (because clear *does* indeed modify the error state) and -should be removed (Interestingly fstream itself never had these, -although -they where needed for that time). -

    - - -

    Proposed resolution:

    -

    -In 27.8.1.9 [ifstream.members], remove footnote: -

    - -

    -334) A successful open does not change the error state. -

    - -

    -In 27.8.1.13 [ofstream.members], remove footnote: -

    - -

    -335) A successful open does not change the error state. -

    - - - - - - -
    -

    645. Missing members in match_results

    -

    Section: 28.10 [re.results] Status: NAD Editorial - Submitter: Daniel Krügler Date: 2007-02-26

    -

    View all other issues in [re.results].

    -

    View all issues with NAD Editorial status.

    -

    Discussion:

    -

    -According to the description given in 28.10 [re.results]/2 the class template -match_results "shall satisfy the requirements of a Sequence, [..], -except that only operations defined for const-qualified Sequences -are supported". -Comparing the provided operations from 28.10 [re.results]/3 with the -sequence/container tables 80 and 81 one recognizes the following -missing operations: -

    - -

    -1) The members -

    - -
    const_iterator rbegin() const;
-const_iterator rend() const;
-
    - -

    -should exists because 23.1/10 demands these for containers -(all sequences are containers) which support bidirectional -iterators. Aren't these supported by match_result? This is not -explicitely expressed, but it's somewhat implied by two arguments: -

    -

    -(a) Several typedefs delegate to -iterator_traits<BidirectionalIterator>. -

    -

    -(b) The existence of const_reference operator[](size_type n) const -implies even random-access iteration. -I also suggest, that match_result should explicitly mention, -which minimum iterator category is supported and if this does -not include random-access the existence of operator[] is -somewhat questionable. -

    -

    -2) The new "convenience" members -

    -
    const_iterator cbegin() const;
-const_iterator cend() const;
-const_iterator crbegin() const;
-const_iterator crend() const;
-
    -

    -should be added according to tables 80/81. -

    - - -

    Proposed resolution:

    -

    -Add the following members to the match_results synopsis after end() in 28.10 [re.results] -para 3: -

    - -
    const_iterator cbegin() const; 
-const_iterator cend() const;
-
    - -

    -In section 28.10.3 [re.results.acc] change: -

    - -
    -
    const_iterator begin() const;
-const_iterator cbegin() const;
-
    -
    -

    --7- Returns: A starting iterator that enumerates over all the sub-expressions stored in *this. -

    -
    - -
    const_iterator end() const;
-const_iterator cend() const;
-
    -
    -

    --8- Returns: A terminating iterator that enumerates over all the sub-expressions stored in *this. -

    -
    -
    - - - -

    [ -Kona (2007): Voted to adopt proposed wording in -N2409 -except removing the entry in the table container requirements. Moved to Review. -]

    - - -

    [ -Bellevue: Proposed wording now in the WP. -]

    - - - - - -
    -

    647. Inconsistent regex_search params

    -

    Section: 28.11.3 [re.alg.search] Status: NAD Editorial - Submitter: Daniel Krügler Date: 2007-02-26

    -

    View all issues with NAD Editorial status.

    -

    Discussion:

    -

    -28.11.3 [re.alg.search]/5 declares -

    - -
    template <class iterator, class charT, class traits>
-bool regex_search(iterator first, iterator last,
-                  const basic_regex<charT, traits>& e,
-                  regex_constants::match_flag_type flags =
-                      regex_constants::match_default);
-
    - -

    -where it's not explained, which iterator category -the parameter iterator belongs to. This is inconsistent -to the preceding declaration in the synopsis section -28.4 [re.syn], which says: -

    - -
    template <class BidirectionalIterator, class charT, class traits>
-bool regex_search(BidirectionalIterator first, BidirectionalIterator last,
-                  const basic_regex<charT, traits>& e,
-                  regex_constants::match_flag_type flags =
-                      regex_constants::match_default);
-
    - - -

    Proposed resolution:

    -

    -In 28.11.3 [re.alg.search]/5 replace all three occurences of param "iterator" with -"BidirectionalIterator" -

    - -
    template <class iterator BidirectionalIterator, class charT, class traits>
-  bool regex_search(iterator BidirectionalIterator first, iterator BidirectionalIterator last, 
-                    const basic_regex<charT, traits>& e, 
-                    regex_constants::match_flag_type flags = 
-                      regex_constants::match_default);
-
    -

    --6- Effects: Behaves "as if" by constructing an object what of -type match_results<iterator -BidirectionalIterator> and then returning the result -of regex_search(first, last, what, e, flags). -

    -
    - - -

    Rationale:

    -Applied to working paper while issue was still in New status. - - - - - -
    -

    648. regex_iterator c'tor needs clarification/editorial fix

    -

    Section: 28.12.1.1 [re.regiter.cnstr] Status: NAD Editorial - Submitter: Daniel Krügler Date: 2007-03-03

    -

    View all issues with NAD Editorial status.

    -

    Discussion:

    -

    -In 28.12.1.1 [re.regiter.cnstr]/2 the effects paragraph starts with: -

    - -
    -

    -Effects: Initializes begin and end to point to the beginning and the -end of the target sequence, sets pregex to &re, sets flags to f,[..] -

    - -

    -There are two issues with this description: -

    - -
      -
    1. -The meaning of very first part of this quote is unclear, because -there is no target sequence provided, instead there are given two -parameters a and b, both of type BidirectionalIterator. The mentioned -part does not explain what a and b represent. -
      2. -
    2. -There does not exist any parameter f, but instead a parameter -m in the constructor declaration, so this is actually an editorial -fix. -
      3. -
    - - -

    Proposed resolution:

    -

    -In 28.12.1.1 [re.regiter.cnstr]/2 change the above quoted part by -

    - -

    -Effects: Initializes begin and end to point to -the beginning and the end of the target sequence designated by the -iterator range [a, b), sets pregex to -&re, sets flags to f -m, then calls regex_search(begin, end, match, -*pregex, flags). If this call returns false the -constructor sets *this to the end-of-sequence iterator. -

    - - - - - -
    -

    649. Several typos in regex_token_iterator constructors

    -

    Section: 28.12.2.1 [re.tokiter.cnstr] Status: NAD Editorial - Submitter: Daniel Krügler Date: 2007-03-03

    -

    View all other issues in [re.tokiter.cnstr].

    -

    View all issues with NAD Editorial status.

    -

    Discussion:

    -

    -In 28.12.2.1 [re.tokiter.cnstr]/1+2 both the constructor declaration -and the following text shows some obvious typos: -

    -

    -1) The third constructor form is written as -

    -
    template <std::size_t N>
-  regex_token_iterator(BidirectionalIterator a, BidirectionalIterator b, 
-                       const regex_type& re, 
-                       const int (&submatches)[R], 
-                       regex_constants::match_flag_type m = 
-                         regex_constants::match_default);
-
    - -

    -where the dimensions of submatches are specified by an -unknown value R, which should be N. -

    -

    -2) Paragraph 2 of the same section says in its last sentence: -

    - -

    -The third constructor initializes the member subs to hold a -copy of the sequence of integer values pointed to by the iterator range -[&submatches, &submatches + R). -

    - -

    -where again R must be replaced by N. -

    - -

    -3) Paragraph 3 of the same section says in its first sentence: -

    - -

    -Each constructor then sets N to 0, and -position to position_iterator(a, b, re, f). -

    - -

    -where a non-existing parameter "f" is mentioned, which must be -replaced -by the parameter "m". -

    - - -

    Proposed resolution:

    -

    -Change 28.12.2.1 [re.tokiter.cnstr]/1: -

    -
    template <std::size_t N>
-  regex_token_iterator(BidirectionalIterator a, BidirectionalIterator b, 
-                       const regex_type& re, 
-                       const int (&submatches)[R N], 
-                       regex_constants::match_flag_type m = 
-                         regex_constants::match_default);
-
    - -

    -Change 28.12.2.1 [re.tokiter.cnstr]/2: -

    - -

    -Effects: The first constructor initializes the member -subs to hold the single value submatch. The second -constructor initializes the member subs to hold a copy of the -argument submatches. The third constructor initializes the -member subs to hold a copy of the sequence of integer values -pointed to by the iterator range [&submatches, &submatches + -R N). -

    - -

    -Change 28.12.2.1 [re.tokiter.cnstr]/3: -

    - -

    -Each constructor then sets N to 0, and -position to position_iterator(a, b, re, f -m). If position is not an end-of-sequence -iterator the constructor sets result to the address of the -current match. Otherwise if any of the values stored in subs is -equal to -1 the constructor sets *this to a suffix -iterator that points to the range [a, b), otherwise the -constructor sets *this to an end-of-sequence iterator. -

    - - - - - - -
    -

    653. Library reserved names

    -

    Section: 1.2 [intro.refs] Status: NAD - Submitter: Alisdair Meredith Date: 2007-03-08

    -

    View all other issues in [intro.refs].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    -

    -
    -

    -1.2 [intro.refs] Normative references -

    - -

    -The following standards contain provisions which, through reference in -this text, constitute provisions of this Interna- tional Standard. At -the time of publication, the editions indicated were valid. All -standards are subject to revision, and parties to agreements based on -this International Standard are encouraged to investigate the -possibility of applying the most recent editions of the standards -indicated below. Members of IEC and ISO maintain registers of currently -valid International Standards. -

    - -
      -
    • Ecma International, ECMAScript Language Specification, Standard -Ecma-262, third edition, 1999.
      • -
    • ISO/IEC 2382 (all parts), Information technology - Vocabulary
      • -
    • ISO/IEC 9899:1990, Programming languages - C
      • -
    • ISO/IEC 9899/Amd.1:1995, Programming languages - C, AMENDMENT 1: C -Integrity
      • -
    • ISO/IEC 9899:1999, Programming languages - C
      • -
    • ISO/IEC 9899:1999/Cor.1:2001 Programming languages - C
      • -
    • ISO/IEC 9899:1999/Cor.2:2004 Programming languages - C
      • -
    • ISO/IEC 9945:2003, Information Technology-Portable Operating System -Interface (POSIX)
      • -
    • ISO/IEC 10646-1:1993 Information technology - Universal Multiple-Octet -Coded Character Set (UCS) - Part 1: Architecture and Basic Multilingual -Plane
      • -
    -
    - -

    -I'm not sure how many of those reserve naming patterns that might affect -us, but I am equally sure I don't own a copy of any of these to check! -

    -

    -The point is to list the reserved naming patterns, rather than the -individual names themselves - although we may want to list C keywords -that are valid identifiers in C++ but likely to cause trouble in shared -headers (e.g. restrict) -

    - -

    [ -Kona (2007): Recommend NAD. No one has identified a specific defect, just the possibility of one. -]

    - - -

    [ -Post-Kona: Alisdair request Open. A good example of the problem was a -discussion of the system error proposal, where it was pointed out an all-caps -identifier starting with a capital E conflicted with reserved macro names for -both Posix and C. I had absolutely no idea of this rule, and suspect I was -not the only one in the room.
    -
    -Resolution will require someone with access to all the listed documents to -research their respective name reservation rules, or people with access to -specific documents add their rules to this issue until the list is complete. -]

    - - -

    [ -Bellevue: Wording is aleady present in various standards, and no-one has come forward with wording. -Suggest a formal paper rather than a defect report is the correct way to proceed. -]

    - - - - -

    Proposed resolution:

    - - - - - -
    -

    656. Typo in subtract_with_carry_engine declaration

    -

    Section: 26.4.2 [rand.synopsis] Status: NAD Editorial - Submitter: Daniel Krügler Date: 2007-03-08

    -

    View all other issues in [rand.synopsis].

    -

    View all issues with NAD Editorial status.

    -

    Discussion:

    -

    -26.4.2 [rand.synopsis] the header <random> synopsis -contains an unreasonable closing curly brace inside the -subtract_with_carry_engine declaration. -

    - - -

    Proposed resolution:

    -

    -Change the current declaration in 26.4.2 [rand.synopsis] -

    - -
    template <class UIntType, size_t w}, size_t s, size_t r>
-class subtract_with_carry_engine;
-
    - - -

    [ -Pete: Recommends editorial. -]

    - - - - - -
    -

    657. unclear requirement about header inclusion

    -

    Section: 17.4.2.1 [using.headers] Status: NAD - Submitter: Gennaro Prota Date: 2007-03-14

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    -17.4.2.1 [using.headers] states: -

    - -

    -A translation unit shall include a header only outside of any -external declaration or definition, [...] -

    - -

    -I see three problems with this requirement: -

    - -
      -

    1. The C++ standard doesn't define what an "external declaration" or -an "external definition" are (incidentally the C99 standard does, and -has a sentence very similar to the above regarding header inclusion). -

      -I think the intent is that the #include directive shall lexically -appear outside *any* declaration; instead, when the issue was pointed -out on comp.std.c++ at least one poster interpreted "external -declaration" as "declaration of an identifier with external linkage". -If this were the correct interpretation, then the two inclusions below -would be legal: -

      -
        // at global scope
-  static void f()
-  {
-# include <cstddef>
-  }
-
-  static void g()
-  {
-# include <stddef.h>
-  }
-
      -

      -(note that while the first example is unlikely to compile correctly, -the second one may well do) -

      2. - -

    2. as the sentence stands, violations will require a diagnostic; is -this the intent? It was pointed out on comp.std.c++ (by several -posters) that at least one way to ensure a diagnostic exists: -

      -

      - [If there is an actual file for each header,] one simple way - to implement this would be to insert a reserved identifier - such as __begin_header at the start of each standard header. - This reserved identifier would be ignored for all other - purposes, except that, at the appropriate point in phase 7, if - it is found inside an external definition, a diagnostic is - generated. There's many other similar ways to achieve the same - effect. -

      -

      --James Kuyper, on comp.std.c++ -

      3. - -

    3. is the term "header" meant to be limited to standard headers? -Clause 17 is all about the library, but still the general question is -interesting and affects one of the points in the explicit namespaces -proposal (n1691): -

      -

      - Those seeking to conveniently enable argument-dependent - lookups for all operators within an explicit namespace - could easily create a header file that does so: -

          namespace mymath::
-    {
-        #include "using_ops.hpp"
-    }
-
      -
      4. -
    - - -

    Proposed resolution:

    -

    -

    - - -

    Rationale:

    -We believe that the existing language does not cause any real confusion -and any new formulation of the rules that we could come up with are -unlikely to be better than what's already in the standard. - - - - - -
    -

    658. Two unspecified function comparators in [function.objects]

    -

    Section: 20.6 [function.objects] Status: NAD Editorial - Submitter: Daniel Krügler Date: 2007-03-19

    -

    View all other issues in [function.objects].

    -

    View all issues with NAD Editorial status.

    -

    Discussion:

    -

    -The header <functional> synopsis in 20.6 [function.objects] -contains the following two free comparison operator templates -for the function class template -

    - -
    template<class Function1, class Function2>
-void operator==(const function<Function1>&, const function<Function2>&);
-template<class Function1, class Function2>
-void operator!=(const function<Function1>&, const function<Function2>&);
-
    - -

    -which are nowhere described. I assume that they are relicts before the -corresponding two private and undefined member templates in the function -template (see 20.6.15.2 [func.wrap.func] and X [func.wrap.func.undef]) have been introduced. The original free -function templates should be removed, because using an undefined entity -would lead to an ODR violation of the user. -

    - - -

    Proposed resolution:

    -

    -Remove the above mentioned two function templates from -the header <functional> synopsis (20.6 [function.objects]) -

    - -
    template<class Function1, class Function2>
-void operator==(const function<Function1>&, const function<Function2>&);
-template<class Function1, class Function2>
-void operator!=(const function<Function1>&, const function<Function2>&);
-
    - - - -

    Rationale:

    -Fixed by -N2292 -Standard Library Applications for Deleted Functions. - - - - - -
    -

    662. Inconsistent handling of incorrectly-placed thousands separators

    -

    Section: 22.2.2.1.2 [facet.num.get.virtuals] Status: NAD - Submitter: Cosmin Truta Date: 2007-04-05

    -

    View other active issues in [facet.num.get.virtuals].

    -

    View all other issues in [facet.num.get.virtuals].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    -From Section 22.2.2.1.2 [facet.num.get.virtuals], paragraphs 11 and 12, it is implied -that the value read from a stream must be stored -even if the placement of thousands separators does not conform to the -grouping() specification from the numpunct facet. -Since incorrectly-placed thousands separators are flagged as an extraction -failure (by the means of failbit), we believe it is better not -to store the value. A consistent strategy, in which any kind of extraction -failure leaves the input item intact, is conceptually cleaner, is able to avoid -corner-case traps, and is also more understandable from the programmer's point -of view. -

    -

    -Here is a quote from "The C++ Programming Language (Special Edition)" -by B. Stroustrup (Section D.4.2.3, pg. 897): -

    -

    -"If a value of the desired type could not be read, failbit is set in r. -[...] An input operator will use r to determine how to set the state of its -stream. If no error was encountered, the value read is assigned through v; -otherwise, v is left unchanged." -

    -

    -This statement implies that rdstate() alone is sufficient to -determine whether an extracted value is to be assigned to the input item -val passed to do_get. However, this is in disagreement -with the current C++ Standard. The above-mentioned assumption is true in all -cases, except when there are mismatches in digit grouping. In the latter case, -the parsed value is assigned to val, and, at the same time, err -is assigned to ios_base::failbit (essentially "lying" about the -success of the operation). Is this intentional? The current behavior raises -both consistency and usability concerns. -

    -

    -Although digit grouping is outside the scope of scanf (on which -the virtual methods of num_get are based), handling of grouping -should be consistent with the overall behavior of scanf. The specification of -scanf makes a distinction between input failures and matching -failures, and yet both kinds of failures have no effect on the input items -passed to scanf. A mismatch in digit grouping logically falls in -the category of matching failures, and it would be more consistent, and less -surprising to the user, to leave the input item intact whenever a failure is -being signaled. -

    -

    -The extraction of bool is another example outside the scope of -scanf, and yet consistent, even in the event of a successful -extraction of a long but a failed conversion from -long to bool. -

    -

    -Inconsistency is further aggravated by the fact that, when failbit is set, -subsequent extraction operations are no-ops until failbit is -explicitly cleared. Assuming that there is no explicit handling of -rdstate() (as in cin>>i>>j) it is -counter-intuitive to be able to extract an integer with mismatched digit -grouping, but to be unable to extract another, properly-formatted integer -that immediately follows. -

    -

    -Moreover, setting failbit, and selectively assigning a value to -the input item, raises usability problems. Either the strategy of -scanf (when there is no extracted value in case of failure), or -the strategy of the strtol family (when there is always an -extracted value, and there are well-defined defaults in case of a failure) are -easy to understand and easy to use. On the other hand, if failbit -alone cannot consistently make a difference between a failed extraction, and a -successful but not-quite-correct extraction whose output happens to be the same -as the previous value, the programmer must resort to implementation tricks. -Consider the following example: -

    -
        int i = old_i;
-    cin >> i;
-    if (cin.fail())
-        // can the value of i be trusted?
-        // what does it mean if i == old_i?
-        // ...
-
    -

    -Last but not least, the current behvaior is not only confusing to the casual -reader, but it has also been confusing to some book authors. Besides -Stroustrup's book, other books (e.g. "Standard C++ IOStreams and Locales" by -Langer and Kreft) are describing the same mistaken assumption. Although books -are not to be used instead of the standard reference, the readers of these -books, as well as the people who are generally familiar to scanf, -are even more likely to misinterpret the standard, and expect the input items -to remain intact when a failure occurs. -

    - - -

    Proposed resolution:

    - -

    -Change 22.2.2.1.2 [facet.num.get.virtuals]: -

    - -
    -

    -Stage 3: The result of stage 2 processing can be one of -

    -
      -
    • A sequence of chars has been accumulated in stage 2 that is converted (according to the rules of scanf) to a value of the type of val. This value is stored in val and ios_base::goodbit is stored in err.
      • - -
    • The sequence of chars accumulated in stage 2 would have caused scanf to report an input failure. ios_base::failbit is assigned to err.
      • -
    -

    -In the first case, Ddigit grouping is checked. That is, the positions of discarded separators is examined for consistency with use_facet<numpunct<charT> >(loc).grouping(). If they are not consistent then ios_base::failbit is assigned to err. Otherwise, the value that was converted in stage 2 is stored in val and ios_base::goodbit is stored in err. -

    -
    - - -

    Rationale:

    -post-Toronto: Changed from New to NAD at the request of the author. The preferred solution of -N2327 -makes this resolution obsolete. - - - - - -
    -

    663. Complexity Requirements

    -

    Section: 17.3.1.3 [structure.specifications] Status: NAD - Submitter: Thomas Plum Date: 2007-04-16

    -

    View all other issues in [structure.specifications].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    -17.3.1.3 [structure.specifications] para 5 says -

    - -

    --5- Complexity requirements specified in the library  -clauses are upper bounds, and implementations that provide better -complexity guarantees satisfy the requirements. -

    - -

    -The following -objection has been raised: -

    - -

    -The library clauses suggest general -guidelines regarding complexity, but we have been unable to discover -any absolute hard-and-fast formulae for these requirements.  Unless -or until the Library group standardizes specific hard-and-fast -formulae, we regard all the complexity requirements as subject to a  -"fudge factor" without any intrinsic upper bound. -

    - -

    -[Plum ref  -_23213Y31 etc] -

    - - -

    Proposed resolution:

    -

    -

    - - -

    Rationale:

    -Kona (2007): No specific instances of underspecification have been -identified, and big-O notation always involves constant factors. - - - - - -
    -

    683. regex_token_iterator summary error

    -

    Section: 28.12.2 [re.tokiter] Status: Pending NAD Editorial - Submitter: Eric Niebler Date: 2007-06-02

    -

    View all other issues in [re.tokiter].

    -

    View all issues with Pending NAD Editorial status.

    -

    Discussion:

    -

    -28.12.2 [re.tokiter], p3 says: -

    -
    -

    -After it is constructed, the iterator finds and stores a value -match_results<BidirectionalIterator> position and sets the -internal count N to zero. -

    -
    - -

    -Should read: -

    - -
    -

    -After it is constructed, the iterator finds and stores a value -match_resultsregex_iterator<BidirectionalIterator, charT, traits> -position and sets the internal count N to zero. -

    -
    - -

    [ -John adds: -]

    - - -

    -Yep, looks like a typo/administrative fix to me. -

    - - - -

    Proposed resolution:

    -

    -

    - - - - - -
    -

    684. Unclear which members of match_results should be used in comparison

    -

    Section: 28.10 [re.results] Status: NAD Editorial - Submitter: Nozomu Katoo Date: 2007-05-27

    -

    View all other issues in [re.results].

    -

    View all issues with NAD Editorial status.

    -

    Discussion:

    -

    -In 28.4 [re.syn] of N2284, two template functions -are declared here: -

    -
    // 28.10, class template match_results: 
-  <snip>
-// match_results comparisons 
-  template <class BidirectionalIterator, class Allocator> 
-    bool operator== (const match_results<BidirectionalIterator, Allocator>& m1, 
-                     const match_results<BidirectionalIterator, Allocator>& m2); 
-  template <class BidirectionalIterator, class Allocator> 
-    bool operator!= (const match_results<BidirectionalIterator, Allocator>& m1, 
-                     const match_results<BidirectionalIterator, Allocator>& m2); 
-
-// 28.10.6, match_results swap:
-
    - -

    -But the details of these two bool operator functions (i.e., which members of -match_results should be used in comparison) are not described in any -following sections. -

    - -

    [ -John adds: -]

    - - -

    -That looks like a bug: operator== should return true only if -the two objects refer to the same match - ie if one object was constructed as a -copy of the other. -

    - -

    [ -Kona (2007): Bill and Pete to add minor wording to that proposed in -N2409. -]

    - - - -

    Proposed resolution:

    -

    -Add a new section after 28.10.6 [re.results.swap], which reads: -

    -

    -28.10.7 match_results non-member functions. -

    - -
    -
    template<class BidirectionalIterator, class Allocator> 
-  bool operator==(const match_results<BidirectionalIterator, Allocator>& m1, 
-                  const match_results<BidirectionalIterator, Allocator>& m2);
-
    -
    -

    -Returns: true only if the two objects refer to the same match. -

    -
    -
    - -
    -
    template<class BidirectionalIterator, class Allocator> 
-  bool operator!=(const match_results<BidirectionalIterator, Allocator>& m1, 
-                  const match_results<BidirectionalIterator, Allocator>& m2);
-
    -
    -

    -Returns: !(m1 == m2). -

    -
    -
    - -
    -
    template<class BidirectionalIterator, class Allocator> 
-  void swap(match_results<BidirectionalIterator, Allocator>& m1, 
-            match_results<BidirectionalIterator, Allocator>& m2);
-
    -
    -

    -Returns: m1.swap(m2). -

    -
    -
    - - -

    [ -Bellevue: Proposed wording now in WP. -]

    - - - - - -
    -

    686. Unique_ptr and shared_ptr fail to specify non-convertibility to int for unspecified-bool-type

    -

    Section: 20.7.11.2.4 [unique.ptr.single.observers], 20.7.12.2.5 [util.smartptr.shared.obs] Status: NAD - Submitter: Beman Dawes Date: 2007-06-14

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    -The standard library uses the operator unspecified-bool-type() const idiom in -five places. In three of those places (20.6.15.2.3 [func.wrap.func.cap], function capacity -for example) the returned value is constrained to disallow -unintended conversions to int. The standardese is -

    -

    -The return type shall not be convertible to int. -

    -

    -This constraint is omitted for unique_ptr and shared_ptr. It should be added for those. -

    - -

    [ -Bellevue: -]

    - - -
    -Close as NAD. Accepting paper -N2435 -makes it irrelevant. -
    - - - -

    Proposed resolution:

    -

    -To the Returns paragraph for operator unspecified-bool-type() -const -of 20.7.11.2.4 [unique.ptr.single.observers] paragraph 11 and -20.7.12.2.5 [util.smartptr.shared.obs] paragraph 16, add the sentence: -

    -

    -The return type shall not be convertible to int. -

    - - -

    [ -Kona (2007): Uncertain if nullptr will address this issue. -]

    - - - - - -
    -

    690. abs(long long) should return long long

    -

    Section: 26.7 [c.math] Status: NAD Editorial - Submitter: Niels Dekker Date: 2007-06-10

    -

    View all other issues in [c.math].

    -

    View all issues with NAD Editorial status.

    -

    Discussion:

    -

    -Quoting the latest draft (n2135), 26.7 [c.math]: -

    - -
    -

    -The added signatures are: -

    -
    long abs(long); // labs()
-long abs(long long); // llabs()
-
    -
    -

    -Shouldn't abs(long long) have long long as return type? -

    - - -

    Proposed resolution:

    -

    -Change 26.7 [c.math]: -

    -
    long long abs(long long); // llabs()
-
    - - -

    Rationale:

    -Had already been fixed in the WP by the time the LWG reviewed this. - - - - - -
    -

    697. New <system_error> header leads to name clashes

    -

    Section: 19.4 [syserr] Status: NAD Editorial - Submitter: Daniel Krügler Date: 2007-06-24

    -

    View other active issues in [syserr].

    -

    View all other issues in [syserr].

    -

    View all issues with NAD Editorial status.

    -

    Discussion:

    -

    -The most recent state of -N2241 -as well as the current draft -N2284 -(section 19.4 [syserr], p.2) proposes a -new -enumeration type posix_errno immediatly in the namespace std. One of -the enumerators has the name invalid_argument, or fully qualified: -std::invalid_argument. This name clashes with the exception type -std::invalid_argument, see 19.1 [std.exceptions]/p.3. This clash makes -e.g. the following snippet invalid: -

    - -
    #include <system_error>
-#include <stdexcept>
-
-void foo() { throw std::invalid_argument("Don't call us - we call you!"); }
-
    - -

    -I propose that this enumeration type (and probably the remaining parts -of -<system_error> as well) should be moved into one additional inner -namespace, e.g. sys or system to reduce foreseeable future clashes -due -to the great number of members that std::posix_errno already contains -(Btw.: Why has the already proposed std::sys sub-namespace from -N2066 -been rejected?). A further clash candidate seems to be -std::protocol_error -(a reasonable name for an exception related to a std network library, -I guess). -

    - -

    -Another possible resolution would rely on the proposed strongly typed -enums, -as described in N2213. -But maybe the forbidden implicit conversion to integral types would -make -these enumerators less attractive in this special case? -

    - - -

    Proposed resolution:

    -

    -Fixed by issue 7 of N2422. -

    - - - - - - -
    -

    707. null pointer constant for exception_ptr

    -

    Section: 18.7.5 [propagation] Status: NAD - Submitter: Jens Maurer Date: 2007-07-20

    -

    View other active issues in [propagation].

    -

    View all other issues in [propagation].

    -

    View all issues with NAD status.

    -

    Discussion:

    - -

    -From the Toronto Core wiki: -

    - -

    -What do you mean by "null pointer constant"? How do you guarantee that -exception_ptr() == 1 doesn't work? Do you even want to prevent that? -What's the semantics? What about void *p = 0; exception_ptr() == p? -Maybe disallow those in the interface, but how do you do that with -portable C++? Could specify just "make it work". -

    - -

    -Peter's response: -

    - -

    -null pointer constant as defined in 4.10 [conv.ptr]. Intent is "just make it -work", can be implemented as assignment operator taking a unique pointer -to member, as in the unspecified bool type idiom. -

    - -

    [ -Bellevue: -]

    - - -
    -

    -Original implementation was possible using the "unspecified-null-pointer" idiom, similar to unspecified-bool. -

    -

    -Even simpler now with nullptr_t. -

    -

    -NAD Rationale : null pointer constant is a perfectly defined term, and -while API is clearly implementable there is no need to spell out -implementation details. -

    -
    - - - -

    Proposed resolution:

    -

    -

    - - - - - -
    -

    717. Incomplete valarray::operator[] specification in [valarray.access]

    -

    Section: 26.5.2.3 [valarray.access] Status: Pending NAD Editorial - Submitter: Daniel Krügler Date: 2007-08-27

    -

    View all other issues in [valarray.access].

    -

    View all issues with Pending NAD Editorial status.

    -

    Discussion:

    -

    -Since the return type of valarray's operator[] const overload has been -changed to const T& as described in 389 several paragraphs of -the section 26.5.2.3 [valarray.access] are now -incompletely -specified, because many requirements and guarantees should now also -apply to the const overload. Most notably, the address and reference -guarantees should be extended to the const overload case. -

    - - -

    Proposed resolution:

    -

    -Change 26.5.2.3 [valarray.access]: -

    - -
    -

    --1- When applied to a constant array, the subscript operator returns a -reference to the corresponding element of the array. When applied to a -non-constant array, tThe subscript operator returns a -reference to the corresponding element of the array. -

    - -

    --3- The expression &a[i+j] == &a[i] + j evaluates as true for all size_t i -and size_t j such that i+j is less -than the length of the non-constant array a. -

    - -

    --4- Likewise, the expression &a[i] != &b[j] evaluates -as true for any two non-constant arrays a and -b and for any size_t i and size_t j such that -i is less than the length of a and j is less -than the length of b. This property indicates an absence of -aliasing and may be used to advantage by optimizing -compilers.281) -

    - -

    --5- The reference returned by the subscript operator for an non-constant array is guaranteed to be valid until -the member function resize(size_t, T) (26.5.2.7) is called for that array or until the lifetime -of that array ends, whichever happens first. -

    - -
    - - - - - - -
    -

    725. Optional sequence container requirements column label

    -

    Section: 23.1.3 [sequence.reqmts] Status: Pending NAD Editorial - Submitter: David Abrahams Date: 2007-09-16

    -

    View all other issues in [sequence.reqmts].

    -

    View all issues with Pending NAD Editorial status.

    -

    Discussion:

    -

    -Table 90: (Optional sequence container operations) states the -"assertion note pre/post-condition" of operator[] to be -

    - -
    *(a.begin() + n)
-
    - -

    -Surely that's meant to be "operational semantics?" -

    - - - -

    Proposed resolution:

    -
    - - - - - -
    Table 90: Optional sequence container operations
    expression return type assertion/note
    pre/post-condition
    operational semantics    		 container
    -
    - - - - - - -
    -

    729. Problem in [rand.req.eng]/3

    -

    Section: 26.4.1.3 [rand.req.eng] Status: NAD - Submitter: Stephan Tolksdorf Date: 2007-09-21

    -

    View all other issues in [rand.req.eng].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    -The 3rd table row in 26.4.1.3 [rand.req.eng]/3 requires random number engines to accept any -arithmetic type as a seed, which is then casted to the engine's result_type and subsequently -used for seeding the state of the engine. The requirement stated as "Creates an engine with -initial state determined by static_cast<X::result_type>(s)" forces random number engines -to either use a seeding method that completely depends on the result_type (see the discussion -of seeding for the mersenne_twister_engine in point T2 above) or at least to throw away "bits -of randomness" in the seed value if the result_type is smaller than the seed type. This seems -to be inappropriate for many modern random number generators, in particular F2-linear or -cryptographic ones, which operate on an internal bit array that in principle is independent of the -type of numbers returned. -

    - -

    -Posible resolution: I propose to change the wording to a version similar to "Creates an -engine with initial state determined by static_cast<UintType>(s), where UintType is an -implementation specific unsigned integer type." -

    - -

    -Additionally, the definition of s in 26.4.1.3 [rand.req.eng]/1 c) could be restricted to unsigned integer types. -

    - -

    -Similarly, the type of the seed in 26.4.1.4 [rand.req.adapt]/3 e) could be left unspecified. -

    - -

    -See N2424 -for further discussion. -

    - -

    [ -Stephan Tolksdorf adds pre-Bellevue: -]

    - - -
    -

    -In reply to the discussion in -N2424 -regarding this issue: -

    -

    -The descriptions of all engines and engine adaptors given in sections -26.4.3 [rand.eng] and 26.4.4 [rand.adapt] already specify the concrete -types of the integer arguments for seeding. Hence, relaxing the general -requirement in 26.4.1.3 [rand.req.eng] would not affect portability and -reproducibility of the standard library. Furthermore, it is not clear to -me what exactly the guarantee "with initial state determined by -static_cast<X::result_type>(s)" is useful for. On the other hand, -relaxing the requirement would allow developers to implement other -random number engines that do not have to cast all arithmetic seed -arguments to their result_types. -

    -
    - -

    [ -Bellevue: -]

    - - -
    -Propose close NAD for the reasons given in N2424. -
    - - - - -

    Proposed resolution:

    -

    -See N2424 -for further discussion. -

    - -

    [ -Stephan Tolksdorf adds pre-Bellevue: -]

    - - -
    -

    -Change row 3 of table 105 "Random number engine requirements" in 26.4.1.3 [rand.req.eng]/3 -

    - -
    -Creates an engine with initial state determined by -static_cast<X::result_type>(s) -
    - -

    -Similarly, change 26.4.1.4 [rand.req.adapt]/3 e) -

    - -
    -When X::X is invoked with an X::result_type value s -of arithmetic type (3.9.1), ... -
    - -
    - - - - - - -
    -

    730. Comment on [rand.req.adapt]/3 e)

    -

    Section: 26.4.1.4 [rand.req.adapt] Status: NAD - Submitter: Stephan Tolksdorf Date: 2007-09-21

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    -If an engine adaptor is invoked with an argument of type seed_seq, then all base -engines are specified to be seeded with this seed_seq. As seed_seq's randomization method is -qualified as constant, this procedure will ef fectively initialize all base engines with the same seed -(though the resulting state might still dif fer to a certain degree if the engines are of different types). -It is not clear whether this mode of operation is in general appropriate, hence -- as far as the -stated requirements are of general nature and not just specific to the engine adaptors provided by -the library -- it might be better to leave the behaviour unspecified, since the current definition of -seed_seq does not allow for a generally satisfying specification. -

    - -

    -Posssible resolution: [As above] -

    - -

    -See N2424 -for further discussion. -

    - -

    [ -Bellevue: -]

    - - -
    -Close NAD for the reasons given in N2424. -
    - - - -

    Proposed resolution:

    -

    -See N2424 -for the proposed resolution. -

    - - - - - -
    -

    731. proposal for a customizable seed_seq

    -

    Section: 26.4.7.1 [rand.util.seedseq] Status: NAD - Submitter: Stephan Tolksdorf Date: 2007-09-21

    -

    View other active issues in [rand.util.seedseq].

    -

    View all other issues in [rand.util.seedseq].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    -The proper way to seed random number engines seems to be the most frequently -discussed issue of the 26.4 [rand] proposal. While the new seed_seq approach is already rather -general and probably sufficient for most situations, it is unlikely to be optimal in every case (one -problem was pointed out in point T5 above). In some situations it might, for instance, be better to -seed the state with a cryptographic generator. -

    -

    -In my opinion this is a pretty strong argument for extending the standard with a simple facility to -customize the seeding procedure. This could, for example, be done with the following minimal -changes: -

    - -

    -Possible resolution: -

    - -
      -
    1. -Turn the interface specification of 26.4.7.1 [rand.util.seedseq]/2 into a "SeedSeq" requirement, where the -exact behaviour of the constructors and the randomize method are left unspecified and where the -const qualification for randomize is removed. Classes implementing this interface are additionally -required to specialize the traits class in c). -
      2. -
    2. -Provide the class seed_seq as a default implementation of the SeedSeq interface. -
      3. -
    3. -

      -Supplement the seed_seq with a traits class -

      -
      template <typename T> 
-struct is_seed_seq { static const bool value = false; }
-
      -

      and the specialization

      -
      template <> 
-struct is_seed_seq<seed_seq> { static const bool value = true; }
-
      -

      which users can supplement with further specializations.

      -
      4. -
    4. -Change 26.4.1.3 [rand.req.eng]/1 d) to "q is an lvalue of a type that fulfils the SeedSeq requirements", and -modify the constructors and seed methods in 26.4.3 [rand.eng] appropriately (the actual implementation -could be done using the SFINAE technique). -
      5. -
    - -

    [ -Bellevue: -]

    - - -
    -See N2424. Close NAD but note that "conceptizing" the library may cause -this problem to be solved by that route. -
    - - -

    Proposed resolution:

    -

    -See N2424 -for the proposed resolution. -

    - - - - - -
    -

    733. Comment on [rand.req.dist]/9

    -

    Section: 26.4.1.5 [rand.req.dist] Status: NAD - Submitter: Stephan Tolksdorf Date: 2007-09-21

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    -The requirement "P shall have a declaration of the form typedef X distribution_- -type" effectively makes the use of inheritance for implementing distributions very inconvenient, -because the child of a distribution class in general will not satisfy this requirement. In my opinion -the benefits of having a typedef in the parameter class pointing back to the distribution class are -not worth the hassle this requirement causes. [In my code base I never made use of the nested -typedef but on several occasions could have profited from being able to use simple inheritance for -the implementation of a distribution class.] -

    - -

    -Proposed resolution: I propose to drop this requirement. -

    - -

    [ -Bellevue: -]

    - - -
    -Close NAD for the reasons given in N2424. In practice it is not inconvenient to meet these requirements. -
    - - - -

    Proposed resolution:

    -

    -See N2424 -for the proposed resolution. -

    - - - - - -
    -

    735. Unfortunate naming

    -

    Section: 26.4.8.2.2 [rand.dist.bern.bin], 26.4.8.2.4 [rand.dist.bern.negbin] Status: NAD - Submitter: Stephan Tolksdorf Date: 2007-09-21

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    -In my opinion the choice of name for the t parameter of the binomial_distribution -is very unfortunate. In virtually every internet reference, book and software implementation -this parameter is called n instead, see for example Wikipedia, Mathworld, Evans et al. (1993) -Statistical Distributions, 2nd E., Wiley, p. 38, the R statistical computing language, p. 926, -Mathematica and Matlab. -

    - -

    -Similarly, the choice of k for the parameter of the negative binomial distributions is rather unusual. -The most common choice for the negative binomial distribution seems to be r instead. -

    - -

    -Choosing unusual names for the parameters causes confusion among users and makes the -interface unnecessarily inconvenient to use. -

    - -

    -Possible resolution: For these reasons, I propose to change the name of the respective parameters -to n and r. -

    - -

    [ -Bellevue: -]

    - - -
    -In N2424. NAD It has been around for a while. It is hardly universal, -there is prior art, and this would confuse people. -
    - - -

    Proposed resolution:

    -

    -See N2424 -for the proposed resolution. -

    - - - - - -
    -

    736. Comment on [rand.dist.samp.discrete]

    -

    Section: 26.4.8.5.1 [rand.dist.samp.discrete] Status: NAD - Submitter: Stephan Tolksdorf Date: 2007-09-21

    -

    View other active issues in [rand.dist.samp.discrete].

    -

    View all other issues in [rand.dist.samp.discrete].

    -

    View all issues with NAD status.

    -

    Discussion:

    -
      -
    1. -The specification for discrete_distribution requires the member probabilities() -to return a vector of standardized probabilities, which forces the implementation every time to -divide each probability by the sum of all probabilities, as the sum will in practice almost never be -exactly 1.0. This is unnecessarily inef ficient as the implementation would otherwise not need to -compute the standardized probabilities at all and could instead work with the non-standardized -probabilities and the sum. If there was no standardization the user would just get back the -probabilities that were previously supplied to the distribution object, which to me seems to be the -more obvious solution. -
      2. -
    2. -The behaviour of discrete_distribution is not specified in case the number of given -probabilities is larger than the maximum number representable by the IntType. -
      3. -
    - -

    -Possible resolution: I propose to change the specification such that the non-standardized -probabilities need to be returned and that an additional requirement is included for the number -of probabilities to be smaller than the maximum of IntType. -

    - -

    [ -Stephan Tolksdorf adds pre-Bellevue: -]

    - - -
    -

    -In reply to the discussion in -N2424 -of this issue: -

    -

    -Rescaled floating-point parameter vectors can not be expected to compare -equal because of the limited precision of floating-point numbers. -My proposal would at least guarantee that a parameter -vector (of type double) passed into the distribution would compare equal -with the one returned by the probabilities() method. Furthermore, I do -not understand why "the changed requirement would lead to a significant -increase in the amount of state in the distribution object". A typical -implementation's state would increase by exactly one number: the sum of -all probabilities. The textual representation for serialization would -not need to grow at all. Finally, the proposed replacement "0 < n <= -numeric_limits<IntType>::max() + 1" makes the implementation -unnecessarily complicated, "0 < n <= numeric_limits<IntType>::max()" -would be better. -

    -
    - -

    [ -Bellevue: -]

    - - -
    -

    -In N2424. We agree with the observation and the proposed resolution to -part b). We recommend the wording n > 0 be replaced with 0 < n -numeric_limits::max() + 1. However, we disagree with part a), as it -would interfere with the definition of parameters' equality. Further, -the changed requirement would lead to a significant increase in the -amount of state of the distribution object. -

    - -

    -As it stands now, it is convenient, and the changes proposed make it -much less so. -

    - -

    -NAD. Part a the current behavior is desirable. Part b, any constructor -can fail, but the rules under which it can fail do not need to be listed -here. -

    -
    - - -

    Proposed resolution:

    -

    -See N2424 -for the proposed resolution. -

    - -

    [ -Stephan Tolksdorf adds pre-Bellevue: -]

    - - -
    -

    -In 26.4.8.5.1 [rand.dist.samp.discrete]: -

    - -

    -Proposed wording a): -

    - -
    -

    -Changae in para. 2 -

    - -
    -Constructs a discrete_distribution object with n=1 and p0 = w0 = 1 -
    - -

    -and change in para. 5 -

    - -
    -Returns: A vector<double> whose size member returns n and whose -operator[] member returns pk -the weight wk as a double value -when invoked with argument k for k = 0, -..., n-1 -
    - -
    - -

    -Proposed wording b): -

    - -
    -

    -Change in para. 3: -

    - -
    -If firstW == lastW, let the sequence w have length n = 1 and consist -of the single value w0 = 1. Otherwise, [firstW,lastW) shall form a -sequence w of length n > 0 -such that 0 < n <= numeric_limits<IntType>::max(), -and *firstW shall yield a value w0 -convertible to double. [Note: The values wk are commonly known -as the weights . -- end note] -
    - -
    - -
    - - - - - -
    -

    737. Comment on [rand.dist.samp.pconst]

    -

    Section: 26.4.8.5.2 [rand.dist.samp.pconst] Status: NAD - Submitter: Stephan Tolksdorf Date: 2007-09-21

    -

    View other active issues in [rand.dist.samp.pconst].

    -

    View all other issues in [rand.dist.samp.pconst].

    -

    View all issues with NAD status.

    -

    Discussion:

    -
      -
    1. -The discussion in point T11 above regarding probabilities() similarly applies -to the method densities() of piecewise_constant_distribution. -
      2. -
    2. -

      -The design of the constructor -

      -
      template <class InputIteratorB, class InputIteratorW> 
-piecewise_constant_distribution( InputIteratorB firstB, InputIteratorB lastB, 
-                                 InputIteratorW firstW);
-
      -

      -is unnecessarily unsafe, as there is no separate end-iterator given for the weights. I can't see -any performance or convenience reasons that would justify the risks inherent in such a function -interface, in particular the risk that input error might go unnoticed. -

      -
      3. -
    - -

    -Possible resolution: I propose to add an InputIteratorW lastW argument to the interface. -

    - -

    [ -Stephan Tolksdorf adds pre-Bellevue: -]

    - -
    -In reply to the discussion in -N2424 -I'd like to make the same comments as for 736. -
    - -

    [ -Bellevue: -]

    - - -
    -In N2424. There is already precedent elsewhere in the library. Follows existing convention. NAD. -
    - - -

    Proposed resolution:

    -

    -See N2424 -for the proposed resolution. -

    - -

    [ -Stephan Tolksdorf adds pre-Bellevue: -]

    - - -
    -

    -In 26.4.8.5.2 [rand.dist.samp.pconst]: -

    - -

    -Proposed wording a) -

    - -
    -

    -Change in para. 2 -

    -
    -Constructs a piecewise_constant_distribution object with n = 1, p0 = w0 = 1, -b0 = 0, and b1 = 1 -
    - -

    -and change in para. 5 -

    - -
    -A vector<result_type> whose size member returns n and whose operator[] -member returns pk -the weight wk as a double value -when invoked with argument k for k = 0, ..., n-1 -
    - -
    - -

    -Proposed wording b) -

    - -
    -

    -Change both occurrences of -

    - -
    -"piecewise_constant_distribution(InputIteratorB firstB, InputIteratorB lastB, - InputIteratorW firstW, InputIteratorW lastW) -
    - -

    -and change in para. 3 -

    - -
    -the length of the sequence w starting from firstW shall be at least n, -*firstW shall return a value w0 that is convertible to double, and any -wk for k >= n shall be ignored by the distribution -[firstW, lastW) shall form a sequence w of length n whose leading element -w0 shall be convertible to double -
    - -
    - - -
    - - - - - - -
    -

    738. Editorial issue in [rand.adapt.disc]/3

    -

    Section: 26.4.4.1 [rand.adapt.disc] Status: Pending NAD Editorial - Submitter: Stephan Tolksdorf Date: 2007-09-21

    -

    View all issues with Pending NAD Editorial status.

    -

    Discussion:

    -

    -Since the template parameter p and r are of type size_t, the member n in the class -exposition should have type size_t, too. -

    - - -

    Proposed resolution:

    -

    -See N2424 -for the proposed resolution. -

    - - - - - -
    -

    739. Defect in [rand.util.canonical]/3

    -

    Section: 26.4.7.2 [rand.util.canonical] Status: NAD - Submitter: Stephan Tolksdorf Date: 2007-09-21

    -

    View all other issues in [rand.util.canonical].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    -The complexity of generate_canonical is specified to be "exactly k=max(1, ceil(b/log2 -R)) invocations of g". This terms involves a logarithm that is not rounded and hence can not (in -general) be computed at compile time. As this function template is performance critical, I propose -to replace ceil(b/log2 R) with ceil(b/floor(log2 R)). -

    - -

    -See N2424 -for further discussion. -

    - -

    [ -Bellevue: -]

    - - -
    -In N2424. Close NAD as described there. -
    - - - -

    Proposed resolution:

    -

    -See N2424 -for the proposed resolution. -

    - - - - - -
    -

    741. Const-incorrect get_deleter function for shared_ptr

    -

    Section: 20.7.12.2.11 [util.smartptr.getdeleter] Status: NAD - Submitter: Daniel Krügler Date: 2007-09-27

    -

    View all other issues in [util.smartptr.getdeleter].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    -The following issue was raised by Alf P. Steinbach in c.l.c++.mod: -

    - -

    -According to the recent draft N2369, both the header memory synopsis -of 20.7 [memory] and 20.7.12.2.11 [util.smartptr.getdeleter] declare: -

    - -
    template<class D, class T> D* get_deleter(shared_ptr<T> const& p);
-
    - -

    -This allows to retrieve the pointer to a mutable deleter of a const -shared_ptr (if that owns one) and therefore contradicts the usual -philosophy that associated functors are either read-only (e.g. -key_comp or value_comp of std::map) or do at least reflect -the mutability of the owner (as seen for the both overloads of -unique_ptr::get_deleter). -Even the next similar counter-part of get_deleter - the two -overloads of function::target in the class template function -synopsis 20.6.15.2 [func.wrap.func] or in 20.6.15.2.5 [func.wrap.func.targ] - do -properly mirror the const-state of the owner. -

    - -Possible proposed resolutions: - -

    -Replace the declarations of get_deleter in the header <memory> -synopsis of 20.7 [memory] and in 20.7.12.2.11 [util.smartptr.getdeleter] by one of the -following alternatives (A) or (B): -

    - -
      -
    1. -Provide only the immutable variant. This would reflect the -current praxis of container::get_allocator(), map::key_comp(), or -map::value_comp. - -
      template<class D, class T> const D* get_deleter(shared_ptr<T> const& p);
-
      -
      2. -
    2. -Just remove the function. -
      3. -
    - -

    -Alberto Ganesh Barbati adds: -

    - -
      -
    1. -

      -Replace it with two functions: -

      -
      template <class D, class T> D get_deleter(shared_ptr<T> const&);
-template <class D, class T> bool has_deleter(shared_ptr<T> const&);
-
      - -

      -The first one would throw if D is the wrong type, while the latter would -never throw. This approach would reflect the current praxis of -use_facet/has_facet, with the twist of returning the deleter by value as -container::get_allocator() do. -

      -
      2. -
    - -

    -Peter Dimov adds: -

    - -
    -

    -My favorite option is "not a defect". A, B and C break useful code. -

    -
    - -

    [ -Bellevue: -]

    - - -
    -Concern this is similar to confusing "pointer to const" with "a constant pointer". -
    - - -

    Proposed resolution:

    -

    -

    - - - - - -
    -

    745. copy_exception API slices.

    -

    Section: 18.7.5 [propagation] Status: NAD - Submitter: Alisdair Meredith Date: 2007-10-10

    -

    View other active issues in [propagation].

    -

    View all other issues in [propagation].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    -It could be I did not understand the design rationale, but I thought -copy_exception would produce an exception_ptr to the most-derived (dynamic) -type of the passed exception. Instead it slices, which appears to be less -useful, and a likely source of FAQ questions in the future. -

    -

    -(Peter Dimov suggests NAD) -

    - -

    [ -Bellevue: -]

    - - -
    -

    -How could this be implemented in a way that the dynamic type is cloned? -

    -

    -The feature is designed to create an exception_ptr from an object whose -static type is identical to the dynamic type and thus there is no -slicing involved. -

    -
    - - -

    Proposed resolution:

    -

    -

    - - - - - -
    -

    748. The is_abstract type trait is defined by reference to 10.4.

    -

    Section: 20.5.4.3 [meta.unary.prop] Status: NAD - Submitter: Alisdair Meredith Date: 2007-10-10

    -

    View all other issues in [meta.unary.prop].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    -I am trying to decide is a pure virtual function is a necessary as well as -sufficient requirement to be classified as abstract? -

    -

    -For instance, is the following (non-polymorphic) type considered abstract? -

    -
    struct abstract {
-protected:
- abstract(){}
- abstract( abstract const & ) {}
- ~abstract() {}
-};
-
    -

    -(Suggested that this may be NAD, with an editorial fix-up from Pete on the -core wording to make clear that abstract requires a pure virtual function) -

    - - -

    Proposed resolution:

    -

    -Core has clarified that the definition abstract is adequate. Issue withdrawn by submitter. NAD. -

    - - - - - -
    -

    754. Ambiguous return clause for std::uninitialized_copy

    -

    Section: 20.7.10.1 [uninitialized.copy] Status: NAD Editorial - Submitter: Daniel Krügler Date: 2007-10-15

    -

    View all other issues in [uninitialized.copy].

    -

    View all issues with NAD Editorial status.

    -

    Discussion:

    -

    -14882-2003, [lib.uninitialized.copy] is currently written as follows: -

    - -
    -
    template <class InputIterator, class ForwardIterator>
-  ForwardIterator uninitialized_copy(InputIterator first, InputIterator last,
-                                     ForwardIterator result);
-
    -
    -

    --1- Effects: -

    -
    for (; first != last; ++result, ++first)
-  new (static_cast<void*>(&*result))
-    typename iterator_traits<ForwardIterator>::value_type(*first);
-
    -

    --2- Returns: result -

    -
    -
    - -

    -similarily for N2369, and its corresponding section -20.7.10.1 [uninitialized.copy]. -

    - -

    -It's not clear to me what the return clause is supposed to mean, I see -two -possible interpretations: -

    - -
      -
    1. -The notion of result is supposed to mean the value given by the -function parameter result [Note to the issue editor: Please use italics for -result]. -This seems somewhat implied by recognizing that both the function -parameter -and the name used in the clause do have the same italic font. -
      2. -
    2. -The notion of "result" is supposed to mean the value of result -after the -preceding effects clause. This is in fact what all implementations I -checked -do (and which is probably it's intend, because it matches the -specification of std::copy). -
      3. -
    - -

    -The problem is: I see nothing in the standard which grants that this -interpretation -is correct, specifically [lib.structure.specifications] or -17.3.1.3 [structure.specifications] -resp. do not clarify which "look-up" rules apply for names found in -the elements -of the detailed specifications - Do they relate to the corresponding -synopsis or -to the effects clause (or possibly other elements)? Fortunately most -detailed -descriptions are unambigious in this regard, e.g. this problem does -not apply -for std::copy. -

    - - - -

    Proposed resolution:

    -

    -Change the wording of the return clause to say (20.7.10.1 [uninitialized.copy]): -

    - -
    -

    --2- Returns: The value of result after effects have taken place. -

    -
    - - -

    [ -Bellevue: -]

    - - -
    -Resolution: NAD editorial -- project editor to decide if change is -worthwhile. Concern is that there are many other places this might -occur. -
    - - - - -
    -

    756. Container adaptors push

    -

    Section: 23.2.5 [container.adaptors] Status: NAD Editorial - Submitter: Paolo Carlini Date: 2007-10-31

    -

    View all issues with NAD Editorial status.

    -

    Discussion:

    -

    -After n2369 we have a single push_back overload in the sequence containers, -of the "emplace" type. At variance with that, still in n2461, we have -two separate overloads, the C++03 one + one taking an rvalue reference -in the container adaptors. Therefore, simply from a consistency point of -view, I was wondering whether the container adaptors should be aligned -with the specifications of the sequence container themselves: thus have -a single push along the lines: -

    - -
    template<typename... _Args>
-void
-push(_Args&&... __args)
-  { c.push_back(std::forward<_Args>(__args)...); }
-
    - -

    [ -Related to 767 -]

    - - - -

    Proposed resolution:

    -

    -Change 23.2.5.1.1 [queue.defn]: -

    - -
    void push(const value_type& x) { c.push_back(x); }
-void push(value_type&& x) { c.push_back(std::move(x)); }
-template<class... Args> void push(Args&&... args) { c.push_back(std::forward<Args>(args)...); }
-
    - -

    -Change 23.2.5.2 [priority.queue]: -

    - -
    void push(const value_type& x) { c.push_back(x); }
-void push(value_type&& x) { c.push_back(std::move(x)); }
-template<class... Args> void push(Args&&... args) { c.push_back(std::forward<Args>(args)...); }
-
    - -

    -Change 23.2.5.2.2 [priqueue.members]: -

    - -
    -
    void push(const value_type& x);
-
    -
    -

    -Effects: -

    -
    c.push_back(x);
-push_heap(c.begin(), c.end(), comp);
-
    -
    - -
    template<class... Args> void push(value_type Args&&... x args);
-
    -
    -

    -Effects: -

    -
    c.push_back(std::moveforward<Args>(x args)...);
-push_heap(c.begin(), c.end(), comp);
-
    -
    -
    - -

    -Change 23.2.5.3.1 [stack.defn]: -

    - -
    void push(const value_type& x) { c.push_back(x); }
-void push(value_type&& x) { c.push_back(std::move(x)); }
-template<class... Args> void push(Args&&... args) { c.push_back(std::forward<Args>(args)...); }
-
    - - - -

    Rationale:

    -

    -Addressed by -N2680 Proposed Wording for Placement Insert (Revision 1). -

    - - - - - -
    -

    757. Typo in the synopsis of vector

    -

    Section: 23.2.6 [vector] Status: NAD Editorial - Submitter: Paolo Carlini Date: 2007-11-04

    -

    View all other issues in [vector].

    -

    View all issues with NAD Editorial status.

    -

    Discussion:

    -

    -In the synopsis 23.2.6 [vector], there is the signature: -

    - -
    void insert(const_iterator position, size_type n, T&& x);
-
    - -

    -instead of: -

    - -
    iterator insert(const_iterator position, T&& x);
-
    - -

    -23.2.6.4 [vector.modifiers] is fine. -

    - - - -

    Proposed resolution:

    -

    -Change the synopsis in 23.2.6 [vector]: -

    - -
    iterator insert(const_iterator position, const T& x); 
-iterator insert(const_iterator position, T&& x);
-void     insert(const_iterator position, size_type n, const T& x); 
-void     insert(const_iterator position, size_type n, T&& x);
-
    - - - - - -
    -

    763. Renaming emplace() overloads

    -

    Section: 23.1.4 [associative.reqmts] Status: NAD - Submitter: Sylvain Pion Date: 2007-12-04

    -

    View all other issues in [associative.reqmts].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    -The associative containers provide 2 overloads of emplace(): -

    - -
    template <class... Args> pair<iterator, bool> emplace(Args&&... args);
-template <class... Args> iterator emplace(const_iterator position, Args&&... args);
-
    - -

    -This is a problem if you mean the first overload while passing -a const_iterator as first argument. -

    - -

    [ -Related to 767 -]

    - - -

    [ -Bellevue: -]

    - - -
    -
    -

    -This can be disambiguated by passing "begin" as the first argument in -the case when the non-default choice is desired. We believe that desire -will be rare. -

    -

    -Resolution: Change state to NAD. -

    - - -

    Proposed resolution:

    -

    -Rename one of the two overloads. -For example to emplace_here, hint_emplace... -

    - - - - - -
    -

    764. equal_range on unordered containers should return a pair of local_iterators

    -

    Section: 23.1.5 [unord.req] Status: NAD - Submitter: Joe Gottman Date: 2007-11-29

    -

    View other active issues in [unord.req].

    -

    View all other issues in [unord.req].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    - A major attribute of the unordered containers is that iterating -though them inside a bucket is very fast while iterating between buckets -can be much slower. If an unordered container has a low load factor, -iterating between the last iterator in one bucket and the next iterator, -which is in another bucket, is O(bucket_count()) which may be much -larger than O(size()). -

    -

    - If b is an non-const unordered container of type B and k is an -object of it's key_type, then b.equal_range(k) currently returns -pair<B::iterator, B::iterator>. Consider the following code: -

    - -
    B::iterator lb, ub;
-tie(lb, ub) = b.equal_range(k);
-for (B::iterator it = lb; it != ub; ++it) {
-        // Do something with *it
-}
-
    - -

    -If b.equal_range(k) returns a non-empty range (i.e. b contains at least -on element whose key is equivalent to k), then every iterator in the -half-open range [lb, ub) will be in the same bucket, but ub will likely -either be in a different bucket or be equal to b.end(). In either case, -iterating between ub - 1 and ub could take a much longer time than -iterating through the rest of the range. -

    -

    -If instead of returning pair<iterator, iterator>, equal_range were to -return pair<local_iterator, local_iterator>, then ub (which, like lb, -would now be a local_iterator) could be guaranteed to always be in the -same bucket as lb. In the cases where currently ub is equal to b.end() -or is in a different bucket, ub would be equal to b.end(b.bucket(key)). - This would make iterating between lb and ub much faster, as every -iteration would be constant time. -

    - -

    [ -Bellevue: -]

    - - -
    -The proposed resolution breaks consistency with other container types -for dubious benefit, and iterators are already constant time. -
    - - - -

    Proposed resolution:

    -

    -Change the entry for equal_range in Table 93 (23.1.5 [unord.req]) as follows: -

    - - - - - - - - - - - -
    expression return type assertion/note pre/post-condition complexity
    b.equal_range(k)pair<local_iterator,local_iterator>; pair<const_local_iterator,const_local_iterator> for const b.Returns a range containing all elements with keys equivalent to k. Returns make_pair(b.end(b.bucket(key)),b.end(b.bucket(key))) if no such elements exist.Average case Θ(b.count(k)). Worst case Θ(b.size()).
    - - - - - -
    -

    767. Forwarding and backward compatibility

    -

    Section: 23 [containers] Status: NAD Editorial - Submitter: Sylvain Pion Date: 2007-12-28

    -

    View other active issues in [containers].

    -

    View all other issues in [containers].

    -

    View all issues with NAD Editorial status.

    -

    Discussion:

    -

    -Playing with g++'s C++0X mode, I noticed that the following -code, which used to compile: -

    - -
    #include <vector>
-
-int main()
-{
-    std::vector<char *> v;
-    v.push_back(0);
-}
-
    - -

    -now fails with the following error message: -

    - -
    .../include/c++/4.3.0/ext/new_allocator.h: In member -function 'void __gnu_cxx::new_allocator<_Tp>::construct(_Tp*, -_Args&& ...) [with _Args = int, _Tp = char*]': -.../include/c++/4.3.0/bits/stl_vector.h:707: instantiated from 'void -std::vector<_Tp, _Alloc>::push_back(_Args&& ...) [with -_Args = int, _Tp = char*, _Alloc = std::allocator<char*>]' -test.cpp:6: instantiated from here -.../include/c++/4.3.0/ext/new_allocator.h:114: error: invalid -conversion from 'int' to 'char*' -
    - -

    -As far as I know, g++ follows the current draft here. -

    -

    -Does the committee really intend to break compatibility for such cases? -

    - -

    [ -Sylvain adds: -]

    - - -
    -

    -I just noticed that std::pair has the same issue. -The following now fails with GCC's -std=c++0x mode: -

    - -
    #include <utility>
-
-int main()
-{
-   std::pair<char *, char *> p (0,0);
-}
-
    - -

    -I have not made any general audit for such problems elsewhere. -

    -
    - -

    [ -Related to 756 -]

    - - -

    [ -Bellevue: -]

    - - -
    -

    -Motivation is to handle the old-style int-zero-valued NULL pointers. -Problem: this solution requires concepts in some cases, which some users -will be slow to adopt. Some discussion of alternatives involving -prohibiting variadic forms and additional library-implementation -complexity. -

    -

    -Discussion of "perfect world" solutions, the only such solution put -forward being to retroactively prohibit use of the integer zero for a -NULL pointer. This approach was deemed unacceptable given the large -bodies of pre-existing code that do use integer zero for a NULL pointer. -

    -

    -Another approach is to change the member names. Yet another approach is -to forbid the extension in absence of concepts. -

    -

    -Resolution: These issues (756, 767, 760, 763) will be subsumed into a -paper to be produced by Alan Talbot in time for review at the 2008 -meeting in France. Once this paper is produced, these issues will be -moved to NAD. -

    -
    - - - -

    Proposed resolution:

    -

    -Add the following rows to Table 90 "Optional sequence container operations", 23.1.3 [sequence.reqmts]: -

    - -
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    expression return type assertion/note
    pre-/post-condition    		 container
    -a.push_front(t) - -void - -a.insert(a.begin(), t)
    -Requires: T shall be CopyConstructible. -    		 -list, deque -
    -a.push_front(rv) - -void - -a.insert(a.begin(), rv)
    -Requires: T shall be MoveConstructible. -    		 -list, deque -
    -a.push_back(t) - -void - -a.insert(a.end(), t)
    -Requires: T shall be CopyConstructible. -    		 -list, deque, vector, basic_string -
    -a.push_back(rv) - -void - -a.insert(a.end(), rv)
    -Requires: T shall be MoveConstructible. -    		 -list, deque, vector, basic_string -
    -
    - -

    -Change the synopsis in 23.2.2 [deque]: -

    - -
    void push_front(const T& x);
-void push_front(T&& x);
-void push_back(const T& x);
-void push_back(T&& x);
-template <class... Args> requires Constructible<T, Args&&...> void push_front(Args&&... args);
-template <class... Args> requires Constructible<T, Args&&...> void push_back(Args&&... args);
-
    - -

    -Change 23.2.2.3 [deque.modifiers]: -

    - -
    void push_front(const T& x);
-void push_front(T&& x);
-void push_back(const T& x);
-void push_back(T&& x);
-template <class... Args> requires Constructible<T, Args&&...> void push_front(Args&&... args);
-template <class... Args> requires Constructible<T, Args&&...> void push_back(Args&&... args);
-
    - -

    -Change the synopsis in 23.2.4 [list]: -

    - -
    void push_front(const T& x);
-void push_front(T&& x);
-void push_back(const T& x);
-void push_back(T&& x);
-template <class... Args> requires Constructible<T, Args&&...> void push_front(Args&&... args);
-template <class... Args> requires Constructible<T, Args&&...> void push_back(Args&&... args);
-
    - -

    -Change 23.2.4.3 [list.modifiers]: -

    - -
    void push_front(const T& x);
-void push_front(T&& x);
-void push_back(const T& x);
-void push_back(T&& x);
-template <class... Args> requires Constructible<T, Args&&...> void push_front(Args&&... args);
-template <class... Args> requires Constructible<T, Args&&...> void push_back(Args&&... args);
-
    - -

    -Change the synopsis in 23.2.6 [vector]: -

    - -
    void push_back(const T& x);
-void push_back(T&& x);
-template <class... Args> requires Constructible<T, Args&&...> void push_back(Args&&... args);
-
    - -

    -Change 23.2.6.4 [vector.modifiers]: -

    - -
    void push_back(const T& x);
-void push_back(T&& x);
-template <class... Args> requires Constructible<T, Args&&...> void push_back(Args&&... args);
-
    - - - - -

    Rationale:

    -

    -Addressed by -N2680 Proposed Wording for Placement Insert (Revision 1). -

    - -

    -If there is still an issue with pair, Howard should submit another issue. -

    - - - - - -
    -

    773. issues with random

    -

    Section: 26.4.8.1 [rand.dist.uni] Status: NAD - Submitter: P.J. Plauger Date: 2008-01-14

    -

    View all other issues in [rand.dist.uni].

    -

    View all issues with NAD status.

    -

    Discussion:

    -
      -
    1. -26.4.8.1.1 [rand.dist.uni.int] uniform_int constructor has changed the default -max constructor parameter from 9 (in TR1) to max(). The value -is arbitrary at best and shouldn't be lightly changed because -it breaks backward compatibility. -
      2. - -
    2. -26.4.8.1.1 [rand.dist.uni.int] uniform_int has a parameter param that you can -provide on construction or operator(), set, and get. But there -is not even a hint of what this might be for. -
      3. - -
    3. -26.4.8.1.2 [rand.dist.uni.real] uniform_real. Same issue as #2. -
      4. -
    - -

    [ -Bellevue: -]

    - - -
    -NAD. Withdrawn. -
    - - -

    Proposed resolution:

    -

    -

    - - - - - -
    -

    784. unique_lock::release

    -

    Section: 30.3.3.2.3 [thread.lock.unique.mod] Status: NAD - Submitter: Constantine Sapuntzakis Date: 2008-02-02

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    -unique_lock::release will probably lead to many mistakes where people -call release instead of unlock. I just coded such a mistake using the -boost pre-1.35 threads library last week. -

    - -

    -In many threading libraries, a call with release in it unlocks the -lock (e.g. ReleaseMutex in Win32, java.util.concurrent.Semaphore). -

    - -

    -I don't call unique_lock::lock much at all, so I don't get to see the -symmetry between ::lock and ::unlock. I usually use the constructor to -lock the mutex. So I'm left to remember whether to call release or -unlock during the few times I need to release the mutex before the scope -ends. If I get it wrong, the compiler doesn't warn me. -

    - -

    -An alternative name for release may be disown. -

    - -

    -This might be a rare case where usability is hurt by consistency with -the rest of the C++ standard (e.g. std::auto_ptr::release). -

    - -

    [ -Bellevue: -]

    - - -
    -Change a name from release to disown. However prior art uses the release -name. Compatibility with prior art is more important that any possible -benefit such a change might make. We do not see the benefit for -changing. NAD -
    - - -

    Proposed resolution:

    -

    -Change the synopsis in 30.3.3.2 [thread.lock.unique]: -

    - -
    template <class Mutex> 
-class unique_lock 
-{ 
-public:
-   ...
-   mutex_type* release disown();
-   ...
-};
-
    - -

    -Change 30.3.3.2.3 [thread.lock.unique.mod]: -

    - -
    mutex_type *release disown();
-
    - - - - - -
    -

    786. Thread library timed waits, UTC and monotonic clocks

    -

    Section: X [datetime.system] Status: NAD Editorial - Submitter: Christopher Kohlhoff, Jeff Garland Date: 2008-02-03

    -

    View all issues with NAD Editorial status.

    -

    Discussion:

    -

    -The draft C++0x thread library requires that the time points of type -system_time and returned by get_system_time() represent Coordinated -Universal Time (UTC) (section X [datetime.system]). This can lead to -surprising behavior when a library user performs a duration-based wait, -such as condition_variable::timed_wait(). A complete explanation of the -problem may be found in the -Rationale for the Monotonic Clock -section in POSIX, but in summary: -

    - -
      -
    • -Operations such as condition_variable::timed_wait() (and its POSIX -equivalent, pthread_cond_timedwait()) are specified using absolute times -to address the problem of spurious wakeups. -
      • - -
    • -The typical use of the timed wait operations is to perform a relative -wait. This may be achieved by first calculating an absolute time as the -sum of the current time and the desired duration. In fact, the C++0x -thread library includes duration-based overloads of -condition_variable::timed_wait() that behave as if by calling the -corresponding absolute time overload with a time point value of -get_system_time() + rel_time. -
      • - -
    • -A UTC clock may be affected by changes to the system time, such as -synchronization with an external source, leap seconds, or manual changes -to the clock. -
      • - -
    • -Should the clock change during a timed wait operation, the actual -duration of the wait will not be the expected length. For example, a -user may intend a timed wait of one second duration but, due to an -adjustment of the system clock backwards by a minute, the wait instead -takes 61 seconds. -
      • -
    - -

    -POSIX solves the problem by introducing a new monotonic clock, which is -unaffected by changes to the system time. When a condition variable is -initialized, the user may specify whether the monotonic clock is to be -used. (It is worth noting that on POSIX systems it is not possible to -use condition_variable::native_handle() to access this facility, since -the desired clock type must be specified during construction of the -condition variable object.) -

    - -

    -In the context of the C++0x thread library, there are added dimensions -to the problem due to the need to support platforms other than POSIX: -

    - -
      -
    • -Some environments (such as embedded systems) do not have a UTC clock, but do have a monotonic clock. -
      • - -
    • -Some environments do not have a monotonic clock, but do have a UTC clock. -
      • - -
    • -The Microsoft Windows API's synchronization functions use relative -timeouts based on an implied monotonic clock. A program that switches -from the Windows API to the C++0x thread library will now find itself -susceptible to clock changes. -
      • -
    - -

    -One possible minimal solution: -

    - -
      -
    • -Strike normative references to UTC and an epoch based on 1970-01-01. -
      • - -
    • -Make the semantics of system_time and get_system_time() -implementation-defined (i.e standard library implementors may choose the -appropriate underlying clock based on the capabilities of the target -platform). -
      • - -
    • -Add a non-normative note encouraging use of a monotonic clock. -
      • - -
    • -Remove system_time::seconds_since_epoch(). -
      • - -
    • -Change the constructor explicit system_time(time_t secs, nanoseconds ns -= 0) to explicit system_time(nanoseconds ns). -
      • -
    - - - -

    Proposed resolution:

    -

    -

    - - -

    Rationale:

    -Addressed by -N2661: A Foundation to Sleep On. - - - - - -
    -

    790. xor_combine::seed not specified

    -

    Section: 26.4.4.4 [rand.adapt.xor] Status: NAD - Submitter: P.J. Plauger Date: 2008-02-09

    -

    View all other issues in [rand.adapt.xor].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    -xor_combine::seed(result_type) and seed(seed_seq&) don't say what -happens to each of the sub-engine seeds. (Should probably do the same -to both, unlike TR1.) -

    - -

    [ -Bellevue: -]

    - - -
    -Overcome by the previous proposal. NAD mooted by resolution of 789. -
    - - - -

    Proposed resolution:

    - - - - - -
    -

    791. piecewise_constant_distribution::densities has wrong name

    -

    Section: 26.4.8.5.2 [rand.dist.samp.pconst] Status: NAD - Submitter: P.J. Plauger Date: 2008-02-09

    -

    View other active issues in [rand.dist.samp.pconst].

    -

    View all other issues in [rand.dist.samp.pconst].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    -piecewise_constant_distribution::densities() should be probabilities(), -just like discrete_distribution. (There's no real use for weights divided -by areas.) -

    - -

    [ -Bellevue: -]

    - - -
    -

    -Fermilab does not agree with this summary. As defined in the equation in -26.4.8.5.2/4, the quantities are indeed probability densities not -probabilities. Because we view this distribution as a parameterization -of a *probability density function*, we prefer to work in terms of -probability densities. -

    - -

    -We don't think this should be changed. -

    - -

    -If there is a technical argument about why the implementation dealing -with these values can't be as efficient as one dealing with -probabilities, we might reconsider. We don't care about this one member -function being somewhat more or less efficient; we care about the size -of the distribution object and the speed of the calls to generate -variates. -

    -
    - - - -

    Proposed resolution:

    - -

    -Change synopsis in 26.4.8.5.2 [rand.dist.samp.pconst]: -

    - -
    template <class RealType = double> 
-class piecewise_constant_distribution 
-{ 
-public:
-    ...
-    vector<double> densities probabilities() const;
-    ...
-};
-
    - -

    -Change 26.4.8.5.2 [rand.dist.samp.pconst]/6: -

    - -
    vector<double> densities probabilities() const;
-
    - - - - - - -
    -

    795. general_pdf_distribution should be dropped

    -

    Section: 26.4.8.5.3 [rand.dist.samp.genpdf] Status: Dup - Submitter: P.J. Plauger Date: 2008-02-09

    -

    View all other issues in [rand.dist.samp.genpdf].

    -

    View all issues with Dup status.

    -

    Duplicate of: 732

    -

    Discussion:

    -

    -general_pdf_distribution should be dropped. (It's a research topic in -adaptive numerical integration.) -

    - -

    [ -Stephan Tolksdorf notes: -]

    - - -
    -This appears to be a duplicate of 732. -
    - - -

    Proposed resolution:

    - - - - - - -
    -

    796. ranlux48_base returns wrong value

    -

    Section: 26.4.5 [rand.predef] Status: NAD - Submitter: P.J. Plauger Date: 2008-02-09

    -

    View all other issues in [rand.predef].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    -The 10,000th value returned by ranlux48_base is supposed to be -61839128582725. We get 192113843633948. (Note that the underlying -generator was changed in Kona.) -

    - -

    [ -Bellevue: -]

    - - -
    -Submitter withdraws defect. -
    - - - -

    Proposed resolution:

    -

    -Change 26.4.5 [rand.predef]/p5: -

    - -
    -
    typedef subtract_with_carry_engine<uint_fast64_t, 48, 5, 12> 
-        ranlux48_base; 
-
    -
    -Required behavior: The 10000th consecutive invocation of a default-constructed -object of type ranlux48_base shall produce the value -61839128582725 192113843633948. -
    -
    - - - - - -
    -

    797. ranlux48 returns wrong value

    -

    Section: 26.4.5 [rand.predef] Status: NAD - Submitter: P.J. Plauger Date: 2008-02-09

    -

    View all other issues in [rand.predef].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    -The 10,000th value returned by ranlux48 is supposed to be -249142670248501. We get 88229545517833. (Note that this depends -on ranlux48_base.) -

    -

    [ -Bellevue: -]

    - - -
    -Submitter withdraws defect. -
    - - - -

    Proposed resolution:

    -

    -Change 26.4.5 [rand.predef]/p6: -

    - -
    -
    typedef discard_block_engine<ranlux48_base, 389, 11> 
-        ranlux48
-
    -
    -Required behavior: The 10000th consecutive invocation of a default-constructed -object of type ranlux48 shall produce the value -249142670248501 88229545517833. -
    -
    - - - - - -
    -

    799. [tr.rand.eng.mers] and [rand.eng.mers]

    -

    Section: 26.4.3.2 [rand.eng.mers], TR1 5.1.4.2 [tr.rand.eng.mers] Status: NAD - Submitter: Stephan Tolksdorf Date: 2008-02-18

    -

    View all other issues in [rand.eng.mers].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    -TR1 5.1.4.2 [tr.rand.eng.mers](10) requires that operator== for the mersenne_twister -returns true if and only if the states of two mersenne_twisters, -consisting each of n integers between 0 and 2w - 1, are completely -equal. This is a contradiction with TR1 5.1.1 [tr.rand.req](3) because the given -definition of the state also includes the lower r bits of x(i-n), which -will never be used to generate a random number. If two mersenne_twisters -only differ in the lower bits of x(i-n) they will not compare equal, -although they will produce an identical sequence of random numbers. -

    - -

    -26.4.3.2 [rand.eng.mers] in the latest C++ draft does not specify the behaviour -of operator== but uses a similar definition of the state and, just like -TR1 5.1.4.2 [tr.rand.eng.mers], requires the textual representation of a -mersenne_twister_engine to consist of Xi-n to Xi-1, including the -lower bits of Xi-n. This leads to two problems: First, the -unsuspecting implementer is likely to erroneously compare the lower r -bits of Xi-n in operator==. Second, if only the lower r bits differ, -two mersenne_twister_engines will compare equal (if correctly -implemented) but have different textual representations, which -conceptually is a bit ugly. -

    - -

    -I propose that a paragraph or footnote is added to 26.4.3.2 [rand.eng.mers] which -clarifies that the lower r bits of Xi-n are not to be compared in -operator== and operator!=. It would only be consequent if furthermore -the specification for the textual respresentation was changed to -Xi-n bitand ((2w - 1) - (2r - 1)), Xi-(n-1), ..., Xi-1 or -something similar. -

    - -

    -These changes would likely have no practical effect, but would allow an -implementation that does the right thing to be standard-conformant. -

    - -

    [ -Bellevue: -]

    - - -
    -

    -Fermi Lab has no objection to the proposed change. However it feels that -more time is needed to check the details, which would suggest a change -to REVIEW. -

    -

    -Bill feels that this is NAD, not enough practical importance to abandon -the simple definition of equality, and someone would have to do a lot -more study to ensure that all cases are covered for a very small -payback. The submitter admits that "These changes would likely have no -practical effect,", and according to Plum's razor this means that it is -not worth the effort! -

    -

    -Revisted: Agree that the fact that there is no practical difference means that no change can be justified. -

    -
    - - -

    Proposed resolution:

    -

    -In 26.4.3.2 [rand.eng.mers]: -

    - -
    -

    -Insert at the end of para 2.: -

    - -
    -[Note: The lower r bits of Xi-n do not influence -the state transition and hence should not be compared when comparing two -mersenne_twister_engine objects. -- end note] -
    - -

    -In para 5. change: -

    - -
    -The textual representation of xi consists of the values of -Xi-n bitand ((2w - 1) - (2r - 1)), Xi-(n-1), -..., Xi-1, in that order. -
    -
    - - - - - -
    -

    802. knuth_b returns wrong value

    -

    Section: 26.4.5 [rand.predef] Status: NAD - Submitter: P.J. Plauger Date: 2008-02-20

    -

    View all other issues in [rand.predef].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    -The 10,000th value returned by knuth_b is supposed to be -1112339016. We get 2126698284. -

    - - -

    Proposed resolution:

    -

    -Change 26.4.5 [rand.predef]/p8: -

    - -
    -
    typedef shuffle_order_engine<minstd_rand0, 256> 
-        knuth_b; 
-
    -
    -Required behavior: The 10000th consecutive invocation of a default-constructed -object of type knuth_b shall produce the value -1112339016 2126698284. -
    -
    - - -

    [ -Bellevue: Submitter withdraws defect. "We got the wrong value for entirely the right reasons". NAD. -]

    - - - - - -
    -

    826. Equivalent of %'d, or rather, lack thereof?

    -

    Section: 22.2.2.2 [locale.nm.put] Status: NAD - Submitter: Peter Dimov Date: 2008-04-07

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    -In the spirit of printf vs iostream... -

    - -

    -POSIX printf says that %'d should insert grouping characters (and the -implication is that in the absence of ' no grouping characters are -inserted). The num_put facet, on the other hand, seems to always insert -grouping characters. Can this be considered a defect worth fixing for -C++0x? Maybe ios_base needs an additional flag? -

    - -

    [ -Pablo Halpern: -]

    - - -
    -I'm not sure it constitutes a defect, but I would be in favor of adding -another flag (and corresponding manipulator). -
    - -

    [ -Martin Sebor: -]

    - - -
    -I don't know if it qualifies as a defect but I agree that there -should be an easy way to control whether the thousands separator -should or shouldn't be inserted. A new flag would be in line with -the current design of iostreams (like boolalpha, showpos, or -showbase). -
    - -

    [ -Sophia Antipolis: -]

    - - -
    -This is not a part of C99. LWG suggests submitting a paper may be appropriate. -
    - - - -

    Proposed resolution:

    -

    -

    - - - - - -
    -

    831. wrong type for not_eof()

    -

    Section: 21.1.3 [char.traits.specializations] Status: NAD Editorial - Submitter: Dietmar Kühl Date: 2008-04-23

    -

    View all other issues in [char.traits.specializations].

    -

    View all issues with NAD Editorial status.

    -

    Discussion:

    -

    - In Table 56 (Traits requirements) the not_eof() member function - is using an argument of type e which denotes an object of - type X::int_type. However, the specializations in - 21.1.3 [char.traits.specializations] all use char_type. - This would effectively mean that the argument type actually can't - represent EOF in the first place. I'm pretty sure that the type used - to be int_type which is quite obviously the only sensible - argument. -

    -

    - This issue is close to being editorial. I suspect that the proposal - changing this section to include the specializations for char16_t - and char32_t accidentally used the wrong type. -

    - - -

    Proposed resolution:

    -

    - In 21.1.3.1 [char.traits.specializations.char], - 21.1.3.2 [char.traits.specializations.char16_t], - 21.1.3.3 [char.traits.specializations.char32_t], and - [char.traits.specializations.wchar_t] correct the - argument type from char_type to int_type. -

    - - -

    Rationale:

    -Already fixed in WP. - - - - - -
    -

    840. pair default template argument

    -

    Section: 20.2.3 [pairs] Status: NAD - Submitter: Thorsten Ottosen Date: 2008-05-23

    -

    View all other issues in [pairs].

    -

    View all issues with NAD status.

    -

    Discussion:

    -

    -I have one issue with std::pair. Well, it might just be a very annoying -historical accident, but why is there no default template argument for -the second template argument? This is so annoying when the type in -question is looong and hard to write (type deduction with auto won't -help those cases where we use it as a return or argument type). -

    - - -

    Proposed resolution:

    -

    -Change the synopsis in 20.2 [utility] to read: -

    - -
    template <class T1, class T2 = T1> struct pair;
-
    - -

    -Change 20.2.3 [pairs] to read: -

    - -
    namespace std {
- template <class T1, class T2 = T1>
- struct pair {
-   typedef T1 first_type;
-   typedef T2 second_type;
-   ...
-
    - - -

    Rationale:

    -std::pair is a heterogeneous container. - - - - - - \ No newline at end of file diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/lwg-defects.html b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/lwg-defects.html deleted file mode 100644 index 5951a9821..000000000 --- a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/lwg-defects.html +++ /dev/null @@ -1,29778 +0,0 @@ - - - - - -C++ Standard Library Defect Report List - - - - - - - - - - - - - - - - - - - -
    Doc. no.N2728=08-0238
    Date:2008-08-24
    Project:Programming Language C++
    Reply to:Howard Hinnant <howard.hinnant@gmail.com>
    -

    C++ Standard Library Defect Report List (Revision R59)

    - -

    Reference ISO/IEC IS 14882:1998(E)

    -

    Also see:

    - -

    This document contains only library issues which have been closed - by the Library Working Group (LWG) after being found to be defects - in the standard. That is, issues which have a status of DR, - TC, or RR. See the - Library Closed Issues List for issues closed as non-defects. See the - Library Active Issues List for active issues and more information. The - introductory material in that document also applies to this - document.

    - -

    Revision History

    -
      -
    • R59: -2008-08-22 pre-San Francisco mailing. -
        -
      • Summary:
          -
        • 192 open issues, up by 9.
          • -
        • 686 closed issues, up by 0.
          • -
        • 878 issues total, up by 9.
          • -
        • -
      • Details:
        • -
      -
      • -
    • R58: -2008-07-28 mid-term mailing. -
        -
      • Summary:
          -
        • 183 open issues, up by 12.
          • -
        • 686 closed issues, down by 4.
          • -
        • 869 issues total, up by 8.
          • -
        • -
      • Details:
          -
        • Added the following New issues: 862, 863, 864, 865, 866, 867, 868, 869.
          • -
        • Changed the following issues from Pending NAD Editorial to NAD Editorial: 393, 557, 592, 754, 757.
          • -
        • Changed the following issues from Pending WP to Open: 644.
          • -
        • Changed the following issues from WP to Ready: 387, 629.
          • -
        • Changed the following issues from Pending NAD Editorial to Review: 709.
          • -
        • -
      -
      • -
    • R57: -2008-06-27 post-Sophia Antipolis mailing. - -
      • -
    • R56: -2008-05-16 pre-Sophia Antipolis mailing. - -
      • -
    • R55: -2008-03-14 post-Bellevue mailing. - -
      • -
    • R54: -2008-02-01 pre-Bellevue mailing. -
        -
      • Summary:
          -
        • 206 open issues, up by 23.
          • -
        • 581 closed issues, up by 0.
          • -
        • 787 issues total, up by 23.
          • -
        • -
      • Details:
          -
        • Added the following New issues: 765, 766, 767, 768, 769, 770, 771, 772, 773, 774, 775, 776, 777, 778, 779, 780, 781, 782, 783, 784, 785, 786, 787.
          • -
        • Changed the following issues from NAD Future to Dup: 105, 348.
          • -
        • Changed the following issues from NAD Future to NAD Editorial: 353.
          • -
        • Changed the following issues from New to NAD Editorial: 697.
          • -
        • Changed the following issues from NAD Future to Open: 388.
          • -
        • Changed the following issues from Open to Tentatively Ready: 527.
          • -
        • -
      -
      • -
    • R53: -2007-12-09 mid-term mailing. -
        -
      • Summary:
          -
        • 183 open issues, up by 11.
          • -
        • 581 closed issues, down by 1.
          • -
        • 764 issues total, up by 10.
          • -
        • -
      • Details:
        • -
      -
      • -
    • R52: -2007-10-19 post-Kona mailing. - -
      • -
    • R51: -2007-09-09 pre-Kona mailing. - -
      • -
    • R50: -2007-08-05 post-Toronto mailing. -
        -
      • Summary:
          -
        • 153 open issues, down by 5.
          • -
        • 555 closed issues, up by 17.
          • -
        • 708 issues total, up by 12.
          • -
        • -
      • Details:
          -
        • Added the following New issues: 697, 698, 699, 700, 701, 702, 703, 704, 705, 706, 707, 708.
          • -
        • Changed the following issues from New to NAD: 583, 584, 662.
          • -
        • Changed the following issues from Open to NAD: 528.
          • -
        • Changed the following issues from New to NAD Editorial: 637, 647, 658, 690.
          • -
        • Changed the following issues from Open to NAD Editorial: 525.
          • -
        • Changed the following issues from Pending NAD Editorial to NAD Editorial: 553, 571, 591, 633, 636, 641, 642, 648, 649, 656.
          • -
        • Changed the following issues from New to Open: 579, 631, 680.
          • -
        • Changed the following issues from Pending WP to Open: 258.
          • -
        • Changed the following issues from Ready to Pending WP: 644.
          • -
        • Changed the following issues from New to Ready: 577, 660.
          • -
        • Changed the following issues from Open to Ready: 488.
          • -
        • Changed the following issues from Open to Review: 518.
          • -
        • Changed the following issues from Ready to TRDec: 604.
          • -
        • Changed the following issues from DR to WP: 453.
          • -
        • Changed the following issues from Ready to WP: 531, 551, 566, 628, 640, 643, 646.
          • -
        • -
      -
      • -
    • R49: -2007-06-23 pre-Toronto mailing. -
        -
      • Summary:
          -
        • 158 open issues, up by 13.
          • -
        • 538 closed issues, up by 7.
          • -
        • 696 issues total, up by 20.
          • -
        • -
      • Details:
          -
        • Added the following New issues: 677, 678, 679, 680, 681, 682, 684, 685, 686, 687, 688, 689, 690, 691, 692, 693, 694, 695, 696.
          • -
        • Added the following Pending NAD Editorial issues: 683.
          • -
        • Changed the following issues from New to NAD Editorial: 587.
          • -
        • Changed the following issues from Open to NAD Editorial: 590.
          • -
        • Changed the following issues from New to Pending NAD Editorial: 636, 642, 648, 649.
          • -
        • -
      -
      • -
    • R48: -2007-05-06 post-Oxford mailing. - -
      • -
    • R47: -2007-03-09 pre-Oxford mailing. - -
      • -
    • R46: -2007-01-12 mid-term mailing. -
        -
      • Summary:
          -
        • 141 open issues, up by 11.
          • -
        • 478 closed issues, down by 1.
          • -
        • 619 issues total, up by 10.
          • -
        • -
      • Details:
        • -
      -
      • -
    • R45: -2006-11-03 post-Portland mailing. - -
      • -
    • R44: -2006-09-08 pre-Portland mailing. -
        -
      • Summary:
          -
        • 130 open issues, up by 6.
          • -
        • 462 closed issues, down by 1.
          • -
        • 592 issues total, up by 5.
          • -
        • -
      • Details:
        • -
      -
      • -
    • R43: -2006-06-23 mid-term mailing. -
        -
      • Summary:
          -
        • 124 open issues, up by 14.
          • -
        • 463 closed issues, down by 1.
          • -
        • 587 issues total, up by 13.
          • -
        • -
      • Details:
        • -
      -
      • -
    • R42: -2006-04-21 post-Berlin mailing. - -
      • -
    • R41: -2006-02-24 pre-Berlin mailing. -
        -
      • Summary:
          -
        • 126 open issues, up by 31.
          • -
        • 440 closed issues, up by 0.
          • -
        • 566 issues total, up by 31.
          • -
        • -
      • Details:
          -
        • Added new issues 536-566.
          • -
        • Moved 342 from Ready to Open.
          • -
        • Reopened 309.
          • -
        • -
      -
      • -
    • R40: -2005-12-16 mid-term mailing. -
        -
      • Summary:
          -
        • 95 open issues.
          • -
        • 440 closed issues.
          • -
        • 535 issues total.
          • -
        • -
      • Details:
        • -
      -
      • -
    • R39: -2005-10-14 post-Mont Tremblant mailing. -Added new issues 526-528. -Moved issues 280, 461, 464, 465, 467, 468, 474, 496 from Ready to WP as per the vote from Mont Tremblant. -Moved issues 247, 294, 342, 362, 369, 371, 376, 384, 475, 478, 495, 497 from Review to Ready. -Moved issues 498, 504, 506, 509, 510, 511, 512, 513, 514 from New to Open. -Moved issues 505, 507, 508, 519 from New to Ready. -Moved issue 500 from New to NAD. -Moved issue 518 from New to Review. -
      • -
    • R38: -2005-07-03 pre-Mont Tremblant mailing. -Merged open TR1 issues in 504-522. -Added new issues 523-523 -
      • -
    • R37: -2005-06 mid-term mailing. -Added new issues 498-503. -
      • -
    • R36: -2005-04 post-Lillehammer mailing. All issues in "ready" status except -for 454 were moved to "DR" status, and all issues -previously in "DR" status were moved to "WP". -
      • -
    • R35: -2005-03 pre-Lillehammer mailing. -
      • -
    • R34: -2005-01 mid-term mailing. Added new issues 488-494. -
      • -
    • R33: -2004-11 post-Redmond mailing. Reflects actions taken in Redmond. -
      • -
    • R32: -2004-09 pre-Redmond mailing: reflects new proposed resolutions and -new issues received after the 2004-07 mailing. Added -new issues 479-481. -
      • -
    • R31: -2004-07 mid-term mailing: reflects new proposed resolutions and -new issues received after the post-Sydney mailing. Added -new issues 463-478. -
      • -
    • R30: -Post-Sydney mailing: reflects decisions made at the Sydney meeting. -Voted all "Ready" issues from R29 into the working paper. -Added new issues 460-462. -
      • -
    • R29: -Pre-Sydney mailing. Added new issues 441-457. -
      • -
    • R28: -Post-Kona mailing: reflects decisions made at the Kona meeting. -Added new issues 432-440. -
      • -
    • R27: -Pre-Kona mailing. Added new issues 404-431. -
      • -
    • R26: -Post-Oxford mailing: reflects decisions made at the Oxford meeting. -All issues in Ready status were voted into DR status. All issues in -DR status were voted into WP status. -
      • -
    • R25: -Pre-Oxford mailing. Added new issues 390-402. -
      • -
    • R24: -Post-Santa Cruz mailing: reflects decisions made at the Santa Cruz -meeting. All Ready issues from R23 with the exception of 253, which has been given a new proposed resolution, were -moved to DR status. Added new issues 383-389. (Issues 387-389 were discussed -at the meeting.) Made progress on issues 225, 226, 229: 225 and 229 have been moved to Ready status, and the only remaining -concerns with 226 involve wording. -
      • -
    • R23: -Pre-Santa Cruz mailing. Added new issues 367-382. -Moved issues in the TC to TC status. -
      • -
    • R22: -Post-Curaçao mailing. Added new issues 362-366. -
      • -
    • R21: -Pre-Curaçao mailing. Added new issues 351-361. -
      • -
    • R20: -Post-Redmond mailing; reflects actions taken in Redmond. Added -new issues 336-350, of which issues -347-350 were added since Redmond, hence -not discussed at the meeting. - -All Ready issues were moved to DR status, with the exception of issues -284, 241, and 267. - -Noteworthy issues discussed at Redmond include -120 202, 226, 233, -270, 253, 254, 323. -
      • -
    • R19: -Pre-Redmond mailing. Added new issues -323-335. -
      • -
    • R18: -Post-Copenhagen mailing; reflects actions taken in Copenhagen. -Added new issues 312-317, and discussed -new issues 271-314. - -Changed status of issues -103 118 136 153 -165 171 183 184 -185 186 214 221 -234 237 243 248 -251 252 256 260 -261 262 263 265 -268 -to DR. - -Changed status of issues -49 109 117 182 -228 230 232 235 -238 241 242 250 -259 264 266 267 -271 272 273 275 -281 284 285 286 -288 292 295 297 -298 301 303 306 -307 308 312 -to Ready. - -Closed issues -111 277 279 287 -289 293 302 313 -314 -as NAD. - -
      • -
    • R17: -Pre-Copenhagen mailing. Converted issues list to XML. Added proposed -resolutions for issues 49, 76, 91, 235, 250, 267. -Added new issues 278-311. -
      • -
    • R16: -post-Toronto mailing; reflects actions taken in Toronto. Added new -issues 265-277. Changed status of issues -3, 8, 9, 19, -26, 31, 61, -63, 86, 108, -112, 114, 115, -122, 127, 129, -134, 137, 142, -144, 146, 147, -159, 164, 170, -181, 199, 208, -209, 210, 211, -212, 217, 220, -222, 223, 224, -227 to "DR". Reopened issue 23. Reopened -issue 187. Changed issues 2 and -4 to NAD. Fixed a typo in issue 17. Fixed -issue 70: signature should be changed both places it -appears. Fixed issue 160: previous version didn't fix -the bug in enough places. -
      • -
    • R15: -pre-Toronto mailing. Added issues -233-264. Some small HTML formatting -changes so that we pass Weblint tests. -
      • -
    • R14: -post-Tokyo II mailing; reflects committee actions taken in -Tokyo. Added issues 228 to 232. (00-0019R1/N1242) -
      • -
    • R13: -pre-Tokyo II updated: Added issues 212 to 227. -
      • -
    • R12: -pre-Tokyo II mailing: Added issues 199 to -211. Added "and paragraph 5" to the proposed resolution -of issue 29. Add further rationale to issue -178. -
      • -
    • R11: -post-Kona mailing: Updated to reflect LWG and full committee actions -in Kona (99-0048/N1224). Note changed resolution of issues -4 and 38. Added issues 196 -to 198. Closed issues list split into "defects" and -"closed" documents. Changed the proposed resolution of issue -4 to NAD, and changed the wording of proposed resolution -of issue 38. -
      • -
    • R10: -pre-Kona updated. Added proposed resolutions 83, -86, 91, 92, -109. Added issues 190 to -195. (99-0033/D1209, 14 Oct 99) -
      • -
    • R9: -pre-Kona mailing. Added issues 140 to -189. Issues list split into separate "active" and -"closed" documents. (99-0030/N1206, 25 Aug 99) -
      • -
    • R8: -post-Dublin mailing. Updated to reflect LWG and full committee actions -in Dublin. (99-0016/N1193, 21 Apr 99) -
      • -
    • R7: -pre-Dublin updated: Added issues 130, 131, -132, 133, 134, -135, 136, 137, -138, 139 (31 Mar 99) -
      • -
    • R6: -pre-Dublin mailing. Added issues 127, 128, -and 129. (99-0007/N1194, 22 Feb 99) -
      • -
    • R5: -update issues 103, 112; added issues -114 to 126. Format revisions to prepare -for making list public. (30 Dec 98) -
      • -
    • R4: -post-Santa Cruz II updated: Issues 110, -111, 112, 113 added, several -issues corrected. (22 Oct 98) -
      • -
    • R3: -post-Santa Cruz II: Issues 94 to 109 -added, many issues updated to reflect LWG consensus (12 Oct 98) -
      • -
    • R2: -pre-Santa Cruz II: Issues 73 to 93 added, -issue 17 updated. (29 Sep 98) -
      • -
    • R1: -Correction to issue 55 resolution, 60 code -format, 64 title. (17 Sep 98) -
      • -
    - -

    Defect Reports

    -
    -

    1. C library linkage editing oversight

    -

    Section: 17.4.2.2 [using.linkage] Status: TC - Submitter: Beman Dawes Date: 1997-11-16

    -

    View all issues with TC status.

    -

    Discussion:

    -

    The change specified in the proposed resolution below did not make -it into the Standard. This change was accepted in principle at the -London meeting, and the exact wording below was accepted at the -Morristown meeting.

    - - -

    Proposed resolution:

    -

    Change 17.4.2.2 [using.linkage] paragraph 2 -from:

    - -
    -

    It is unspecified whether a name from the Standard C library - declared with external linkage has either extern "C" or - extern "C++" linkage.

    -
    - -

    to:

    - -
    -

    Whether a name from the Standard C library declared with external - linkage has extern "C" or extern "C++" linkage - is implementation defined. It is recommended that an implementation - use extern "C++" linkage for this purpose.

    -
    - - - - - -
    -

    3. Atexit registration during atexit() call is not described

    -

    Section: 18.4 [support.start.term] Status: TC - Submitter: Steve Clamage Date: 1997-12-12

    -

    View all issues with TC status.

    -

    Discussion:

    -

    We appear not to have covered all the possibilities of - exit processing with respect to -atexit registration.
    -
    -Example 1: (C and C++)

    - -
        #include <stdlib.h>
-    void f1() { }
-    void f2() { atexit(f1); }
-    
-    int main()
-    {
-        atexit(f2); // the only use of f2
-        return 0; // for C compatibility
-    }
    - -

    At program exit, f2 gets called due to its registration in -main. Running f2 causes f1 to be newly registered during the exit -processing. Is this a valid program? If so, what are its -semantics?

    - -

    -Interestingly, neither the C standard, nor the C++ draft standard nor -the forthcoming C9X Committee Draft says directly whether you can -register a function with atexit during exit processing.

    - -

    -All 3 standards say that functions are run in reverse order of their -registration. Since f1 is registered last, it ought to be run first, -but by the time it is registered, it is too late to be first.

    - -

    If the program is valid, the standards are self-contradictory about -its semantics.

    - -

    Example 2: (C++ only)

    - -
        
-    void F() { static T t; } // type T has a destructor
-
-    int main()
-    {
-        atexit(F); // the only use of F
-    }
-
    - -

    Function F registered with atexit has a local static variable t, -and F is called for the first time during exit processing. A local -static object is initialized the first time control flow passes -through its definition, and all static objects are destroyed during -exit processing. Is the code valid? If so, what are its semantics?

    - -

    -Section 18.3 "Start and termination" says that if a function -F is registered with atexit before a static object t is initialized, F -will not be called until after t's destructor completes.

    - -

    -In example 2, function F is registered with atexit before its local -static object O could possibly be initialized. On that basis, it must -not be called by exit processing until after O's destructor -completes. But the destructor cannot be run until after F is called, -since otherwise the object could not be constructed in the first -place.

    - -

    If the program is valid, the standard is self-contradictory about -its semantics.

    - -

    I plan to submit Example 1 as a public comment on the C9X CD, with -a recommendation that the results be undefined. (Alternative: make it -unspecified. I don't think it is worthwhile to specify the case where -f1 itself registers additional functions, each of which registers -still more functions.)

    - -

    I think we should resolve the situation in the whatever way the C -committee decides.

    - -

    For Example 2, I recommend we declare the results undefined.

    - -

    [See reflector message lib-6500 for further discussion.]

    - - - - -

    Proposed resolution:

    -

    Change section 18.3/8 from:

    -

    - First, objects with static storage duration are destroyed and - functions registered by calling atexit are called. Objects with - static storage duration are destroyed in the reverse order of the - completion of their constructor. (Automatic objects are not - destroyed as a result of calling exit().) Functions registered with - atexit are called in the reverse order of their registration. A - function registered with atexit before an object obj1 of static - storage duration is initialized will not be called until obj1's - destruction has completed. A function registered with atexit after - an object obj2 of static storage duration is initialized will be - called before obj2's destruction starts. -

    -

    to:

    -

    - First, objects with static storage duration are destroyed and - functions registered by calling atexit are called. Non-local objects - with static storage duration are destroyed in the reverse order of - the completion of their constructor. (Automatic objects are not - destroyed as a result of calling exit().) Functions registered with - atexit are called in the reverse order of their registration, except - that a function is called after any previously registered functions - that had already been called at the time it was registered. A - function registered with atexit before a non-local object obj1 of - static storage duration is initialized will not be called until - obj1's destruction has completed. A function registered with atexit - after a non-local object obj2 of static storage duration is - initialized will be called before obj2's destruction starts. A local - static object obj3 is destroyed at the same time it would be if a - function calling the obj3 destructor were registered with atexit at - the completion of the obj3 constructor. -

    - - -

    Rationale:

    -

    See 99-0039/N1215, October 22, 1999, by Stephen D. Clamage for the analysis -supporting to the proposed resolution.

    - - - - - -
    -

    5. String::compare specification questionable

    -

    Section: 21.3.6.8 [string::swap] Status: TC - Submitter: Jack Reeves Date: 1997-12-11

    -

    View all other issues in [string::swap].

    -

    View all issues with TC status.

    -

    Duplicate of: 87

    -

    Discussion:

    -

    At the very end of the basic_string class definition is the signature: int -compare(size_type pos1, size_type n1, const charT* s, size_type n2 = npos) const; In the -following text this is defined as: returns -basic_string<charT,traits,Allocator>(*this,pos1,n1).compare( -basic_string<charT,traits,Allocator>(s,n2);

    - -

    Since the constructor basic_string(const charT* s, size_type n, const Allocator& a -= Allocator()) clearly requires that s != NULL and n < npos and further states that it -throws length_error if n == npos, it appears the compare() signature above should always -throw length error if invoked like so: str.compare(1, str.size()-1, s); where 's' is some -null terminated character array.

    - -

    This appears to be a typo since the obvious intent is to allow either the call above or -something like: str.compare(1, str.size()-1, s, strlen(s)-1);

    - -

    This would imply that what was really intended was two signatures int compare(size_type -pos1, size_type n1, const charT* s) const int compare(size_type pos1, size_type n1, const -charT* s, size_type n2) const; each defined in terms of the corresponding constructor.

    - - -

    Proposed resolution:

    -

    Replace the compare signature in 21.3 [basic.string] -(at the very end of the basic_string synopsis) which reads:

    - -
    -

    int compare(size_type pos1, size_type n1,
    -             const charT* s, - size_type n2 = npos) const;

    -
    - -

    with:

    - -
    -

    int compare(size_type pos1, size_type n1,
    -             const charT* s) const;
    - int compare(size_type pos1, size_type n1,
    -             const charT* s, - size_type n2) const;

    -
    - -

    Replace the portion of 21.3.6.8 [string::swap] -paragraphs 5 and 6 which read:

    - -
    -

    int compare(size_type pos, size_type n1,
    -             charT * s, size_type n2 - = npos) const;
    -     Returns:
    - basic_string<charT,traits,Allocator>(*this, pos, n1).compare(
    -              - basic_string<charT,traits,Allocator>( s, n2))

    -
    - -

    with:

    - -
    -

    int compare(size_type pos, size_type n1,
    -             const charT * s) const;
    -     Returns:
    - basic_string<charT,traits,Allocator>(*this, pos, n1).compare(
    -              - basic_string<charT,traits,Allocator>( s ))
    -
    - int compare(size_type pos, size_type n1,
    -             const charT * s, - size_type n2) const;
    -     Returns:
    - basic_string<charT,traits,Allocator>(*this, pos, n1).compare(
    -              - basic_string<charT,traits,Allocator>( s, n2))

    -
    - -

    Editors please note that in addition to splitting the signature, the third argument -becomes const, matching the existing synopsis.

    - - -

    Rationale:

    -

    While the LWG dislikes adding signatures, this is a clear defect in -the Standard which must be fixed.  The same problem was also -identified in issues 7 (item 5) and 87.

    - - - - - -
    -

    7. String clause minor problems

    -

    Section: 21 [strings] Status: TC - Submitter: Matt Austern Date: 1997-12-15

    -

    View all other issues in [strings].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    (1) In 21.3.6.4 [string::insert], the description of template -<class InputIterator> insert(iterator, InputIterator, -InputIterator) makes no sense. It refers to a member function that -doesn't exist. It also talks about the return value of a void -function.

    - -

    (2) Several versions of basic_string::replace don't appear in the -class synopsis.

    - -

    (3) basic_string::push_back appears in the synopsis, but is never -described elsewhere. In the synopsis its argument is const charT, -which doesn't makes much sense; it should probably be charT, or -possible const charT&.

    - -

    (4) basic_string::pop_back is missing.

    - -

    (5) int compare(size_type pos, size_type n1, charT* s, size_type n2 -= npos) make no sense. First, it's const charT* in the synopsis and -charT* in the description. Second, given what it says in RETURNS, -leaving out the final argument will always result in an exception -getting thrown. This is paragraphs 5 and 6 of -21.3.6.8 [string::swap]

    - -

    (6) In table 37, in section 21.1.1 [char.traits.require], -there's a note for X::move(s, p, n). It says "Copies correctly -even where p is in [s, s+n)". This is correct as far as it goes, -but it doesn't go far enough; it should also guarantee that the copy -is correct even where s in in [p, p+n). These are two orthogonal -guarantees, and neither one follows from the other. Both guarantees -are necessary if X::move is supposed to have the same sort of -semantics as memmove (which was clearly the intent), and both -guarantees are necessary if X::move is actually supposed to be -useful.

    - - -

    Proposed resolution:

    -

    ITEM 1: In 21.3.5.4 [lib.string::insert], change paragraph 16 to
    -
    -    EFFECTS: Equivalent to insert(p - begin(), basic_string(first, last)).
    -
    -ITEM 2:  Not a defect; the Standard is clear.. There are ten versions of replace() in -the synopsis, and ten versions in 21.3.5.6 [lib.string::replace].
    -
    -ITEM 3: Change the declaration of push_back in the string synopsis (21.3, -[lib.basic.string]) from:

    - -

         void push_back(const charT)
    -
    -to
    -
    -     void push_back(charT)
    -
    -Add the following text immediately after 21.3.5.2 [lib.string::append], paragraph 10.
    -
    -    void basic_string::push_back(charT c);
    -    EFFECTS: Equivalent to append(static_cast<size_type>(1), c);
    -
    -ITEM 4: Not a defect. The omission appears to have been deliberate.
    -
    -ITEM 5: Duplicate; see issue 5 (and 87).
    -
    -ITEM 6: In table 37, Replace:
    -
    -    "Copies correctly even where p is in [s, s+n)."
    -
    -with:
    -
    -     "Copies correctly even where the ranges [p, p+n) and [s, -s+n) overlap."

    - - - - - -
    -

    8. Locale::global lacks guarantee

    -

    Section: 22.1.1.5 [locale.statics] Status: TC - Submitter: Matt Austern Date: 1997-12-24

    -

    View all issues with TC status.

    -

    Discussion:

    -

    It appears there's an important guarantee missing from clause -22. We're told that invoking locale::global(L) sets the C locale if L -has a name. However, we're not told whether or not invoking -setlocale(s) sets the global C++ locale.

    - -

    The intent, I think, is that it should not, but I can't find any -such words anywhere.

    - - -

    Proposed resolution:

    -

    Add a sentence at the end of 22.1.1.5 [locale.statics], -paragraph 2: 

    - -
    -

    No library function other than locale::global() shall affect - the value returned by locale().

    - -
    - - - - - -
    -

    9. Operator new(0) calls should not yield the same pointer

    -

    Section: 18.5.1 [new.delete] Status: TC - Submitter: Steve Clamage Date: 1998-01-04

    -

    View all issues with TC status.

    -

    Discussion:

    -

    Scott Meyers, in a comp.std.c++ posting: I just noticed that -section 3.7.3.1 of CD2 seems to allow for the possibility that all -calls to operator new(0) yield the same pointer, an implementation -technique specifically prohibited by ARM 5.3.3.Was this prohibition -really lifted? Does the FDIS agree with CD2 in the regard? [Issues -list maintainer's note: the IS is the same.]

    - - -

    Proposed resolution:

    -

    Change the last paragraph of 3.7.3 from:

    -
    -

    Any allocation and/or deallocation functions defined in a C++ program shall - conform to the semantics specified in 3.7.3.1 and 3.7.3.2.

    -
    -

    to:

    -
    -

    Any allocation and/or deallocation functions defined in a C++ program, - including the default versions in the library, shall conform to the semantics - specified in 3.7.3.1 and 3.7.3.2.

    -
    -

    Change 3.7.3.1/2, next-to-last sentence, from :

    -
    -

    If the size of the space requested is zero, the value returned shall not be - a null pointer value (4.10).

    -
    -

    to:

    -
    -

    Even if the size of the space requested is zero, the request can fail. If - the request succeeds, the value returned shall be a non-null pointer value - (4.10) p0 different from any previously returned value p1, unless that value - p1 was since passed to an operator delete.

    -
    -

    5.3.4/7 currently reads:

    -
    -

    When the value of the expression in a direct-new-declarator is zero, the - allocation function is called to allocate an array with no elements. The - pointer returned by the new-expression is non-null. [Note: If the library - allocation function is called, the pointer returned is distinct from the - pointer to any other object.]

    -
    -

    Retain the first sentence, and delete the remainder.

    -

    18.5.1 currently has no text. Add the following:

    -
    -

    Except where otherwise specified, the provisions of 3.7.3 apply to the - library versions of operator new and operator delete.

    -
    -

    To 18.5.1.3, add the following text:

    -
    -

    The provisions of 3.7.3 do not apply to these reserved placement forms of - operator new and operator delete.

    -
    - - -

    Rationale:

    -

    See 99-0040/N1216, October 22, 1999, by Stephen D. Clamage for the analysis -supporting to the proposed resolution.

    - - - - - -
    -

    11. Bitset minor problems

    -

    Section: 23.3.5 [template.bitset] Status: TC - Submitter: Matt Austern Date: 1998-01-22

    -

    View all other issues in [template.bitset].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    (1) bitset<>::operator[] is mentioned in the class synopsis (23.3.5), but it is -not documented in 23.3.5.2.

    - -

    (2) The class synopsis only gives a single signature for bitset<>::operator[], -reference operator[](size_t pos). This doesn't make much sense. It ought to be overloaded -on const. reference operator[](size_t pos); bool operator[](size_t pos) const.

    - -

    (3) Bitset's stream input function (23.3.5.3) ought to skip all whitespace before -trying to extract 0s and 1s. The standard doesn't explicitly say that, though. This should -go in the Effects clause.

    - - -

    Proposed resolution:

    -

    ITEMS 1 AND 2:
    -
    -In the bitset synopsis (23.3.5 [template.bitset]), -replace the member function
    -
    -    reference operator[](size_t pos);
    -
    -with the two member functions
    -
    -    bool operator[](size_t pos) const;
    -    reference operator[](size_t pos);
    -
    -Add the following text at the end of 23.3.5.2 [bitset.members], -immediately after paragraph 45:

    - -
    -

    bool operator[](size_t pos) const;
    - Requires: pos is valid
    - Throws: nothing
    - Returns: test(pos)
    -
    - bitset<N>::reference operator[](size_t pos);
    - Requires: pos is valid
    - Throws: nothing
    - Returns: An object of type bitset<N>::reference such that (*this)[pos] - == this->test(pos), and such that (*this)[pos] = val is equivalent to this->set(pos, - val);

    -
    - - -

    Rationale:

    -

    The LWG believes Item 3 is not a defect. "Formatted -input" implies the desired semantics. See 27.6.1.2 [istream.formatted]. -

    - - - - - -
    -

    13. Eos refuses to die

    -

    Section: 27.6.1.2.3 [istream::extractors] Status: TC - Submitter: William M. Miller Date: 1998-03-03

    -

    View all other issues in [istream::extractors].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    In 27.6.1.2.3, there is a reference to "eos", which is -the only one in the whole draft (at least using Acrobat search), so -it's undefined.

    - - -

    Proposed resolution:

    -

    In 27.6.1.2.3 [istream::extractors], replace "eos" with -"charT()"

    - - - - - -
    -

    14. Locale::combine should be const

    -

    Section: 22.1.1.3 [locale.members] Status: TC - Submitter: Nathan Myers Date: 1998-08-06

    -

    View all other issues in [locale.members].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    locale::combine is the only member function of locale (other than constructors and -destructor) that is not const. There is no reason for it not to be const, and good reasons -why it should have been const. Furthermore, leaving it non-const conflicts with 22.1.1 -paragraph 6: "An instance of a locale is immutable."

    - -

    History: this member function originally was a constructor. it happened that the -interface it specified had no corresponding language syntax, so it was changed to a member -function. As constructors are never const, there was no "const" in the interface -which was transformed into member "combine". It should have been added at that -time, but the omission was not noticed.

    - - -

    Proposed resolution:

    -

    In 22.1.1 [locale] and also in 22.1.1.3 [locale.members], add -"const" to the declaration of member combine:

    -
    - 
    template <class Facet> locale combine(const locale& other) const;
    -
    - - - - - -
    -

    15. Locale::name requirement inconsistent

    -

    Section: 22.1.1.3 [locale.members] Status: TC - Submitter: Nathan Myers Date: 1998-08-06

    -

    View all other issues in [locale.members].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    locale::name() is described as returning a string that can be passed to a locale -constructor, but there is no matching constructor.

    - - -

    Proposed resolution:

    -

    In 22.1.1.3 [locale.members], paragraph 5, replace -"locale(name())" with -"locale(name().c_str())". -

    - - - - - -
    -

    16. Bad ctype_byname<char> decl

    -

    Section: 22.2.1.4 [locale.codecvt] Status: TC - Submitter: Nathan Myers Date: 1998-08-06

    -

    View all other issues in [locale.codecvt].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    The new virtual members ctype_byname<char>::do_widen and do_narrow did not get -edited in properly. Instead, the member do_widen appears four times, with wrong argument -lists.

    - - -

    Proposed resolution:

    -

    The correct declarations for the overloaded members -do_narrow and do_widen should be copied -from 22.2.1.3 [facet.ctype.special].

    - - - - - -
    -

    17. Bad bool parsing

    -

    Section: 22.2.2.1.2 [facet.num.get.virtuals] Status: TC - Submitter: Nathan Myers Date: 1998-08-06

    -

    View other active issues in [facet.num.get.virtuals].

    -

    View all other issues in [facet.num.get.virtuals].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    This section describes the process of parsing a text boolean value from the input -stream. It does not say it recognizes either of the sequences "true" or -"false" and returns the corresponding bool value; instead, it says it recognizes -only one of those sequences, and chooses which according to the received value of a -reference argument intended for returning the result, and reports an error if the other -sequence is found. (!) Furthermore, it claims to get the names from the ctype<> -facet rather than the numpunct<> facet, and it examines the "boolalpha" -flag wrongly; it doesn't define the value "loc"; and finally, it computes -wrongly whether to use numeric or "alpha" parsing.
    -
    -I believe the correct algorithm is "as if":

    - -
      // in, err, val, and str are arguments.
-  err = 0;
-  const numpunct<charT>& np = use_facet<numpunct<charT> >(str.getloc());
-  const string_type t = np.truename(), f = np.falsename();
-  bool tm = true, fm = true;
-  size_t pos = 0;
-  while (tm && pos < t.size() || fm && pos < f.size()) {
-    if (in == end) { err = str.eofbit; }
-    bool matched = false;
-    if (tm && pos < t.size()) {
-      if (!err && t[pos] == *in) matched = true;
-      else tm = false;
-    }
-    if (fm && pos < f.size()) {
-      if (!err && f[pos] == *in) matched = true;
-      else fm = false;
-    }
-    if (matched) { ++in; ++pos; }
-    if (pos > t.size()) tm = false;
-    if (pos > f.size()) fm = false;
-  }
-  if (tm == fm || pos == 0) { err |= str.failbit; }
-  else                      { val = tm; }
-  return in;
    - -

    Notice this works reasonably when the candidate strings are both empty, or equal, or -when one is a substring of the other. The proposed text below captures the logic of the -code above.

    - - -

    Proposed resolution:

    -

    In 22.2.2.1.2 [facet.num.get.virtuals], in the first line of paragraph 14, -change "&&" to "&".

    - -

    Then, replace paragraphs 15 and 16 as follows:

    - -
    - -

    Otherwise target sequences are determined "as if" by - calling the members falsename() and - truename() of the facet obtained by - use_facet<numpunct<charT> >(str.getloc()). - Successive characters in the range [in,end) (see - [lib.sequence.reqmts]) are obtained and matched against - corresponding positions in the target sequences only as necessary to - identify a unique match. The input iterator in is - compared to end only when necessary to obtain a - character. If and only if a target sequence is uniquely matched, - val is set to the corresponding value.

    - -
    - -
    -

    The in iterator is always left pointing one position beyond the last character - successfully matched. If val is set, then err is set to str.goodbit; or to - str.eofbit if, when seeking another character to match, it is found that - (in==end). If val is not set, then err is set to str.failbit; or to - (str.failbit|str.eofbit)if - the reason for the failure was that (in==end). [Example: for targets - true:"a" and false:"abb", the input sequence "a" yields - val==true and err==str.eofbit; the input sequence "abc" yields - err=str.failbit, with in ending at the 'c' element. For targets - true:"1" - and false:"0", the input sequence "1" yields val==true - and err=str.goodbit. For empty targets (""), any input sequence yields - err==str.failbit. --end example]

    -
    - - - - - -
    -

    18. Get(...bool&) omitted

    -

    Section: 22.2.2.1.1 [facet.num.get.members] Status: TC - Submitter: Nathan Myers Date: 1998-08-06

    -

    View all other issues in [facet.num.get.members].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    In the list of num_get<> non-virtual members on page 22-23, the member -that parses bool values was omitted from the list of definitions of non-virtual -members, though it is listed in the class definition and the corresponding -virtual is listed everywhere appropriate.

    - - -

    Proposed resolution:

    -

    Add at the beginning of 22.2.2.1.1 [facet.num.get.members] -another get member for bool&, copied from the entry in -22.2.2.1 [locale.num.get].

    - - - - - -
    -

    19. "Noconv" definition too vague

    -

    Section: 22.2.1.4 [locale.codecvt] Status: TC - Submitter: Nathan Myers Date: 1998-08-06

    -

    View all other issues in [locale.codecvt].

    -

    View all issues with TC status.

    -

    Duplicate of: 10

    -

    Discussion:

    -

    -In the definitions of codecvt<>::do_out and do_in, they are -specified to return noconv if "no conversion is -needed". This definition is too vague, and does not say -normatively what is done with the buffers. -

    - - -

    Proposed resolution:

    -

    -Change the entry for noconv in the table under paragraph 4 in section -22.2.1.4.2 [locale.codecvt.virtuals] to read: -

    -
    -

    noconv: internT and externT are the same type, - and input sequence is identical to converted sequence.

    -
    -

    Change the Note in paragraph 2 to normative text as follows:

    -
    -

    If returns noconv, internT and externT are the - same type and the converted sequence is identical to the input sequence [from,from_next). - to_next is set equal to to, the value of state is - unchanged, and there are no changes to the values in [to, to_limit).

    -
    - - - - - -
    -

    20. Thousands_sep returns wrong type

    -

    Section: 22.2.3.1.2 [facet.numpunct.virtuals] Status: TC - Submitter: Nathan Myers Date: 1998-08-06

    -

    View all issues with TC status.

    -

    Discussion:

    -

    The synopsis for numpunct<>::do_thousands_sep, and the -definition of numpunct<>::thousands_sep which calls it, specify -that it returns a value of type char_type. Here it is erroneously -described as returning a "string_type".

    - - -

    Proposed resolution:

    -

    In 22.2.3.1.2 [facet.numpunct.virtuals], above paragraph 2, change -"string_type" to "char_type".

    - - - - - -
    -

    21. Codecvt_byname<> instantiations

    -

    Section: 22.1.1.1.1 [locale.category] Status: TC - Submitter: Nathan Myers Date: 1998-08-06

    -

    View all other issues in [locale.category].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    In the second table in the section, captioned "Required -instantiations", the instantiations for codecvt_byname<> -have been omitted. These are necessary to allow users to construct a -locale by name from facets.

    - - -

    Proposed resolution:

    -

    Add in 22.1.1.1.1 [locale.category] to the table captioned -"Required instantiations", in the category "ctype" -the lines

    - -
    - 
    codecvt_byname<char,char,mbstate_t>,
-codecvt_byname<wchar_t,char,mbstate_t>
    -
    - - - - - -
    -

    22. Member open vs. flags

    -

    Section: 27.8.1.9 [ifstream.members] Status: TC - Submitter: Nathan Myers Date: 1998-08-06

    -

    View all other issues in [ifstream.members].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    The description of basic_istream<>::open leaves unanswered questions about how it -responds to or changes flags in the error status for the stream. A strict reading -indicates that it ignores the bits and does not change them, which confuses users who do -not expect eofbit and failbit to remain set after a successful open. There are three -reasonable resolutions: 1) status quo 2) fail if fail(), ignore eofbit 3) clear failbit -and eofbit on call to open().

    - - -

    Proposed resolution:

    -

    In 27.8.1.9 [ifstream.members] paragraph 3, and in 27.8.1.13 [ofstream.members] paragraph 3, under open() effects, add a footnote: -

    - -
    -

    A successful open does not change the error state.

    -
    - - -

    Rationale:

    -

    This may seem surprising to some users, but it's just an instance -of a general rule: error flags are never cleared by the -implementation. The only way error flags are are ever cleared is if -the user explicitly clears them by hand.

    - -

    The LWG believed that preserving this general rule was -important enough so that an exception shouldn't be made just for this -one case. The resolution of this issue clarifies what the LWG -believes to have been the original intent.

    - - - - - - -
    -

    24. "do_convert" doesn't exist

    -

    Section: 22.2.1.4 [locale.codecvt] Status: TC - Submitter: Nathan Myers Date: 1998-08-06

    -

    View all other issues in [locale.codecvt].

    -

    View all issues with TC status.

    -

    Duplicate of: 72

    -

    Discussion:

    -

    The description of codecvt<>::do_out and do_in mentions a -symbol "do_convert" which is not defined in the -standard. This is a leftover from an edit, and should be "do_in -and do_out".

    - - -

    Proposed resolution:

    -

    In 22.2.1.4 [locale.codecvt], paragraph 3, change -"do_convert" to "do_in or do_out". Also, in 22.2.1.4.2 [locale.codecvt.virtuals], change "do_convert()" to "do_in -or do_out".

    - - - - - -
    -

    25. String operator<< uses width() value wrong

    -

    Section: 21.3.8.9 [string.io] Status: TC - Submitter: Nathan Myers Date: 1998-08-06

    -

    View all other issues in [string.io].

    -

    View all issues with TC status.

    -

    Duplicate of: 67

    -

    Discussion:

    -

    In the description of operator<< applied to strings, the standard says that uses -the smaller of os.width() and str.size(), to pad "as described in stage 3" -elsewhere; but this is inconsistent, as this allows no possibility of space for padding.

    - - -

    Proposed resolution:

    -

    Change 21.3.8.9 [string.io] paragraph 4 from:
    -
    -    "... where n is the smaller of os.width() and str.size(); -..."
    -
    -to:
    -
    -    "... where n is the larger of os.width() and str.size(); -..."

    - - - - - -
    -

    26. Bad sentry example

    -

    Section: 27.6.1.1.3 [istream::sentry] Status: TC - Submitter: Nathan Myers Date: 1998-08-06

    -

    View all other issues in [istream::sentry].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    In paragraph 6, the code in the example:

    - -
      template <class charT, class traits = char_traits<charT> >
-  basic_istream<charT,traits>::sentry(
-           basic_istream<charT,traits>& is, bool noskipws = false) {
-      ...
-      int_type c;
-      typedef ctype<charT> ctype_type;
-      const ctype_type& ctype = use_facet<ctype_type>(is.getloc());
-      while ((c = is.rdbuf()->snextc()) != traits::eof()) {
-        if (ctype.is(ctype.space,c)==0) {
-          is.rdbuf()->sputbackc (c);
-          break;
-        }
-      }
-      ...
-   }
    - -

    fails to demonstrate correct use of the facilities described. In -particular, it fails to use traits operators, and specifies incorrect -semantics. (E.g. it specifies skipping over the first character in the -sequence without examining it.)

    - - -

    Proposed resolution:

    -

    Remove the example above from 27.6.1.1.3 [istream::sentry] -paragraph 6.

    - - -

    Rationale:

    -

    The originally proposed replacement code for the example was not -correct. The LWG tried in Kona and again in Tokyo to correct it -without success. In Tokyo, an implementor reported that actual working -code ran over one page in length and was quite complicated. The LWG -decided that it would be counter-productive to include such a lengthy -example, which might well still contain errors.

    - - - - - -
    -

    27. String::erase(range) yields wrong iterator

    -

    Section: 21.3.6.5 [string::erase] Status: TC - Submitter: Nathan Myers Date: 1998-08-06

    -

    View all other issues in [string::erase].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    The string::erase(iterator first, iterator last) is specified to return an element one -place beyond the next element after the last one erased. E.g. for the string -"abcde", erasing the range ['b'..'d') would yield an iterator for element 'e', -while 'd' has not been erased.

    - - -

    Proposed resolution:

    -

    In 21.3.6.5 [string::erase], paragraph 10, change:

    - -
    -

    Returns: an iterator which points to the element immediately following _last_ prior to - the element being erased.

    -
    - -

    to read

    - -
    -

    Returns: an iterator which points to the element pointed to by _last_ prior to the - other elements being erased.

    -
    - - - - - -
    -

    28. Ctype<char>is ambiguous

    -

    Section: 22.2.1.3.2 [facet.ctype.char.members] Status: TC - Submitter: Nathan Myers Date: 1998-08-06

    -

    View all other issues in [facet.ctype.char.members].

    -

    View all issues with TC status.

    -

    Duplicate of: 236

    -

    Discussion:

    -

    The description of the vector form of ctype<char>::is can be interpreted to mean -something very different from what was intended. Paragraph 4 says

    - -
    -

    Effects: The second form, for all *p in the range [low, high), assigns vec[p-low] to - table()[(unsigned char)*p].

    -
    - -

    This is intended to copy the value indexed from table()[] into the place identified in -vec[].

    - - -

    Proposed resolution:

    -

    Change 22.2.1.3.2 [facet.ctype.char.members], paragraph 4, to read

    - -
    -

    Effects: The second form, for all *p in the range [low, high), assigns into vec[p-low] - the value table()[(unsigned char)*p].

    -
    - - - - - -
    -

    29. Ios_base::init doesn't exist

    -

    Section: 27.3.1 [narrow.stream.objects] Status: TC - Submitter: Nathan Myers Date: 1998-08-06

    -

    View all other issues in [narrow.stream.objects].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    Sections 27.3.1 [narrow.stream.objects] and 27.3.2 [wide.stream.objects] mention -a function ios_base::init, which is not defined. Probably they mean -basic_ios<>::init, defined in 27.4.4.1 [basic.ios.cons], -paragraph 3.

    - - -

    Proposed resolution:

    -

    [R12: modified to include paragraph 5.]

    - -

    In 27.3.1 [narrow.stream.objects] paragraph 2 and 5, change

    - -
    -

    ios_base::init

    -
    - -

    to

    - -
    -

    basic_ios<char>::init

    -
    - -

    Also, make a similar change in 27.3.2 [wide.stream.objects] except it -should read

    - -
    -

    basic_ios<wchar_t>::init

    -
    - - - - - -
    -

    30. Wrong header for LC_*

    -

    Section: 22.1.1.1.1 [locale.category] Status: TC - Submitter: Nathan Myers Date: 1998-08-06

    -

    View all other issues in [locale.category].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    Paragraph 2 implies that the C macros LC_CTYPE etc. are defined in <cctype>, -where they are in fact defined elsewhere to appear in <clocale>.

    - - -

    Proposed resolution:

    -

    In 22.1.1.1.1 [locale.category], paragraph 2, change -"<cctype>" to read "<clocale>".

    - - - - - -
    -

    31. Immutable locale values

    -

    Section: 22.1.1 [locale] Status: TC - Submitter: Nathan Myers Date: 1998-08-06

    -

    View all other issues in [locale].

    -

    View all issues with TC status.

    -

    Duplicate of: 378

    -

    Discussion:

    -

    Paragraph 6, says "An instance of locale is -immutable; once a facet reference is obtained from it, -...". This has caused some confusion, because locale variables -are manifestly assignable.

    - - -

    Proposed resolution:

    -

    In 22.1.1 [locale] replace paragraph 6

    - -
    -

    An instance of locale is immutable; once a facet - reference is obtained from it, that reference remains usable as long - as the locale value itself exists.

    -
    - -

    with

    - -
    -

    Once a facet reference is obtained from a locale object by - calling use_facet<>, that reference remains usable, and the - results from member functions of it may be cached and re-used, as - long as some locale object refers to that facet.

    -
    - - - - - -
    -

    32. Pbackfail description inconsistent

    -

    Section: 27.5.2.4.4 [streambuf.virt.pback] Status: TC - Submitter: Nathan Myers Date: 1998-08-06

    -

    View all issues with TC status.

    -

    Discussion:

    -

    The description of the required state before calling virtual member -basic_streambuf<>::pbackfail requirements is inconsistent with the conditions -described in 27.5.2.2.4 [lib.streambuf.pub.pback] where member sputbackc calls it. -Specifically, the latter says it calls pbackfail if:

    - -

        traits::eq(c,gptr()[-1]) is false

    - -

    where pbackfail claims to require:

    - -

        traits::eq(*gptr(),traits::to_char_type(c)) returns false

    - -

    It appears that the pbackfail description is wrong.

    - - -

    Proposed resolution:

    -

    In 27.5.2.4.4 [streambuf.virt.pback], paragraph 1, change:

    - -
    -

    "traits::eq(*gptr(),traits::to_char_type( c))"

    -
    - -

    to

    - -
    -

    "traits::eq(traits::to_char_type(c),gptr()[-1])" -

    -
    - - -

    Rationale:

    -

    Note deliberate reordering of arguments for clarity in addition to the correction of -the argument value.

    - - - - - -
    -

    33. Codecvt<> mentions from_type

    -

    Section: 22.2.1.4 [locale.codecvt] Status: TC - Submitter: Nathan Myers Date: 1998-08-06

    -

    View all other issues in [locale.codecvt].

    -

    View all issues with TC status.

    -

    Duplicate of: 43

    -

    Discussion:

    -

    In the table defining the results from do_out and do_in, the specification for the -result error says

    - -
    -

    encountered a from_type character it could not convert

    -
    - -

    but from_type is not defined. This clearly is intended to be an externT for do_in, or -an internT for do_out.

    - - -

    Proposed resolution:

    -

    In 22.2.1.4.2 [locale.codecvt.virtuals] paragraph 4, replace the definition -in the table for the case of _error_ with

    - -
    -

    encountered a character in [from,from_end) that it could not convert.

    -
    - - - - - -
    -

    34. True/falsename() not in ctype<>

    -

    Section: 22.2.2.2.2 [facet.num.put.virtuals] Status: TC - Submitter: Nathan Myers Date: 1998-08-06

    -

    View all other issues in [facet.num.put.virtuals].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    In paragraph 19, Effects:, members truename() and falsename are used from facet -ctype<charT>, but it has no such members. Note that this is also a problem in -22.2.2.1.2, addressed in (4).

    - - -

    Proposed resolution:

    -

    In 22.2.2.2.2 [facet.num.put.virtuals], paragraph 19, in the Effects: -clause for member put(...., bool), replace the initialization of the -string_type value s as follows:

    - -
    - 
    const numpunct& np = use_facet<numpunct<charT> >(loc);
-string_type s = val ? np.truename() : np.falsename();
    -
    - - - - - -
    -

    35. No manipulator unitbuf in synopsis

    -

    Section: 27.4 [iostreams.base] Status: TC - Submitter: Nathan Myers Date: 1998-08-06

    -

    View all issues with TC status.

    -

    Discussion:

    -

    In 27.4.5.1 [fmtflags.manip], we have a definition for a manipulator -named "unitbuf". Unlike other manipulators, it's not listed -in synopsis. Similarly for "nounitbuf".

    - - -

    Proposed resolution:

    -

    Add to the synopsis for <ios> in 27.4 [iostreams.base], after -the entry for "nouppercase", the prototypes:

    - -
    - 
    ios_base& unitbuf(ios_base& str);
-ios_base& nounitbuf(ios_base& str);
    -
    - - - - - -
    -

    36. Iword & pword storage lifetime omitted

    -

    Section: 27.4.2.5 [ios.base.storage] Status: TC - Submitter: Nathan Myers Date: 1998-08-06

    -

    View all other issues in [ios.base.storage].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    In the definitions for ios_base::iword and pword, the lifetime of the storage is -specified badly, so that an implementation which only keeps the last value stored appears -to conform. In particular, it says:

    - -

    The reference returned may become invalid after another call to the object's iword -member with a different index ...

    - -

    This is not idle speculation; at least one implementation was done this way.

    - - -

    Proposed resolution:

    -

    Add in 27.4.2.5 [ios.base.storage], in both paragraph 2 and also in -paragraph 4, replace the sentence:

    - -
    -

    The reference returned may become invalid after another call to the object's iword - [pword] member with a different index, after a call to its copyfmt member, or when the - object is destroyed.

    -
    - -

    with:

    - -
    -

    The reference returned is invalid after any other operations on the object. However, - the value of the storage referred to is retained, so that until the next call to copyfmt, - calling iword [pword] with the same index yields another reference to the same value.

    -
    - -

    substituting "iword" or "pword" as appropriate.

    - - - - - -
    -

    37. Leftover "global" reference

    -

    Section: 22.1.1 [locale] Status: TC - Submitter: Nathan Myers Date: 1998-08-06

    -

    View all other issues in [locale].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    In the overview of locale semantics, paragraph 4, is the sentence

    - -
    -

    If Facet is not present in a locale (or, failing that, in the global locale), it throws - the standard exception bad_cast.

    -
    - -

    This is not supported by the definition of use_facet<>, and represents semantics -from an old draft.

    - - -

    Proposed resolution:

    -

    In 22.1.1 [locale], paragraph 4, delete the parenthesized -expression

    - -
    -

    (or, failing that, in the global locale)

    -
    - - - - - -
    -

    38. Facet definition incomplete

    -

    Section: 22.1.2 [locale.global.templates] Status: TC - Submitter: Nathan Myers Date: 1998-08-06

    -

    View all issues with TC status.

    -

    Discussion:

    -

    It has been noticed by Esa Pulkkinen that the definition of -"facet" is incomplete. In particular, a class derived from -another facet, but which does not define a member id, cannot -safely serve as the argument F to use_facet<F>(loc), -because there is no guarantee that a reference to the facet instance -stored in loc is safely convertible to F.

    - - -

    Proposed resolution:

    -

    In the definition of std::use_facet<>(), replace the text in paragraph 1 which -reads:

    - -
    -

    Get a reference to a facet of a locale.

    -
    - -

    with:

    - -
    -

    Requires: Facet is a facet class whose definition - contains the public static member id as defined in 22.1.1.1.2 [locale.facet].

    -
    - -

    [ -Kona: strike as overspecification the text "(not inherits)" -from the original resolution, which read "... whose definition -contains (not inherits) the public static member -id..." -]

    - - - - - - - -
    -

    39. istreambuf_iterator<>::operator++(int) definition garbled

    -

    Section: 24.5.3.4 [istreambuf.iterator::op++] Status: TC - Submitter: Nathan Myers Date: 1998-08-06

    -

    View all issues with TC status.

    -

    Discussion:

    -

    Following the definition of istreambuf_iterator<>::operator++(int) in paragraph -3, the standard contains three lines of garbage text left over from a previous edit.

    - -
    - 
    istreambuf_iterator<charT,traits> tmp = *this;
-sbuf_->sbumpc();
-return(tmp);
    -
    - - -

    Proposed resolution:

    -

    In 24.5.3.4 [istreambuf.iterator::op++], delete the three lines of code at the -end of paragraph 3.

    - - - - - -
    -

    40. Meaningless normative paragraph in examples

    -

    Section: 22.2.8 [facets.examples] Status: TC - Submitter: Nathan Myers Date: 1998-08-06

    -

    View all other issues in [facets.examples].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    Paragraph 3 of the locale examples is a description of part of an -implementation technique that has lost its referent, and doesn't mean -anything.

    - - -

    Proposed resolution:

    -

    Delete 22.2.8 [facets.examples] paragraph 3 which begins "This -initialization/identification system depends...", or (at the -editor's option) replace it with a place-holder to keep the paragraph -numbering the same.

    - - - - - -
    -

    41. Ios_base needs clear(), exceptions()

    -

    Section: 27.4.2 [ios.base] Status: TC - Submitter: Nathan Myers Date: 1998-08-06

    -

    View all other issues in [ios.base].

    -

    View all issues with TC status.

    -

    Duplicate of: 157

    -

    Discussion:

    -

    The description of ios_base::iword() and pword() in 27.4.2.4 [ios.members.static], say that if they fail, they "set badbit, -which may throw an exception". However, ios_base offers no -interface to set or to test badbit; those interfaces are defined in -basic_ios<>.

    - - -

    Proposed resolution:

    -

    Change the description in 27.4.2.5 [ios.base.storage] in -paragraph 2, and also in paragraph 4, as follows. Replace

    - -
    -

    If the function fails it sets badbit, which may throw an exception.

    -
    - -

    with

    - -
    -

    If the function fails, and *this is a base sub-object of - a basic_ios<> object or sub-object, the effect is - equivalent to calling basic_ios<>::setstate(badbit) - on the derived object (which may throw failure).

    -
    - -

    [Kona: LWG reviewed wording; setstate(failbit) changed to -setstate(badbit).]

    - - - - - - - -
    -

    42. String ctors specify wrong default allocator

    -

    Section: 21.3 [basic.string] Status: TC - Submitter: Nathan Myers Date: 1998-08-06

    -

    View other active issues in [basic.string].

    -

    View all other issues in [basic.string].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    The basic_string<> copy constructor:

    - -
    basic_string(const basic_string& str, size_type pos = 0,
-             size_type n = npos, const Allocator& a = Allocator());
    - -

    specifies an Allocator argument default value that is -counter-intuitive. The natural choice for a the allocator to copy from -is str.get_allocator(). Though this cannot be expressed in -default-argument notation, overloading suffices.

    - -

    Alternatively, the other containers in Clause 23 (deque, list, -vector) do not have this form of constructor, so it is inconsistent, -and an evident source of confusion, for basic_string<> to have -it, so it might better be removed.

    - - -

    Proposed resolution:

    -

    In 21.3 [basic.string], replace the declaration of the copy -constructor as follows:

    - -
    - 
    basic_string(const basic_string& str);
-basic_string(const basic_string& str, size_type pos, size_type n = npos,
-             const Allocator& a = Allocator());
    -
    - -

    In 21.3.1 [string.require], replace the copy constructor declaration -as above. Add to paragraph 5, Effects:

    - -
    -

    In the first form, the Allocator value used is copied from - str.get_allocator().

    -
    - - -

    Rationale:

    -

    The LWG believes the constructor is actually broken, rather than -just an unfortunate design choice.

    - -

    The LWG considered two other possible resolutions:

    - -

    A. In 21.3 [basic.string], replace the declaration of the copy -constructor as follows:

    - -
    - 
    basic_string(const basic_string& str, size_type pos = 0,
-             size_type n = npos);
-basic_string(const basic_string& str, size_type pos,
-             size_type n, const Allocator& a);
    -
    - -

    In 21.3.1 [string.require], replace the copy constructor declaration -as above. Add to paragraph 5, Effects:

    - -
    -

    When no Allocator argument is provided, the string is constructed using the - value str.get_allocator().

    -
    - -

    B. In 21.3 [basic.string], and also in 21.3.1 [string.require], replace -the declaration of the copy constructor as follows:

    - -
    - 
    basic_string(const basic_string& str, size_type pos = 0,
-             size_type n = npos);
    -
    - -

    The proposed resolution reflects the original intent of the LWG. It -was also noted by Pete Becker that this fix "will cause -a small amount of existing code to now work correctly."

    - -

    [ -Kona: issue editing snafu fixed - the proposed resolution now correctly -reflects the LWG consensus. -]

    - - - - - - -
    -

    44. Iostreams use operator== on int_type values

    -

    Section: 27 [input.output] Status: WP - Submitter: Nathan Myers Date: 1998-08-06

    -

    View all other issues in [input.output].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    Many of the specifications for iostreams specify that character -values or their int_type equivalents are compared using operators == -or !=, though in other places traits::eq() or traits::eq_int_type is -specified to be used throughout. This is an inconsistency; we should -change uses of == and != to use the traits members instead.

    - - -

    Proposed resolution:

    - -

    [Pre-Kona: Dietmar supplied wording]

    - - -

    List of changes to clause 27:

    -
      -
    1. - In lib.basic.ios.members paragraph 13 (postcondition clause for - 'fill(cT)') change - -
           fillch == fill()
-
      - - to - -
           traits::eq(fillch, fill())
-
      - - -
      2. -
    2. - In lib.istream.unformatted paragraph 7 (effects clause for - 'get(cT,streamsize,cT)'), third bullet, change - -
           c == delim for the next available input character c
-
      - - to - -
           traits::eq(c, delim) for the next available input character c
-
      - -
      3. -
    3. - In lib.istream.unformatted paragraph 12 (effects clause for - 'get(basic_streambuf<cT,Tr>&,cT)'), third bullet, change - -
           c == delim for the next available input character c
-
      - - to - -
           traits::eq(c, delim) for the next available input character c
-
      - -
      4. -
    4. - In lib.istream.unformatted paragraph 17 (effects clause for - 'getline(cT,streamsize,cT)'), second bullet, change - -
           c == delim for the next available input character c
-
      - - to - -
           traits::eq(c, delim) for the next available input character c
-
      - -
      5. -
    5. - In lib.istream.unformatted paragraph 24 (effects clause for - 'ignore(int,int_type)'), second bullet, change - -
           c == delim for the next available input character c
-
      - - to - -
           traits::eq_int_type(c, delim) for the next available input
-     character c
-
      - -
      6. -
    6. - In lib.istream.unformatted paragraph 25 (notes clause for - 'ignore(int,int_type)'), second bullet, change - -
           The last condition will never occur if delim == traits::eof()
-
      - - to - -
           The last condition will never occur if
-     traits::eq_int_type(delim, traits::eof()).
-
      - -
      7. -
    7. - In lib.istream.sentry paragraph 6 (example implementation for the - sentry constructor) change - -
           while ((c = is.rdbuf()->snextc()) != traits::eof()) {
-
      - - to - -
           while (!traits::eq_int_type(c = is.rdbuf()->snextc(), traits::eof())) {
-
      - -
      8. -
    - -

    List of changes to Chapter 21:

    - -
      -
    1. - In lib.string::find paragraph 1 (effects clause for find()), - second bullet, change - -
           at(xpos+I) == str.at(I) for all elements ...
-
      - - to - -
           traits::eq(at(xpos+I), str.at(I)) for all elements ...
-
      - -
      2. -
    2. - In lib.string::rfind paragraph 1 (effects clause for rfind()), - second bullet, change - -
           at(xpos+I) == str.at(I) for all elements ...
-
      - - to - -
           traits::eq(at(xpos+I), str.at(I)) for all elements ...
-
      - -
      3. -
    3. - In lib.string::find.first.of paragraph 1 (effects clause for - find_first_of()), second bullet, change - -
           at(xpos+I) == str.at(I) for all elements ...
-
      - - to - -
           traits::eq(at(xpos+I), str.at(I)) for all elements ...
-
      - -
      4. -
    4. - In lib.string::find.last.of paragraph 1 (effects clause for - find_last_of()), second bullet, change - -
           at(xpos+I) == str.at(I) for all elements ...
-
      - - to - -
           traits::eq(at(xpos+I), str.at(I)) for all elements ...
-
      - -
      5. -
    5. - In lib.string::find.first.not.of paragraph 1 (effects clause for - find_first_not_of()), second bullet, change - -
           at(xpos+I) == str.at(I) for all elements ...
-
      - - to - -
           traits::eq(at(xpos+I), str.at(I)) for all elements ...
-
      -
      6. - -
    6. - In lib.string::find.last.not.of paragraph 1 (effects clause for - find_last_not_of()), second bullet, change - -
           at(xpos+I) == str.at(I) for all elements ...
-
      - - to - -
           traits::eq(at(xpos+I), str.at(I)) for all elements ...
-
      -
      7. - -
    7. - In lib.string.ios paragraph 5 (effects clause for getline()), - second bullet, change - -
           c == delim for the next available input character c 
-
      - - to - -
           traits::eq(c, delim) for the next available input character c 
-
      -
      8. - -
    - -

    Notes:

    -
      -
    • - Fixing this issue highlights another sloppyness in - lib.istream.unformatted paragraph 24: this clause mentions a "character" - which is then compared to an 'int_type' (see item 5. in the list - below). It is not clear whether this requires explicit words and - if so what these words are supposed to be. A similar issue exists, - BTW, for operator*() of istreambuf_iterator which returns the result - of sgetc() as a character type (see lib.istreambuf.iterator::op* - paragraph 1), and for operator++() of istreambuf_iterator which - passes the result of sbumpc() to a constructor taking a char_type - (see lib.istreambuf.iterator::operator++ paragraph 3). Similarily, the - assignment operator ostreambuf_iterator passes a char_type to a function - taking an int_type (see lib.ostreambuf.iter.ops paragraph 1). -
      • -
    • - It is inconsistent to use comparisons using the traits functions in - Chapter 27 while not using them in Chapter 21, especially as some - of the inconsistent uses actually involve streams (eg. getline() on - streams). To avoid leaving this issue open still longer due to this - inconsistency (it is open since 1998), a list of changes to Chapter - 21 is below. -
      • -
    • - In Chapter 24 there are several places with statements like "the end - of stream is reached (streambuf_type::sgetc() returns traits::eof())" - (lib.istreambuf.iterator paragraph 1, lib.ostreambuf.iter.ops - paragraph 5). It is unclear whether these should be clarified to use - traits::eq_int_type() for detecting traits::eof(). -
      • -
    - - - - - - -
    -

    46. Minor Annex D errors

    -

    Section: D.7 [depr.str.strstreams] Status: TC - Submitter: Brendan Kehoe Date: 1998-06-01

    -

    View all issues with TC status.

    -

    Discussion:

    See lib-6522 and edit-814.

    - -

    Proposed resolution:

    -

    Change D.7.1 [depr.strstreambuf] (since streambuf is a typedef of -basic_streambuf<char>) from:

    - -
             virtual streambuf<char>* setbuf(char* s, streamsize n);
    - -

    to:

    - -
             virtual streambuf* setbuf(char* s, streamsize n);
    - -

    In D.7.4 [depr.strstream] insert the semicolon now missing after -int_type:

    - -
         namespace std {
-       class strstream
-         : public basic_iostream<char> {
-       public:
-         // Types
-         typedef char                                char_type;
-         typedef typename char_traits<char>::int_type int_type
-         typedef typename char_traits<char>::pos_type pos_type;
    - - - - - -
    -

    47. Imbue() and getloc() Returns clauses swapped

    -

    Section: 27.4.2.3 [ios.base.locales] Status: TC - Submitter: Matt Austern Date: 1998-06-21

    -

    View all other issues in [ios.base.locales].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    Section 27.4.2.3 specifies how imbue() and getloc() work. That -section has two RETURNS clauses, and they make no sense as -stated. They make perfect sense, though, if you swap them. Am I -correct in thinking that paragraphs 2 and 4 just got mixed up by -accident?

    - - -

    Proposed resolution:

    -

    In 27.4.2.3 [ios.base.locales] swap paragraphs 2 and 4.

    - - - - - -
    -

    48. Use of non-existent exception constructor

    -

    Section: 27.4.2.1.1 [ios::failure] Status: TC - Submitter: Matt Austern Date: 1998-06-21

    -

    View all other issues in [ios::failure].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    27.4.2.1.1, paragraph 2, says that class failure initializes the -base class, exception, with exception(msg). Class exception (see -18.6.1) has no such constructor.

    - - -

    Proposed resolution:

    -

    Replace 27.4.2.1.1 [ios::failure], paragraph 2, with

    - -
    -

    EFFECTS: Constructs an object of class failure.

    -
    - - - - - -
    -

    49. Underspecification of ios_base::sync_with_stdio

    -

    Section: 27.4.2.4 [ios.members.static] Status: WP - Submitter: Matt Austern Date: 1998-06-21

    -

    View all issues with WP status.

    -

    Discussion:

    -

    Two problems

    - -

    (1) 27.4.2.4 doesn't say what ios_base::sync_with_stdio(f) -returns. Does it return f, or does it return the previous -synchronization state? My guess is the latter, but the standard -doesn't say so.

    - -

    (2) 27.4.2.4 doesn't say what it means for streams to be -synchronized with stdio. Again, of course, I can make some -guesses. (And I'm unhappy about the performance implications of those -guesses, but that's another matter.)

    - - -

    Proposed resolution:

    -

    Change the following sentence in 27.4.2.4 [ios.members.static] -returns clause from:

    - -
    -

    true if the standard iostream objects (27.3) are - synchronized and otherwise returns false.

    -
    - -

    to:

    - -
    -

    true if the previous state of the standard iostream - objects (27.3) was synchronized and otherwise returns - false.

    -
    - -

    Add the following immediately after 27.4.2.4 [ios.members.static], -paragraph 2:

    - -
    -

    When a standard iostream object str is synchronized with a -standard stdio stream f, the effect of inserting a character c by

    -
      fputc(f, c);
-
    - -

    is the same as the effect of

    -
      str.rdbuf()->sputc(c);
-
    - -

    for any sequence of characters; the effect of extracting a -character c by

    -
      c = fgetc(f);
-
    - -

    is the same as the effect of:

    -
      c = str.rdbuf()->sbumpc(c);
-
    - -

    for any sequences of characters; and the effect of pushing -back a character c by

    -
      ungetc(c, f);
-
    - -

    is the same as the effect of

    -
      str.rdbuf()->sputbackc(c);
-
    - -

    for any sequence of characters. [Footnote: This implies -that operations on a standard iostream object can be mixed arbitrarily -with operations on the corresponding stdio stream. In practical -terms, synchronization usually means that a standard iostream object -and a standard stdio object share a buffer. --End Footnote]

    -
    - -

    [pre-Copenhagen: PJP and Matt contributed the definition -of "synchronization"]

    - - -

    [post-Copenhagen: proposed resolution was revised slightly: -text was added in the non-normative footnote to say that operations -on the two streams can be mixed arbitrarily.]

    - - - - - - -
    -

    50. Copy constructor and assignment operator of ios_base

    -

    Section: 27.4.2 [ios.base] Status: TC - Submitter: Matt Austern Date: 1998-06-21

    -

    View all other issues in [ios.base].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    As written, ios_base has a copy constructor and an assignment -operator. (Nothing in the standard says it doesn't have one, and all -classes have copy constructors and assignment operators unless you -take specific steps to avoid them.) However, nothing in 27.4.2 says -what the copy constructor and assignment operator do.

    - -

    My guess is that this was an oversight, that ios_base is, like -basic_ios, not supposed to have a copy constructor or an assignment -operator.

    - -

    -Jerry Schwarz comments: Yes, its an oversight, but in the opposite -sense to what you're suggesting. At one point there was a definite -intention that you could copy ios_base. It's an easy way to save the -entire state of a stream for future use. As you note, to carry out -that intention would have required a explicit description of the -semantics (e.g. what happens to the iarray and parray stuff). -

    - - -

    Proposed resolution:

    -

    In 27.4.2 [ios.base], class ios_base, specify the copy -constructor and operator= members as being private.

    - - -

    Rationale:

    -

    The LWG believes the difficulty of specifying correct semantics -outweighs any benefit of allowing ios_base objects to be copyable.

    - - - - - -
    -

    51. Requirement to not invalidate iterators missing

    -

    Section: 23.1 [container.requirements] Status: TC - Submitter: David Vandevoorde Date: 1998-06-23

    -

    View other active issues in [container.requirements].

    -

    View all other issues in [container.requirements].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    The std::sort algorithm can in general only sort a given sequence -by moving around values. The list<>::sort() member on the other -hand could move around values or just update internal pointers. Either -method can leave iterators into the list<> dereferencable, but -they would point to different things.

    - -

    Does the FDIS mandate anywhere which method should be used for -list<>::sort()?

    - -

    Matt Austern comments:

    - -

    I think you've found an omission in the standard.

    - -

    The library working group discussed this point, and there was -supposed to be a general requirement saying that list, set, map, -multiset, and multimap may not invalidate iterators, or change the -values that iterators point to, except when an operation does it -explicitly. So, for example, insert() doesn't invalidate any iterators -and erase() and remove() only invalidate iterators pointing to the -elements that are being erased.

    - -

    I looked for that general requirement in the FDIS, and, while I -found a limited form of it for the sorted associative containers, I -didn't find it for list. It looks like it just got omitted.

    - -

    The intention, though, is that list<>::sort does not -invalidate any iterators and does not change the values that any -iterator points to. There would be no reason to have the member -function otherwise.

    - - -

    Proposed resolution:

    -

    Add a new paragraph at the end of 23.1:

    - -
    -

    Unless otherwise specified (either explicitly or by defining a function in terms of - other functions), invoking a container member function or passing a container as an - argument to a library function shall not invalidate iterators to, or change the values of, - objects within that container.

    -
    - - -

    Rationale:

    -

    This was US issue CD2-23-011; it was accepted in London but the -change was not made due to an editing oversight. The wording in the -proposed resolution below is somewhat updated from CD2-23-011, -particularly the addition of the phrase "or change the values -of"

    - - - - - -
    -

    52. Small I/O problems

    -

    Section: 27.4.3.2 [fpos.operations] Status: TC - Submitter: Matt Austern Date: 1998-06-23

    -

    View all issues with TC status.

    -

    Discussion:

    -

    First, 27.4.4.1 [basic.ios.cons], table 89. This is pretty obvious: -it should be titled "basic_ios<>() effects", not -"ios_base() effects".

    - -

    [The second item is a duplicate; see issue 6 for -resolution.]

    - -

    Second, 27.4.3.2 [fpos.operations] table 88 . There are a couple -different things wrong with it, some of which I've already discussed -with Jerry, but the most obvious mechanical sort of error is that it -uses expressions like P(i) and p(i), without ever defining what sort -of thing "i" is. -

    - -

    (The other problem is that it requires support for streampos -arithmetic. This is impossible on some systems, i.e. ones where file -position is a complicated structure rather than just a number. Jerry -tells me that the intention was to require syntactic support for -streampos arithmetic, but that it wasn't actually supposed to do -anything meaningful except on platforms, like Unix, where genuine -arithmetic is possible.)

    - - -

    Proposed resolution:

    -

    Change 27.4.4.1 [basic.ios.cons] table 89 title from -"ios_base() effects" to "basic_ios<>() -effects".

    - - - - - -
    -

    53. Basic_ios destructor unspecified

    -

    Section: 27.4.4.1 [basic.ios.cons] Status: TC - Submitter: Matt Austern Date: 1998-06-23

    -

    View all other issues in [basic.ios.cons].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    There's nothing in 27.4.4 saying what basic_ios's destructor does. -The important question is whether basic_ios::~basic_ios() destroys -rdbuf().

    - - -

    Proposed resolution:

    -

    Add after 27.4.4.1 [basic.ios.cons] paragraph 2:

    - -
    -

    virtual ~basic_ios();

    -

    Notes: The destructor does not destroy rdbuf().

    -
    - - -

    Rationale:

    -

    The LWG reviewed the additional question of whether or not -rdbuf(0) may set badbit. The answer is -clearly yes; it may be set via clear(). See 27.4.4.2 [basic.ios.members], paragraph 6. This issue was reviewed at length -by the LWG, which removed from the original proposed resolution a -footnote which incorrectly said "rdbuf(0) does not set -badbit".

    - - - - - -
    -

    54. Basic_streambuf's destructor

    -

    Section: 27.5.2.1 [streambuf.cons] Status: TC - Submitter: Matt Austern Date: 1998-06-25

    -

    View all other issues in [streambuf.cons].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    The class synopsis for basic_streambuf shows a (virtual) -destructor, but the standard doesn't say what that destructor does. My -assumption is that it does nothing, but the standard should say so -explicitly.

    - - -

    Proposed resolution:

    -

    Add after 27.5.2.1 [streambuf.cons] paragraph 2:

    - -
    -

    virtual  ~basic_streambuf();

    -

    Effects: None.

    -
    - - - - - -
    -

    55. Invalid stream position is undefined

    -

    Section: 27 [input.output] Status: TC - Submitter: Matt Austern Date: 1998-06-26

    -

    View all other issues in [input.output].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    Several member functions in clause 27 are defined in certain -circumstances to return an "invalid stream position", a term -that is defined nowhere in the standard. Two places (27.5.2.4.2, -paragraph 4, and 27.8.1.4, paragraph 15) contain a cross-reference to -a definition in _lib.iostreams.definitions_, a nonexistent -section.

    - -

    I suspect that the invalid stream position is just supposed to be -pos_type(-1). Probably best to say explicitly in (for example) -27.5.2.4.2 that the return value is pos_type(-1), rather than to use -the term "invalid stream position", define that term -somewhere, and then put in a cross-reference.

    - -

    The phrase "invalid stream position" appears ten times in -the C++ Standard. In seven places it refers to a return value, and it -should be changed. In three places it refers to an argument, and it -should not be changed. Here are the three places where "invalid -stream position" should not be changed:

    - -
    -

    27.7.1.4 [stringbuf.virtuals], paragraph 14
    - 27.8.1.5 [filebuf.virtuals], paragraph 14
    - D.7.1.3 [depr.strstreambuf.virtuals], paragraph 17 -

    -
    - - -

    Proposed resolution:

    -

    In 27.5.2.4.2 [streambuf.virt.buffer], paragraph 4, change "Returns an -object of class pos_type that stores an invalid stream position -(_lib.iostreams.definitions_)" to "Returns -pos_type(off_type(-1))". -

    - -

    In 27.5.2.4.2 [streambuf.virt.buffer], paragraph 6, change "Returns -an object of class pos_type that stores an invalid stream -position" to "Returns pos_type(off_type(-1))".

    - -

    In 27.7.1.4 [stringbuf.virtuals], paragraph 13, change "the object -stores an invalid stream position" to "the return value is -pos_type(off_type(-1))".

    - -

    In 27.8.1.5 [filebuf.virtuals], paragraph 13, change "returns an -invalid stream position (27.4.3)" to "returns -pos_type(off_type(-1))"

    - -

    In 27.8.1.5 [filebuf.virtuals], paragraph 15, change "Otherwise -returns an invalid stream position (_lib.iostreams.definitions_)" -to "Otherwise returns pos_type(off_type(-1))" -

    - -

    In D.7.1.3 [depr.strstreambuf.virtuals], paragraph 15, change "the object -stores an invalid stream position" to "the return value is -pos_type(off_type(-1))"

    - -

    In D.7.1.3 [depr.strstreambuf.virtuals], paragraph 18, change "the object -stores an invalid stream position" to "the return value is -pos_type(off_type(-1))"

    - - - - - -
    -

    56. Showmanyc's return type

    -

    Section: 27.5.2 [streambuf] Status: TC - Submitter: Matt Austern Date: 1998-06-29

    -

    View all other issues in [streambuf].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    The class summary for basic_streambuf<>, in 27.5.2, says that -showmanyc has return type int. However, 27.5.2.4.3 says that its -return type is streamsize.

    - - -

    Proposed resolution:

    -

    Change showmanyc's return type in the -27.5.2 [streambuf] class summary to streamsize.

    - - - - - -
    -

    57. Mistake in char_traits

    -

    Section: 21.1.3.4 [char.traits.specializations.wchar.t] Status: TC - Submitter: Matt Austern Date: 1998-07-01

    -

    View all issues with TC status.

    -

    Discussion:

    -

    21.1.3.2, paragraph 3, says "The types streampos and -wstreampos may be different if the implementation supports no shift -encoding in narrow-oriented iostreams but supports one or more shift -encodings in wide-oriented streams".

    - -

    That's wrong: the two are the same type. The <iosfwd> summary -in 27.2 says that streampos and wstreampos are, respectively, synonyms -for fpos<char_traits<char>::state_type> and -fpos<char_traits<wchar_t>::state_type>, and, flipping back -to clause 21, we see in 21.1.3.1 and 21.1.3.2 that -char_traits<char>::state_type and -char_traits<wchar_t>::state_type must both be mbstate_t.

    - - -

    Proposed resolution:

    -

    Remove the sentence in 21.1.3.4 [char.traits.specializations.wchar.t] paragraph 3 which -begins "The types streampos and wstreampos may be -different..." .

    - - - - - -
    -

    59. Ambiguity in specification of gbump

    -

    Section: 27.5.2.3.2 [streambuf.get.area] Status: TC - Submitter: Matt Austern Date: 1998-07-28

    -

    View all issues with TC status.

    -

    Discussion:

    -

    27.5.2.3.1 says that basic_streambuf::gbump() "Advances the -next pointer for the input sequence by n."

    - -

    The straightforward interpretation is that it is just gptr() += -n. An alternative interpretation, though, is that it behaves as if it -calls sbumpc n times. (The issue, of course, is whether it might ever -call underflow.) There is a similar ambiguity in the case of -pbump.

    - -

    (The "classic" AT&T implementation used the -former interpretation.)

    - - -

    Proposed resolution:

    -

    Change 27.5.2.3.2 [streambuf.get.area] paragraph 4 gbump effects from:

    - -
    -

    Effects: Advances the next pointer for the input sequence by n.

    -
    - -

    to:

    - -
    -

    Effects: Adds n to the next pointer for the input sequence.

    -
    - -

    Make the same change to 27.5.2.3.3 [streambuf.put.area] paragraph 4 pbump -effects.

    - - - - - -
    -

    60. What is a formatted input function?

    -

    Section: 27.6.1.2.1 [istream.formatted.reqmts] Status: TC - Submitter: Matt Austern Date: 1998-08-03

    -

    View all other issues in [istream.formatted.reqmts].

    -

    View all issues with TC status.

    -

    Duplicate of: 162, 163, 166

    -

    Discussion:

    -

    Paragraph 1 of 27.6.1.2.1 contains general requirements for all -formatted input functions. Some of the functions defined in section -27.6.1.2 explicitly say that those requirements apply ("Behaves -like a formatted input member (as described in 27.6.1.2.1)"), but -others don't. The question: is 27.6.1.2.1 supposed to apply to -everything in 27.6.1.2, or only to those member functions that -explicitly say "behaves like a formatted input member"? Or -to put it differently: are we to assume that everything that appears -in a section called "Formatted input functions" really is a -formatted input function? I assume that 27.6.1.2.1 is intended to -apply to the arithmetic extractors (27.6.1.2.2), but I assume that it -is not intended to apply to extractors like

    - -
        basic_istream& operator>>(basic_istream& (*pf)(basic_istream&));
    - -

    and

    - -
        basic_istream& operator>>(basic_streammbuf*);
    - -

    There is a similar ambiguity for unformatted input, formatted output, and unformatted -output.

    - -

    Comments from Judy Ward: It seems like the problem is that the -basic_istream and basic_ostream operator <<()'s that are used -for the manipulators and streambuf* are in the wrong section and -should have their own separate section or be modified to make it clear -that the "Common requirements" listed in section 27.6.1.2.1 -(for basic_istream) and section 27.6.2.5.1 (for basic_ostream) do not -apply to them.

    - -

    Additional comments from Dietmar Kühl: It appears to be somewhat -nonsensical to consider the functions defined in 27.6.1.2.3 -[istream::extractors] paragraphs 1 to 5 to be "Formatted input -function" but since these functions are defined in a section -labeled "Formatted input functions" it is unclear to me -whether these operators are considered formatted input functions which -have to conform to the "common requirements" from 27.6.1.2.1 -[istream.formatted.reqmts]: If this is the case, all manipulators, not -just ws, would skip whitespace unless noskipws is -set (... but setting noskipws using the manipulator syntax -would also skip whitespace :-)

    It is not clear which functions -are to be considered unformatted input functions. As written, it seems -that all functions in 27.6.1.3 [istream.unformatted] are unformatted input -functions. However, it does not really make much sense to construct a -sentry object for gcount(), sync(), ... Also it is -unclear what happens to the gcount() if -eg. gcount(), putback(), unget(), or -sync() is called: These functions don't extract characters, -some of them even "unextract" a character. Should this still -be reflected in gcount()? Of course, it could be read as if -after a call to gcount() gcount() return 0 -(the last unformatted input function, gcount(), didn't -extract any character) and after a call to putback() -gcount() returns -1 (the last unformatted input -function putback() did "extract" back into the -stream). Correspondingly for unget(). Is this what is -intended? If so, this should be clarified. Otherwise, a corresponding -clarification should be used.

    - - -

    Proposed resolution:

    -

    -In 27.6.1.2.2 [lib.istream.formatted.arithmetic], paragraph 1. -Change the beginning of the second sentence from "The conversion -occurs" to "These extractors behave as formatted input functions (as -described in 27.6.1.2.1). After a sentry object is constructed, -the conversion occurs" -

    - -

    -In 27.6.1.2.3, [lib.istream::extractors], before paragraph 1. -Add an effects clause. "Effects: None. This extractor does -not behave as a formatted input function (as described in -27.6.1.2.1). -

    - -

    -In 27.6.1.2.3, [lib.istream::extractors], paragraph 2. Change the -effects clause to "Effects: Calls pf(*this). This extractor does not -behave as a formatted input function (as described in 27.6.1.2.1). -

    - -

    -In 27.6.1.2.3, [lib.istream::extractors], paragraph 4. Change the -effects clause to "Effects: Calls pf(*this). This extractor does not -behave as a formatted input function (as described in 27.6.1.2.1). -

    - -

    -In 27.6.1.2.3, [lib.istream::extractors], paragraph 12. Change the -first two sentences from "If sb is null, calls setstate(failbit), -which may throw ios_base::failure (27.4.4.3). Extracts characters -from *this..." to "Behaves as a formatted input function (as described -in 27.6.1.2.1). If sb is null, calls setstate(failbit), which may -throw ios_base::failure (27.4.4.3). After a sentry object is -constructed, extracts characters from *this...". -

    - -

    -In 27.6.1.3, [lib.istream.unformatted], before paragraph 2. Add an -effects clause. "Effects: none. This member function does not behave -as an unformatted input function (as described in 27.6.1.3, paragraph 1)." -

    - -

    -In 27.6.1.3, [lib.istream.unformatted], paragraph 3. Change the -beginning of the first sentence of the effects clause from "Extracts a -character" to "Behaves as an unformatted input function (as described -in 27.6.1.3, paragraph 1). After constructing a sentry object, extracts a -character" -

    - -

    -In 27.6.1.3, [lib.istream.unformatted], paragraph 5. Change the -beginning of the first sentence of the effects clause from "Extracts a -character" to "Behaves as an unformatted input function (as described -in 27.6.1.3, paragraph 1). After constructing a sentry object, extracts a -character" -

    - -

    -In 27.6.1.3, [lib.istream.unformatted], paragraph 7. Change the -beginning of the first sentence of the effects clause from "Extracts -characters" to "Behaves as an unformatted input function (as described -in 27.6.1.3, paragraph 1). After constructing a sentry object, extracts -characters" -

    - -

    -[No change needed in paragraph 10, because it refers to paragraph 7.] -

    - -

    -In 27.6.1.3, [lib.istream.unformatted], paragraph 12. Change the -beginning of the first sentence of the effects clause from "Extracts -characters" to "Behaves as an unformatted input function (as described -in 27.6.1.3, paragraph 1). After constructing a sentry object, extracts -characters" -

    - -

    -[No change needed in paragraph 15.] -

    - -

    -In 27.6.1.3, [lib.istream.unformatted], paragraph 17. Change the -beginning of the first sentence of the effects clause from "Extracts -characters" to "Behaves as an unformatted input function (as described -in 27.6.1.3, paragraph 1). After constructing a sentry object, extracts -characters" -

    - -

    -[No change needed in paragraph 23.] -

    - -

    -In 27.6.1.3, [lib.istream.unformatted], paragraph 24. Change the -beginning of the first sentence of the effects clause from "Extracts -characters" to "Behaves as an unformatted input function (as described -in 27.6.1.3, paragraph 1). After constructing a sentry object, extracts -characters" -

    - -

    -In 27.6.1.3, [lib.istream.unformatted], before paragraph 27. Add an -Effects clause: "Effects: Behaves as an unformatted input function (as -described in 27.6.1.3, paragraph 1). After constructing a sentry -object, reads but does not extract the current input character." -

    - -

    -In 27.6.1.3, [lib.istream.unformatted], paragraph 28. Change the -first sentence of the Effects clause from "If !good() calls" to -Behaves as an unformatted input function (as described in 27.6.1.3, -paragraph 1). After constructing a sentry object, if !good() calls" -

    - -

    -In 27.6.1.3, [lib.istream.unformatted], paragraph 30. Change the -first sentence of the Effects clause from "If !good() calls" to -"Behaves as an unformatted input function (as described in 27.6.1.3, -paragraph 1). After constructing a sentry object, if !good() calls" -

    - -

    -In 27.6.1.3, [lib.istream.unformatted], paragraph 32. Change the -first sentence of the Effects clause from "If !good() calls..." to -"Behaves as an unformatted input function (as described in 27.6.1.3, -paragraph 1). After constructing a sentry object, if !good() -calls..." Add a new sentence to the end of the Effects clause: -"[Note: this function extracts no characters, so the value returned -by the next call to gcount() is 0.]" -

    - -

    -In 27.6.1.3, [lib.istream.unformatted], paragraph 34. Change the -first sentence of the Effects clause from "If !good() calls" to -"Behaves as an unformatted input function (as described in 27.6.1.3, -paragraph 1). After constructing a sentry object, if !good() calls". -Add a new sentence to the end of the Effects clause: "[Note: this -function extracts no characters, so the value returned by the next -call to gcount() is 0.]" -

    - -

    -In 27.6.1.3, [lib.istream.unformatted], paragraph 36. Change the -first sentence of the Effects clause from "If !rdbuf() is" to "Behaves -as an unformatted input function (as described in 27.6.1.3, paragraph -1), except that it does not count the number of characters extracted -and does not affect the value returned by subsequent calls to -gcount(). After constructing a sentry object, if rdbuf() is" -

    - -

    -In 27.6.1.3, [lib.istream.unformatted], before paragraph 37. Add an -Effects clause: "Effects: Behaves as an unformatted input function (as -described in 27.6.1.3, paragraph 1), except that it does not count the -number of characters extracted and does not affect the value returned -by subsequent calls to gcount()." Change the first sentence of -paragraph 37 from "if fail()" to "after constructing a sentry object, -if fail()". -

    - -

    -In 27.6.1.3, [lib.istream.unformatted], paragraph 38. Change the -first sentence of the Effects clause from "If fail()" to "Behaves -as an unformatted input function (as described in 27.6.1.3, paragraph -1), except that it does not count the number of characters extracted -and does not affect the value returned by subsequent calls to -gcount(). After constructing a sentry object, if fail() -

    - -

    -In 27.6.1.3, [lib.istream.unformatted], paragraph 40. Change the -first sentence of the Effects clause from "If fail()" to "Behaves -as an unformatted input function (as described in 27.6.1.3, paragraph -1), except that it does not count the number of characters extracted -and does not affect the value returned by subsequent calls to -gcount(). After constructing a sentry object, if fail() -

    - -

    -In 27.6.2.5.2 [lib.ostream.inserters.arithmetic], paragraph 1. Change -the beginning of the third sentence from "The formatting conversion" -to "These extractors behave as formatted output functions (as -described in 27.6.2.5.1). After the sentry object is constructed, the -conversion occurs". -

    - -

    -In 27.6.2.5.3 [lib.ostream.inserters], before paragraph 1. Add an -effects clause: "Effects: None. Does not behave as a formatted output -function (as described in 27.6.2.5.1).". -

    - -

    -In 27.6.2.5.3 [lib.ostream.inserters], paragraph 2. Change the -effects clause to "Effects: calls pf(*this). This extractor does not -behave as a formatted output function (as described in 27.6.2.5.1).". -

    - -

    -In 27.6.2.5.3 [lib.ostream.inserters], paragraph 4. Change the -effects clause to "Effects: calls pf(*this). This extractor does not -behave as a formatted output function (as described in 27.6.2.5.1).". -

    - -

    -In 27.6.2.5.3 [lib.ostream.inserters], paragraph 6. Change the first -sentence from "If sb" to "Behaves as a formatted output function (as -described in 27.6.2.5.1). After the sentry object is constructed, if -sb". -

    - -

    -In 27.6.2.6 [lib.ostream.unformatted], paragraph 2. Change the first -sentence from "Inserts the character" to "Behaves as an unformatted -output function (as described in 27.6.2.6, paragraph 1). After -constructing a sentry object, inserts the character". -

    - -

    -In 27.6.2.6 [lib.ostream.unformatted], paragraph 5. Change the first -sentence from "Obtains characters" to "Behaves as an unformatted -output function (as described in 27.6.2.6, paragraph 1). After -constructing a sentry object, obtains characters". -

    - -

    -In 27.6.2.6 [lib.ostream.unformatted], paragraph 7. Add a new -sentence at the end of the paragraph: "Does not behave as an -unformatted output function (as described in 27.6.2.6, paragraph 1)." -

    - - -

    Rationale:

    -

    See J16/99-0043==WG21/N1219, Proposed Resolution to Library Issue 60, -by Judy Ward and Matt Austern. This proposed resolution is section -VI of that paper.

    - - - - - -
    -

    61. Ambiguity in iostreams exception policy

    -

    Section: 27.6.1.3 [istream.unformatted] Status: TC - Submitter: Matt Austern Date: 1998-08-06

    -

    View all other issues in [istream.unformatted].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    The introduction to the section on unformatted input (27.6.1.3) -says that every unformatted input function catches all exceptions that -were thrown during input, sets badbit, and then conditionally rethrows -the exception. That seems clear enough. Several of the specific -functions, however, such as get() and read(), are documented in some -circumstances as setting eofbit and/or failbit. (The standard notes, -correctly, that setting eofbit or failbit can sometimes result in an -exception being thrown.) The question: if one of these functions -throws an exception triggered by setting failbit, is this an exception -"thrown during input" and hence covered by 27.6.1.3, or does -27.6.1.3 only refer to a limited class of exceptions? Just to make -this concrete, suppose you have the following snippet.

    - -
      
-  char buffer[N];
-  istream is;
-  ...
-  is.exceptions(istream::failbit); // Throw on failbit but not on badbit.
-  is.read(buffer, N);
    - -

    Now suppose we reach EOF before we've read N characters. What -iostate bits can we expect to be set, and what exception (if any) will -be thrown?

    - - -

    Proposed resolution:

    -

    -In 27.6.1.3, paragraph 1, after the sentence that begins -"If an exception is thrown...", add the following -parenthetical comment: "(Exceptions thrown from -basic_ios<>::clear() are not caught or rethrown.)" -

    - - -

    Rationale:

    -

    The LWG looked to two alternative wordings, and choose the proposed -resolution as better standardese.

    - - - - - -
    -

    62. Sync's return value

    -

    Section: 27.6.1.3 [istream.unformatted] Status: TC - Submitter: Matt Austern Date: 1998-08-06

    -

    View all other issues in [istream.unformatted].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    The Effects clause for sync() (27.6.1.3, paragraph 36) says that it -"calls rdbuf()->pubsync() and, if that function returns -1 -... returns traits::eof()."

    - -

    That looks suspicious, because traits::eof() is of type -traits::int_type while the return type of sync() is int.

    - - -

    Proposed resolution:

    -

    In 27.6.1.3 [istream.unformatted], paragraph 36, change "returns -traits::eof()" to "returns -1". -

    - - - - - -
    -

    63. Exception-handling policy for unformatted output

    -

    Section: 27.6.2.7 [ostream.unformatted] Status: TC - Submitter: Matt Austern Date: 1998-08-11

    -

    View all other issues in [ostream.unformatted].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    Clause 27 details an exception-handling policy for formatted input, -unformatted input, and formatted output. It says nothing for -unformatted output (27.6.2.6). 27.6.2.6 should either include the same -kind of exception-handling policy as in the other three places, or -else it should have a footnote saying that the omission is -deliberate.

    - - -

    Proposed resolution:

    -

    -In 27.6.2.6, paragraph 1, replace the last sentence ("In any -case, the unformatted output function ends by destroying the sentry -object, then returning the value specified for the formatted output -function.") with the following text: -

    -

    -If an exception is thrown during output, then ios::badbit is -turned on [Footnote: without causing an ios::failure to be -thrown.] in *this's error state. If (exceptions() & -badbit) != 0 then the exception is rethrown. In any case, the -unformatted output function ends by destroying the sentry object, -then, if no exception was thrown, returning the value specified for -the formatted output function. -

    - - -

    Rationale:

    -

    -This exception-handling policy is consistent with that of formatted -input, unformatted input, and formatted output. -

    - - - - - -
    -

    64. Exception handling in basic_istream::operator>>(basic_streambuf*)

    -

    Section: 27.6.1.2.3 [istream::extractors] Status: TC - Submitter: Matt Austern Date: 1998-08-11

    -

    View all other issues in [istream::extractors].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    27.6.1.2.3, paragraph 13, is ambiguous. It can be interpreted two -different ways, depending on whether the second sentence is read as an -elaboration of the first.

    - - -

    Proposed resolution:

    -

    Replace 27.6.1.2.3 [istream::extractors], paragraph 13, which begins -"If the function inserts no characters ..." with:

    - -
    -

    If the function inserts no characters, it calls - setstate(failbit), which may throw - ios_base::failure (27.4.4.3). If it inserted no characters - because it caught an exception thrown while extracting characters - from sb and failbit is on in exceptions() - (27.4.4.3), then the caught exception is rethrown.

    -
    - - - - - -
    -

    66. Strstreambuf::setbuf

    -

    Section: D.7.1.3 [depr.strstreambuf.virtuals] Status: TC - Submitter: Matt Austern Date: 1998-08-18

    -

    View all other issues in [depr.strstreambuf.virtuals].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    D.7.1.3, paragraph 19, says that strstreambuf::setbuf -"Performs an operation that is defined separately for each class -derived from strstreambuf". This is obviously an incorrect -cut-and-paste from basic_streambuf. There are no classes derived from -strstreambuf.

    - - -

    Proposed resolution:

    -

    D.7.1.3 [depr.strstreambuf.virtuals], paragraph 19, replace the setbuf effects -clause which currently says "Performs an operation that is -defined separately for each class derived from strstreambuf" -with:

    - -
    -

    Effects: implementation defined, except that - setbuf(0,0) has no effect.

    -
    - - - - - -
    -

    68. Extractors for char* should store null at end

    -

    Section: 27.6.1.2.3 [istream::extractors] Status: TC - Submitter: Angelika Langer Date: 1998-07-14

    -

    View all other issues in [istream::extractors].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    Extractors for char* (27.6.1.2.3) do not store a null character -after the extracted character sequence whereas the unformatted -functions like get() do. Why is this?

    - -

    Comment from Jerry Schwarz: There is apparently an editing -glitch. You'll notice that the last item of the list of what stops -extraction doesn't make any sense. It was supposed to be the line that -said a null is stored.

    - - -

    Proposed resolution:

    -

    27.6.1.2.3 [istream::extractors], paragraph 7, change the last list -item from:

    - -

    - A null byte (charT()) in the next position, which may be - the first position if no characters were extracted. -

    - -

    to become a new paragraph which reads:

    - -

    - Operator>> then stores a null byte (charT()) in the - next position, which may be the first position if no characters were - extracted. -

    - - - - - -
    -

    69. Must elements of a vector be contiguous?

    -

    Section: 23.2.6 [vector] Status: TC - Submitter: Andrew Koenig Date: 1998-07-29

    -

    View all other issues in [vector].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    The issue is this: Must the elements of a vector be in contiguous memory?

    - -

    (Please note that this is entirely separate from the question of -whether a vector iterator is required to be a pointer; the answer to -that question is clearly "no," as it would rule out -debugging implementations)

    - - -

    Proposed resolution:

    -

    Add the following text to the end of 23.2.6 [vector], -paragraph 1.

    - -
    -

    The elements of a vector are stored contiguously, meaning that if - v is a vector<T, Allocator> where T is some type - other than bool, then it obeys the identity &v[n] - == &v[0] + n for all 0 <= n < v.size().

    -
    - - -

    Rationale:

    -

    The LWG feels that as a practical matter the answer is clearly -"yes". There was considerable discussion as to the best way -to express the concept of "contiguous", which is not -directly defined in the standard. Discussion included:

    - -
      -
    • An operational definition similar to the above proposed resolution is - already used for valarray (26.5.2.3 [valarray.access]).
      • -
    • There is no need to explicitly consider a user-defined operator& - because elements must be copyconstructible (23.1 [container.requirements] para 3) - and copyconstructible (20.1.1 [utility.arg.requirements]) specifies - requirements for operator&.
      • -
    • There is no issue of one-past-the-end because of language rules.
      • -
    - - - - - -
    -

    70. Uncaught_exception() missing throw() specification

    -

    Section: 18.7 [support.exception], 18.7.4 [uncaught] Status: TC - Submitter: Steve Clamage Date: 1998-08-03

    -

    View all other issues in [support.exception].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    In article 3E04@pratique.fr, Valentin Bonnard writes:

    - -

    uncaught_exception() doesn't have a throw specification.

    - -

    It is intentional ? Does it means that one should be prepared to -handle exceptions thrown from uncaught_exception() ?

    - -

    uncaught_exception() is called in exception handling contexts where -exception safety is very important.

    - - -

    Proposed resolution:

    -

    In 15.5.3 [except.uncaught], paragraph 1, 18.7 [support.exception], -and 18.7.4 [uncaught], add "throw()" to uncaught_exception().

    - - - - -
    -

    71. Do_get_monthname synopsis missing argument

    -

    Section: 22.2.5.1 [locale.time.get] Status: TC - Submitter: Nathan Myers Date: 1998-08-13

    -

    View all issues with TC status.

    -

    Discussion:

    -

    The locale facet member time_get<>::do_get_monthname -is described in 22.2.5.1.2 [locale.time.get.virtuals] with five arguments, -consistent with do_get_weekday and with its specified use by member -get_monthname. However, in the synopsis, it is specified instead with -four arguments. The missing argument is the "end" iterator -value.

    - - -

    Proposed resolution:

    -

    In 22.2.5.1 [locale.time.get], add an "end" argument to -the declaration of member do_monthname as follows:

    - -
      virtual iter_type do_get_monthname(iter_type s, iter_type end, ios_base&,
-                                     ios_base::iostate& err, tm* t) const;
    - - - - -
    -

    74. Garbled text for codecvt::do_max_length

    -

    Section: 22.2.1.4 [locale.codecvt] Status: TC - Submitter: Matt Austern Date: 1998-09-08

    -

    View all other issues in [locale.codecvt].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    The text of codecvt::do_max_length's "Returns" -clause (22.2.1.5.2, paragraph 11) is garbled. It has unbalanced -parentheses and a spurious n.

    - - -

    Proposed resolution:

    -

    Replace 22.2.1.4.2 [locale.codecvt.virtuals] paragraph 11 with the -following:

    - -

    - Returns: The maximum value that - do_length(state, from, from_end, 1) can return for any - valid range [from, from_end) and stateT value - state. The specialization codecvt<char, char, - mbstate_t>::do_max_length() returns 1. -

    - - - - -
    -

    75. Contradiction in codecvt::length's argument types

    -

    Section: 22.2.1.4 [locale.codecvt] Status: TC - Submitter: Matt -Austern Date: 1998-09-18

    -

    View all other issues in [locale.codecvt].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    The class synopses for classes codecvt<> (22.2.1.5) -and codecvt_byname<> (22.2.1.6) say that the first -parameter of the member functions length and -do_length is of type const stateT&. The member -function descriptions, however (22.2.1.5.1, paragraph 6; 22.2.1.5.2, -paragraph 9) say that the type is stateT&. Either the -synopsis or the summary must be changed.

    - -

    If (as I believe) the member function descriptions are correct, -then we must also add text saying how do_length changes its -stateT argument.

    - - -

    Proposed resolution:

    -

    In 22.2.1.4 [locale.codecvt], and also in 22.2.1.5 [locale.codecvt.byname], -change the stateT argument type on both member -length() and member do_length() from

    - -
    -

    const stateT&

    -
    - -

    to

    - -
    -

    stateT&

    -
    - -

    In 22.2.1.4.2 [locale.codecvt.virtuals], add to the definition for member -do_length a paragraph:

    - -
    -

    Effects: The effect on the state argument is ``as if'' - it called do_in(state, from, from_end, from, to, to+max, - to) for to pointing to a buffer of at least - max elements.

    -
    - - - - -
    -

    76. Can a codecvt facet always convert one internal character at a time?

    -

    Section: 22.2.1.4 [locale.codecvt] Status: WP - Submitter: Matt Austern Date: 1998-09-25

    -

    View all other issues in [locale.codecvt].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    This issue concerns the requirements on classes derived from -codecvt, including user-defined classes. What are the -restrictions on the conversion from external characters -(e.g. char) to internal characters (e.g. wchar_t)? -Or, alternatively, what assumptions about codecvt facets can -the I/O library make?

    - -

    The question is whether it's possible to convert from internal -characters to external characters one internal character at a time, -and whether, given a valid sequence of external characters, it's -possible to pick off internal characters one at a time. Or, to put it -differently: given a sequence of external characters and the -corresponding sequence of internal characters, does a position in the -internal sequence correspond to some position in the external -sequence?

    - -

    To make this concrete, suppose that [first, last) is a -sequence of M external characters and that [ifirst, -ilast) is the corresponding sequence of N internal -characters, where N > 1. That is, my_encoding.in(), -applied to [first, last), yields [ifirst, -ilast). Now the question: does there necessarily exist a -subsequence of external characters, [first, last_1), such -that the corresponding sequence of internal characters is the single -character *ifirst? -

    - -

    (What a "no" answer would mean is that -my_encoding translates sequences only as blocks. There's a -sequence of M external characters that maps to a sequence of -N internal characters, but that external sequence has no -subsequence that maps to N-1 internal characters.)

    - -

    Some of the wording in the standard, such as the description of -codecvt::do_max_length (22.2.1.4.2 [locale.codecvt.virtuals], -paragraph 11) and basic_filebuf::underflow (27.8.1.5 [filebuf.virtuals], paragraph 3) suggests that it must always be -possible to pick off internal characters one at a time from a sequence -of external characters. However, this is never explicitly stated one -way or the other.

    - -

    This issue seems (and is) quite technical, but it is important if -we expect users to provide their own encoding facets. This is an area -where the standard library calls user-supplied code, so a well-defined -set of requirements for the user-supplied code is crucial. Users must -be aware of the assumptions that the library makes. This issue affects -positioning operations on basic_filebuf, unbuffered input, -and several of codecvt's member functions.

    - - -

    Proposed resolution:

    -

    Add the following text as a new paragraph, following 22.2.1.4.2 [locale.codecvt.virtuals] paragraph 2:

    - -
    -

    A codecvt facet that is used by basic_filebuf -(27.8 [file.streams]) must have the property that if

    -
        do_out(state, from, from_end, from_next, to, to_lim, to_next)
-
    -

    would return ok, where from != from_end, then

    -
        do_out(state, from, from + 1, from_next, to, to_end, to_next)
-
    -

    must also return ok, and that if

    -
        do_in(state, from, from_end, from_next, to, to_lim, to_next)
-
    -

    would return ok, where to != to_lim, then

    -
        do_in(state, from, from_end, from_next, to, to + 1, to_next)
-
    -

    must also return ok. [Footnote: Informally, this -means that basic_filebuf assumes that the mapping from -internal to external characters is 1 to N: a codecvt that is -used by basic_filebuf must be able to translate characters -one internal character at a time. --End Footnote]

    -
    - -

    [Redmond: Minor change in proposed resolution. Original -proposed resolution talked about "success", with a parenthetical -comment that success meant returning ok. New wording -removes all talk about "success", and just talks about the -return value.]

    - - - - -

    Rationale:

    - -

    The proposed resoluion says that conversions can be performed one - internal character at a time. This rules out some encodings that - would otherwise be legal. The alternative answer would mean there - would be some internal positions that do not correspond to any - external file position.

    -

    - An example of an encoding that this rules out is one where the - internT and externT are of the same type, and - where the internal sequence c1 c2 corresponds to the - external sequence c2 c1. -

    -

    It was generally agreed that basic_filebuf relies - on this property: it was designed under the assumption that - the external-to-internal mapping is N-to-1, and it is not clear - that basic_filebuf is implementable without that - restriction. -

    -

    - The proposed resolution is expressed as a restriction on - codecvt when used by basic_filebuf, rather - than a blanket restriction on all codecvt facets, - because basic_filebuf is the only other part of the - library that uses codecvt. If a user wants to define - a codecvt facet that implements a more general N-to-M - mapping, there is no reason to prohibit it, so long as the user - does not expect basic_filebuf to be able to use it. -

    - - - - - -
    -

    78. Typo: event_call_back

    -

    Section: 27.4.2 [ios.base] Status: TC - Submitter: Nico Josuttis Date: 1998-09-29

    -

    View all other issues in [ios.base].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    typo: event_call_back should be event_callback  

    - - -

    Proposed resolution:

    -

    In the 27.4.2 [ios.base] synopsis change -"event_call_back" to "event_callback".

    - - - - -
    -

    79. Inconsistent declaration of polar()

    -

    Section: 26.3.1 [complex.synopsis], 26.3.7 [complex.value.ops] Status: TC - Submitter: Nico Josuttis Date: 1998-09-29

    -

    View all other issues in [complex.synopsis].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    In 26.3.1 [complex.synopsis] polar is declared as follows:

    -
       template<class T> complex<T> polar(const T&, const T&);
    - -

    In 26.3.7 [complex.value.ops] it is declared as follows:

    -
       template<class T> complex<T> polar(const T& rho, const T& theta = 0);
    - -

    Thus whether the second parameter is optional is not clear.

    - - -

    Proposed resolution:

    -

    In 26.3.1 [complex.synopsis] change:

    -
       template<class T> complex<T> polar(const T&, const T&);
    - -

    to:

    -
       template<class T> complex<T> polar(const T& rho, const T& theta = 0);
    - - - - - -
    -

    80. Global Operators of complex declared twice

    -

    Section: 26.3.1 [complex.synopsis], 26.3.2 [complex] Status: TC - Submitter: Nico Josuttis Date: 1998-09-29

    -

    View all other issues in [complex.synopsis].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    Both 26.2.1 and 26.2.2 contain declarations of global operators for -class complex. This redundancy should be removed.

    - - -

    Proposed resolution:

    -

    Reduce redundancy according to the general style of the standard.

    - - - - -
    -

    83. String::npos vs. string::max_size()

    -

    Section: 21.3 [basic.string] Status: TC - Submitter: Nico Josuttis Date: 1998-09-29

    -

    View other active issues in [basic.string].

    -

    View all other issues in [basic.string].

    -

    View all issues with TC status.

    -

    Duplicate of: 89

    -

    Discussion:

    -

    Many string member functions throw if size is getting or exceeding -npos. However, I wonder why they don't throw if size is getting or -exceeding max_size() instead of npos. May be npos is known at compile -time, while max_size() is known at runtime. However, what happens if -size exceeds max_size() but not npos, then? It seems the standard -lacks some clarifications here.

    - - -

    Proposed resolution:

    -

    After 21.3 [basic.string] paragraph 4 ("The functions -described in this clause...") add a new paragraph:

    - -
    -

    For any string operation, if as a result of the operation, size() would exceed - max_size() then - the operation throws length_error.

    -
    - - -

    Rationale:

    -

    The LWG believes length_error is the correct exception to throw.

    - - - - -
    -

    86. String constructors don't describe exceptions

    -

    Section: 21.3.1 [string.require] Status: TC - Submitter: Nico Josuttis Date: 1998-09-29

    -

    View all other issues in [string.require].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    The constructor from a range:

    - -
    template<class InputIterator> 
-         basic_string(InputIterator begin, InputIterator end, 
-                      const Allocator& a = Allocator());
    - -

    lacks a throws clause. However, I would expect that it throws -according to the other constructors if the numbers of characters in -the range equals npos (or exceeds max_size(), see above).

    - - -

    Proposed resolution:

    -

    In 21.3.1 [string.require], Strike throws paragraphs for -constructors which say "Throws: length_error if n == -npos."

    - - -

    Rationale:

    -

    Throws clauses for length_error if n == npos are no longer needed -because they are subsumed by the general wording added by the -resolution for issue 83.

    - - - - -
    -

    90. Incorrect description of operator >> for strings

    -

    Section: 21.3.8.9 [string.io] Status: TC - Submitter: Nico Josuttis Date: 1998-09-29

    -

    View all other issues in [string.io].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    The effect of operator >> for strings contain the following item:

    - -

        isspace(c,getloc()) is true for the next available input -character c.

    - -

    Here getloc() has to be replaced by is.getloc().

    - - -

    Proposed resolution:

    -

    In 21.3.8.9 [string.io] paragraph 1 Effects clause replace:

    - -
    -

    isspace(c,getloc()) is true for the next available input character c.

    -
    - -

    with:

    - -
    -

    isspace(c,is.getloc()) is true for the next available input character c.

    -
    - - - - - -
    -

    91. Description of operator>> and getline() for string<> might cause endless loop

    -

    Section: 21.3.8.9 [string.io] Status: WP - Submitter: Nico Josuttis Date: 1998-09-29

    -

    View all other issues in [string.io].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    Operator >> and getline() for strings read until eof() -in the input stream is true. However, this might never happen, if the -stream can't read anymore without reaching EOF. So shouldn't it be -changed into that it reads until !good() ?

    - - -

    Proposed resolution:

    -

    In 21.3.8.9 [string.io], paragraph 1, replace:

    -

    -Effects: Begins by constructing a sentry object k as if k were -constructed by typename basic_istream<charT,traits>::sentry k( is). If -bool( k) is true, it calls str.erase() and then extracts characters -from is and appends them to str as if by calling str.append(1, c). If -is.width() is greater than zero, the maximum number n of characters -appended is is.width(); otherwise n is str.max_size(). Characters are -extracted and appended until any of the following occurs: -

    -

    with:

    -

    -Effects: Behaves as a formatted input function (27.6.1.2.1 -[istream.formatted.reqmts]). After constructing a sentry object, if the -sentry converts to true, calls str.erase() and then extracts -characters from is and appends them to str as if by calling -str.append(1,c). If is.width() is greater than zero, the maximum -number n of characters appended is is.width(); otherwise n is -str.max_size(). Characters are extracted and appended until any of the -following occurs: -

    - -

    In 21.3.8.9 [string.io], paragraph 6, replace

    -

    -Effects: Begins by constructing a sentry object k as if by typename -basic_istream<charT,traits>::sentry k( is, true). If bool( k) is true, -it calls str.erase() and then extracts characters from is and appends -them to str as if by calling str.append(1, c) until any of the -following occurs: -

    -

    with:

    -

    Effects: Behaves as an unformatted input function -(27.6.1.3 [istream.unformatted]), except that it does not affect the -value returned -by subsequent calls to basic_istream<>::gcount(). After -constructing a sentry object, if the sentry converts to true, calls -str.erase() and then extracts characters from is and appends them to -str as if by calling str.append(1,c) until any of the following -occurs: -

    - -

    [Redmond: Made changes in proposed resolution. operator>> -should be a formatted input function, not an unformatted input function. -getline should not be required to set gcount, since -there is no mechanism for gcount to be set except by one of -basic_istream's member functions.]

    - - -

    [Curaçao: Nico agrees with proposed resolution.]

    - - - - -

    Rationale:

    -

    The real issue here is whether or not these string input functions -get their characters from a streambuf, rather than by calling an -istream's member functions, a streambuf signals failure either by -returning eof or by throwing an exception; there are no other -possibilities. The proposed resolution makes it clear that these two -functions do get characters from a streambuf.

    - - - - - -
    -

    92. Incomplete Algorithm Requirements

    -

    Section: 25 [algorithms] Status: WP - Submitter: Nico Josuttis Date: 1998-09-29

    -

    View all other issues in [algorithms].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    The standard does not state, how often a function object is copied, -called, or the order of calls inside an algorithm. This may lead to -surprising/buggy behavior. Consider the following example:

    - -
    class Nth {    // function object that returns true for the nth element 
-  private: 
-    int nth;     // element to return true for 
-    int count;   // element counter 
-  public: 
-    Nth (int n) : nth(n), count(0) { 
-    } 
-    bool operator() (int) { 
-        return ++count == nth; 
-    } 
-}; 
-.... 
-// remove third element 
-    list<int>::iterator pos; 
-    pos = remove_if(coll.begin(),coll.end(),  // range 
-                    Nth(3)),                  // remove criterion 
-    coll.erase(pos,coll.end());
    - -

    This call, in fact removes the 3rd AND the 6th element. This -happens because the usual implementation of the algorithm copies the -function object internally:

    - -
    template <class ForwIter, class Predicate> 
-ForwIter std::remove_if(ForwIter beg, ForwIter end, Predicate op) 
-{ 
-    beg = find_if(beg, end, op); 
-    if (beg == end) { 
-        return beg; 
-    } 
-    else { 
-        ForwIter next = beg; 
-        return remove_copy_if(++next, end, beg, op); 
-    } 
-}
    - -

    The algorithm uses find_if() to find the first element that should -be removed. However, it then uses a copy of the passed function object -to process the resulting elements (if any). Here, Nth is used again -and removes also the sixth element. This behavior compromises the -advantage of function objects being able to have a state. Without any -cost it could be avoided (just implement it directly instead of -calling find_if()).

    - - -

    Proposed resolution:

    - -

    Add a new paragraph following 25 [algorithms] paragraph 8:

    -

    -[Note: Unless otherwise specified, algorithms that take function -objects as arguments are permitted to copy those function objects -freely. Programmers for whom object identity is important should -consider using a wrapper class that points to a noncopied -implementation object, or some equivalent solution.] -

    - -

    [Dublin: Pete Becker felt that this may not be a defect, -but rather something that programmers need to be educated about. -There was discussion of adding wording to the effect that the number -and order of calls to function objects, including predicates, not -affect the behavior of the function object.]

    - - -

    [Pre-Kona: Nico comments: It seems the problem is that we don't -have a clear statement of "predicate" in the -standard. People including me seemed to think "a function -returning a Boolean value and being able to be called by an STL -algorithm or be used as sorting criterion or ... is a -predicate". But a predicate has more requirements: It should -never change its behavior due to a call or being copied. IMHO we have -to state this in the standard. If you like, see section 8.1.4 of my -library book for a detailed discussion.]

    - - -

    [Kona: Nico will provide wording to the effect that "unless -otherwise specified, the number of copies of and calls to function -objects by algorithms is unspecified".  Consider placing in -25 [algorithms] after paragraph 9.]

    - - -

    [Santa Cruz: The standard doesn't currently guarantee that - functions object won't be copied, and what isn't forbidden is - allowed. It is believed (especially since implementations that were - written in concert with the standard do make copies of function - objects) that this was intentional. Thus, no normative change is - needed. What we should put in is a non-normative note suggesting to - programmers that if they want to guarantee the lack of copying they - should use something like the ref wrapper.]

    - - -

    [Oxford: Matt provided wording.]

    - - - - - - - - -
    -

    98. Input iterator requirements are badly written

    -

    Section: 24.1.1 [input.iterators] Status: WP - Submitter: AFNOR Date: 1998-10-07

    -

    View all other issues in [input.iterators].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    Table 72 in 24.1.1 [input.iterators] specifies semantics for -*r++ of:

    - -

       { T tmp = *r; ++r; return tmp; }

    - -

    There are two problems with this. First, the return type is -specified to be "T", as opposed to something like "convertible to T". -This is too specific: we want to allow *r++ to return an lvalue.

    - -

    Second, writing the semantics in terms of code misleadingly -suggests that the effects *r++ should precisely replicate the behavior -of this code, including side effects. (Does this mean that *r++ -should invoke the copy constructor exactly as many times as the sample -code above would?) See issue 334 for a similar -problem.

    - - - -

    Proposed resolution:

    -

    In Table 72 in 24.1.1 [input.iterators], change the return type -for *r++ from T to "convertible to T".

    - - -

    Rationale:

    -

    This issue has two parts: the return type, and the number of times - the copy constructor is invoked.

    - -

    The LWG believes the the first part is a real issue. It's - inappropriate for the return type to be specified so much more - precisely for *r++ than it is for *r. In particular, if r is of - (say) type int*, then *r++ isn't int, - but int&.

    - -

    The LWG does not believe that the number of times the copy - constructor is invoked is a real issue. This can vary in any case, - because of language rules on copy constructor elision. That's too - much to read into these semantics clauses.

    - -

    Additionally, as Dave Abrahams pointed out (c++std-lib-13703): since - we're told (24.1/3) that forward iterators satisfy all the requirements - of input iterators, we can't impose any requirements in the Input - Iterator requirements table that forward iterators don't satisfy.

    - - - - - -
    -

    103. set::iterator is required to be modifiable, but this allows modification of keys

    -

    Section: 23.1.4 [associative.reqmts] Status: WP - Submitter: AFNOR Date: 1998-10-07

    -

    View all other issues in [associative.reqmts].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    Set::iterator is described as implementation-defined with a -reference to the container requirement; the container requirement says -that const_iterator is an iterator pointing to const T and iterator an -iterator pointing to T.

    - -

    23.1.2 paragraph 2 implies that the keys should not be modified to -break the ordering of elements. But that is not clearly -specified. Especially considering that the current standard requires -that iterator for associative containers be different from -const_iterator. Set, for example, has the following:

    - -

    typedef implementation defined iterator;
    -       // See _lib.container.requirements_

    - -

    23.1 [container.requirements] actually requires that iterator type pointing -to T (table 65). Disallowing user modification of keys by changing the -standard to require an iterator for associative container to be the -same as const_iterator would be overkill since that will unnecessarily -significantly restrict the usage of associative container. A class to -be used as elements of set, for example, can no longer be modified -easily without either redesigning the class (using mutable on fields -that have nothing to do with ordering), or using const_cast, which -defeats requiring iterator to be const_iterator. The proposed solution -goes in line with trusting user knows what he is doing.

    - -

    Other Options Evaluated:

    - -

    Option A.   In 23.1.4 [associative.reqmts], paragraph 2, after -first sentence, and before "In addition,...", add one line: -

    - -
    -

    Modification of keys shall not change their strict weak ordering.

    -
    - -

    Option B. Add three new sentences to 23.1.4 [associative.reqmts]:

    - -
    -

    At the end of paragraph 5: "Keys in an associative container - are immutable." At the end of paragraph 6: "For - associative containers where the value type is the same as the key - type, both iterator and const_iterator are - constant iterators. It is unspecified whether or not - iterator and const_iterator are the same - type."

    -
    - -

    Option C. To 23.1.4 [associative.reqmts], paragraph 3, which -currently reads:

    - -
    -

    The phrase ``equivalence of keys'' means the equivalence relation imposed by the - comparison and not the operator== on keys. That is, two keys k1 and k2 in the same - container are considered to be equivalent if for the comparison object comp, comp(k1, k2) - == false && comp(k2, k1) == false.

    -
    - -

      add the following:

    - -
    -

    For any two keys k1 and k2 in the same container, comp(k1, k2) shall return the same - value whenever it is evaluated. [Note: If k2 is removed from the container and later - reinserted, comp(k1, k2) must still return a consistent value but this value may be - different than it was the first time k1 and k2 were in the same container. This is - intended to allow usage like a string key that contains a filename, where comp compares - file contents; if k2 is removed, the file is changed, and the same k2 (filename) is - reinserted, comp(k1, k2) must again return a consistent value but this value may be - different than it was the previous time k2 was in the container.]

    -
    - - - -

    Proposed resolution:

    -

    Add the following to 23.1.4 [associative.reqmts] at -the indicated location:

    - -
    -

    At the end of paragraph 3: "For any two keys k1 and k2 in the same container, - calling comp(k1, k2) shall always return the same - value."

    -

    At the end of paragraph 5: "Keys in an associative container are immutable."

    -

    At the end of paragraph 6: "For associative containers where the value type is the - same as the key type, both iterator and const_iterator are constant - iterators. It is unspecified whether or not iterator and const_iterator - are the same type."

    -
    - - -

    Rationale:

    -

    Several arguments were advanced for and against allowing set elements to be -mutable as long as the ordering was not effected. The argument which swayed the -LWG was one of safety; if elements were mutable, there would be no compile-time -way to detect of a simple user oversight which caused ordering to be -modified. There was a report that this had actually happened in practice, -and had been painful to diagnose. If users need to modify elements, -it is possible to use mutable members or const_cast.

    - -

    Simply requiring that keys be immutable is not sufficient, because the comparison -object may indirectly (via pointers) operate on values outside of the keys.

    - -

    -The types iterator and const_iterator are permitted -to be different types to allow for potential future work in which some -member functions might be overloaded between the two types. No such -member functions exist now, and the LWG believes that user functionality -will not be impaired by permitting the two types to be the same. A -function that operates on both iterator types can be defined for -const_iterator alone, and can rely on the automatic -conversion from iterator to const_iterator. -

    - -

    [Tokyo: The LWG crafted the proposed resolution and rationale.]

    - - - - - - -
    -

    106. Numeric library private members are implementation defined

    -

    Section: 26.5.5 [template.slice.array] Status: TC - Submitter: AFNOR Date: 1998-10-07

    -

    View all other issues in [template.slice.array].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    This is the only place in the whole standard where the implementation has to document -something private.

    - - -

    Proposed resolution:

    -

    -Remove the comment which says "// remainder implementation defined" from: -

    - -
      -
    • 26.5.5 [template.slice.array]
      • -
    • 26.5.7 [template.gslice.array]
      • -
    • 26.5.8 [template.mask.array]
      • -
    • 26.5.9 [template.indirect.array]
      • -
    - - - - - -
    -

    108. Lifetime of exception::what() return unspecified

    -

    Section: 18.6.1 [type.info] Status: TC - Submitter: AFNOR Date: 1998-10-07

    -

    View all other issues in [type.info].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    In 18.6.1, paragraphs 8-9, the lifetime of the return value of -exception::what() is left unspecified. This issue has implications -with exception safety of exception handling: some exceptions should -not throw bad_alloc.

    - - -

    Proposed resolution:

    -

    Add to 18.6.1 [type.info] paragraph 9 (exception::what notes -clause) the sentence:

    - -
    -

    The return value remains valid until the exception object from which it is obtained is - destroyed or a non-const member function of the exception object is called.

    -
    - - -

    Rationale:

    -

    If an exception object has non-const members, they may be used -to set internal state that should affect the contents of the string -returned by what(). -

    - - - - - -
    -

    109. Missing binders for non-const sequence elements

    -

    Section: D.8 [depr.lib.binders] Status: WP - Submitter: Bjarne Stroustrup Date: 1998-10-07

    -

    View all other issues in [depr.lib.binders].

    -

    View all issues with WP status.

    -

    Discussion:

    - -

    There are no versions of binders that apply to non-const elements -of a sequence. This makes examples like for_each() using bind2nd() on -page 521 of "The C++ Programming Language (3rd)" -non-conforming. Suitable versions of the binders need to be added.

    - -

    Further discussion from Nico:

    - -

    What is probably meant here is shown in the following example:

    - -
    class Elem { 
-  public: 
-    void print (int i) const { } 
-    void modify (int i) { } 
-};
    -
    int main() 
-{ 
-    vector<Elem> coll(2); 
-    for_each (coll.begin(), coll.end(), bind2nd(mem_fun_ref(&Elem::print),42));    // OK 
-    for_each (coll.begin(), coll.end(), bind2nd(mem_fun_ref(&Elem::modify),42));   // ERROR 
-}
    - -

    The error results from the fact that bind2nd() passes its first -argument (the argument of the sequence) as constant reference. See the -following typical implementation:

    - -
    - 
    template <class Operation> 
-class binder2nd 
-  : public unary_function<typename Operation::first_argument_type, 
-                          typename Operation::result_type> { 
-protected: 
-  Operation op; 
-  typename Operation::second_argument_type value; 
-public: 
-  binder2nd(const Operation& o, 
-            const typename Operation::second_argument_type& v) 
-      : op(o), value(v) {}
    - 
     typename Operation::result_type 
-  operator()(const typename Operation::first_argument_type& x) const { 
-    return op(x, value); 
-  } 
-};
    -
    - -

    The solution is to overload operator () of bind2nd for non-constant arguments:

    - -
    - 
    template <class Operation> 
-class binder2nd 
-  : public unary_function<typename Operation::first_argument_type, 
-                          typename Operation::result_type> { 
-protected: 
-  Operation op; 
-  typename Operation::second_argument_type value; 
-public: 
-  binder2nd(const Operation& o, 
-            const typename Operation::second_argument_type& v) 
-      : op(o), value(v) {}
    - 
     typename Operation::result_type 
-  operator()(const typename Operation::first_argument_type& x) const { 
-    return op(x, value); 
-  } 
-  typename Operation::result_type 
-  operator()(typename Operation::first_argument_type& x) const { 
-    return op(x, value); 
-  } 
-};
    -
    - - -

    Proposed resolution:

    - -

    Howard believes there is a flaw in this resolution. -See c++std-lib-9127. We may need to reopen this issue.

    - -

    In D.8 [depr.lib.binders] in the declaration of binder1st after:

    -
    -

    typename Operation::result_type
    -  operator()(const typename Operation::second_argument_type& x) const;

    -
    -

    insert:

    -
    -

    typename Operation::result_type
    -  operator()(typename Operation::second_argument_type& x) const;

    -
    -

    In D.8 [depr.lib.binders] in the declaration of binder2nd after:

    -
    -

    typename Operation::result_type
    -  operator()(const typename Operation::first_argument_type& x) const;

    -
    -

    insert:

    -
    -

    typename Operation::result_type
    -  operator()(typename Operation::first_argument_type& x) const;

    -
    - -

    [Kona: The LWG discussed this at some length.It was agreed that -this is a mistake in the design, but there was no consensus on whether -it was a defect in the Standard. Straw vote: NAD - 5. Accept -proposed resolution - 3. Leave open - 6.]

    - - -

    [Copenhagen: It was generally agreed that this was a defect. -Strap poll: NAD - 0. Accept proposed resolution - 10. -Leave open - 1.]

    - - - - - - - -
    -

    110. istreambuf_iterator::equal not const

    -

    Section: 24.5.3 [istreambuf.iterator], 24.5.3.5 [istreambuf.iterator::equal] Status: TC - Submitter: Nathan Myers Date: 1998-10-15

    -

    View all other issues in [istreambuf.iterator].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    Member istreambuf_iterator<>::equal is not declared -"const", yet 24.5.3.6 [istreambuf.iterator::op==] says that operator==, -which is const, calls it. This is contradictory.

    - - -

    Proposed resolution:

    -

    In 24.5.3 [istreambuf.iterator] and also in 24.5.3.5 [istreambuf.iterator::equal], -replace:

    - -
    - 
    bool equal(istreambuf_iterator& b);
    -
    - -

    with:

    - -
    - 
    bool equal(const istreambuf_iterator& b) const;
    -
    - - - - - -
    -

    112. Minor typo in ostreambuf_iterator constructor

    -

    Section: 24.5.4.1 [ostreambuf.iter.cons] Status: TC - Submitter: Matt Austern Date: 1998-10-20

    -

    View all issues with TC status.

    -

    Discussion:

    -

    The requires clause for ostreambuf_iterator's -constructor from an ostream_type (24.5.4.1, paragraph 1) -reads "s is not null". However, s is a -reference, and references can't be null.

    - - -

    Proposed resolution:

    -

    In 24.5.4.1 [ostreambuf.iter.cons]:

    - -

    Move the current paragraph 1, which reads "Requires: s is not -null.", from the first constructor to the second constructor.

    - -

    Insert a new paragraph 1 Requires clause for the first constructor -reading:

    - -
    -

    Requires: s.rdbuf() is not null.

    -
    - - - - - -
    -

    114. Placement forms example in error twice

    -

    Section: 18.5.1.3 [new.delete.placement] Status: TC - Submitter: Steve Clamage Date: 1998-10-28

    -

    View all other issues in [new.delete.placement].

    -

    View all issues with TC status.

    -

    Duplicate of: 196

    -

    Discussion:

    -

    Section 18.5.1.3 contains the following example:

    - -
    [Example: This can be useful for constructing an object at a known address:
-        char place[sizeof(Something)];
-        Something* p = new (place) Something();
- -end example]
    - -

    First code line: "place" need not have any special alignment, and the -following constructor could fail due to misaligned data.

    - -

    Second code line: Aren't the parens on Something() incorrect?  [Dublin: the LWG -believes the () are correct.]

    - -

    Examples are not normative, but nevertheless should not show code that is invalid or -likely to fail.

    - - -

    Proposed resolution:

    -

    Replace the first line of code in the example in -18.5.1.3 [new.delete.placement] with: -

    - -
    - 
    void* place = operator new(sizeof(Something));
    -
    - - - - - -
    -

    115. Typo in strstream constructors

    -

    Section: D.7.4.1 [depr.strstream.cons] Status: TC - Submitter: Steve Clamage Date: 1998-11-02

    -

    View all issues with TC status.

    -

    Discussion:

    -

    D.7.4.1 strstream constructors paragraph 2 says:

    - -
    -

    Effects: Constructs an object of class strstream, initializing the base class with - iostream(& sb) and initializing sb with one of the two constructors:

    -

    - If mode&app==0, then s shall designate the first element of an array of n - elements. The constructor is strstreambuf(s, n, s).

    -

    - If mode&app==0, then s shall designate the first element of an array of n - elements that contains an NTBS whose first element is designated by s. The constructor is - strstreambuf(s, n, s+std::strlen(s)).

    -
    - -

    Notice the second condition is the same as the first. I think the second condition -should be "If mode&app==app", or "mode&app!=0", meaning that -the append bit is set.

    - - -

    Proposed resolution:

    -

    In D.7.3.1 [depr.ostrstream.cons] paragraph 2 and D.7.4.1 [depr.strstream.cons] -paragraph 2, change the first condition to (mode&app)==0 -and the second condition to (mode&app)!=0.

    - - - - - -
    -

    117. basic_ostream uses nonexistent num_put member functions

    -

    Section: 27.6.2.6.2 [ostream.inserters.arithmetic] Status: WP - Submitter: Matt Austern Date: 1998-11-20

    -

    View all other issues in [ostream.inserters.arithmetic].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    The effects clause for numeric inserters says that -insertion of a value x, whose type is either bool, -short, unsigned short, int, unsigned -int, long, unsigned long, float, -double, long double, or const void*, is -delegated to num_put, and that insertion is performed as if -through the following code fragment:

    - -
    bool failed = use_facet<
-   num_put<charT,ostreambuf_iterator<charT,traits> > 
-   >(getloc()).put(*this, *this, fill(), val). failed();
    - -

    This doesn't work, because num_put<>::put is only -overloaded for the types bool, long, unsigned -long, double, long double, and const -void*. That is, the code fragment in the standard is incorrect -(it is diagnosed as ambiguous at compile time) for the types -short, unsigned short, int, unsigned -int, and float.

    - -

    We must either add new member functions to num_put, or -else change the description in ostream so that it only calls -functions that are actually there. I prefer the latter.

    - - -

    Proposed resolution:

    -

    Replace 27.6.2.5.2, paragraph 1 with the following:

    - -
    -

    -The classes num_get<> and num_put<> handle locale-dependent numeric -formatting and parsing. These inserter functions use the imbued -locale value to perform numeric formatting. When val is of type bool, -long, unsigned long, double, long double, or const void*, the -formatting conversion occurs as if it performed the following code -fragment: -

    - -
    bool failed = use_facet<
-   num_put<charT,ostreambuf_iterator<charT,traits> >
-   >(getloc()).put(*this, *this, fill(), val). failed();
-
    - -

    -When val is of type short the formatting conversion occurs as if it -performed the following code fragment: -

    - -
    ios_base::fmtflags baseflags = ios_base::flags() & ios_base::basefield;
-bool failed = use_facet<
-   num_put<charT,ostreambuf_iterator<charT,traits> >
-   >(getloc()).put(*this, *this, fill(),
-      baseflags == ios_base::oct || baseflags == ios_base::hex
-         ? static_cast<long>(static_cast<unsigned short>(val))
-         : static_cast<long>(val)). failed();
-
    - -

    -When val is of type int the formatting conversion occurs as if it performed -the following code fragment: -

    - -
    ios_base::fmtflags baseflags = ios_base::flags() & ios_base::basefield;
-bool failed = use_facet<
-   num_put<charT,ostreambuf_iterator<charT,traits> >
-   >(getloc()).put(*this, *this, fill(),
-      baseflags == ios_base::oct || baseflags == ios_base::hex
-         ? static_cast<long>(static_cast<unsigned int>(val))
-         : static_cast<long>(val)). failed();
-
    - -

    -When val is of type unsigned short or unsigned int the formatting conversion -occurs as if it performed the following code fragment: -

    - -
    bool failed = use_facet<
-   num_put<charT,ostreambuf_iterator<charT,traits> >
-   >(getloc()).put(*this, *this, fill(), static_cast<unsigned long>(val)).
-failed();
-
    - -

    -When val is of type float the formatting conversion occurs as if it -performed the following code fragment: -

    - -
    bool failed = use_facet<
-   num_put<charT,ostreambuf_iterator<charT,traits> >
-   >(getloc()).put(*this, *this, fill(), static_cast<double>(val)).
-failed();
-
    - -
    - -

    [post-Toronto: This differs from the previous proposed -resolution; PJP provided the new wording. The differences are in -signed short and int output.]

    - - - -

    Rationale:

    -

    The original proposed resolution was to cast int and short to long, -unsigned int and unsigned short to unsigned long, and float to double, -thus ensuring that we don't try to use nonexistent num_put<> -member functions. The current proposed resolution is more -complicated, but gives more expected results for hex and octal output -of signed short and signed int. (On a system with 16-bit short, for -example, printing short(-1) in hex format should yield 0xffff.)

    - - - - - -
    -

    118. basic_istream uses nonexistent num_get member functions

    -

    Section: 27.6.1.2.2 [istream.formatted.arithmetic] Status: WP - Submitter: Matt Austern Date: 1998-11-20

    -

    View all other issues in [istream.formatted.arithmetic].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    Formatted input is defined for the types short, unsigned short, int, -unsigned int, long, unsigned long, float, double, -long double, bool, and void*. According to section 27.6.1.2.2, -formatted input of a value x is done as if by the following code fragment:

    - -
    typedef num_get< charT,istreambuf_iterator<charT,traits> > numget; 
-iostate err = 0; 
-use_facet< numget >(loc).get(*this, 0, *this, err, val); 
-setstate(err);
    - -

    According to section 22.2.2.1.1 [facet.num.get.members], however, -num_get<>::get() is only overloaded for the types -bool, long, unsigned short, unsigned -int, unsigned long, unsigned long, -float, double, long double, and -void*. Comparing the lists from the two sections, we find -that 27.6.1.2.2 is using a nonexistent function for types -short and int.

    - - -

    Proposed resolution:

    -

    In 27.6.1.2.2 [istream.formatted.arithmetic] Arithmetic Extractors, remove the -two lines (1st and 3rd) which read:

    -
    - 
    operator>>(short& val);
-...
-operator>>(int& val);
    -
    - -

    And add the following at the end of that section (27.6.1.2.2) :

    - -
    - 
    operator>>(short& val);
    -

    The conversion occurs as if performed by the following code fragment (using - the same notation as for the preceding code fragment):

    - 
      typedef num_get< charT,istreambuf_iterator<charT,traits> > numget;
-  iostate err = 0;
-  long lval;
-  use_facet< numget >(loc).get(*this, 0, *this, err, lval);
-        if (err == 0
-                && (lval < numeric_limits<short>::min() || numeric_limits<short>::max() < lval))
-                err = ios_base::failbit;
-  setstate(err);
    - 
    operator>>(int& val);
    -

    The conversion occurs as if performed by the following code fragment (using - the same notation as for the preceding code fragment):

    - 
      typedef num_get< charT,istreambuf_iterator<charT,traits> > numget;
-  iostate err = 0;
-  long lval;
-  use_facet< numget >(loc).get(*this, 0, *this, err, lval);
-        if (err == 0
-                && (lval < numeric_limits<int>::min() || numeric_limits<int>::max() < lval))
-                err = ios_base::failbit;
-  setstate(err);
    -
    - -

    [Post-Tokyo: PJP provided the above wording.]

    - - - - - - -
    -

    119. Should virtual functions be allowed to strengthen the exception specification?

    -

    Section: 17.4.4.9 [res.on.exception.handling] Status: TC - Submitter: Judy Ward Date: 1998-12-15

    -

    View all other issues in [res.on.exception.handling].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    Section 17.4.4.9 [res.on.exception.handling] states:

    - -

    "An implementation may strengthen the exception-specification -for a function by removing listed exceptions."

    - -

    The problem is that if an implementation is allowed to do this for -virtual functions, then a library user cannot write a class that -portably derives from that class.

    - -

    For example, this would not compile if ios_base::failure::~failure -had an empty exception specification:

    - -
    #include <ios>
-#include <string>
-
-class D : public std::ios_base::failure {
-public:
-        D(const std::string&);
-        ~D(); // error - exception specification must be compatible with 
-              // overridden virtual function ios_base::failure::~failure()
-};
    - - -

    Proposed resolution:

    -

    Change Section 17.4.4.9 [res.on.exception.handling] from:

    - -

         "may strengthen the -exception-specification for a function"

    - -

    to:

    - -

         "may strengthen the -exception-specification for a non-virtual function".

    - - - - - -
    -

    120. Can an implementor add specializations?

    -

    Section: 17.4.3.2 [reserved.names] Status: WP - Submitter: Judy Ward Date: 1998-12-15

    -

    View all other issues in [reserved.names].

    -

    View all issues with WP status.

    -

    Discussion:

    - -

    The original issue asked whether a library implementor could -specialize standard library templates for built-in types. (This was -an issue because users are permitted to explicitly instantiate -standard library templates.)

    - -

    Specializations are no longer a problem, because of the resolution -to core issue 259. Under the proposed resolution, it will be legal -for a translation unit to contain both a specialization and an -explicit instantiation of the same template, provided that the -specialization comes first. In such a case, the explicit -instantiation will be ignored. Further discussion of library issue -120 assumes that the core 259 resolution will be adopted.

    - -

    However, as noted in lib-7047, one piece of this issue still -remains: what happens if a standard library implementor explicitly -instantiates a standard library templates? It's illegal for a program -to contain two different explicit instantiations of the same template -for the same type in two different translation units (ODR violation), -and the core working group doesn't believe it is practical to relax -that restriction.

    - -

    The issue, then, is: are users allowed to explicitly instantiate -standard library templates for non-user defined types? The status quo -answer is 'yes'. Changing it to 'no' would give library implementors -more freedom.

    - -

    This is an issue because, for performance reasons, library -implementors often need to explicitly instantiate standard library -templates. (for example, std::basic_string<char>) Does giving -users freedom to explicitly instantiate standard library templates for -non-user defined types make it impossible or painfully difficult for -library implementors to do this?

    - -

    John Spicer suggests, in lib-8957, that library implementors have a -mechanism they can use for explicit instantiations that doesn't -prevent users from performing their own explicit instantiations: put -each explicit instantiation in its own object file. (Different -solutions might be necessary for Unix DSOs or MS-Windows DLLs.) On -some platforms, library implementors might not need to do anything -special: the "undefined behavior" that results from having two -different explicit instantiations might be harmless.

    - - - -

    Proposed resolution:

    -

    Append to 17.4.3.2 [reserved.names] paragraph 1:

    -

    - A program may explicitly instantiate any templates in the standard - library only if the declaration depends on the name of a user-defined - type of external linkage and the instantiation meets the standard library - requirements for the original template. -

    - -

    [Kona: changed the wording from "a user-defined name" to "the name of - a user-defined type"]

    - - - - -

    Rationale:

    -

    The LWG considered another possible resolution:

    -
    -

    In light of the resolution to core issue 259, no normative changes - in the library clauses are necessary. Add the following non-normative - note to the end of 17.4.3.2 [reserved.names] paragraph 1:

    -

    - [Note: A program may explicitly instantiate standard library - templates, even when an explicit instantiation does not depend on - a user-defined name. --end note] -

    -
    - -

    The LWG rejected this because it was believed that it would make - it unnecessarily difficult for library implementors to write - high-quality implementations. A program may not include an - explicit instantiation of the same template, for the same template - arguments, in two different translation units. If users are - allowed to provide explicit instantiations of Standard Library - templates for built-in types, then library implementors aren't, - at least not without nonportable tricks.

    - -

    The most serious problem is a class template that has writeable - static member variables. Unfortunately, such class templates are - important and, in existing Standard Library implementations, are - often explicitly specialized by library implementors: locale facets, - which have a writeable static member variable id. If a - user's explicit instantiation collided with the implementations - explicit instantiation, iostream initialization could cause locales - to be constructed in an inconsistent state.

    - -

    One proposed implementation technique was for Standard Library - implementors to provide explicit instantiations in separate object - files, so that they would not be picked up by the linker when the - user also provides an explicit instantiation. However, this - technique only applies for Standard Library implementations that - are packaged as static archives. Most Standard Library - implementations nowadays are packaged as dynamic libraries, so this - technique would not apply.

    - -

    The Committee is now considering standardization of dynamic - linking. If there are such changes in the future, it may be - appropriate to revisit this issue later.

    - - - - - -
    -

    122. streambuf/wstreambuf description should not say they are specializations

    -

    Section: 27.5.2 [streambuf] Status: TC - Submitter: Judy Ward Date: 1998-12-15

    -

    View all other issues in [streambuf].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    Section 27.5.2 describes the streambuf classes this way:

    - -
    - -

    The class streambuf is a specialization of the template class basic_streambuf -specialized for the type char.

    - -

    The class wstreambuf is a specialization of the template class basic_streambuf -specialized for the type wchar_t.

    - -
    - -

    This implies that these classes must be template specializations, not typedefs.

    - -

    It doesn't seem this was intended, since Section 27.5 has them declared as typedefs.

    - - -

    Proposed resolution:

    -

    Remove 27.5.2 [streambuf] paragraphs 2 and 3 (the above two -sentences).

    - - -

    Rationale:

    -

    The streambuf synopsis already has a declaration for the -typedefs and that is sufficient.

    - - - - - -
    -

    123. Should valarray helper arrays fill functions be const?

    -

    Section: 26.5.5.3 [slice.arr.fill], 26.5.7.3 [gslice.array.fill], 26.5.8.3 [mask.array.fill], 26.5.9.3 [indirect.array.fill] Status: WP - Submitter: Judy Ward Date: 1998-12-15

    -

    View all issues with WP status.

    -

    Discussion:

    -

    One of the operator= in the valarray helper arrays is const and one -is not. For example, look at slice_array. This operator= in Section -26.5.5.1 [slice.arr.assign] is const:

    - -

        void operator=(const valarray<T>&) const;

    - -

    but this one in Section 26.5.5.3 [slice.arr.fill] is not:

    - -

        void operator=(const T&);

    - -

    The description of the semantics for these two functions is similar.

    - - -

    Proposed resolution:

    - -

    26.5.5 [template.slice.array] Template class slice_array

    -
    - -

    In the class template definition for slice_array, replace the member - function declaration

    - 
          void operator=(const T&);
-
    -

    with

    - 
          void operator=(const T&) const;
-
    -
    - -

    26.5.5.3 [slice.arr.fill] slice_array fill function

    -
    - -

    Change the function declaration

    - 
          void operator=(const T&);
-
    -

    to

    - 
          void operator=(const T&) const;
-
    -
    - -

    26.5.7 [template.gslice.array] Template class gslice_array

    -
    - -

    In the class template definition for gslice_array, replace the member - function declaration

    - 
          void operator=(const T&);
-
    -

    with

    - 
          void operator=(const T&) const;
-
    -
    - -

    26.5.7.3 [gslice.array.fill] gslice_array fill function

    -
    - -

    Change the function declaration

    - 
          void operator=(const T&);
-
    -

    to

    - 
          void operator=(const T&) const;
-
    -
    - -

    26.5.8 [template.mask.array] Template class mask_array

    -
    - -

    In the class template definition for mask_array, replace the member - function declaration

    - 
          void operator=(const T&);
-
    -

    with

    - 
          void operator=(const T&) const;
-
    -
    - -

    26.5.8.3 [mask.array.fill] mask_array fill function

    -
    - -

    Change the function declaration

    - 
          void operator=(const T&);
-
    -

    to

    - 
          void operator=(const T&) const;
-
    -
    - -

    26.5.9 [template.indirect.array] Template class indirect_array

    -
    - -

    In the class template definition for indirect_array, replace the member - function declaration

    - 
          void operator=(const T&);
-
    -

    with

    - 
          void operator=(const T&) const;
-
    -
    - -

    26.5.9.3 [indirect.array.fill] indirect_array fill function

    -
    - -

    Change the function declaration

    - 
          void operator=(const T&);
-
    -

    to

    - 
          void operator=(const T&) const;
-
    -
    - - -

    [Redmond: Robert provided wording.]

    - - - - -

    Rationale:

    -

    There's no good reason for one version of operator= being const and -another one not. Because of issue 253, this now -matters: these functions are now callable in more circumstances. In -many existing implementations, both versions are already const.

    - - - - - -
    -

    124. ctype_byname<charT>::do_scan_is & do_scan_not return type should be const charT*

    -

    Section: 22.2.1.2 [locale.ctype.byname] Status: TC - Submitter: Judy Ward Date: 1998-12-15

    -

    View all other issues in [locale.ctype.byname].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    In Section 22.2.1.2 [locale.ctype.byname] -ctype_byname<charT>::do_scan_is() and do_scan_not() are declared -to return a const char* not a const charT*.

    - - -

    Proposed resolution:

    -

    Change Section 22.2.1.2 [locale.ctype.byname] do_scan_is() and -do_scan_not() to return a const -charT*.

    - - - - - -
    -

    125. valarray<T>::operator!() return type is inconsistent

    -

    Section: 26.5.2 [template.valarray] Status: TC - Submitter: Judy Ward Date: 1998-12-15

    -

    View all other issues in [template.valarray].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    In Section 26.5.2 [template.valarray] valarray<T>::operator!() -is -declared to return a valarray<T>, but in Section 26.5.2.5 -[valarray.unary] it is declared to return a valarray<bool>. The -latter appears to be correct.

    - - -

    Proposed resolution:

    -

    Change in Section 26.5.2 [template.valarray] the declaration of -operator!() so that the return type is -valarray<bool>.

    - - - - -
    -

    126. typos in Effects clause of ctype::do_narrow()

    -

    Section: 22.2.1.1.2 [locale.ctype.virtuals] Status: TC - Submitter: Judy Ward Date: 1998-12-15

    -

    View all other issues in [locale.ctype.virtuals].

    -

    View all issues with TC status.

    -

    Discussion:

    Typos in 22.2.1.1.2 need to be fixed.

    - -

    Proposed resolution:

    -

    In Section 22.2.1.1.2 [locale.ctype.virtuals] change:

    - -
       do_widen(do_narrow(c),0) == c
    - -

    to:

    - -
       do_widen(do_narrow(c,0)) == c
    - -

    and change:

    - -
       (is(M,c) || !ctc.is(M, do_narrow(c),dfault) )
    - -

    to:

    - -
       (is(M,c) || !ctc.is(M, do_narrow(c,dfault)) )
    - - - - - -
    -

    127. auto_ptr<> conversion issues

    -

    Section: D.9.1 [auto.ptr] Status: TC - Submitter: Greg Colvin Date: 1999-02-17

    -

    View all other issues in [auto.ptr].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    There are two problems with the current auto_ptr wording -in the standard:

    - -

    First, the auto_ptr_ref definition cannot be nested -because auto_ptr<Derived>::auto_ptr_ref is unrelated to -auto_ptr<Base>::auto_ptr_ref. Also submitted by -Nathan Myers, with the same proposed resolution.

    - -

    Second, there is no auto_ptr assignment operator taking an -auto_ptr_ref argument.

    - -

    I have discussed these problems with my proposal coauthor, Bill -Gibbons, and with some compiler and library implementors, and we -believe that these problems are not desired or desirable implications -of the standard.

    - -

    25 Aug 1999: The proposed resolution now reflects changes suggested -by Dave Abrahams, with Greg Colvin's concurrence; 1) changed -"assignment operator" to "public assignment -operator", 2) changed effects to specify use of release(), 3) -made the conversion to auto_ptr_ref const.

    - -

    2 Feb 2000: Lisa Lippincott comments: [The resolution of] this issue -states that the conversion from auto_ptr to auto_ptr_ref should -be const. This is not acceptable, because it would allow -initialization and assignment from _any_ const auto_ptr! It also -introduces an implementation difficulty in writing this conversion -function -- namely, somewhere along the line, a const_cast will be -necessary to remove that const so that release() may be called. This -may result in undefined behavior [7.1.5.1/4]. The conversion -operator does not have to be const, because a non-const implicit -object parameter may be bound to an rvalue [13.3.3.1.4/3] -[13.3.1/5].

    - -

    Tokyo: The LWG removed the following from the proposed resolution:

    - -

    In 20.5.4 [meta.unary], paragraph 2, and 20.5.4.3 [meta.unary.prop], - paragraph 2, make the conversion to auto_ptr_ref const:

    -
    - 
    template<class Y> operator auto_ptr_ref<Y>() const throw();
    -
    - - -

    Proposed resolution:

    -

    In 20.5.4 [meta.unary], paragraph 2, move -the auto_ptr_ref definition to namespace scope.

    - -

    In 20.5.4 [meta.unary], paragraph 2, add -a public assignment operator to the auto_ptr definition:

    - -
    - 
    auto_ptr& operator=(auto_ptr_ref<X> r) throw();
    -
    - -

    Also add the assignment operator to 20.5.4.3 [meta.unary.prop]:

    - -
    - 
    auto_ptr& operator=(auto_ptr_ref<X> r) throw()
    - -

    Effects: Calls reset(p.release()) for the auto_ptr - p that r holds a reference to.
    - Returns: *this.

    - -
    - - - - - -
    -

    129. Need error indication from seekp() and seekg()

    -

    Section: 27.6.1.3 [istream.unformatted], 27.6.2.5 [ostream.seeks] Status: TC - Submitter: Angelika Langer Date: 1999-02-22

    -

    View all other issues in [istream.unformatted].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    Currently, the standard does not specify how seekg() and seekp() -indicate failure. They are not required to set failbit, and they can't -return an error indication because they must return *this, i.e. the -stream. Hence, it is undefined what happens if they fail. And they -can fail, for instance, when a file stream is disconnected from the -underlying file (is_open()==false) or when a wide character file -stream must perform a state-dependent code conversion, etc.

    - -

    The stream functions seekg() and seekp() should set failbit in the -stream state in case of failure.

    - - -

    Proposed resolution:

    -

    Add to the Effects: clause of  seekg() in -27.6.1.3 [istream.unformatted] and to the Effects: clause of seekp() in -27.6.2.5 [ostream.seeks]:

    - -
    -

    In case of failure, the function calls setstate(failbit) (which may throw ios_base::failure). -

    -
    - - -

    Rationale:

    -

    Setting failbit is the usual error reporting mechanism for streams

    - - - - -
    -

    130. Return type of container::erase(iterator) differs for associative containers

    -

    Section: 23.1.4 [associative.reqmts], 23.1.3 [sequence.reqmts] Status: DR - Submitter: Andrew Koenig Date: 1999-03-02

    -

    View all other issues in [associative.reqmts].

    -

    View all issues with DR status.

    -

    Duplicate of: 451

    -

    Discussion:

    -

    Table 67 (23.1.1) says that container::erase(iterator) returns an -iterator. Table 69 (23.1.2) says that in addition to this requirement, -associative containers also say that container::erase(iterator) -returns void. That's not an addition; it's a change to the -requirements, which has the effect of making associative containers -fail to meet the requirements for containers.

    - - -

    Proposed resolution:

    - -

    -In 23.1.4 [associative.reqmts], in Table 69 Associative container -requirements, change the return type of a.erase(q) from -void to iterator. Change the -assertion/not/pre/post-condition from "erases the element pointed to -by q" to "erases the element pointed to by q. -Returns an iterator pointing to the element immediately following q -prior to the element being erased. If no such element exists, a.end() -is returned." -

    - -

    -In 23.1.4 [associative.reqmts], in Table 69 Associative container -requirements, change the return type of a.erase(q1, q2) -from void to iterator. Change the -assertion/not/pre/post-condition from "erases the elements in the -range [q1, q2)" to "erases the elements in the range [q1, -q2). Returns q2." -

    - -

    -In 23.3.1 [map], in the map class synopsis; and -in 23.3.2 [multimap], in the multimap class synopsis; and -in 23.3.3 [set], in the set class synopsis; and -in 23.3.4 [multiset], in the multiset class synopsis: -change the signature of the first erase overload to -

    -
       iterator erase(iterator position);
-
    -

    and change the signature of the third erase overload to

    -
      iterator erase(iterator first, iterator last); 
-
    - - -

    [Pre-Kona: reopened at the request of Howard Hinnant]

    - - -

    [Post-Kona: the LWG agrees the return type should be -iterator, not void. (Alex Stepanov agrees too.) -Matt provided wording.]

    - - -

    [ - Sydney: the proposed wording went in the right direction, but it - wasn't good enough. We want to return an iterator from the range form - of erase as well as the single-iterator form. Also, the wording is - slightly different from the wording we have for sequences; there's no - good reason for having a difference. Matt provided new wording, -(reflected above) which we will review at the next meeting. -]

    - - -

    [ -Redmond: formally voted into WP. -]

    - - - - - - - -
    -

    132. list::resize description uses random access iterators

    -

    Section: 23.2.4.2 [list.capacity] Status: TC - Submitter: Howard Hinnant Date: 1999-03-06

    -

    View all issues with TC status.

    -

    Discussion:

    -

    The description reads:

    - -

    -1- Effects:

    - -
             if (sz > size())
-           insert(end(), sz-size(), c);
-         else if (sz < size())
-           erase(begin()+sz, end());
-         else
-           ;                           //  do nothing
    - -

    Obviously list::resize should not be specified in terms of random access iterators.

    - - -

    Proposed resolution:

    -

    Change 23.2.4.2 [list.capacity] paragraph 1 to:

    - -

    Effects:

    - -
             if (sz > size())
-           insert(end(), sz-size(), c);
-         else if (sz < size())
-         {
-           iterator i = begin();
-           advance(i, sz);
-           erase(i, end());
-         }
    - -

    [Dublin: The LWG asked Howard to discuss exception safety offline -with David Abrahams. They had a discussion and believe there is -no issue of exception safety with the proposed resolution.]

    - - - - - - -
    -

    133. map missing get_allocator()

    -

    Section: 23.3.1 [map] Status: TC - Submitter: Howard Hinnant Date: 1999-03-06

    -

    View all other issues in [map].

    -

    View all issues with TC status.

    -

    Discussion:

    The title says it all.

    - -

    Proposed resolution:

    -

    Insert in 23.3.1 [map], paragraph 2, -after operator= in the map declaration:

    - -
        allocator_type get_allocator() const;
    - - - - -
    -

    134. vector constructors over specified

    -

    Section: 23.2.6.1 [vector.cons] Status: TC - Submitter: Howard Hinnant Date: 1999-03-06

    -

    View all issues with TC status.

    -

    Discussion:

    -

    The complexity description says: "It does at most 2N calls to the copy constructor -of T and logN reallocations if they are just input iterators ...".

    - -

    This appears to be overly restrictive, dictating the precise memory/performance -tradeoff for the implementor.

    - - -

    Proposed resolution:

    -

    Change 23.2.6.1 [vector.cons], paragraph 1 to:

    - -

    -1- Complexity: The constructor template <class -InputIterator> vector(InputIterator first, InputIterator last) -makes only N calls to the copy constructor of T (where N is the -distance between first and last) and no reallocations if iterators -first and last are of forward, bidirectional, or random access -categories. It makes order N calls to the copy constructor of T and -order logN reallocations if they are just input iterators. -

    - - -

    Rationale:

    -

    "at most 2N calls" is correct only if the growth factor -is greater than or equal to 2. -

    - - - - -
    -

    136. seekp, seekg setting wrong streams?

    -

    Section: 27.6.1.3 [istream.unformatted] Status: WP - Submitter: Howard Hinnant Date: 1999-03-06

    -

    View all other issues in [istream.unformatted].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    I may be misunderstanding the intent, but should not seekg set only -the input stream and seekp set only the output stream? The description -seems to say that each should set both input and output streams. If -that's really the intent, I withdraw this proposal.

    - - -

    Proposed resolution:

    -

    In section 27.6.1.3 change:

    - -
    basic_istream<charT,traits>& seekg(pos_type pos);
-Effects: If fail() != true, executes rdbuf()->pubseekpos(pos).
    - -

    To:

    - -
    basic_istream<charT,traits>& seekg(pos_type pos);
-Effects: If fail() != true, executes rdbuf()->pubseekpos(pos, ios_base::in).
    - -

    In section 27.6.1.3 change:

    - -
    basic_istream<charT,traits>& seekg(off_type& off, ios_base::seekdir dir);
-Effects: If fail() != true, executes rdbuf()->pubseekoff(off, dir).
    - -

    To:

    - -
    basic_istream<charT,traits>& seekg(off_type& off, ios_base::seekdir dir);
-Effects: If fail() != true, executes rdbuf()->pubseekoff(off, dir, ios_base::in).
    - -

    In section 27.6.2.4, paragraph 2 change:

    - -
    -2- Effects: If fail() != true, executes rdbuf()->pubseekpos(pos).
    - -

    To:

    - -
    -2- Effects: If fail() != true, executes rdbuf()->pubseekpos(pos, ios_base::out).
    - -

    In section 27.6.2.4, paragraph 4 change:

    - -
    -4- Effects: If fail() != true, executes rdbuf()->pubseekoff(off, dir).
    - -

    To:

    - -
    -4- Effects: If fail() != true, executes rdbuf()->pubseekoff(off, dir, ios_base::out).
    - -

    [Dublin: Dietmar Kühl thinks this is probably correct, but would -like the opinion of more iostream experts before taking action.]

    - - -

    [Tokyo: Reviewed by the LWG. PJP noted that although his docs are -incorrect, his implementation already implements the Proposed -Resolution.]

    - - -

    [Post-Tokyo: Matt Austern comments:
    -Is it a problem with basic_istream and basic_ostream, or is it a problem -with basic_stringbuf? -We could resolve the issue either by changing basic_istream and -basic_ostream, or by changing basic_stringbuf. I prefer the latter -change (or maybe both changes): I don't see any reason for the standard to -require that std::stringbuf s(std::string("foo"), std::ios_base::in); -s.pubseekoff(0, std::ios_base::beg); must fail.
    -This requirement is a bit weird. There's no similar requirement -for basic_streambuf<>::seekpos, or for basic_filebuf<>::seekoff or -basic_filebuf<>::seekpos.]

    - - - - - - -
    -

    137. Do use_facet and has_facet look in the global locale?

    -

    Section: 22.1.1 [locale] Status: TC - Submitter: Angelika Langer Date: 1999-03-17

    -

    View all other issues in [locale].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    Section 22.1.1 [locale] says:

    - -

    -4- In the call to use_facet<Facet>(loc), the type argument -chooses a facet, making available all members of the named type. If -Facet is not present in a locale (or, failing that, in the global -locale), it throws the standard exception bad_cast. A C++ program can -check if a locale implements a particular facet with the template -function has_facet<Facet>().

    - -

    This contradicts the specification given in section -22.1.2 [locale.global.templates]: -

    -template <class  Facet> const  Facet& use_facet(const -locale&  loc);
    -
    --1- Get a reference to a facet of a locale.
    --2- Returns: a reference to the corresponding facet of loc, if present.
    --3- Throws: bad_cast if has_facet<Facet>(loc) is false.
    --4- Notes: The reference returned remains valid at least as long as any copy of loc exists -

    - - -

    Proposed resolution:

    -

    Remove the phrase "(or, failing that, in the global locale)" -from section 22.1.1.

    - - -

    Rationale:

    -

    Needed for consistency with the way locales are handled elsewhere -in the standard.

    - - - - -
    -

    139. Optional sequence operation table description unclear

    -

    Section: 23.1.3 [sequence.reqmts] Status: TC - Submitter: Andrew Koenig Date: 1999-03-30

    -

    View all other issues in [sequence.reqmts].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    The sentence introducing the Optional sequence operation table -(23.1.1 paragraph 12) has two problems:

    - -

    A. It says ``The operations in table 68 are provided only for the containers for which -they take constant time.''
    -
    -That could be interpreted in two ways, one of them being ``Even though table 68 shows -particular operations as being provided, implementations are free to omit them if they -cannot implement them in constant time.''
    -
    -B. That paragraph says nothing about amortized constant time, and it should. 

    - - -

    Proposed resolution:

    -

    Replace the wording in 23.1.1 paragraph 12  which begins ``The operations in table 68 are provided only..." -with:

    - -
    -

    Table 68 lists sequence operations that are provided for some types of sequential - containers but not others. An implementation shall provide these operations for all - container types shown in the ``container'' column, and shall implement them so as to take - amortized constant time.

    -
    - - - - -
    -

    141. basic_string::find_last_of, find_last_not_of say pos instead of xpos

    -

    Section: 21.3.6.4 [string::insert], 21.3.6.6 [string::replace] Status: TC - Submitter: Arch Robison Date: 1999-04-28

    -

    View all other issues in [string::insert].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    Sections 21.3.6.4 paragraph 1 and 21.3.6.6 paragraph 1 surely have misprints where they -say:
    -
    -— xpos <= pos and pos < size();

    - -

    Surely the document meant to say ``xpos < size()'' in both places.

    - -

    [Judy Ward also sent in this issue for 21.3.6.4 with the same -proposed resolution.]

    - - - -

    Proposed resolution:

    -

    Change Sections 21.3.6.4 paragraph 1 and 21.3.6.6 paragraph 1, the line which says:
    -
    -— xpos <= pos and pos < size();
    -
    -    to:
    -
    -    — xpos <= pos and xpos < size();

    - - - - -
    -

    142. lexicographical_compare complexity wrong

    -

    Section: 25.3.8 [alg.lex.comparison] Status: TC - Submitter: Howard Hinnant Date: 1999-06-20

    -

    View all issues with TC status.

    -

    Discussion:

    -

    The lexicographical_compare complexity is specified as:
    -
    -     "At most min((last1 - first1), (last2 - first2)) -applications of the corresponding comparison."
    -
    -The best I can do is twice that expensive.

    - -

    Nicolai Josuttis comments in lib-6862: You mean, to check for -equality you have to check both < and >? Yes, IMO you are -right! (and Matt states this complexity in his book)

    - - - -

    Proposed resolution:

    -

    Change 25.3.8 [alg.lex.comparison] complexity to:

    -

    - At most 2*min((last1 - first1), (last2 - first2)) - applications of the corresponding comparison. -

    - -

    Change the example at the end of paragraph 3 to read:

    -

    - [Example:
    -
    -     for ( ; first1 != last1 && first2 != last2 ; - ++first1, ++first2) {
    -       if (*first1 < *first2) return true;
    -       if (*first2 < *first1) return false;
    -     }
    -     return first1 == last1 && first2 != last2;
    -    
    - --end example] -

    - - - - -
    -

    144. Deque constructor complexity wrong

    -

    Section: 23.2.2.1 [deque.cons] Status: TC - Submitter: Herb Sutter Date: 1999-05-09

    -

    View all other issues in [deque.cons].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    In 23.2.2.1 [deque.cons] paragraph 6, the deque ctor that takes an iterator range appears -to have complexity requirements which are incorrect, and which contradict the -complexity requirements for insert(). I suspect that the text in question, -below, was taken from vector:

    -
    -

    Complexity: If the iterators first and last are forward iterators, - bidirectional iterators, or random access iterators the constructor makes only - N calls to the copy constructor, and performs no reallocations, where N is - last - first.

    -
    -

    The word "reallocations" does not really apply to deque. Further, -all of the following appears to be spurious:

    -
    -

    It makes at most 2N calls to the copy constructor of T and log N - reallocations if they are input iterators.1)

    -

    1) The complexity is greater in the case of input iterators because each - element must be added individually: it is impossible to determine the distance - between first abd last before doing the copying.

    -
    -

    This makes perfect sense for vector, but not for deque. Why should deque gain -an efficiency advantage from knowing in advance the number of elements to -insert?

    - - -

    Proposed resolution:

    -

    In 23.2.2.1 [deque.cons] paragraph 6, replace the Complexity description, including the -footnote, with the following text (which also corrects the "abd" -typo):

    -
    -

    Complexity: Makes last - first calls to the copy constructor of T.

    -
    - - - - -
    -

    146. complex<T> Inserter and Extractor need sentries

    -

    Section: 26.3.6 [complex.ops] Status: TC - Submitter: Angelika Langer Date: 1999-05-12

    -

    View all other issues in [complex.ops].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    The extractor for complex numbers is specified as: 

    - -
    - -

    template<class T, class charT, class traits> 
    - basic_istream<charT, traits>& 
    - operator>>(basic_istream<charT, traits>& is, complex<T>& x);
    - 
    -Effects: Extracts a complex number x of the form: u, (u), or (u,v), -where u is the real part and v is the imaginary part -(lib.istream.formatted). 
    -Requires: The input values be convertible to T. If bad input is -encountered, calls is.setstate(ios::failbit) (which may throw -ios::failure (lib.iostate.flags). 
    -Returns: is .

    - -
    -

    Is it intended that the extractor for complex numbers does not skip -whitespace, unlike all other extractors in the standard library do? -Shouldn't a sentry be used? 
    -
    -The inserter for complex numbers is specified as:

    - -
    - -

    template<class T, class charT, class traits> 
    - basic_ostream<charT, traits>& 
    - operator<<(basic_ostream<charT, traits>& o, const complex<T>& x);
    -
    -Effects: inserts the complex number x onto the stream o as if it were implemented as follows:
    -
    - template<class T, class charT, class traits> 
    - basic_ostream<charT, traits>& 
    - operator<<(basic_ostream<charT, traits>& o, const complex<T>& x) 
    - { 
    - basic_ostringstream<charT, traits> s; 
    - s.flags(o.flags()); 
    - s.imbue(o.getloc()); 
    - s.precision(o.precision()); 
    - s << '(' << x.real() << "," << x.imag() << ')'; 
    - return o << s.str(); 
    - }

    - -
    - -

    Is it intended that the inserter for complex numbers ignores the -field width and does not do any padding? If, with the suggested -implementation above, the field width were set in the stream then the -opening parentheses would be adjusted, but the rest not, because the -field width is reset to zero after each insertion.

    - -

    I think that both operations should use sentries, for sake of -consistency with the other inserters and extractors in the -library. Regarding the issue of padding in the inserter, I don't know -what the intent was. 

    - - -

    Proposed resolution:

    -

    After 26.3.6 [complex.ops] paragraph 14 (operator>>), add a -Notes clause:

    - -
    - -

    Notes: This extraction is performed as a series of simpler -extractions. Therefore, the skipping of whitespace is specified to be the -same for each of the simpler extractions.

    - -
    - - -

    Rationale:

    -

    For extractors, the note is added to make it clear that skipping whitespace -follows an "all-or-none" rule.

    - -

    For inserters, the LWG believes there is no defect; the standard is correct -as written.

    - - - - -
    -

    147. Library Intro refers to global functions that aren't global

    -

    Section: 17.4.4.3 [global.functions] Status: TC - Submitter: Lois Goldthwaite Date: 1999-06-04

    -

    View all other issues in [global.functions].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    The library had many global functions until 17.4.1.1 [lib.contents] -paragraph 2 was added:

    - -
    - -

    All library entities except macros, operator new and operator -delete are defined within the namespace std or namespaces nested -within namespace std.

    - -
    - -

    It appears "global function" was never updated in the following:

    - -
    - -

    17.4.4.3 - Global functions [lib.global.functions]
    -
    --1- It is unspecified whether any global functions in the C++ Standard -Library are defined as inline (dcl.fct.spec).
    -
    --2- A call to a global function signature described in Clauses -lib.language.support through lib.input.output behaves the same as if -the implementation declares no additional global function -signatures.*
    -
    - [Footnote: A valid C++ program always calls the expected library - global function. An implementation may also define additional - global functions that would otherwise not be called by a valid C++ - program. --- end footnote]
    -
    --3- A global function cannot be declared by the implementation as -taking additional default arguments. 
    -
    -17.4.4.4 - Member functions [lib.member.functions]
    -
    --2- An implementation can declare additional non-virtual member -function signatures within a class:

    - -
    - -

    -- by adding arguments with default values to a member function -signature; The same latitude does not extend to the implementation of -virtual or global functions, however.

    - -
    -
    - - -

    Proposed resolution:

    -

    Change "global" to "global or non-member" in:

    -
    -

    17.4.4.3 [lib.global.functions] section title,
    - 17.4.4.3 [lib.global.functions] para 1,
    - 17.4.4.3 [lib.global.functions] para 2 in 2 places plus 2 - places in the footnote,
    - 17.4.4.3 [lib.global.functions] para 3,
    - 17.4.4.4 [lib.member.functions] para 2

    -
    - - -

    Rationale:

    -

    -Because operator new and delete are global, the proposed resolution -was changed from "non-member" to "global or non-member. -

    - - - - -
    -

    148. Functions in the example facet BoolNames should be const

    -

    Section: 22.2.8 [facets.examples] Status: TC - Submitter: Jeremy Siek Date: 1999-06-03

    -

    View all other issues in [facets.examples].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    In 22.2.8 [facets.examples] paragraph 13, the do_truename() and -do_falsename() functions in the example facet BoolNames should be -const. The functions they are overriding in -numpunct_byname<char> are const.

    - - -

    Proposed resolution:

    -

    In 22.2.8 [facets.examples] paragraph 13, insert "const" in -two places:

    -
    -

    string do_truename() const { return "Oui Oui!"; }
    - string do_falsename() const { return "Mais Non!"; }

    -
    - - - - -
    -

    150. Find_first_of says integer instead of iterator

    -

    Section: 25.1.7 [alg.find.first.of] Status: TC - Submitter: Matt McClure Date: 1999-06-30

    -

    View all other issues in [alg.find.first.of].

    -

    View all issues with TC status.

    -

    Discussion:

    - - -

    Proposed resolution:

    -

    Change 25.1.7 [alg.find.first.of] paragraph 2 from:

    - -
    -

    Returns: The first iterator i in the range [first1, last1) such -that for some integer j in the range [first2, last2) ...

    -
    - -

    to:

    - -
    -

    Returns: The first iterator i in the range [first1, last1) such -that for some iterator j in the range [first2, last2) ...

    -
    - - - - -
    -

    151. Can't currently clear() empty container

    -

    Section: 23.1.3 [sequence.reqmts] Status: TC - Submitter: Ed Brey Date: 1999-06-21

    -

    View all other issues in [sequence.reqmts].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    For both sequences and associative containers, a.clear() has the -semantics of erase(a.begin(),a.end()), which is undefined for an empty -container since erase(q1,q2) requires that q1 be dereferenceable -(23.1.1,3 and 23.1.2,7). When the container is empty, a.begin() is -not dereferenceable.
    -
    -The requirement that q1 be unconditionally dereferenceable causes many -operations to be intuitively undefined, of which clearing an empty -container is probably the most dire.
    -
    -Since q1 and q2 are only referenced in the range [q1, q2), and [q1, -q2) is required to be a valid range, stating that q1 and q2 must be -iterators or certain kinds of iterators is unnecessary. -

    - - -

    Proposed resolution:

    -

    In 23.1.1, paragraph 3, change:

    -
    -

    p and q2 denote valid iterators to a, q and q1 denote valid dereferenceable iterators to a, [q1, q2) denotes a valid range

    -
    -

    to:

    -
    -

    p denotes a valid iterator to a, q denotes a valid dereferenceable iterator to a, [q1, q2) denotes a valid range - in a

    -
    -

    In 23.1.2, paragraph 7, change:

    -
    -

    p and q2 are valid iterators to a, q and q1 are valid dereferenceable - iterators to a, [q1, q2) is a valid range

    -
    -

    to

    -
    -

    p is a valid iterator to a, q is a valid dereferenceable iterator to a, [q1, q2) is a valid range - into a

    -
    - - - - -
    -

    152. Typo in scan_is() semantics

    -

    Section: 22.2.1.1.2 [locale.ctype.virtuals] Status: TC - Submitter: Dietmar Kühl Date: 1999-07-20

    -

    View all other issues in [locale.ctype.virtuals].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    The semantics of scan_is() (paragraphs 4 and 6) is not exactly described -because there is no function is() which only takes a character as -argument. Also, in the effects clause (paragraph 3), the semantic is also kept -vague.

    - - -

    Proposed resolution:

    -

    In 22.2.1.1.2 [locale.ctype.virtuals] paragraphs 4 and 6, change the returns -clause from:

    -
    -

    "... such that is(*p) -would..."

    -
    -

    to:  "... such that is(m, *p) - would...."

    - - - - - -
    -

    153. Typo in narrow() semantics

    -

    Section: 22.2.1.3.2 [facet.ctype.char.members] Status: WP - Submitter: Dietmar Kühl Date: 1999-07-20

    -

    View all other issues in [facet.ctype.char.members].

    -

    View all issues with WP status.

    -

    Duplicate of: 207

    -

    Discussion:

    -

    The description of the array version of narrow() (in -paragraph 11) is flawed: There is no member do_narrow() which -takes only three arguments because in addition to the range a default -character is needed.

    - -

    Additionally, for both widen and narrow we have -two signatures followed by a Returns clause that only addresses -one of them.

    - - - -

    Proposed resolution:

    -

    Change the returns clause in 22.2.1.3.2 [facet.ctype.char.members] -paragraph 10 from:

    -

        Returns: do_widen(low, high, to).

    - -

    to:

    -

        Returns: do_widen(c) or do_widen(low, high, to), -respectively.

    - -

    Change 22.2.1.3.2 [facet.ctype.char.members] paragraph 10 and 11 from:

    -
            char        narrow(char c, char /*dfault*/) const;
-        const char* narrow(const char* low, const char* high,
-                           char /*dfault*/, char* to) const;
    -
            Returns: do_narrow(low, high, to).
    -

    to:

    -
            char        narrow(char c, char dfault) const;
-        const char* narrow(const char* low, const char* high,
-                           char dfault, char* to) const;
    -
            Returns: do_narrow(c, dfault) or
-                 do_narrow(low, high, dfault, to), respectively.
    - -

    [Kona: 1) the problem occurs in additional places, 2) a user -defined version could be different.]

    - - -

    [Post-Tokyo: Dietmar provided the above wording at the request of -the LWG. He could find no other places the problem occurred. He -asks for clarification of the Kona "a user defined -version..." comment above. Perhaps it was a circuitous way of -saying "dfault" needed to be uncommented?]

    - - -

    [Post-Toronto: the issues list maintainer has merged in the -proposed resolution from issue 207, which addresses the -same paragraphs.]

    - - - - - - -
    -

    154. Missing double specifier for do_get()

    -

    Section: 22.2.2.1.2 [facet.num.get.virtuals] Status: TC - Submitter: Dietmar Kühl Date: 1999-07-20

    -

    View other active issues in [facet.num.get.virtuals].

    -

    View all other issues in [facet.num.get.virtuals].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    The table in paragraph 7 for the length modifier does not list the length -modifier l to be applied if the type is double. Thus, the -standard asks the implementation to do undefined things when using scanf() -(the missing length modifier for scanf() when scanning doubles -is actually a problem I found quite often in production code, too).

    - - -

    Proposed resolution:

    -

    In 22.2.2.1.2 [facet.num.get.virtuals], paragraph 7, add a row in the Length -Modifier table to say that for double a length modifier -l is to be used.

    - - -

    Rationale:

    -

    The standard makes an embarrassing beginner's mistake.

    - - - - -
    -

    155. Typo in naming the class defining the class Init

    -

    Section: 27.3 [iostream.objects] Status: TC - Submitter: Dietmar Kühl Date: 1999-07-20

    -

    View all other issues in [iostream.objects].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    There are conflicting statements about where the class -Init is defined. According to 27.3 [iostream.objects] paragraph 2 -it is defined as basic_ios::Init, according to 27.4.2 [ios.base] it is defined as ios_base::Init.

    - - -

    Proposed resolution:

    -

    Change 27.3 [iostream.objects] paragraph 2 from -"basic_ios::Init" to -"ios_base::Init".

    - - -

    Rationale:

    -

    Although not strictly wrong, the standard was misleading enough to warrant -the change.

    - - - - -
    -

    156. Typo in imbue() description

    -

    Section: 27.4.2.3 [ios.base.locales] Status: TC - Submitter: Dietmar Kühl Date: 1999-07-20

    -

    View all other issues in [ios.base.locales].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    There is a small discrepancy between the declarations of -imbue(): in 27.4.2 [ios.base] the argument is passed as -locale const& (correct), in 27.4.2.3 [ios.base.locales] it -is passed as locale const (wrong).

    - - -

    Proposed resolution:

    -

    In 27.4.2.3 [ios.base.locales] change the imbue argument -from "locale const" to "locale -const&".

    - - - - -
    -

    158. Underspecified semantics for setbuf()

    -

    Section: 27.5.2.4.2 [streambuf.virt.buffer] Status: TC - Submitter: Dietmar Kühl Date: 1999-07-20

    -

    View all other issues in [streambuf.virt.buffer].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    The default behavior of setbuf() is described only for the -situation that gptr() != 0 && gptr() != egptr(): -namely to do nothing. What has to be done in other situations  -is not described although there is actually only one reasonable -approach, namely to do nothing, too.

    - -

    Since changing the buffer would almost certainly mess up most -buffer management of derived classes unless these classes do it -themselves, the default behavior of setbuf() should always be -to do nothing.

    - - -

    Proposed resolution:

    -

    Change 27.5.2.4.2 [streambuf.virt.buffer], paragraph 3, Default behavior, -to: "Default behavior: Does nothing. Returns this."

    - - - - -
    -

    159. Strange use of underflow()

    -

    Section: 27.5.2.4.3 [streambuf.virt.get] Status: TC - Submitter: Dietmar Kühl Date: 1999-07-20

    -

    View all issues with TC status.

    -

    Discussion:

    -

    The description of the meaning of the result of -showmanyc() seems to be rather strange: It uses calls to -underflow(). Using underflow() is strange because -this function only reads the current character but does not extract -it, uflow() would extract the current character. This should -be fixed to use sbumpc() instead.

    - - -

    Proposed resolution:

    -

    Change 27.5.2.4.3 [streambuf.virt.get] paragraph 1, -showmanyc()returns clause, by replacing the word -"supplied" with the words "extracted from the -stream".

    - - - - -
    -

    160. Typo: Use of non-existing function exception()

    -

    Section: 27.6.1.1 [istream] Status: TC - Submitter: Dietmar Kühl Date: 1999-07-20

    -

    View all other issues in [istream].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    The paragraph 4 refers to the function exception() which -is not defined. Probably, the referred function is -basic_ios<>::exceptions().

    - - -

    Proposed resolution:

    -

    In 27.6.1.1 [istream], 27.6.1.3 [istream.unformatted], paragraph 1, -27.6.2.1 [ostream], paragraph 3, and 27.6.2.6.1 [ostream.formatted.reqmts], -paragraph 1, change "exception()" to -"exceptions()".

    - -

    [Note to Editor: "exceptions" with an "s" -is the correct spelling.]

    - - - - - - -
    -

    161. Typo: istream_iterator vs. istreambuf_iterator

    -

    Section: 27.6.1.2.2 [istream.formatted.arithmetic] Status: TC - Submitter: Dietmar Kühl Date: 1999-07-20

    -

    View all other issues in [istream.formatted.arithmetic].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    The note in the second paragraph pretends that the first argument -is an object of type istream_iterator. This is wrong: It is -an object of type istreambuf_iterator.

    - - -

    Proposed resolution:

    -

    Change 27.6.1.2.2 [istream.formatted.arithmetic] from:

    -
    -

    The first argument provides an object of the istream_iterator class...

    -
    -

    to

    -
    -

    The first argument provides an object of the istreambuf_iterator class...

    -
    - - - - - -
    -

    164. do_put() has apparently unused fill argument

    -

    Section: 22.2.5.3.2 [locale.time.put.virtuals] Status: TC - Submitter: Angelika Langer Date: 1999-07-23

    -

    View all issues with TC status.

    -

    Discussion:

    -

    In 22.2.5.3.2 [locale.time.put.virtuals] the do_put() function is specified -as taking a fill character as an argument, but the description of the -function does not say whether the character is used at all and, if so, -in which way. The same holds for any format control parameters that -are accessible through the ios_base& argument, such as the -adjustment or the field width. Is strftime() supposed to use the fill -character in any way? In any case, the specification of -time_put.do_put() looks inconsistent to me.

    Is the -signature of do_put() wrong, or is the effects clause incomplete?

    - - -

    Proposed resolution:

    -

    Add the following note after 22.2.5.3.2 [locale.time.put.virtuals] -paragraph 2:

    -
    -

    [Note: the fill argument may be used in the implementation-defined formats, or by derivations. A space character is a reasonable default - for this argument. --end Note]

    -
    - - -

    Rationale:

    -

    The LWG felt that while the normative text was correct, -users need some guidance on what to pass for the fill -argument since the standard doesn't say how it's used.

    - - - - -
    -

    165. xsputn(), pubsync() never called by basic_ostream members?

    -

    Section: 27.6.2.1 [ostream] Status: WP - Submitter: Dietmar Kühl Date: 1999-07-20

    -

    View all other issues in [ostream].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    Paragraph 2 explicitly states that none of the basic_ostream -functions falling into one of the groups "formatted output functions" -and "unformatted output functions" calls any stream buffer function -which might call a virtual function other than overflow(). Basically -this is fine but this implies that sputn() (this function would call -the virtual function xsputn()) is never called by any of the standard -output functions. Is this really intended? At minimum it would be convenient to -call xsputn() for strings... Also, the statement that overflow() -is the only virtual member of basic_streambuf called is in conflict -with the definition of flush() which calls rdbuf()->pubsync() -and thereby the virtual function sync() (flush() is listed -under "unformatted output functions").

    -

    In addition, I guess that the sentence starting with "They may use other -public members of basic_ostream ..." probably was intended to -start with "They may use other public members of basic_streamuf..." -although the problem with the virtual members exists in both cases.

    -

    I see two obvious resolutions:

    -
      -
    1. state in a footnote that this means that xsputn() will never be - called by any ostream member and that this is intended.
      2. -
    2. relax the restriction and allow calling overflow() and xsputn(). - Of course, the problem with flush() has to be resolved in some way.
      3. -
    - - -

    Proposed resolution:

    -

    Change the last sentence of 27.6.2.1 (lib.ostream) paragraph 2 from:

    -
    -

    They may use other public members of basic_ostream except that they do not - invoke any virtual members of rdbuf() except overflow().

    -
    -

    to:

    -
    -

    They may use other public members of basic_ostream except that they shall - not invoke any virtual members of rdbuf() except overflow(), xsputn(), and - sync().

    -
    - -

    [Kona: the LWG believes this is a problem. Wish to ask Jerry or -PJP why the standard is written this way.]

    - - -

    [Post-Tokyo: Dietmar supplied wording at the request of the -LWG. He comments: The rules can be made a little bit more specific if -necessary be explicitly spelling out what virtuals are allowed to be -called from what functions and eg to state specifically that flush() -is allowed to call sync() while other functions are not.]

    - - - - - - -
    -

    167. Improper use of traits_type::length()

    -

    Section: 27.6.2.6.4 [ostream.inserters.character] Status: WP - Submitter: Dietmar Kühl Date: 1999-07-20

    -

    View all other issues in [ostream.inserters.character].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    Paragraph 4 states that the length is determined using -traits::length(s). Unfortunately, this function is not -defined for example if the character type is wchar_t and the -type of s is char const*. Similar problems exist if -the character type is char and the type of s is -either signed char const* or unsigned char -const*.

    - - -

    Proposed resolution:

    -

    Change 27.6.2.6.4 [ostream.inserters.character] paragraph 4 from:

    -
    -

    Effects: Behaves like an formatted inserter (as described in - lib.ostream.formatted.reqmts) of out. After a sentry object is - constructed it inserts characters. The number of characters starting - at s to be inserted is traits::length(s). Padding is determined as - described in lib.facet.num.put.virtuals. The traits::length(s) - characters starting at s are widened using out.widen - (lib.basic.ios.members). The widened characters and any required - padding are inserted into out. Calls width(0).

    -
    -

    to:

    -
    -

    Effects: Behaves like a formatted inserter (as described in - lib.ostream.formatted.reqmts) of out. After a sentry object is - constructed it inserts n characters starting at s, - where n is the number that would be computed as if by:

    -
      -
    • traits::length(s) for the overload where the first argument is of - type basic_ostream<charT, traits>& and the second is - of type const charT*, and also for the overload where the first - argument is of type basic_ostream<char, traits>& and - the second is of type const char*.
      • -
    • std::char_traits<char>::length(s) - for the overload where the first argument is of type - basic_ostream<charT, traits>& and the second is of type - const char*.
      • -
    • traits::length(reinterpret_cast<const char*>(s)) - for the other two overloads.
      • -
    -

    Padding is determined as described in - lib.facet.num.put.virtuals. The n characters starting at - s are widened using out.widen (lib.basic.ios.members). The - widened characters and any required padding are inserted into - out. Calls width(0).

    -
    - -

    [Santa Cruz: Matt supplied new wording]

    - - -

    [Kona: changed "where n is" to " where n is the - number that would be computed as if by"]

    - - - - -

    Rationale:

    -

    We have five separate cases. In two of them we can use the -user-supplied traits class without any fuss. In the other three we -try to use something as close to that user-supplied class as possible. -In two cases we've got a traits class that's appropriate for -char and what we've got is a const signed char* or a const -unsigned char*; that's close enough so we can just use a reinterpret -cast, and continue to use the user-supplied traits class. Finally, -there's one case where we just have to give up: where we've got a -traits class for some arbitrary charT type, and we somehow have to -deal with a const char*. There's nothing better to do but fall back -to char_traits<char>

    - - - - - -
    -

    168. Typo: formatted vs. unformatted

    -

    Section: 27.6.2.7 [ostream.unformatted] Status: TC - Submitter: Dietmar Kühl Date: 1999-07-20

    -

    View all other issues in [ostream.unformatted].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    The first paragraph begins with a descriptions what has to be done -in formatted output functions. Probably this is a typo and the -paragraph really want to describe unformatted output functions...

    - - -

    Proposed resolution:

    -

    In 27.6.2.7 [ostream.unformatted] paragraph 1, the first and last -sentences, change the word "formatted" to -"unformatted":

    -
    -

    "Each unformatted output function begins ..."
    - "... value specified for the unformatted output - function."

    -
    - - - - -
    -

    169. Bad efficiency of overflow() mandated

    -

    Section: 27.7.1.4 [stringbuf.virtuals] Status: TC - Submitter: Dietmar Kühl Date: 1999-07-20

    -

    View all other issues in [stringbuf.virtuals].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    Paragraph 8, Notes, of this section seems to mandate an extremely -inefficient way of buffer handling for basic_stringbuf, -especially in view of the restriction that basic_ostream -member functions are not allowed to use xsputn() (see 27.6.2.1 [ostream]): For each character to be inserted, a new buffer -is to be created.

    -

    Of course, the resolution below requires some handling of -simultaneous input and output since it is no longer possible to update -egptr() whenever epptr() is changed. A possible -solution is to handle this in underflow().

    - - -

    Proposed resolution:

    -

    In 27.7.1.4 [stringbuf.virtuals] paragraph 8, Notes, insert the words -"at least" as in the following:

    -
    -

    To make a write position available, the function reallocates (or initially - allocates) an array object with a sufficient number of elements to hold the - current array object (if any), plus at least one additional write - position.

    -
    - - - - -
    -

    170. Inconsistent definition of traits_type

    -

    Section: 27.7.4 [stringstream] Status: TC - Submitter: Dietmar Kühl Date: 1999-07-20

    -

    View all issues with TC status.

    -

    Discussion:

    -

    The classes basic_stringstream (27.7.4 [stringstream]), -basic_istringstream (27.7.2 [istringstream]), and -basic_ostringstream (27.7.3 [ostringstream]) are inconsistent -in their definition of the type traits_type: For -istringstream, this type is defined, for the other two it is -not. This should be consistent.

    - - -

    Proposed resolution:

    -

    Proposed resolution:

    To the declarations of -basic_ostringstream (27.7.3 [ostringstream]) and -basic_stringstream (27.7.4 [stringstream]) add:

    -
    -
    typedef traits traits_type;
    -
    - - - - -
    -

    171. Strange seekpos() semantics due to joint position

    -

    Section: 27.8.1.5 [filebuf.virtuals] Status: WP - Submitter: Dietmar Kühl Date: 1999-07-20

    -

    View all other issues in [filebuf.virtuals].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    Overridden virtual functions, seekpos()

    In 27.8.1.1 [filebuf] paragraph 3, it is stated that a joint input and -output position is maintained by basic_filebuf. Still, the -description of seekpos() seems to talk about different file -positions. In particular, it is unclear (at least to me) what is -supposed to happen to the output buffer (if there is one) if only the -input position is changed. The standard seems to mandate that the -output buffer is kept and processed as if there was no positioning of -the output position (by changing the input position). Of course, this -can be exactly what you want if the flag ios_base::ate is -set. However, I think, the standard should say something like -this:

    -
      -
    • If (which & mode) == 0 neither read nor write position is - changed and the call fails. Otherwise, the joint read and write position is - altered to correspond to sp.
      • -
    • If there is an output buffer, the output sequences is updated and any - unshift sequence is written before the position is altered.
      • -
    • If there is an input buffer, the input sequence is updated after the - position is altered.
      • -
    -

    Plus the appropriate error handling, that is...

    - - -

    Proposed resolution:

    -

    Change the unnumbered paragraph in 27.8.1.4 (lib.filebuf.virtuals) before -paragraph 14 from:

    -
    -

    pos_type seekpos(pos_type sp, ios_base::openmode = ios_base::in | - ios_base::out);

    -

    Alters the file position, if possible, to correspond to the position stored - in sp (as described below).

    -

    - if (which&ios_base::in)!=0, set the file position to sp, then update - the input sequence

    -

    - if (which&ios_base::out)!=0, then update the output sequence, write - any unshift sequence, and set the file position to sp.

    -
    -

    to:

    -
    -

    pos_type seekpos(pos_type sp, ios_base::openmode = ios_base::in | - ios_base::out);

    -

    Alters the file position, if possible, to correspond to the position stored - in sp (as described below). Altering the file position performs as follows:

    -

    1. if (om & ios_base::out)!=0, then update the output sequence and - write any unshift sequence;

    -

    2. set the file position to sp;

    -

    3. if (om & ios_base::in)!=0, then update the input sequence;

    -

    where om is the open mode passed to the last call to open(). The operation - fails if is_open() returns false.

    -
    - -

    [Kona: Dietmar is working on a proposed resolution.]

    - -

    [Post-Tokyo: Dietmar supplied the above wording.]

    - - - - - - -
    -

    172. Inconsistent types for basic_istream::ignore()

    -

    Section: 27.6.1.3 [istream.unformatted] Status: TC - Submitter: Greg Comeau, Dietmar Kühl Date: 1999-07-23

    -

    View all other issues in [istream.unformatted].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    In 27.6.1.1 [istream] the function -ignore() gets an object of type streamsize as first -argument. However, in 27.6.1.3 [istream.unformatted] -paragraph 23 the first argument is of type int.

    - -

    As far as I can see this is not really a contradiction because -everything is consistent if streamsize is typedef to be -int. However, this is almost certainly not what was -intended. The same thing happened to basic_filebuf::setbuf(), -as described in issue 173.

    - -

    Darin Adler also -submitted this issue, commenting: Either 27.6.1.1 should be modified -to show a first parameter of type int, or 27.6.1.3 should be modified -to show a first parameter of type streamsize and use -numeric_limits<streamsize>::max.

    - - -

    Proposed resolution:

    -

    In 27.6.1.3 [istream.unformatted] paragraph 23 and 24, change both uses -of int in the description of ignore() to -streamsize.

    - - - - -
    -

    173. Inconsistent types for basic_filebuf::setbuf()

    -

    Section: 27.8.1.5 [filebuf.virtuals] Status: TC - Submitter: Greg Comeau, Dietmar Kühl Date: 1999-07-23

    -

    View all other issues in [filebuf.virtuals].

    -

    View all issues with TC status.

    -

    Discussion:

    - -

    -In 27.8.1.1 [filebuf] the function setbuf() gets an -object of type streamsize as second argument. However, in -27.8.1.5 [filebuf.virtuals] paragraph 9 the second argument is of type -int. -

    - -

    -As far as I can see this is not really a contradiction because -everything is consistent if streamsize is typedef to be -int. However, this is almost certainly not what was -intended. The same thing happened to basic_istream::ignore(), -as described in issue 172. -

    - - - -

    Proposed resolution:

    -

    In 27.8.1.5 [filebuf.virtuals] paragraph 9, change all uses of -int in the description of setbuf() to -streamsize.

    - - - - -
    -

    174. Typo: OFF_T vs. POS_T

    -

    Section: D.6 [depr.ios.members] Status: TC - Submitter: Dietmar Kühl Date: 1999-07-23

    -

    View all other issues in [depr.ios.members].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    According to paragraph 1 of this section, streampos is the -type OFF_T, the same type as streamoff. However, in -paragraph 6 the streampos gets the type POS_T

    - - -

    Proposed resolution:

    -

    Change D.6 [depr.ios.members] paragraph 1 from "typedef -OFF_T streampos;" to "typedef POS_T -streampos;"

    - - - - -
    -

    175. Ambiguity for basic_streambuf::pubseekpos() and a few other functions.

    -

    Section: D.6 [depr.ios.members] Status: TC - Submitter: Dietmar Kühl Date: 1999-07-23

    -

    View all other issues in [depr.ios.members].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    According to paragraph 8 of this section, the methods -basic_streambuf::pubseekpos(), -basic_ifstream::open(), and basic_ofstream::open -"may" be overloaded by a version of this function taking the -type ios_base::open_mode as last argument argument instead of -ios_base::openmode (ios_base::open_mode is defined -in this section to be an alias for one of the integral types). The -clause specifies, that the last argument has a default argument in -three cases. However, this generates an ambiguity with the overloaded -version because now the arguments are absolutely identical if the last -argument is not specified.

    - - -

    Proposed resolution:

    -

    In D.6 [depr.ios.members] paragraph 8, remove the default arguments for -basic_streambuf::pubseekpos(), -basic_ifstream::open(), and -basic_ofstream::open().

    - - - - -
    -

    176. exceptions() in ios_base...?

    -

    Section: D.6 [depr.ios.members] Status: TC - Submitter: Dietmar Kühl Date: 1999-07-23

    -

    View all other issues in [depr.ios.members].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    The "overload" for the function exceptions() in -paragraph 8 gives the impression that there is another function of -this function defined in class ios_base. However, this is not -the case. Thus, it is hard to tell how the semantics (paragraph 9) can -be implemented: "Call the corresponding member function specified -in clause 27 [input.output]."

    - - -

    Proposed resolution:

    -

    In D.6 [depr.ios.members] paragraph 8, move the declaration of the -function exceptions()into class basic_ios.

    - - - - -
    -

    179. Comparison of const_iterators to iterators doesn't work

    -

    Section: 23.1 [container.requirements] Status: WP - Submitter: Judy Ward Date: 1998-07-02

    -

    View other active issues in [container.requirements].

    -

    View all other issues in [container.requirements].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    Currently the following will not compile on two well-known standard -library implementations:

    - -
    - 
    #include <set>
-using namespace std;
-
-void f(const set<int> &s)
-{
-  set<int>::iterator i;
-  if (i==s.end()); // s.end() returns a const_iterator
-}
    -
    - -

    -The reason this doesn't compile is because operator== was implemented -as a member function of the nested classes set:iterator and -set::const_iterator, and there is no conversion from const_iterator to -iterator. Surprisingly, (s.end() == i) does work, though, because of -the conversion from iterator to const_iterator. -

    - -

    -I don't see a requirement anywhere in the standard that this must -work. Should there be one? If so, I think the requirement would need -to be added to the tables in section 24.1.1. I'm not sure about the -wording. If this requirement existed in the standard, I would think -that implementors would have to make the comparison operators -non-member functions.

    - -

    This issues was also raised on comp.std.c++ by Darin -Adler.  The example given was:

    - -
    - 
    bool check_equal(std::deque<int>::iterator i,
-std::deque<int>::const_iterator ci)
-{
-return i == ci;
-}
    -
    - -

    Comment from John Potter:

    -
    -

    - In case nobody has noticed, accepting it will break reverse_iterator. -

    - -

    - The fix is to make the comparison operators templated on two types. -

    - - 
        template <class Iterator1, class Iterator2>
-    bool operator== (reverse_iterator<Iterator1> const& x,
-                     reverse_iterator<Iterator2> const& y);
-
    - -

    - Obviously: return x.base() == y.base(); -

    - -

    - Currently, no reverse_iterator to const_reverse_iterator compares are - valid. -

    - -

    - BTW, I think the issue is in support of bad code. Compares should be - between two iterators of the same type. All std::algorithms require - the begin and end iterators to be of the same type. -

    -
    - - -

    Proposed resolution:

    -

    Insert this paragraph after 23.1 [container.requirements] paragraph 7:

    -
    -

    In the expressions

    - 
        i == j
-    i != j
-    i < j
-    i <= j
-    i >= j
-    i > j
-    i - j
-
    -

    Where i and j denote objects of a container's iterator type, - either or both may be replaced by an object of the container's - const_iterator type referring to the same element with no - change in semantics.

    -
    - -

    [post-Toronto: Judy supplied a proposed resolution saying that -iterator and const_iterator could be freely mixed in -iterator comparison and difference operations.]

    - - -

    [Redmond: Dave and Howard supplied a new proposed resolution which -explicitly listed expressions; there was concern that the previous -proposed resolution was too informal.]

    - - - -

    Rationale:

    -

    -The LWG believes it is clear that the above wording applies only to -the nested types X::iterator and X::const_iterator, -where X is a container. There is no requirement that -X::reverse_iterator and X::const_reverse_iterator -can be mixed. If mixing them is considered important, that's a -separate issue. (Issue 280.) -

    - - - - -
    -

    181. make_pair() unintended behavior

    -

    Section: 20.2.3 [pairs] Status: TC - Submitter: Andrew Koenig Date: 1999-08-03

    -

    View all other issues in [pairs].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    The claim has surfaced in Usenet that expressions such as
    -
    -       make_pair("abc", 3)
    -
    -are illegal, notwithstanding their use in examples, because template instantiation tries to bind the first template -parameter to const char (&)[4], which type is uncopyable.
    -
    -I doubt anyone intended that behavior... -

    - - -

    Proposed resolution:

    -

    In 20.2 [utility], paragraph 1 change the following -declaration of make_pair():

    -
    - 
    template <class T1, class T2> pair<T1,T2> make_pair(const T1&, const T2&);
    -
    -

    to:

    -
    - 
    template <class T1, class T2> pair<T1,T2> make_pair(T1, T2);
    -
    -

    In 20.2.3 [pairs] paragraph 7 and the line before, change:

    -
    -
    template <class T1, class T2>
-pair<T1, T2> make_pair(const T1& x, const T2& y);
    -
    -

    to:

    -
    -
    template <class T1, class T2>
-pair<T1, T2> make_pair(T1 x, T2 y);
    -
    -

    and add the following footnote to the effects clause:

    -
    -

    According to 12.8 [class.copy], an implementation is permitted - to not perform a copy of an argument, thus avoiding unnecessary - copies.

    -
    - - -

    Rationale:

    -

    Two potential fixes were suggested by Matt Austern and Dietmar -Kühl, respectively, 1) overloading with array arguments, and 2) use of -a reference_traits class with a specialization for arrays. Andy -Koenig suggested changing to pass by value. In discussion, it appeared -that this was a much smaller change to the standard that the other two -suggestions, and any efficiency concerns were more than offset by the -advantages of the solution. Two implementors reported that the -proposed resolution passed their test suites.

    - - - - -
    -

    182. Ambiguous references to size_t

    -

    Section: 17 [library] Status: WP - Submitter: Al Stevens Date: 1999-08-15

    -

    View all other issues in [library].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    Many references to size_t throughout the document -omit the std:: namespace qualification.

    For -example, 17.4.3.5 [replacement.functions] paragraph 2:

    -
    -
     operator new(size_t)
- operator new(size_t, const std::nothrow_t&)
- operator new[](size_t)
- operator new[](size_t, const std::nothrow_t&)
    -
    - - -

    Proposed resolution:

    -

    In 17.4.3.5 [replacement.functions] paragraph 2: replace:

    -
    -

    - operator new(size_t)
    - - operator new(size_t, const std::nothrow_t&)
    - - operator new[](size_t)
    - - operator new[](size_t, const std::nothrow_t&)

    -
    -

    by:

    -
    -
    - operator new(std::size_t)
-- operator new(std::size_t, const std::nothrow_t&)
-- operator new[](std::size_t)
-- operator new[](std::size_t, const std::nothrow_t&)
    -
    -

    In [lib.allocator.requirements] 20.1.5, paragraph 4: replace:

    -
    -

    The typedef members pointer, const_pointer, size_type, and difference_type - are required to be T*, T const*, size_t, and ptrdiff_t, respectively.

    -
    -

     by:

    -
    -

    The typedef members pointer, const_pointer, size_type, and difference_type - are required to be T*, T const*, std::size_t, and std::ptrdiff_t, - respectively.

    -
    -

    In [lib.allocator.members] 20.4.1.1, paragraphs 3 and 6: replace:

    -
    -

    3 Notes: Uses ::operator new(size_t) (18.4.1).

    -

    6 Note: the storage is obtained by calling ::operator new(size_t), but it - is unspecified when or how often this function is called. The use of hint is - unspecified, but intended as an aid to locality if an implementation so - desires.

    -
    -

    by:

    -
    -

    3 Notes: Uses ::operator new(std::size_t) (18.4.1).

    -

    6 Note: the storage is obtained by calling ::operator new(std::size_t), but - it is unspecified when or how often this function is called. The use of hint - is unspecified, but intended as an aid to locality if an implementation so - desires.

    -
    -

    In [lib.char.traits.require] 21.1.1, paragraph 1: replace:

    -
    -

    In Table 37, X denotes a Traits class defining types and functions for the - character container type CharT; c and d denote values of type CharT; p and q - denote values of type const CharT*; s denotes a value of type CharT*; n, i and - j denote values of type size_t; e and f denote values of type X::int_type; pos - denotes a value of type X::pos_type; and state denotes a value of type X::state_type.

    -
    -

    by:

    -
    -

    In Table 37, X denotes a Traits class defining types and functions for the - character container type CharT; c and d denote values of type CharT; p and q - denote values of type const CharT*; s denotes a value of type CharT*; n, i and - j denote values of type std::size_t; e and f denote values of type X::int_type; - pos denotes a value of type X::pos_type; and state denotes a value of type X::state_type.

    -
    -

    In [lib.char.traits.require] 21.1.1, table 37: replace the return type of -X::length(p): "size_t" by "std::size_t".

    -

    In [lib.std.iterator.tags] 24.3.3, paragraph 2: replace:
    -    typedef ptrdiff_t difference_type;
    - by:
    -    typedef std::ptrdiff_t difference_type;

    -

    In [lib.locale.ctype] 22.2.1.1 put namespace std { ...} around the -declaration of template <class charT> class ctype.
    -
    - In [lib.iterator.traits] 24.3.1, paragraph 2 put namespace std { ...} around the declaration of:
    -
    -    template<class Iterator> struct iterator_traits
    -    template<class T> struct iterator_traits<T*>
    -    template<class T> struct iterator_traits<const T*>

    - - -

    Rationale:

    -

    The LWG believes correcting names like size_t and -ptrdiff_t to std::size_t and std::ptrdiff_t -to be essentially editorial. There there can't be another size_t or -ptrdiff_t meant anyway because, according to 17.4.3.2.4 [extern.types],

    - -

    -For each type T from the Standard C library, the types ::T and std::T -are reserved to the implementation and, when defined, ::T shall be -identical to std::T. -

    - -

    The issue is treated as a Defect Report to make explicit the Project -Editor's authority to make this change.

    - -

    [Post-Tokyo: Nico Josuttis provided the above wording at the -request of the LWG.]

    - - -

    [Toronto: This is tangentially related to issue 229, but only tangentially: the intent of this issue is to -address use of the name size_t in contexts outside of -namespace std, such as in the description of ::operator new. -The proposed changes should be reviewed to make sure they are -correct.]

    - - -

    [pre-Copenhagen: Nico has reviewed the changes and believes -them to be correct.]

    - - - - - - - -
    -

    183. I/O stream manipulators don't work for wide character streams

    -

    Section: 27.6.3 [std.manip] Status: WP - Submitter: Andy Sawyer Date: 1999-07-07

    -

    View all other issues in [std.manip].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    27.6.3 [std.manip] paragraph 3 says (clause numbering added for -exposition):

    -
    -

    Returns: An object s of unspecified type such that if [1] out is an (instance -of) basic_ostream then the expression out<<s behaves as if f(s) were -called, and if [2] in is an (instance of) basic_istream then the expression -in>>s behaves as if f(s) were called. Where f can be defined as: ios_base& -f(ios_base& str, ios_base::fmtflags mask) { // reset specified flags -str.setf(ios_base::fmtflags(0), mask); return str; } [3] The expression -out<<s has type ostream& and value out. [4] The expression in>>s -has type istream& and value in.

    -
    -

    Given the definitions [1] and [2] for out and in, surely [3] should read: -"The expression out << s has type basic_ostream& ..." and -[4] should read: "The expression in >> s has type basic_istream& -..."

    -

    If the wording in the standard is correct, I can see no way of implementing -any of the manipulators so that they will work with wide character streams.

    -

    e.g. wcout << setbase( 16 );

    -

    Must have value 'wcout' (which makes sense) and type 'ostream&' (which -doesn't).

    -

    The same "cut'n'paste" type also seems to occur in Paras 4,5,7 and -8. In addition, Para 6 [setfill] has a similar error, but relates only to -ostreams.

    -

    I'd be happier if there was a better way of saying this, to make it clear -that the value of the expression is "the same specialization of -basic_ostream as out"&

    - - -

    Proposed resolution:

    -

    Replace section 27.6.3 [std.manip] except paragraph 1 with the -following:

    -
    -

    2- The type designated smanip in each of the following function -descriptions is implementation-specified and may be different for each -function.
    -
    -smanip resetiosflags(ios_base::fmtflags mask);
    -
    --3- Returns: An object s of unspecified type such that if out is an -instance of basic_ostream<charT,traits> then the expression -out<<s behaves -as if f(s, mask) were called, or if in is an instance of -basic_istream<charT,traits> then the expression in>>s -behaves as if -f(s, mask) were called. The function f can be defined as:*
    -
    -[Footnote: The expression cin >> resetiosflags(ios_base::skipws) -clears ios_base::skipws in the format flags stored in the -basic_istream<charT,traits> object cin (the same as cin >> -noskipws), and the expression cout << -resetiosflags(ios_base::showbase) clears -ios_base::showbase in the format flags stored in the -basic_ostream<charT,traits> object cout (the same as cout -<< -noshowbase). --- end footnote]
    -
    -     ios_base& f(ios_base& str, ios_base::fmtflags mask)
    -   {
    -   // reset specified flags
    -   str.setf(ios_base::fmtflags(0), mask);
    -   return str;
    -   }
    -
    -The expression out<<s has type basic_ostream<charT,traits>& and value out. -The expression in>>s has type basic_istream<charT,traits>& and value in.
    -
    - smanip setiosflags(ios_base::fmtflags mask);
    -
    --4- Returns: An object s of unspecified type such that if out is an -instance of basic_ostream<charT,traits> then the expression -out<<s behaves -as if f(s, mask) were called, or if in is an instance of -basic_istream<charT,traits> then the expression in>>s -behaves as if f(s, -mask) were called. The function f can be defined as:
    -
    -     ios_base& f(ios_base& str, ios_base::fmtflags mask)
    -   {
    -   // set specified flags
    -   str.setf(mask);
    -   return str;
    -   }
    -
    -The expression out<<s has type basic_ostream<charT,traits>& and value out. -The expression in>>s has type basic_istream<charT,traits>& and value in.
    -
    -smanip setbase(int base);
    -
    --5- Returns: An object s of unspecified type such that if out is an -instance of basic_ostream<charT,traits> then the expression -out<<s behaves -as if f(s, base) were called, or if in is an instance of -basic_istream<charT,traits> then the expression in>>s -behaves as if f(s, -base) were called. The function f can be defined as:
    -
    -     ios_base& f(ios_base& str, int base)
    -   {
    -   // set basefield
    -   str.setf(base == 8 ? ios_base::oct :
    -   base == 10 ? ios_base::dec :
    -   base == 16 ? ios_base::hex :
    -   ios_base::fmtflags(0), ios_base::basefield);
    -   return str;
    -   }
    -
    -The expression out<<s has type basic_ostream<charT,traits>& and value out. -The expression in>>s has type basic_istream<charT,traits>& and value in.
    -
    -smanip setfill(char_type c);
    -
    --6- Returns: An object s of unspecified type such that if out is (or is -derived from) basic_ostream<charT,traits> and c has type charT -then the -expression out<<s behaves as if f(s, c) were called. The function -f can be -defined as:
    -
    -      template<class charT, class traits>
    -   basic_ios<charT,traits>& f(basic_ios<charT,traits>& str, charT c)
    -   {
    -   // set fill character
    -   str.fill(c);
    -   return str;
    -   }
    -
    -The expression out<<s has type basic_ostream<charT,traits>& and value out.
    -
    -smanip setprecision(int n);
    -
    --7- Returns: An object s of unspecified type such that if out is an -instance of basic_ostream<charT,traits> then the expression -out<<s behaves -as if f(s, n) were called, or if in is an instance of -basic_istream<charT,traits> then the expression in>>s -behaves as if f(s, n) -were called. The function f can be defined as:
    -
    -      ios_base& f(ios_base& str, int n)
    -   {
    -   // set precision
    -   str.precision(n);
    -   return str;
    -   }
    -
    -The expression out<<s has type basic_ostream<charT,traits>& and value out. -The expression in>>s has type basic_istream<charT,traits>& and value in
    -.
    -smanip setw(int n);
    -
    --8- Returns: An object s of unspecified type such that if out is an -instance of basic_ostream<charT,traits> then the expression -out<<s behaves -as if f(s, n) were called, or if in is an instance of -basic_istream<charT,traits> then the expression in>>s -behaves as if f(s, n) -were called. The function f can be defined as:
    -
    -      ios_base& f(ios_base& str, int n)
    -   {
    -   // set width
    -   str.width(n);
    -   return str;
    -   }
    -
    -The expression out<<s has type -basic_ostream<charT,traits>& and value out. The expression -in>>s has type basic_istream<charT,traits>& and value -in. -

    -
    - -

    [Kona: Andy Sawyer and Beman Dawes will work to improve the wording of -the proposed resolution.]

    - - -

    [Tokyo - The LWG noted that issue 216 involves -the same paragraphs.]

    - - -

    [Post-Tokyo: The issues list maintainer combined the proposed -resolution of this issue with the proposed resolution for issue 216 as they both involved the same paragraphs, and were so -intertwined that dealing with them separately appear fraught with -error. The full text was supplied by Bill Plauger; it was cross -checked against changes supplied by Andy Sawyer. It should be further -checked by the LWG.]

    - - - - - - -
    -

    184. numeric_limits<bool> wording problems

    -

    Section: 18.2.1.5 [numeric.special] Status: WP - Submitter: Gabriel Dos Reis Date: 1999-07-21

    -

    View all other issues in [numeric.special].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    bools are defined by the standard to be of integer types, as per -3.9.1 [basic.fundamental] paragraph 7. However "integer types" -seems to have a special meaning for the author of 18.2. The net effect -is an unclear and confusing specification for -numeric_limits<bool> as evidenced below.

    - -

    18.2.1.2/7 says numeric_limits<>::digits is, for built-in integer -types, the number of non-sign bits in the representation.

    - -

    4.5/4 states that a bool promotes to int ; whereas 4.12/1 says any non zero -arithmetical value converts to true.

    - -

    I don't think it makes sense at all to require -numeric_limits<bool>::digits and numeric_limits<bool>::digits10 to -be meaningful.

    - -

    The standard defines what constitutes a signed (resp. unsigned) integer -types. It doesn't categorize bool as being signed or unsigned. And the set of -values of bool type has only two elements.

    - -

    I don't think it makes sense to require numeric_limits<bool>::is_signed -to be meaningful.

    - -

    18.2.1.2/18 for numeric_limits<integer_type>::radix  says:

    -
    -

    For integer types, specifies the base of the representation.186)

    -
    - -

    This disposition is at best misleading and confusing for the standard -requires a "pure binary numeration system" for integer types as per -3.9.1/7

    - -

    The footnote 186) says: "Distinguishes types with base other than 2 (e.g -BCD)."  This also erroneous as the standard never defines any integer -types with base representation other than 2.

    - -

    Furthermore, numeric_limits<bool>::is_modulo and -numeric_limits<bool>::is_signed have similar problems.

    - - -

    Proposed resolution:

    -

    Append to the end of 18.2.1.5 [numeric.special]:

    -
    -

    The specialization for bool shall be provided as follows:

    - 
        namespace std {
-       template<> class numeric_limits<bool> {
-       public:
-         static const bool is_specialized = true;
-         static bool min() throw() { return false; }
-         static bool max() throw() { return true; }
-
-         static const int  digits = 1;
-         static const int  digits10 = 0;
-         static const bool is_signed = false;
-         static const bool is_integer = true;
-         static const bool is_exact = true;
-         static const int  radix = 2;
-         static bool epsilon() throw() { return 0; }
-         static bool round_error() throw() { return 0; }
-
-         static const int  min_exponent = 0;
-         static const int  min_exponent10 = 0;
-         static const int  max_exponent = 0;
-         static const int  max_exponent10 = 0;
-
-         static const bool has_infinity = false;
-         static const bool has_quiet_NaN = false;
-         static const bool has_signaling_NaN = false;
-         static const float_denorm_style has_denorm = denorm_absent;
-         static const bool has_denorm_loss = false;
-         static bool infinity() throw() { return 0; }
-         static bool quiet_NaN() throw() { return 0; }
-         static bool signaling_NaN() throw() { return 0; }
-         static bool denorm_min() throw() { return 0; }
-
-         static const bool is_iec559 = false;
-         static const bool is_bounded = true;
-         static const bool is_modulo = false;
-
-         static const bool traps = false;
-         static const bool tinyness_before = false;
-         static const float_round_style round_style = round_toward_zero;
-       };
-     }
    -
    - -

    [Tokyo:  The LWG desires wording that specifies exact values -rather than more general wording in the original proposed -resolution.]

    - - -

    [Post-Tokyo:  At the request of the LWG in Tokyo, Nico -Josuttis provided the above wording.]

    - - - - - - -
    -

    185. Questionable use of term "inline"

    -

    Section: 20.6 [function.objects] Status: WP - Submitter: UK Panel Date: 1999-07-26

    -

    View all other issues in [function.objects].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    Paragraph 4 of 20.6 [function.objects] says:

    -
    -

     [Example: To negate every element of a: transform(a.begin(), a.end(), - a.begin(), negate<double>()); The corresponding functions will inline - the addition and the negation. end example]

    -
    -

    (Note: The "addition" referred to in the above is in para 3) we can -find no other wording, except this (non-normative) example which suggests that -any "inlining" will take place in this case.

    -

    Indeed both:

    -
    -

    17.4.4.3 Global Functions [lib.global.functions] 1 It is - unspecified whether any global functions in the C++ Standard Library - are defined as inline (7.1.2).

    -
    -

    and

    -
    -

    17.4.4.4 Member Functions [lib.member.functions] 1 It is - unspecified whether any member functions in the C++ Standard Library - are defined as inline (7.1.2).

    -
    -

    take care to state that this may indeed NOT be the case.

    -

    Thus the example "mandates" behavior that is explicitly -not required elsewhere.

    - - -

    Proposed resolution:

    -

    In 20.6 [function.objects] paragraph 1, remove the sentence:

    -
    -

    They are important for the effective use of the library.

    -
    -

    Remove 20.6 [function.objects] paragraph 2, which reads:

    -
    -

    Using function objects together with function templates - increases the expressive power of the library as well as making the - resulting code much more efficient.

    -
    -

    In 20.6 [function.objects] paragraph 4, remove the sentence:

    -
    -

    The corresponding functions will inline the addition and the - negation.

    -
    - -

    [Kona: The LWG agreed there was a defect.]

    - -

    [Tokyo: The LWG crafted the proposed resolution.]

    - - - - - - -
    -

    186. bitset::set() second parameter should be bool

    -

    Section: 23.3.5.2 [bitset.members] Status: WP - Submitter: Darin Adler Date: 1999-08-13

    -

    View all other issues in [bitset.members].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    In section 23.3.5.2 [bitset.members], paragraph 13 defines the -bitset::set operation to take a second parameter of type int. The -function tests whether this value is non-zero to determine whether to -set the bit to true or false. The type of this second parameter should -be bool. For one thing, the intent is to specify a Boolean value. For -another, the result type from test() is bool. In addition, it's -possible to slice an integer that's larger than an int. This can't -happen with bool, since conversion to bool has the semantic of -translating 0 to false and any non-zero value to true.

    - - -

    Proposed resolution:

    -

    In 23.3.5 [template.bitset] Para 1 Replace:

    -
    -
    bitset<N>& set(size_t pos, int val = true );
    -
    -

    With:

    -
    - 
    bitset<N>& set(size_t pos, bool val = true );
    -
    -

    In 23.3.5.2 [bitset.members] Para 12(.5) Replace:

    -
    - 
    bitset<N>& set(size_t pos, int val = 1 );
    -
    -

    With:

    -
    - 
    bitset<N>& set(size_t pos, bool val = true );
    -
    - -

    [Kona: The LWG agrees with the description.  Andy Sawyer will work -on better P/R wording.]

    - -

    [Post-Tokyo: Andy provided the above wording.]

    - - - -

    Rationale:

    -

    bool is a better choice. It is believed that binary -compatibility is not an issue, because this member function is -usually implemented as inline, and because it is already -the case that users cannot rely on the type of a pointer to a -nonvirtual member of a standard library class.

    - - - - - -
    -

    187. iter_swap underspecified

    -

    Section: 25.2.3 [alg.swap] Status: WP - Submitter: Andrew Koenig Date: 1999-08-14

    -

    View all other issues in [alg.swap].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    The description of iter_swap in 25.2.2 paragraph 7,says that it -``exchanges the values'' of the objects to which two iterators -refer.

    What it doesn't say is whether it does so using swap -or using the assignment operator and copy constructor.

    This -question is an important one to answer, because swap is specialized to -work efficiently for standard containers.
    For example:

    -
    -
    vector<int> v1, v2;
-iter_swap(&v1, &v2);
    -
    -

    Is this call to iter_swap equivalent to calling swap(v1, v2)?  -Or is it equivalent to

    -
    -
    {
-vector<int> temp = v1;
-v1 = v2;
-v2 = temp;
-}
    -
    -

    The first alternative is O(1); the second is O(n).

    -

    A LWG member, Dave Abrahams, comments:

    -
    -

    Not an objection necessarily, but I want to point out the cost of -that requirement:

    -
    -

    iter_swap(list<T>::iterator, list<T>::iterator)

    -
    -

    can currently be specialized to be more efficient than -iter_swap(T*,T*) for many T (by using splicing). Your proposal would -make that optimization illegal. 

    -
    - -

    [Kona: The LWG notes the original need for iter_swap was proxy iterators -which are no longer permitted.]

    - - - -

    Proposed resolution:

    -

    Change the effect clause of iter_swap in 25.2.2 paragraph 7 from:

    -
    -

    Exchanges the values pointed to by the two iterators a and b.

    -
    -

    to

    -
    -

    swap(*a, *b).

    -
    - - - -

    Rationale:

    -

    It's useful to say just what iter_swap does. There may be - some iterators for which we want to specialize iter_swap, - but the fully general version should have a general specification.

    - -

    Note that in the specific case of list<T>::iterator, -iter_swap should not be specialized as suggested above. That would do -much more than exchanging the two iterators' values: it would change -predecessor/successor relationships, possibly moving the iterator from -one list to another. That would surely be inappropriate.

    - - - - - -
    -

    189. setprecision() not specified correctly

    -

    Section: 27.4.2.2 [fmtflags.state] Status: TC - Submitter: Andrew Koenig Date: 1999-08-25

    -

    View all other issues in [fmtflags.state].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    27.4.2.2 paragraph 9 claims that setprecision() sets the precision, -and includes a parenthetical note saying that it is the number of -digits after the decimal point.
    -
    -This claim is not strictly correct. For example, in the default -floating-point output format, setprecision sets the number of -significant digits printed, not the number of digits after the decimal -point.
    -
    -I would like the committee to look at the definition carefully and -correct the statement in 27.4.2.2

    - - -

    Proposed resolution:

    -

    Remove from 27.4.2.2 [fmtflags.state], paragraph 9, the text -"(number of digits after the decimal point)".

    - - - - -
    -

    193. Heap operations description incorrect

    -

    Section: 25.3.6 [alg.heap.operations] Status: TC - Submitter: Markus Mauhart Date: 1999-09-24

    -

    View all issues with TC status.

    -

    Duplicate of: 216

    -

    Discussion:

    -

    25.3.6 [lib.alg.heap.operations] states two key properties of a heap [a,b), the first of them -is
    -
    -    `"(1) *a is the largest element"
    -
    -I think this is incorrect and should be changed to the wording in the proposed -resolution.

    -

    Actually there are two independent changes:

    -
    -

    A-"part of largest equivalence class" instead of "largest", cause 25.3 - [lib.alg.sorting] asserts "strict weak ordering" for all its sub clauses.

    -

    B-Take -'an oldest' from that equivalence class, otherwise the heap functions -could not be used for a priority queue as explained in 23.2.3.2.2 -[lib.priqueue.members] (where I assume that a "priority queue" respects -priority AND time).

    -
    - - -

    Proposed resolution:

    -

    Change 25.3.6 [alg.heap.operations] property (1) from:

    -
    -

    (1) *a is the largest element

    -
    -

    to:

    -
    -

    (1) There is no element greater than *a

    -
    - - - - - -
    -

    195. Should basic_istream::sentry's constructor ever set eofbit?

    -

    Section: 27.6.1.1.3 [istream::sentry] Status: TC - Submitter: Matt Austern Date: 1999-10-13

    -

    View all other issues in [istream::sentry].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    Suppose that is.flags() & ios_base::skipws is nonzero. -What should basic_istream<>::sentry's constructor do if it -reaches eof while skipping whitespace? 27.6.1.1.2/5 suggests it -should set failbit. Should it set eofbit as well? The standard -doesn't seem to answer that question.

    - -

    On the one hand, nothing in 27.6.1.1.3 [istream::sentry] says that -basic_istream<>::sentry should ever set eofbit. On the -other hand, 27.6.1.1 [istream] paragraph 4 says that if -extraction from a streambuf "returns -traits::eof(), then the input function, except as explicitly -noted otherwise, completes its actions and does -setstate(eofbit)". So the question comes down to -whether basic_istream<>::sentry's constructor is an -input function.

    - -

    Comments from Jerry Schwarz:

    -
    -

    It was always my intention that eofbit should be set any time that a -virtual returned something to indicate eof, no matter what reason -iostream code had for calling the virtual.

    -

    -The motivation for this is that I did not want to require streambufs -to behave consistently if their virtuals are called after they have -signaled eof.

    -

    -The classic case is a streambuf reading from a UNIX file. EOF isn't -really a state for UNIX file descriptors. The convention is that a -read on UNIX returns 0 bytes to indicate "EOF", but the file -descriptor isn't shut down in any way and future reads do not -necessarily also return 0 bytes. In particular, you can read from -tty's on UNIX even after they have signaled "EOF". (It -isn't always understood that a ^D on UNIX is not an EOF indicator, but -an EOL indicator. By typing a "line" consisting solely of -^D you cause a read to return 0 bytes, and by convention this is -interpreted as end of file.)

    -
    - - -

    Proposed resolution:

    -

    Add a sentence to the end of 27.6.1.1.2 paragraph 2:

    -
    -

    If is.rdbuf()->sbumpc() or is.rdbuf()->sgetc() -returns traits::eof(), the function calls -setstate(failbit | eofbit) (which may throw -ios_base::failure). -

    -
    - - - - -
    -

    198. Validity of pointers and references unspecified after iterator destruction

    -

    Section: 24.1 [iterator.requirements] Status: WP - Submitter: Beman Dawes Date: 1999-11-03

    -

    View other active issues in [iterator.requirements].

    -

    View all other issues in [iterator.requirements].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -Is a pointer or reference obtained from an iterator still valid after -destruction of the iterator? -

    -

    -Is a pointer or reference obtained from an iterator still valid after the value -of the iterator changes? -

    -
    -
    #include <iostream>
-#include <vector>
-#include <iterator>
-
-int main()
-{
-    typedef std::vector<int> vec_t;
-    vec_t v;
-    v.push_back( 1 );
-
-    // Is a pointer or reference obtained from an iterator still
-    // valid after destruction of the iterator?
-    int * p = &*v.begin();
-    std::cout << *p << '\n';  // OK?
-
-    // Is a pointer or reference obtained from an iterator still
-    // valid after the value of the iterator changes?
-    vec_t::iterator iter( v.begin() );
-    p = &*iter++;
-    std::cout << *p << '\n';  // OK?
-
-    return 0;
-}
-
    -
    - -

    The standard doesn't appear to directly address these -questions. The standard needs to be clarified. At least two real-world -cases have been reported where library implementors wasted -considerable effort because of the lack of clarity in the -standard. The question is important because requiring pointers and -references to remain valid has the effect for practical purposes of -prohibiting iterators from pointing to cached rather than actual -elements of containers.

    - -

    The standard itself assumes that pointers and references obtained -from an iterator are still valid after iterator destruction or -change. The definition of reverse_iterator::operator*(), 24.4.1.3.3 [reverse.iter.conv], which returns a reference, defines -effects:

    - -
    - 
    Iterator tmp = current;
-return *--tmp;
    -
    -

    The definition of reverse_iterator::operator->(), 24.4.1.3.4 -[reverse.iter.op.star], which returns a pointer, defines effects:

    -
    - 
    return &(operator*());
    -
    - -

    Because the standard itself assumes pointers and references remain -valid after iterator destruction or change, the standard should say so -explicitly. This will also reduce the chance of user code breaking -unexpectedly when porting to a different standard library -implementation.

    - - -

    Proposed resolution:

    -

    Add a new paragraph to 24.1 [iterator.requirements]:

    -

    -Destruction of an iterator may invalidate pointers and references -previously obtained from that iterator. -

    - -

    Replace paragraph 1 of 24.4.1.3.3 [reverse.iter.conv] with:

    - -
    -

    Effects:

    -
      this->tmp = current;
-  --this->tmp;
-  return *this->tmp;
-
    - -

    -[Note: This operation must use an auxiliary member variable, -rather than a temporary variable, to avoid returning a reference that -persists beyond the lifetime of its associated iterator. (See -24.1 [iterator.requirements].) The name of this member variable is shown for -exposition only. --end note] -

    -
    - -

    [Post-Tokyo: The issue has been reformulated purely -in terms of iterators.]

    - - -

    [Pre-Toronto: Steve Cleary pointed out the no-invalidation -assumption by reverse_iterator. The issue and proposed resolution was -reformulated yet again to reflect this reality.]

    - - -

    [Copenhagen: Steve Cleary pointed out that reverse_iterator -assumes its underlying iterator has persistent pointers and -references. Andy Koenig pointed out that it is possible to rewrite -reverse_iterator so that it no longer makes such an assupmption. -However, this issue is related to issue 299. If we -decide it is intentional that p[n] may return by value -instead of reference when p is a Random Access Iterator, -other changes in reverse_iterator will be necessary.]

    - - - -

    Rationale:

    -

    This issue has been discussed extensively. Note that it is -not an issue about the behavior of predefined iterators. It is -asking whether or not user-defined iterators are permitted to have -transient pointers and references. Several people presented examples -of useful user-defined iterators that have such a property; examples -include a B-tree iterator, and an "iota iterator" that doesn't point -to memory. Library implementors already seem to be able to cope with -such iterators: they take pains to avoid forming references to memory -that gets iterated past. The only place where this is a problem is -reverse_iterator, so this issue changes -reverse_iterator to make it work.

    - -

    This resolution does not weaken any guarantees provided by -predefined iterators like list<int>::iterator. -Clause 23 should be reviewed to make sure that guarantees for -predefined iterators are as strong as users expect.

    - - - - - - -
    -

    199. What does allocate(0) return?

    -

    Section: 20.1.2 [allocator.requirements] Status: TC - Submitter: Matt Austern Date: 1999-11-19

    -

    View other active issues in [allocator.requirements].

    -

    View all other issues in [allocator.requirements].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    -Suppose that A is a class that conforms to the -Allocator requirements of Table 32, and a is an -object of class A What should be the return -value of a.allocate(0)? Three reasonable -possibilities: forbid the argument 0, return -a null pointer, or require that the return value be a -unique non-null pointer. -

    - - -

    Proposed resolution:

    -

    -Add a note to the allocate row of Table 32: -"[Note: If n == 0, the return value is unspecified. --end note]"

    - - -

    Rationale:

    -

    A key to understanding this issue is that the ultimate use of -allocate() is to construct an iterator, and that iterator for zero -length sequences must be the container's past-the-end -representation. Since this already implies special case code, it -would be over-specification to mandate the return value. -

    - - - - -
    -

    200. Forward iterator requirements don't allow constant iterators

    -

    Section: 24.1.3 [forward.iterators] Status: WP - Submitter: Matt Austern Date: 1999-11-19

    -

    View all other issues in [forward.iterators].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -In table 74, the return type of the expression *a is given -as T&, where T is the iterator's value type. -For constant iterators, however, this is wrong. ("Value type" -is never defined very precisely, but it is clear that the value type -of, say, std::list<int>::const_iterator is supposed to be -int, not const int.) -

    - - -

    Proposed resolution:

    -

    -In table 74, in the *a and *r++ rows, change the -return type from "T&" to "T& -if X is mutable, otherwise const T&". -In the a->m row, change the return type from -"U&" to "U& if X is mutable, -otherwise const U&". -

    - -

    [Tokyo: The LWG believes this is the tip of a larger iceberg; -there are multiple const problems with the STL portion of the library -and that these should be addressed as a single package.  Note -that issue 180 has already been declared NAD Future for -that very reason.]

    - - -

    [Redmond: the LWG thinks this is separable from other constness -issues. This issue is just cleanup; it clarifies language that was -written before we had iterator_traits. Proposed resolution was -modified: the original version only discussed *a. It was pointed out -that we also need to worry about *r++ and a->m.]

    - - - - - - - -
    -

    201. Numeric limits terminology wrong

    -

    Section: 18.2.1 [limits] Status: WP - Submitter: Stephen Cleary Date: 1999-12-21

    -

    View all other issues in [limits].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -In some places in this section, the terms "fundamental types" and -"scalar types" are used when the term "arithmetic types" is intended. -The current usage is incorrect because void is a fundamental type and -pointers are scalar types, neither of which should have -specializations of numeric_limits. -

    -

    [Lillehammer: it remains true that numeric_limits is using - imprecise language. However, none of the proposals for changed - wording are clearer. A redesign of numeric_limits is needed, but this - is more a task than an open issue.]

    - - - -

    Proposed resolution:

    - -

    -Change 18.2 [support.limits] to: -

    - -
    -

    --1- The headers <limits>, <climits>, -<cfloat>, and <cinttypes> supply -characteristics of implementation-dependent fundamental -arithmetic types (3.9.1). -

    -
    - -

    -Change 18.2.1 [limits] to: -

    - -
    -

    --1- The numeric_limits component provides a C++ program with -information about various properties of the implementation's -representation of the fundamental arithmetic -types. -

    -

    --2- Specializations shall be provided for each fundamental -arithmetic type, both floating point and integer, including -bool. The member is_specialized shall be true -for all such specializations of numeric_limits. -

    -

    --4- Non-fundamentalarithmetic standard types, such -as complex<T> (26.3.2), shall not have specializations. -

    -
    - -

    -Change 18.2.1.1 [numeric.limits] to: -

    - -
    -

    --1- The member is_specialized makes it possible to distinguish -between fundamental types, which have specializations, and non-scalar types, -which do not. -

    -
    - - - - - - -
    -

    202. unique() effects unclear when predicate not an equivalence relation

    -

    Section: 25.2.9 [alg.unique] Status: WP - Submitter: Andrew Koenig Date: 2000-01-13

    -

    View all other issues in [alg.unique].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -What should unique() do if you give it a predicate that is not an -equivalence relation? There are at least two plausible answers: -

    - -
    - -

    - 1. You can't, because 25.2.8 says that it it "eliminates all but - the first element from every consecutive group of equal - elements..." and it wouldn't make sense to interpret "equal" as - meaning anything but an equivalence relation. [It also doesn't - make sense to interpret "equal" as meaning ==, because then there - would never be any sense in giving a predicate as an argument at - all.] -

    - -

    - 2. The word "equal" should be interpreted to mean whatever the - predicate says, even if it is not an equivalence relation - (and in particular, even if it is not transitive). -

    - -
    - -

    -The example that raised this question is from Usenet: -

    - -
    - -
    int f[] = { 1, 3, 7, 1, 2 };
-int* z = unique(f, f+5, greater<int>());
    - -
    - -

    -If one blindly applies the definition using the predicate -greater<int>, and ignore the word "equal", you get: -

    - -
    - -

    - Eliminates all but the first element from every consecutive group - of elements referred to by the iterator i in the range [first, last) - for which *i > *(i - 1). -

    - -
    - -

    -The first surprise is the order of the comparison. If we wanted to -allow for the predicate not being an equivalence relation, then we -should surely compare elements the other way: pred(*(i - 1), *i). If -we do that, then the description would seem to say: "Break the -sequence into subsequences whose elements are in strictly increasing -order, and keep only the first element of each subsequence". So the -result would be 1, 1, 2. If we take the description at its word, it -would seem to call for strictly DEcreasing order, in which case the -result should be 1, 3, 7, 2.
    -
    -In fact, the SGI implementation of unique() does neither: It yields 1, -3, 7. -

    - - -

    Proposed resolution:

    -

    Change 25.2.9 [alg.unique] paragraph 1 to:

    -

    -For a nonempty range, eliminates all but the first element from every -consecutive group of equivalent elements referred to by the iterator -i in the range [first+1, last) for which the following -conditions hold: *(i-1) == *i or pred(*(i-1), *i) != -false. -

    - -

    -Also insert a new paragraph, paragraph 2a, that reads: "Requires: The -comparison function must be an equivalence relation." -

    - -

    [Redmond: discussed arguments for and against requiring the -comparison function to be an equivalence relation. Straw poll: -14-2-5. First number is to require that it be an equivalence -relation, second number is to explicitly not require that it be an -equivalence relation, third number is people who believe they need -more time to consider the issue. A separate issue: Andy Sawyer -pointed out that "i-1" is incorrect, since "i" can refer to the first -iterator in the range. Matt provided wording to address this -problem.]

    - - -

    [Curaçao: The LWG changed "... the range (first, -last)..." to "... the range [first+1, last)..." for -clarity. They considered this change close enough to editorial to not -require another round of review.]

    - - - - -

    Rationale:

    -

    The LWG also considered an alternative resolution: change -25.2.9 [alg.unique] paragraph 1 to:

    - -

    -For a nonempty range, eliminates all but the first element from every -consecutive group of elements referred to by the iterator -i in the range (first, last) for which the following -conditions hold: *(i-1) == *i or pred(*(i-1), *i) != -false. -

    - -

    -Also insert a new paragraph, paragraph 1a, that reads: "Notes: The -comparison function need not be an equivalence relation." -

    - - -

    Informally: the proposed resolution imposes an explicit requirement -that the comparison function be an equivalence relation. The -alternative resolution does not, and it gives enough information so -that the behavior of unique() for a non-equivalence relation is -specified. Both resolutions are consistent with the behavior of -existing implementations.

    - - - - - -
    -

    206. operator new(size_t, nothrow) may become unlinked to ordinary operator new if ordinary version replaced

    -

    Section: 18.5.1.1 [new.delete.single] Status: WP - Submitter: Howard Hinnant Date: 1999-08-29

    -

    View all other issues in [new.delete.single].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    As specified, the implementation of the nothrow version of operator -new does not necessarily call the ordinary operator new, but may -instead simply call the same underlying allocator and return a null -pointer instead of throwing an exception in case of failure.

    - -

    Such an implementation breaks code that replaces the ordinary -version of new, but not the nothrow version. If the ordinary version -of new/delete is replaced, and if the replaced delete is not -compatible with pointers returned from the library versions of new, -then when the replaced delete receives a pointer allocated by the -library new(nothrow), crash follows.

    - -

    The fix appears to be that the lib version of new(nothrow) must -call the ordinary new. Thus when the ordinary new gets replaced, the -lib version will call the replaced ordinary new and things will -continue to work.

    - -

    An alternative would be to have the ordinary new call -new(nothrow). This seems sub-optimal to me as the ordinary version of -new is the version most commonly replaced in practice. So one would -still need to replace both ordinary and nothrow versions if one wanted -to replace the ordinary version.

    - -

    Another alternative is to put in clear text that if one version is -replaced, then the other must also be replaced to maintain -compatibility. Then the proposed resolution below would just be a -quality of implementation issue. There is already such text in -paragraph 7 (under the new(nothrow) version). But this nuance is -easily missed if one reads only the paragraphs relating to the -ordinary new.

    - -

    -N2158 -has been written explaining the rationale for the proposed resolution below. -

    - - - -

    Proposed resolution:

    -

    -Change 18.5.1.1 [new.delete.single]: -

    - -
    -
    void* operator new(std::size_t size, const std::nothrow_t&) throw();
-
    -
    -

    --5- Effects: Same as above, except that it is called by a placement -version of a new-expression when a C++ program prefers a null pointer result as -an error indication, instead of a bad_alloc exception. -

    - -

    --6- Replaceable: a C++ program may define a function with this function -signature that displaces the default version defined by the C++ Standard -library. -

    - -

    --7- Required behavior: Return a non-null pointer to suitably aligned -storage (3.7.4), or else return a null pointer. This nothrow version of operator -new returns a pointer obtained as if acquired from the (possibly -replaced) ordinary version. This requirement is binding on a replacement -version of this function. -

    - -

    --8- Default behavior: -

    -
      -
    • -Calls operator new(size). -
      • -
    • -If the call to operator new(size) returns normally, returns -the result of that call, else -
      • -
    • -if the call to operator new(size) throws an exception, returns -a null pointer. -
      • -
    • -Executes a loop: Within the loop, the function first attempts to allocate the -requested storage. Whether the attempt involves a call to the Standard C library -function malloc is unspecified. -
      • -
    • -Returns a pointer to the allocated storage if the attempt is successful. -Otherwise, if the last argument to set_new_handler() was a null -pointer, return a null pointer. -
      • -
    • -Otherwise, the function calls the current new_handler (18.5.2.2). If the -called function returns, the loop repeats. -
      • -
    • -The loop terminates when an attempt to allocate the requested storage is -successful or when a called new_handler function does not return. If the -called new_handler function terminates by throwing a bad_alloc -exception, the function returns a null pointer. -
      • -
    -

    --9- [Example: -

    -
    T* p1 = new T;                 // throws bad_alloc if it fails
-T* p2 = new(nothrow) T;        // returns 0 if it fails
-
    -

    ---end example] -

    -
    - -
    void operator delete(void* ptr) throw();
-void operator delete(void* ptr, const std::nothrow_t&) throw();
-
    - -
    -

    --10- Effects: The deallocation function (3.7.4.2) called by a -delete-expression to render the value of ptr invalid. -

    -

    --11- Replaceable: a C++ program may define a function with this function -signature that displaces the default version defined by the C++ Standard -library. -

    -

    --12- Requires: the value of ptr is null or the value -returned by an earlier call to the default (possibly -replaced) operator new(std::size_t) or operator -new(std::size_t, const std::nothrow_t&). -

    -

    --13- Default behavior: -

    -
      -
    • -For a null value of ptr, do nothing. -
      • -
    • -Any other value of ptr shall be a value returned earlier by a -call to the default operator new, which was not invalidated by an -intervening call to operator delete(void*) (17.4.3.7). For such a -non-null value of ptr, reclaims storage allocated by the earlier -call to the default operator new. -
      • -
    -

    --14- Remarks: It is unspecified under what conditions part or all of -such reclaimed storage is allocated by a subsequent call to operator -new or any of calloc, malloc, or realloc, -declared in <cstdlib>. -

    -
    - -
    void operator delete(void* ptr, const std::nothrow_t&) throw();
-
    - -
    -

    --15- Effects: Same as above, except that it is called by the -implementation when an exception propagates from a nothrow placement version -of the new-expression (i.e. when the constructor throws an exception). -

    -

    --16- Replaceable: a C++ program may define a function with this function -signature that displaces the default version defined by the C++ Standard -library. -

    -

    --17- Requires: the value of ptr is null or the -value returned by an earlier call to the (possibly replaced) operator -new(std::size_t) or operator new(std::size_t, const -std::nothrow_t&).

    -

    --18- Default behavior: Calls operator delete(ptr). -

    -
    - -
    - -

    -Change 18.5.1.2 [new.delete.array] -

    - -
    -
    void* operator new[](std::size_t size, const std::nothrow_t&) throw();
-
    - -
    -

    --5- Effects: Same as above, except that it is called by a placement -version of a new-expression when a C++ program prefers a null pointer result as -an error indication, instead of a bad_alloc exception. -

    - -

    --6- Replaceable: a C++ program can define a function with this function -signature that displaces the default version defined by the C++ Standard -library. -

    - -

    --7- Required behavior: Same as for operator new(std::size_t, -const std::nothrow_t&). This nothrow version of operator new[] -returns a pointer obtained as if acquired from the ordinary version. -Return a non-null pointer to suitably aligned storage (3.7.4), or else -return a null pointer. This nothrow version of operator new returns a pointer -obtained as if acquired from the (possibly replaced) operator -new[](std::size_t size). This requirement is binding on a -replacement version of this function. -

    - -

    --8- Default behavior: Returns operator new(size, -nothrow). -

    - -
      -
    • -Calls operator new[](size). -
      • -
    • -If the call to operator new[](size) returns normally, returns -the result of that call, else -
      • -
    • -if the call to operator new[](size) throws an exception, returns -a null pointer. -
      • -
    -
    - -
    void operator delete[](void* ptr) throw(); 
-void operator delete[](void* ptr, const std::nothrow_t&) throw();
-
    - -
    -

    --9- Effects: The deallocation function (3.7.4.2) called by the -array form of a delete-expression to render the value of -ptr invalid. -

    - -

    --10- Replaceable: a C++ program can define a function with this function -signature that displaces the default version defined by the C++ Standard -library. -

    - -

    --11- Requires: the value of -ptr is null or the value returned by an earlier call to -operator new[](std::size_t) or operator new[](std::size_t, const -std::nothrow_t&). -

    - -

    --12- Default behavior: Calls operator delete(ptr) or -operator delete[](ptr, std::nothrow) respectively. -

    -
    - -
    - - - -

    Rationale:

    -

    Yes, they may become unlinked, and that is by design. If a user -replaces one, the user should also replace the other.

    - -

    [ -Reopened due to a gcc conversation between Howard, Martin and Gaby. Forwarding -or not is visible behavior to the client and it would be useful for the client -to know which behavior it could depend on. -]

    - - -

    [ -Batavia: Robert voiced serious reservations about backwards compatibility for -his customers. -]

    - - - - - - -
    -

    208. Unnecessary restriction on past-the-end iterators

    -

    Section: 24.1 [iterator.requirements] Status: TC - Submitter: Stephen Cleary Date: 2000-02-02

    -

    View other active issues in [iterator.requirements].

    -

    View all other issues in [iterator.requirements].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    In 24.1 paragraph 5, it is stated ". . . Dereferenceable and -past-the-end values are always non-singular."

    -

    This places an unnecessary restriction on past-the-end iterators for -containers with forward iterators (for example, a singly-linked list). If the -past-the-end value on such a container was a well-known singular value, it would -still satisfy all forward iterator requirements.

    -

    Removing this restriction would allow, for example, a singly-linked list -without a "footer" node.

    -

    This would have an impact on existing code that expects past-the-end -iterators obtained from different (generic) containers being not equal.

    - - -

    Proposed resolution:

    -

    Change 24.1 [iterator.requirements] paragraph 5, the last sentence, from:

    -
    -

    Dereferenceable and past-the-end values are always non-singular.

    -
    -

    to:

    -
    -

    Dereferenceable values are always non-singular. 

    -
    - - -

    Rationale:

    -

    For some kinds of containers, including singly linked lists and -zero-length vectors, null pointers are perfectly reasonable past-the-end -iterators. Null pointers are singular. -

    - - - - -
    -

    209. basic_string declarations inconsistent

    -

    Section: 21.3 [basic.string] Status: TC - Submitter: Igor Stauder Date: 2000-02-11

    -

    View other active issues in [basic.string].

    -

    View all other issues in [basic.string].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    In Section 21.3 [basic.string] the basic_string member function -declarations use a consistent style except for the following functions:

    -
    - 
    void push_back(const charT);
-basic_string& assign(const basic_string&);
-void swap(basic_string<charT,traits,Allocator>&);
    -
    -

    - push_back, assign, swap: missing argument name 
    -- push_back: use of const with charT (i.e. POD type passed by value -not by reference - should be charT or const charT& )
    -- swap: redundant use of template parameters in argument -basic_string<charT,traits,Allocator>&

    - - -

    Proposed resolution:

    -

    In Section 21.3 [basic.string] change the basic_string member -function declarations push_back, assign, and swap to:

    -
    - 
    void push_back(charT c); 
-
-basic_string& assign(const basic_string& str);
-void swap(basic_string& str);
    -
    - - -

    Rationale:

    -

    Although the standard is in general not consistent in declaration -style, the basic_string declarations are consistent other than the -above. The LWG felt that this was sufficient reason to merit the -change. -

    - - - - -
    -

    210. distance first and last confused

    -

    Section: 25 [algorithms] Status: TC - Submitter: Lisa Lippincott Date: 2000-02-15

    -

    View all other issues in [algorithms].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    In paragraph 9 of section 25 [algorithms], it is written:

    -
    -

    In the description of the algorithms operators + and - are used - for some of the iterator categories for which they do not have to - be defined. In these cases the semantics of [...] a-b is the same - as of
    -
    -      return distance(a, b);

    -
    - - -

    Proposed resolution:

    -

    On the last line of paragraph 9 of section 25 [algorithms] change -"a-b" to "b-a".

    - - -

    Rationale:

    -

    There are two ways to fix the defect; change the description to b-a -or change the return to distance(b,a). The LWG preferred the -former for consistency.

    - - - - -
    -

    211. operator>>(istream&, string&) doesn't set failbit

    -

    Section: 21.3.8.9 [string.io] Status: TC - Submitter: Scott Snyder Date: 2000-02-04

    -

    View all other issues in [string.io].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    The description of the stream extraction operator for std::string (section -21.3.7.9 [lib.string.io]) does not contain a requirement that failbit be set in -the case that the operator fails to extract any characters from the input -stream.

    -

    This implies that the typical construction

    -
    - 
    std::istream is;
-std::string str;
-...
-while (is >> str) ... ;
    -
    -

    (which tests failbit) is not required to terminate at EOF.

    -

    Furthermore, this is inconsistent with other extraction operators, -which do include this requirement. (See sections 27.6.1.2 [istream.formatted] and 27.6.1.3 [istream.unformatted]), where this -requirement is present, either explicitly or implicitly, for the -extraction operators. It is also present explicitly in the description -of getline (istream&, string&, charT) in section 21.3.8.9 [string.io] paragraph 8.)

    - - -

    Proposed resolution:

    -

    Insert new paragraph after paragraph 2 in section 21.3.8.9 [string.io]:

    -
    - -

    If the function extracts no characters, it calls -is.setstate(ios::failbit) which may throw ios_base::failure -(27.4.4.3).

    -
    - - - - -
    -

    212. Empty range behavior unclear for several algorithms

    -

    Section: 25.3.7 [alg.min.max] Status: TC - Submitter: Nico Josuttis Date: 2000-02-26

    -

    View all other issues in [alg.min.max].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    The standard doesn't specify what min_element() and max_element() shall -return if the range is empty (first equals last). The usual implementations -return last. This problem seems also apply to partition(), stable_partition(), -next_permutation(), and prev_permutation().

    - - -

    Proposed resolution:

    -

    In 25.3.7 [alg.min.max] - Minimum and maximum, paragraphs 7 and -9, append: Returns last if first==last.

    - - -

    Rationale:

    -

    The LWG looked in some detail at all of the above mentioned -algorithms, but believes that except for min_element() and -max_element() it is already clear that last is returned if first == -last.

    - - - - -
    -

    214. set::find() missing const overload

    -

    Section: 23.3.3 [set], 23.3.4 [multiset] Status: WP - Submitter: Judy Ward Date: 2000-02-28

    -

    View all other issues in [set].

    -

    View all issues with WP status.

    -

    Duplicate of: 450

    -

    Discussion:

    -

    The specification for the associative container requirements in -Table 69 state that the find member function should "return -iterator; const_iterator for constant a". The map and multimap -container descriptions have two overloaded versions of find, but set -and multiset do not, all they have is:

    -
    - 
    iterator find(const key_type & x) const;
    -
    - - -

    Proposed resolution:

    -

    Change the prototypes for find(), lower_bound(), upper_bound(), and -equal_range() in section 23.3.3 [set] and section 23.3.4 [multiset] to each have two overloads:

    -
    - 
    iterator find(const key_type & x);
-const_iterator find(const key_type & x) const;
    - 
    iterator lower_bound(const key_type & x);
-const_iterator lower_bound(const key_type & x) const;
    - 
    iterator upper_bound(const key_type & x);
-const_iterator upper_bound(const key_type & x) const;
    - 
    pair<iterator, iterator> equal_range(const key_type & x);
-pair<const_iterator, const_iterator> equal_range(const key_type & x) const;
    -
    - -

    [Tokyo: At the request of the LWG, Judy Ward provided wording -extending the proposed resolution to lower_bound, upper_bound, and -equal_range.]

    - - - - - - -
    -

    217. Facets example (Classifying Japanese characters) contains errors

    -

    Section: 22.2.8 [facets.examples] Status: TC - Submitter: Martin Sebor Date: 2000-02-29

    -

    View all other issues in [facets.examples].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    The example in 22.2.8, paragraph 11 contains the following errors:

    -

    1) The member function `My::JCtype::is_kanji()' is non-const; the function -must be const in order for it to be callable on a const object (a reference to -which which is what std::use_facet<>() returns).

    -

    2) In file filt.C, the definition of `JCtype::id' must be qualified with the -name of the namespace `My'.

    -

    3) In the definition of `loc' and subsequently in the call to use_facet<>() -in main(), the name of the facet is misspelled: it should read `My::JCtype' -rather than `My::JCType'.

    - - -

    Proposed resolution:

    -

    Replace the "Classifying Japanese characters" example in 22.2.8, -paragraph 11 with the following:

    -
    #include <locale>
    -
    namespace My {
-    using namespace std;
-    class JCtype : public locale::facet {
-    public:
-        static locale::id id;     //  required for use as a new locale facet
-        bool is_kanji (wchar_t c) const;
-        JCtype() {}
-    protected:
-        ~JCtype() {}
-    };
-}
    -
    //  file:  filt.C
-#include <iostream>
-#include <locale>
-#include "jctype"                 //  above
-std::locale::id My::JCtype::id;   //  the static  JCtype  member
-declared above.
    -
    int main()
-{
-    using namespace std;
-    typedef ctype<wchar_t> wctype;
-    locale loc(locale(""),              //  the user's preferred locale...
-               new My::JCtype);         //  and a new feature ...
-    wchar_t c = use_facet<wctype>(loc).widen('!');
-    if (!use_facet<My::JCtype>(loc).is_kanji(c))
-        cout << "no it isn't!" << endl;
-    return 0;
-}
    - - - - -
    -

    220. ~ios_base() usage valid?

    -

    Section: 27.4.2.7 [ios.base.cons] Status: TC - Submitter: Jonathan Schilling, Howard Hinnant Date: 2000-03-13

    -

    View all issues with TC status.

    -

    Discussion:

    -

    The pre-conditions for the ios_base destructor are described in 27.4.2.7 -paragraph 2:

    -
    -

    Effects: Destroys an object of class ios_base. Calls each registered - callback pair (fn,index) (27.4.2.6) as (*fn)(erase_event,*this,index) at such - time that any ios_base member function called from within fn has well defined - results.

    -
    -

    But what is not clear is: If no callback functions were ever registered, does -it matter whether the ios_base members were ever initialized?

    -

    For instance, does this program have defined behavior:

    -
    - 
    #include <ios>
    - 
    class D : public std::ios_base { };
    - 
    int main() { D d; }
    -
    -

    It seems that registration of a callback function would surely affect the -state of an ios_base. That is, when you register a callback function with an -ios_base, the ios_base must record that fact somehow.

    -

    But if after construction the ios_base is in an indeterminate state, and that -state is not made determinate before the destructor is called, then how would -the destructor know if any callbacks had indeed been registered? And if the -number of callbacks that had been registered is indeterminate, then is not the -behavior of the destructor undefined?

    -

    By comparison, the basic_ios class description in 27.4.4.1 paragraph 2 makes -it explicit that destruction before initialization results in undefined -behavior.

    - - -

    Proposed resolution:

    -

    Modify 27.4.2.7 paragraph 1 from

    -
    -

    Effects: Each ios_base member has an indeterminate value after - construction.

    -
    -

    to

    -
    -

    Effects: Each ios_base member has an indeterminate -value after construction. These members must be initialized by calling -basic_ios::init. If an ios_base object is destroyed before these -initializations have taken place, the behavior is undefined.

    -
    - - - - -
    -

    221. num_get<>::do_get stage 2 processing broken

    -

    Section: 22.2.2.1.2 [facet.num.get.virtuals] Status: WP - Submitter: Matt Austern Date: 2000-03-14

    -

    View other active issues in [facet.num.get.virtuals].

    -

    View all other issues in [facet.num.get.virtuals].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    Stage 2 processing of numeric conversion is broken.

    - -

    Table 55 in 22.2.2.1.2 says that when basefield is 0 the integral -conversion specifier is %i. A %i specifier determines a number's base -by its prefix (0 for octal, 0x for hex), so the intention is clearly -that a 0x prefix is allowed. Paragraph 8 in the same section, -however, describes very precisely how characters are processed. (It -must be done "as if" by a specified code fragment.) That -description does not allow a 0x prefix to be recognized.

    - -

    Very roughly, stage 2 processing reads a char_type ct. It converts -ct to a char, not by using narrow but by looking it up in a -translation table that was created by widening the string literal -"0123456789abcdefABCDEF+-". The character "x" is -not found in that table, so it can't be recognized by stage 2 -processing.

    - - -

    Proposed resolution:

    -

    In 22.2.2.1.2 paragraph 8, replace the line:

    -
    - 
    static const char src[] = "0123456789abcdefABCDEF+-";
    -
    -

    with the line:

    -
    - 
    static const char src[] = "0123456789abcdefxABCDEFX+-";
    -
    - - -

    Rationale:

    -

    If we're using the technique of widening a string literal, the -string literal must contain every character we wish to recognize. -This technique has the consequence that alternate representations -of digits will not be recognized. This design decision was made -deliberately, with full knowledge of that limitation.

    - - - - - -
    -

    222. Are throw clauses necessary if a throw is already implied by the effects clause?

    -

    Section: 17.3.1.3 [structure.specifications] Status: TC - Submitter: Judy Ward Date: 2000-03-17

    -

    View all other issues in [structure.specifications].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    Section 21.3.6.8 describes the basic_string::compare function this way:

    -
    - 
    21.3.6.8 - basic_string::compare [lib.string::compare]
-
-int compare(size_type pos1, size_type n1,
-                const basic_string<charT,traits,Allocator>&  str ,
-                size_type  pos2 , size_type  n2 ) const;
-
--4- Returns: 
-
-    basic_string<charT,traits,Allocator>(*this,pos1,n1).compare(
-                 basic_string<charT,traits,Allocator>(str,pos2,n2)) .
    -
    -

    and the constructor that's implicitly called by the above is -defined to throw an out-of-range exception if pos > str.size(). See -section 21.3.1 [string.require] paragraph 4.

    - -

    On the other hand, the compare function descriptions themselves don't have -"Throws: " clauses and according to 17.3.1.3, paragraph 3, elements -that do not apply to a function are omitted.

    -

    So it seems there is an inconsistency in the standard -- are the -"Effects" clauses correct, or are the "Throws" clauses -missing?

    - - -

    Proposed resolution:

    -

    In 17.3.1.3 [structure.specifications] paragraph 3, the footnote 148 attached to -the sentence "Descriptions of function semantics contain the -following elements (as appropriate):", insert the word -"further" so that the foot note reads:

    -
    -

    To save space, items that do not apply to a function are - omitted. For example, if a function does not specify any further - preconditions, there will be no "Requires" paragraph.

    -
    - - -

    Rationale:

    -

    The standard is somewhat inconsistent, but a failure to note a -throw condition in a throws clause does not grant permission not to -throw. The inconsistent wording is in a footnote, and thus -non-normative. The proposed resolution from the LWG clarifies the -footnote.

    - - - - -
    -

    223. reverse algorithm should use iter_swap rather than swap

    -

    Section: 25.2.10 [alg.reverse] Status: TC - Submitter: Dave Abrahams Date: 2000-03-21

    -

    View all issues with TC status.

    -

    Discussion:

    -

    Shouldn't the effects say "applies iter_swap to all pairs..."?

    - - -

    Proposed resolution:

    -

    In 25.2.10 [alg.reverse], replace:

    -

    - Effects: For each non-negative integer i <= (last - first)/2, - applies swap to all pairs of iterators first + i, (last - i) - 1. -

    -

    with:

    -

    - Effects: For each non-negative integer i <= (last - first)/2, - applies iter_swap to all pairs of iterators first + i, (last - i) - 1. -

    - - - - -
    -

    224. clear() complexity for associative containers refers to undefined N

    -

    Section: 23.1.4 [associative.reqmts] Status: TC - Submitter: Ed Brey Date: 2000-03-23

    -

    View all other issues in [associative.reqmts].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    In the associative container requirements table in 23.1.2 paragraph 7, -a.clear() has complexity "log(size()) + N". However, the meaning of N -is not defined.

    - - -

    Proposed resolution:

    -

    In the associative container requirements table in 23.1.2 paragraph -7, the complexity of a.clear(), change "log(size()) + N" to -"linear in size()".

    - - -

    Rationale:

    -

    It's the "log(size())", not the "N", that is in -error: there's no difference between O(N) and O(N + -log(N)). The text in the standard is probably an incorrect -cut-and-paste from the range version of erase.

    - - - - -
    -

    225. std:: algorithms use of other unqualified algorithms

    -

    Section: 17.4.4.3 [global.functions] Status: WP - Submitter: Dave Abrahams Date: 2000-04-01

    -

    View all other issues in [global.functions].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    Are algorithms in std:: allowed to use other algorithms without qualification, so functions in -user namespaces might be found through Koenig lookup?

    -

    For example, a popular standard library implementation includes this -implementation of std::unique:

    -
    -
    namespace std {
-    template <class _ForwardIter>
-    _ForwardIter unique(_ForwardIter __first, _ForwardIter __last) {
-      __first = adjacent_find(__first, __last);
-      return unique_copy(__first, __last, __first);
-    }
-    }
    -
    -

    Imagine two users on opposite sides of town, each using unique on his own -sequences bounded by my_iterators . User1 looks at his standard library -implementation and says, "I know how to implement a more efficient -unique_copy for my_iterators", and writes:

    -
    -
    namespace user1 {
-    class my_iterator;
-    // faster version for my_iterator
-    my_iterator unique_copy(my_iterator, my_iterator, my_iterator);
-    }
    -
    -

    user1::unique_copy() is selected by Koenig lookup, as he intended.

    -

    User2 has other needs, and writes:

    -
    -
    namespace user2 {
-    class my_iterator;
-    // Returns true iff *c is a unique copy of *a and *b.
-    bool unique_copy(my_iterator a, my_iterator b, my_iterator c);
-    }
    -
    -

    User2 is shocked to find later that his fully-qualified use of -std::unique(user2::my_iterator, user2::my_iterator, user2::my_iterator) fails to -compile (if he's lucky). Looking in the standard, he sees the following Effects -clause for unique():

    -
    -

    Effects: Eliminates all but the first element from every consecutive group - of equal elements referred to by the iterator i in the range [first, last) for - which the following corresponding conditions hold: *i == *(i - 1) or pred(*i, - *(i - 1)) != false

    -
    -

    The standard gives user2 absolutely no reason to think he can interfere with -std::unique by defining names in namespace user2. His standard library has been -built with the template export feature, so he is unable to inspect the -implementation. User1 eventually compiles his code with another compiler, and -his version of unique_copy silently stops being called. Eventually, he realizes -that he was depending on an implementation detail of his library and had no -right to expect his unique_copy() to be called portably.

    -

    On the face of it, and given above scenario, it may seem obvious that the -implementation of unique() shown is non-conforming because it uses unique_copy() -rather than ::std::unique_copy(). Most standard library implementations, -however, seem to disagree with this notion.

    -

    [Tokyo:  Steve Adamczyk from -the core working group indicates that "std::" is sufficient;  -leading "::" qualification is not required because any namespace -qualification is sufficient to suppress Koenig lookup.]

    - - -

    Proposed resolution:

    -

    Add a paragraph and a note at the end of -17.4.4.3 [global.functions]:

    -
    - -

    Unless otherwise specified, no global or non-member function in the -standard library shall use a function from another namespace which is -found through argument-dependent name lookup (3.4.2 [basic.lookup.argdep]).

    - -

    [Note: the phrase "unless otherwise specified" is intended to -allow Koenig lookup in cases like that of ostream_iterators:
    - -
    - Effects:

    -
    -

    *out_stream << value;
    - if(delim != 0) *out_stream << delim;
    - return (*this);

    -

    --end note]

    -
    -
    - -

    [Tokyo: The LWG agrees that this is a defect in the standard, but -is as yet unsure if the proposed resolution is the best -solution. Furthermore, the LWG believes that the same problem of -unqualified library names applies to wording in the standard itself, -and has opened issue 229 accordingly. Any resolution of -issue 225 should be coordinated with the resolution of -issue 229.]

    - - -

    [Toronto: The LWG is not sure if this is a defect in the -standard. Most LWG members believe that an implementation of -std::unique like the one quoted in this issue is already -illegal, since, under certain circumstances, its semantics are not -those specified in the standard. The standard's description of -unique does not say that overloading adjacent_find -should have any effect.]

    - - -

    [Curaçao: An LWG-subgroup spent an afternoon working on issues -225, 226, and 229. Their conclusion was that the issues should be -separated into an LWG portion (Howard's paper, N1387=02-0045), and a -EWG portion (Dave will write a proposal). The LWG and EWG had -(separate) discussions of this plan the next day. The proposed -resolution for this issue is in accordance with Howard's paper.]

    - - - - -

    Rationale:

    -

    It could be argued that this proposed isn't strictly necessary, - that the Standard doesn't grant implementors license to write a - standard function that behaves differently than specified in the - Standard just because of an unrelated user-defined name in some - other namespace. However, this is at worst a clarification. It is - surely right that algorithsm shouldn't pick up random names, that - user-defined names should have no effect unless otherwise specified. - Issue 226 deals with the question of when it is - appropriate for the standard to explicitly specify otherwise.

    - - - - - -
    -

    226. User supplied specializations or overloads of namespace std function templates

    -

    Section: 17.4.3.2 [reserved.names] Status: WP - Submitter: Dave Abrahams Date: 2000-04-01

    -

    View all other issues in [reserved.names].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    The issues are: 

    -

    1. How can a 3rd party library implementor (lib1) write a version of a standard -algorithm which is specialized to work with his own class template? 

    -

    2. How can another library implementor (lib2) write a generic algorithm which -will take advantage of the specialized algorithm in lib1?

    -

    This appears to be the only viable answer under current language rules:

    -
    - 
    namespace lib1
-{
-    // arbitrary-precision numbers using T as a basic unit
-    template <class T>
-    class big_num { //...
-    };
-
    - 
        // defining this in namespace std is illegal (it would be an
-    // overload), so we hope users will rely on Koenig lookup
-    template <class T>
-    void swap(big_int<T>&, big_int<T>&);
-}
    - 
    #include <algorithm>
-namespace lib2
-{
-    template <class T>
-    void generic_sort(T* start, T* end)
-    {
-            ...
-        // using-declaration required so we can work on built-in types
-        using std::swap;
-        // use Koenig lookup to find specialized algorithm if available
-        swap(*x, *y);
-    }
-}
    -
    -

    This answer has some drawbacks. First of all, it makes writing lib2 difficult -and somewhat slippery. The implementor needs to remember to write the -using-declaration, or generic_sort will fail to compile when T is a built-in -type. The second drawback is that the use of this style in lib2 effectively -"reserves" names in any namespace which defines types which may -eventually be used with lib2. This may seem innocuous at first when applied to -names like swap, but consider more ambiguous names like unique_copy() instead. -It is easy to imagine the user wanting to define these names differently in his -own namespace. A definition with semantics incompatible with the standard -library could cause serious problems (see issue 225).

    -

    Why, you may ask, can't we just partially specialize std::swap()? It's -because the language doesn't allow for partial specialization of function -templates. If you write:

    -
    - 
    namespace std
-{
-    template <class T>
-    void swap(lib1::big_int<T>&, lib1::big_int<T>&);
-}
    -
    -

    You have just overloaded std::swap, which is illegal under the current -language rules. On the other hand, the following full specialization is legal:

    -
    - 
    namespace std
-{
-    template <>
-    void swap(lib1::other_type&, lib1::other_type&);
-}
    -
    - -

    This issue reflects concerns raised by the "Namespace issue -with specialized swap" thread on comp.lang.c++.moderated. A -similar set of concerns was earlier raised on the boost.org mailing -list and the ACCU-general mailing list. Also see library reflector -message c++std-lib-7354.

    - -

    -J. C. van Winkel points out (in c++std-lib-9565) another unexpected -fact: it's impossible to output a container of std::pair's using copy -and an ostream_iterator, as long as both pair-members are built-in or -std:: types. That's because a user-defined operator<< for (for -example) std::pair<const std::string, int> will not be found: -lookup for operator<< will be performed only in namespace std. -Opinions differed on whether or not this was a defect, and, if so, -whether the defect is that something is wrong with user-defined -functionality and std, or whether it's that the standard library does -not provide an operator<< for std::pair<>. -

    - - - -

    Proposed resolution:

    - -

    Adopt the wording proposed in Howard Hinnant's paper - N1523=03-0106, "Proposed Resolution To LWG issues 225, 226, 229".

    - - -

    [Tokyo: Summary, "There is no conforming way to extend -std::swap for user defined templates."  The LWG agrees that -there is a problem. Would like more information before -proceeding. This may be a core issue. Core issue 229 has been opened -to discuss the core aspects of this problem. It was also noted that -submissions regarding this issue have been received from several -sources, but too late to be integrated into the issues list. -]

    - - -

    [Post-Tokyo: A paper with several proposed resolutions, -J16/00-0029==WG21/N1252, "Shades of namespace std functions -" by Alan Griffiths, is in the Post-Tokyo mailing. It -should be considered a part of this issue.]

    - - -

    [Toronto: Dave Abrahams and Peter Dimov have proposed a -resolution that involves core changes: it would add partial -specialization of function template. The Core Working Group is -reluctant to add partial specialization of function templates. It is -viewed as a large change, CWG believes that proposal presented leaves -some syntactic issues unanswered; if the CWG does add partial -specialization of function templates, it wishes to develop its own -proposal. The LWG continues to believe that there is a serious -problem: there is no good way for users to force the library to use -user specializations of generic standard library functions, and in -certain cases (e.g. transcendental functions called by -valarray and complex) this is important. Koenig -lookup isn't adequate, since names within the library must be -qualified with std (see issue 225), specialization doesn't -work (we don't have partial specialization of function templates), and -users aren't permitted to add overloads within namespace std. -]

    - - -

    [Copenhagen: Discussed at length, with no consensus. Relevant -papers in the pre-Copenhagen mailing: N1289, N1295, N1296. Discussion -focused on four options. (1) Relax restrictions on overloads within -namespace std. (2) Mandate that the standard library use unqualified -calls for swap and possibly other functions. (3) Introduce -helper class templates for swap and possibly other functions. -(4) Introduce partial specialization of function templates. Every -option had both support and opposition. Straw poll (first number is -support, second is strongly opposed): (1) 6, 4; (2) 6, 7; (3) 3, 8; -(4) 4, 4.]

    - - -

    [Redmond: Discussed, again no consensus. Herb presented an -argument that a user who is defining a type T with an -associated swap should not be expected to put that -swap in namespace std, either by overloading or by partial -specialization. The argument is that swap is part of -T's interface, and thus should to in the same namespace as -T and only in that namespace. If we accept this argument, -the consequence is that standard library functions should use -unqualified call of swap. (And which other functions? Any?) -A small group (Nathan, Howard, Jeremy, Dave, Matt, Walter, Marc) will -try to put together a proposal before the next meeting.]

    - - -

    [Curaçao: An LWG-subgroup spent an afternoon working on issues -225, 226, and 229. Their conclusion was that the issues should be -separated into an LWG portion (Howard's paper, N1387=02-0045), and a -EWG portion (Dave will write a proposal). The LWG and EWG had -(separate) discussions of this plan the next day. The proposed -resolution is the one proposed by Howard.]

    - - -

    [Santa Cruz: the LWG agreed with the general direction of - Howard's paper, N1387. (Roughly: Koenig lookup is disabled unless - we say otherwise; this issue is about when we do say otherwise.) - However, there were concerns about wording. Howard will provide new - wording. Bill and Jeremy will review it.]

    - - -

    [Kona: Howard proposed the new wording. The LWG accepted his - proposed resolution.]

    - - - - -

    Rationale:

    -

    Informally: introduce a Swappable concept, and specify that the - value types of the iterators passed to certain standard algorithms - (such as iter_swap, swap_ranges, reverse, rotate, and sort) conform - to that concept. The Swappable concept will make it clear that - these algorithms use unqualified lookup for the calls - to swap. Also, in 26.5.3.3 [valarray.transcend] paragraph 1, - state that the valarray transcendentals use unqualified lookup.

    - - - - - -
    -

    227. std::swap() should require CopyConstructible or DefaultConstructible arguments

    -

    Section: 25.2.3 [alg.swap] Status: TC - Submitter: Dave Abrahams Date: 2000-04-09

    -

    View all other issues in [alg.swap].

    -

    View all issues with TC status.

    -

    Discussion:

    -

    25.2.2 reads:

    -
    -

    template<class T> void swap(T& a, T& b);
    -
    - Requires: Type T is Assignable (_lib.container.requirements_).
    - Effects: Exchanges values stored in two locations.

    -
    -

    The only reasonable** generic implementation of swap requires construction of a - new temporary copy of one of its arguments:

    -
    -
    template<class T> void swap(T& a, T& b);
-  {
-      T tmp(a);
-      a = b;
-      b = tmp;
-  }
    -
    -

    But a type which is only Assignable cannot be swapped by this implementation.

    -

    **Yes, there's also an unreasonable implementation which would require T to be - DefaultConstructible instead of CopyConstructible. I don't think this is worthy - of consideration:

    -
    -
    template<class T> void swap(T& a, T& b);
-{
-    T tmp;
-    tmp = a;
-    a = b;
-    b = tmp;
-}
    -
    - - -

    Proposed resolution:

    -

    Change 25.2.2 paragraph 1 from:

    -
    -

    Requires: Type T is Assignable (23.1).

    -
    -

    to:

    -
    -

    Requires: Type T is CopyConstructible (20.1.3) and Assignable (23.1)

    -
    - - - - - -
    -

    228. Incorrect specification of "..._byname" facets

    -

    Section: 22.2 [locale.categories] Status: WP - Submitter: Dietmar Kühl Date: 2000-04-20

    -

    View other active issues in [locale.categories].

    -

    View all other issues in [locale.categories].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    The sections 22.2.1.2 [locale.ctype.byname], 22.2.1.5 -[locale.codecvt.byname], -sref ref="22.2.1.6", 22.2.3.2 [locale.numpunct.byname], 22.2.4.2 -[locale.collate.byname], 22.2.5.4 [locale.time.put.byname], 22.2.6.4 -[locale.moneypunct.byname], and 22.2.7.2 [locale.messages.byname] -overspecify the -definitions of the "..._byname" classes by listing a bunch -of virtual functions. At the same time, no semantics of these -functions are defined. Real implementations do not define these -functions because the functional part of the facets is actually -implemented in the corresponding base classes and the constructor of -the "..._byname" version just provides suitable date used by -these implementations. For example, the 'numpunct' methods just return -values from a struct. The base class uses a statically initialized -struct while the derived version reads the contents of this struct -from a table. However, no virtual function is defined in -'numpunct_byname'.

    - -

    For most classes this does not impose a problem but specifically -for 'ctype' it does: The specialization for 'ctype_byname<char>' -is required because otherwise the semantics would change due to the -virtual functions defined in the general version for 'ctype_byname': -In 'ctype<char>' the method 'do_is()' is not virtual but it is -made virtual in both 'ctype<cT>' and 'ctype_byname<cT>'. -Thus, a class derived from 'ctype_byname<char>' can tell whether -this class is specialized or not under the current specification: -Without the specialization, 'do_is()' is virtual while with -specialization it is not virtual.

    - - -

    Proposed resolution:

    -

      Change section 22.2.1.2 (lib.locale.ctype.byname) to become:

    -
         namespace std {
-       template <class charT>
-       class ctype_byname : public ctype<charT> {
-       public:
-         typedef ctype<charT>::mask mask;
-         explicit ctype_byname(const char*, size_t refs = 0);
-       protected:
-        ~ctype_byname();             //  virtual
-       };
-     }
    -

      Change section 22.2.1.6 (lib.locale.codecvt.byname) to become:

    -
        namespace std {
-      template <class internT, class externT, class stateT>
-      class codecvt_byname : public codecvt<internT, externT, stateT> {
-      public:
-       explicit codecvt_byname(const char*, size_t refs = 0);
-      protected:
-      ~codecvt_byname();             //  virtual
-       };
-     }
-
    -

      Change section 22.2.3.2 (lib.locale.numpunct.byname) to become:

    -
         namespace std {
-       template <class charT>
-       class numpunct_byname : public numpunct<charT> {
-     //  this class is specialized for  char  and  wchar_t.
-       public:
-         typedef charT                char_type;
-         typedef basic_string<charT>  string_type;
-         explicit numpunct_byname(const char*, size_t refs = 0);
-       protected:
-        ~numpunct_byname();          //  virtual
-       };
-     }
    -

      Change section 22.2.4.2 (lib.locale.collate.byname) to become:

    -
         namespace std {
-       template <class charT>
-       class collate_byname : public collate<charT> {
-       public:
-         typedef basic_string<charT> string_type;
-         explicit collate_byname(const char*, size_t refs = 0);
-       protected:
-        ~collate_byname();           //  virtual
-       };
-     }
    -

      Change section 22.2.5.2 (lib.locale.time.get.byname) to become:

    -
         namespace std {
-       template <class charT, class InputIterator = istreambuf_iterator<charT> >
-       class time_get_byname : public time_get<charT, InputIterator> {
-       public:
-         typedef time_base::dateorder dateorder;
-         typedef InputIterator        iter_type
    -
             explicit time_get_byname(const char*, size_t refs = 0);
-       protected:
-        ~time_get_byname();          //  virtual
-       };
-     }
    -

      Change section 22.2.5.4 (lib.locale.time.put.byname) to become:

    -
         namespace std {
-       template <class charT, class OutputIterator = ostreambuf_iterator<charT> >
-       class time_put_byname : public time_put<charT, OutputIterator>
-       {
-       public:
-         typedef charT          char_type;
-         typedef OutputIterator iter_type;
    -
             explicit time_put_byname(const char*, size_t refs = 0);
-       protected:
-        ~time_put_byname();          //  virtual
-       };
-     }"
    -

      Change section 22.2.6.4 (lib.locale.moneypunct.byname) to become:

    -
         namespace std {
-       template <class charT, bool Intl = false>
-       class moneypunct_byname : public moneypunct<charT, Intl> {
-       public:
-         typedef money_base::pattern pattern;
-         typedef basic_string<charT> string_type;
    -
             explicit moneypunct_byname(const char*, size_t refs = 0);
-       protected:
-        ~moneypunct_byname();        //  virtual
-       };
-     }
    -

      Change section 22.2.7.2 (lib.locale.messages.byname) to become:

    -
         namespace std {
-       template <class charT>
-       class messages_byname : public messages<charT> {
-       public:
-         typedef messages_base::catalog catalog;
-         typedef basic_string<charT>    string_type;
    -
             explicit messages_byname(const char*, size_t refs = 0);
-       protected:
-        ~messages_byname();          //  virtual
-       };
-     }
    -

    Remove section 22.2.1.4 [locale.codecvt] completely (because in -this case only those members are defined to be virtual which are -defined to be virtual in 'ctype<cT>'.)

    - -

    [Post-Tokyo: Dietmar Kühl submitted this issue at the request of -the LWG to solve the underlying problems raised by issue 138.]

    - - -

    [Copenhagen: proposed resolution was revised slightly, to remove -three last virtual functions from messages_byname.]

    - - - - - - - -
    -

    229. Unqualified references of other library entities

    -

    Section: 17.4.1.1 [contents] Status: WP - Submitter: Steve Clamage Date: 2000-04-19

    -

    View all issues with WP status.

    -

    Discussion:

    -

    Throughout the library chapters, the descriptions of library entities refer -to other library entities without necessarily qualifying the names.

    - -

    For example, section 25.2.2 "Swap" describes the effect of -swap_ranges in terms of the unqualified name "swap". This section -could reasonably be interpreted to mean that the library must be implemented so -as to do a lookup of the unqualified name "swap", allowing users to -override any ::std::swap function when Koenig lookup applies.

    - -

    Although it would have been best to use explicit qualification with -"::std::" throughout, too many lines in the standard would have to be -adjusted to make that change in a Technical Corrigendum.

    - -

    Issue 182, which addresses qualification of -size_t, is a special case of this. -

    - - -

    Proposed resolution:

    -

    To section 17.4.1.1 "Library contents" Add the following paragraph:

    -
    -

    Whenever a name x defined in the standard library is mentioned, the name x - is assumed to be fully qualified as ::std::x, unless explicitly described - otherwise. For example, if the Effects section for library function F is - described as calling library function G, the function ::std::G is meant.

    -
    - -

    [Post-Tokyo: Steve Clamage submitted this issue at the request of -the LWG to solve a problem in the standard itself similar to the -problem within implementations of library identified by issue 225. Any resolution of issue 225 should be -coordinated with the resolution of this issue.]

    - - -

    [post-Toronto: Howard is undecided about whether it is -appropriate for all standard library function names referred to in -other standard library functions to be explicitly qualified by -std: it is common advice that users should define global -functions that operate on their class in the same namespace as the -class, and this requires argument-dependent lookup if those functions -are intended to be called by library code. Several LWG members are -concerned that valarray appears to require argument-dependent lookup, -but that the wording may not be clear enough to fall under -"unless explicitly described otherwise".]

    - - -

    [Curaçao: An LWG-subgroup spent an afternoon working on issues -225, 226, and 229. Their conclusion was that the issues should be -separated into an LWG portion (Howard's paper, N1387=02-0045), and a -EWG portion (Dave will write a proposal). The LWG and EWG had -(separate) discussions of this plan the next day. This paper resolves -issues 225 and 226. In light of that resolution, the proposed -resolution for the current issue makes sense.]

    - - - - - - - -
    -

    230. Assignable specified without also specifying CopyConstructible

    -

    Section: 17 [library] Status: WP - Submitter: Beman Dawes Date: 2000-04-26

    -

    View all other issues in [library].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    Issue 227 identified an instance (std::swap) where -Assignable was specified without also specifying -CopyConstructible. The LWG asked that the standard be searched to -determine if the same defect existed elsewhere.

    - -

    There are a number of places (see proposed resolution below) where -Assignable is specified without also specifying -CopyConstructible. There are also several cases where both are -specified. For example, 26.4.1 [rand.req].

    - - -

    Proposed resolution:

    -

    In 23.1 [container.requirements] table 65 for value_type: -change "T is Assignable" to "T is CopyConstructible and -Assignable" -

    - -

    In 23.1.4 [associative.reqmts] table 69 X::key_type; change -"Key is Assignable" to "Key is -CopyConstructible and Assignable"
    -

    - -

    In 24.1.2 [output.iterators] paragraph 1, change: -

    -
    -

    A class or a built-in type X satisfies the requirements of an -output iterator if X is an Assignable type (23.1) and also the -following expressions are valid, as shown in Table 73: -

    -
    -

    to: -

    -
    -

    A class or a built-in type X satisfies the requirements of an -output iterator if X is a CopyConstructible (20.1.3) and Assignable -type (23.1) and also the following expressions are valid, as shown in -Table 73: -

    -
    - -

    [Post-Tokyo: Beman Dawes submitted this issue at the request of -the LWG. He asks that the 25.2.5 [alg.replace] and 25.2.6 [alg.fill] changes be studied carefully, as it is not clear that -CopyConstructible is really a requirement and may be -overspecification.]

    - - -

    [Portions of the resolution for issue 230 have been superceded by -the resolution of issue 276.]

    - - - - -

    Rationale:

    -

    The original proposed resolution also included changes to input -iterator, fill, and replace. The LWG believes that those changes are -not necessary. The LWG considered some blanket statement, where an -Assignable type was also required to be Copy Constructible, but -decided against this because fill and replace really don't require the -Copy Constructible property.

    - - - - -
    -

    231. Precision in iostream?

    -

    Section: 22.2.2.2.2 [facet.num.put.virtuals] Status: WP - Submitter: James Kanze, Stephen Clamage Date: 2000-04-25

    -

    View all other issues in [facet.num.put.virtuals].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    What is the following program supposed to output?

    -
    #include <iostream>
-
-    int
-    main()
-    {
-        std::cout.setf( std::ios::scientific , std::ios::floatfield ) ;
-        std::cout.precision( 0 ) ;
-        std::cout << 1.00 << '\n' ;
-        return 0 ;
-    }
    -

    From my C experience, I would expect "1e+00"; this is what -printf("%.0e" , 1.00 ); does. G++ outputs -"1.000000e+00".

    - -

    The only indication I can find in the standard is 22.2.2.2.2/11, -where it says "For conversion from a floating-point type, if -(flags & fixed) != 0 or if str.precision() > 0, then -str.precision() is specified in the conversion specification." -This is an obvious error, however, fixed is not a mask for a field, -but a value that a multi-bit field may take -- the results of and'ing -fmtflags with ios::fixed are not defined, at least not if -ios::scientific has been set. G++'s behavior corresponds to what might -happen if you do use (flags & fixed) != 0 with a typical -implementation (floatfield == 3 << something, fixed == 1 -<< something, and scientific == 2 << something).

    - -

    Presumably, the intent is either (flags & floatfield) != 0, or -(flags & floatfield) == fixed; the first gives something more or -less like the effect of precision in a printf floating point -conversion. Only more or less, of course. In order to implement printf -formatting correctly, you must know whether the precision was -explicitly set or not. Say by initializing it to -1, instead of 6, and -stating that for floating point conversions, if precision < -1, 6 -will be used, for fixed point, if precision < -1, 1 will be used, -etc. Plus, of course, if precision == 0 and flags & floatfield == -0, 1 should be = used. But it probably isn't necessary to emulate all -of the anomalies of printf:-).

    - - -

    Proposed resolution:

    -

    -Replace 22.2.2.2.2 [facet.num.put.virtuals], paragraph 11, with the following -sentence: -

    -

    -For conversion from a floating-point type, -str.precision() is specified in the conversion -specification. -

    - - -

    Rationale:

    -

    The floatfield determines whether numbers are formatted as if -with %f, %e, or %g. If the fixed bit is set, it's %f, -if scientific it's %e, and if both bits are set, or -neither, it's %g.

    -

    Turning to the C standard, a precision of 0 is meaningful -for %f and %e. For %g, precision 0 is taken to be the same as -precision 1.

    -

    The proposed resolution has the effect that if neither -fixed nor scientific is set we'll be -specifying a precision of 0, which will be internally -turned into 1. There's no need to call it out as a special -case.

    -

    The output of the above program will be "1e+00".

    - -

    [Post-Curaçao: Howard provided improved wording covering the case -where precision is 0 and mode is %g.]

    - - - - - - - -
    -

    232. "depends" poorly defined in 17.4.3.1

    -

    Section: 17.4.3.2 [reserved.names] Status: WP - Submitter: Peter Dimov Date: 2000-04-18

    -

    View all other issues in [reserved.names].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    17.4.3.1/1 uses the term "depends" to limit the set of allowed -specializations of standard templates to those that "depend on a -user-defined name of external linkage."

    -

    This term, however, is not adequately defined, making it possible to -construct a specialization that is, I believe, technically legal according to -17.4.3.1/1, but that specializes a standard template for a built-in type such as -'int'.

    -

    The following code demonstrates the problem:

    -
    - 
    #include <algorithm>
    - 
    template<class T> struct X
-{
- typedef T type;
-};
    - 
    namespace std
-{
- template<> void swap(::X<int>::type& i, ::X<int>::type& j);
-}
    -
    - - -

    Proposed resolution:

    -

    Change "user-defined name" to "user-defined -type".

    - - -

    Rationale:

    -

    This terminology is used in section 2.5.2 and 4.1.1 of The C++ -Programming Language. It disallows the example in the issue, -since the underlying type itself is not user-defined. The only -possible problem I can see is for non-type templates, but there's no -possible way for a user to come up with a specialization for bitset, -for example, that might not have already been specialized by the -implementor?

    - -

    [Toronto: this may be related to issue 120.]

    - - -

    [post-Toronto: Judy provided the above proposed resolution and -rationale.]

    - - - - - - -
    -

    233. Insertion hints in associative containers

    -

    Section: 23.1.4 [associative.reqmts] Status: WP - Submitter: Andrew Koenig Date: 2000-04-30

    -

    View all other issues in [associative.reqmts].

    -

    View all issues with WP status.

    -

    Duplicate of: 192, 246

    -

    Discussion:

    -

    -If mm is a multimap and p is an iterator -into the multimap, then mm.insert(p, x) inserts -x into mm with p as a hint as -to where it should go. Table 69 claims that the execution time is -amortized constant if the insert winds up taking place adjacent to -p, but does not say when, if ever, this is guaranteed to -happen. All it says it that p is a hint as to where to -insert. -

    -

    -The question is whether there is any guarantee about the relationship -between p and the insertion point, and, if so, what it -is. -

    -

    -I believe the present state is that there is no guarantee: The user -can supply p, and the implementation is allowed to -disregard it entirely. -

    - -

    Additional comments from Nathan:
    - -The vote [in Redmond] was on whether to elaborately specify the use of -the hint, or to require behavior only if the value could be inserted -adjacent to the hint. I would like to ensure that we have a chance to -vote for a deterministic treatment: "before, if possible, otherwise -after, otherwise anywhere appropriate", as an alternative to the -proposed "before or after, if possible, otherwise [...]". -

    - -

    [Toronto: there was general agreement that this is a real defect: -when inserting an element x into a multiset that already contains -several copies of x, there is no way to know whether the hint will be -used. The proposed resolution was that the new element should always -be inserted as close to the hint as possible. So, for example, if -there is a subsequence of equivalent values, then providing a.begin() -as the hint means that the new element should be inserted before the -subsequence even if a.begin() is far away. JC van Winkel supplied -precise wording for this proposed resolution, and also for an -alternative resolution in which hints are only used when they are -adjacent to the insertion point.]

    - - -

    [Copenhagen: the LWG agreed to the original proposed resolution, -in which an insertion hint would be used even when it is far from the -insertion point. This was contingent on seeing a example -implementation showing that it is possible to implement this -requirement without loss of efficiency. John Potter provided such a -example implementation.]

    - - -

    [Redmond: The LWG was reluctant to adopt the proposal that -emerged from Copenhagen: it seemed excessively complicated, and went -beyond fixing the defect that we identified in Toronto. PJP provided -the new wording described in this issue. Nathan agrees that we -shouldn't adopt the more detailed semantics, and notes: "we know that -you can do it efficiently enough with a red-black tree, but there are -other (perhaps better) balanced tree techniques that might differ -enough to make the detailed semantics hard to satisfy."]

    - - -

    [Curaçao: Nathan should give us the alternative wording he -suggests so the LWG can decide between the two options.]

    - - -

    [Lillehammer: The LWG previously rejected the more detailed - semantics, because it seemed more loike a new feature than like - defect fixing. We're now more sympathetic to it, but we (especially - Bill) are still worried about performance. N1780 describes a naive - algorithm, but it's not clear whether there is a non-naive - implementation. Is it possible to implement this as efficently as - the current version of insert?]

    - - -

    [Post Lillehammer: -N1780 -updated in post meeting mailing with -feedback from Lillehammer with more information regarding performance. -]

    - - -

    [ -Batavia: -1780 -accepted with minor wording changes in the proposed wording (reflected in the -proposed resolution below). Concerns about the performance of the algorithm -were satisfactorily met by -1780. -371 already handles the stability of equal ranges -and so that part of the resolution from -1780 -is no longer needed (or reflected in the proposed wording below). -]

    - - - - -

    Proposed resolution:

    - -

    -Change the indicated rows of the "Associative container requirements" Table in -23.1.4 [associative.reqmts] to: -

    - -

    - - - - - - - - - - - - - -
    Associative container requirements
    expression return typeassertion/note
    pre/post-condition    		complexity
    a_eq.insert(t)iterator -inserts t and returns the iterator pointing to the newly inserted -element. If a range containing elements equivalent to t exists in -a_eq, t is inserted at the end of that range. - -logarithmic -
    a.insert(p,t)iterator -inserts t if and only if there is no element with key equivalent to the -key of t in containers with unique keys; always inserts t in containers -with equivalent keys. always returns the iterator pointing to the element with key -equivalent to the key of t. iterator p is a hint pointing to where -the insert should start to search. t is inserted as close as possible -to the position just prior to p. - -logarithmic in general, but amortized constant if t is inserted right after - before p. -
    -
    - - - - - - -
    -

    234. Typos in allocator definition

    -

    Section: 20.7.5.1 [allocator.members] Status: WP - Submitter: Dietmar Kühl Date: 2000-04-24

    -

    View all other issues in [allocator.members].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    In paragraphs 12 and 13 the effects of construct() and -destruct() are described as returns but the functions actually -return void.

    - - -

    Proposed resolution:

    -

    Substitute "Returns" by "Effect".

    - - - - -
    -

    235. No specification of default ctor for reverse_iterator

    -

    Section: 24.4.1.1 [reverse.iterator] Status: WP - Submitter: Dietmar Kühl Date: 2000-04-24

    -

    View all issues with WP status.

    -

    Discussion:

    -

    The declaration of reverse_iterator lists a default -constructor. However, no specification is given what this constructor -should do.

    - - -

    Proposed resolution:

    -

    In section 24.4.1.3.1 [reverse.iter.cons] add the following - paragraph:

    -
    -

    reverse_iterator()

    - -

    Default initializes current. Iterator operations - applied to the resulting iterator have defined behavior if and - only if the corresponding operations are defined on a default - constructed iterator of type Iterator.

    -
    -

    [pre-Copenhagen: Dietmar provide wording for proposed - resolution.]

    - - - - - - -
    -

    237. Undefined expression in complexity specification

    -

    Section: 23.2.2.1 [deque.cons] Status: WP - Submitter: Dietmar Kühl Date: 2000-04-24

    -

    View all other issues in [deque.cons].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    The complexity specification in paragraph 6 says that the complexity -is linear in first - last. Even if operator-() is -defined on iterators this term is in general undefined because it -would have to be last - first.

    - - -

    Proposed resolution:

    -

    Change paragraph 6 from

    -

    Linear in first - last.

    -

    to become

    -

    Linear in distance(first, last).

    - - - - -
    -

    238. Contradictory results of stringbuf initialization.

    -

    Section: 27.7.1.1 [stringbuf.cons] Status: WP - Submitter: Dietmar Kühl Date: 2000-05-11

    -

    View all issues with WP status.

    -

    Discussion:

    -

    In 27.7.1.1 paragraph 4 the results of calling the constructor of -'basic_stringbuf' are said to be str() == str. This is fine -that far but consider this code:

    - -
      std::basic_stringbuf<char> sbuf("hello, world", std::ios_base::openmode(0));
-  std::cout << "'" << sbuf.str() << "'\n";
-
    - -

    Paragraph 3 of 27.7.1.1 basically says that in this case neither -the output sequence nor the input sequence is initialized and -paragraph 2 of 27.7.1.2 basically says that str() either -returns the input or the output sequence. None of them is initialized, -ie. both are empty, in which case the return from str() is -defined to be basic_string<cT>().

    - -

    However, probably only test cases in some testsuites will detect this -"problem"...

    - - -

    Proposed resolution:

    -

    Remove 27.7.1.1 paragraph 4.

    - - -

    Rationale:

    -

    We could fix 27.7.1.1 paragraph 4, but there would be no point. If -we fixed it, it would say just the same thing as text that's already -in the standard.

    - - - - -
    -

    239. Complexity of unique() and/or unique_copy incorrect

    -

    Section: 25.2.9 [alg.unique] Status: WP - Submitter: Angelika Langer Date: 2000-05-15

    -

    View all other issues in [alg.unique].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    The complexity of unique and unique_copy are inconsistent with each -other and inconsistent with the implementations.  The standard -specifies:

    - -

    for unique():

    - -

    -3- Complexity: If the range (last - first) is not empty, exactly -(last - first) - 1 applications of the corresponding predicate, otherwise -no applications of the predicate.

    - -

    for unique_copy():

    - -

    -7- Complexity: Exactly last - first applications of the corresponding -predicate.

    - -

    -The implementations do it the other way round: unique() applies the -predicate last-first times and unique_copy() applies it last-first-1 -times.

    - -

    As both algorithms use the predicate for pair-wise comparison of -sequence elements I don't see a justification for unique_copy() -applying the predicate last-first times, especially since it is not -specified to which pair in the sequence the predicate is applied -twice.

    - - -

    Proposed resolution:

    -

    Change both complexity sections in 25.2.9 [alg.unique] to:

    - -

    Complexity: For nonempty ranges, exactly last - first - 1 -applications of the corresponding predicate.

    - - - - - - -
    -

    240. Complexity of adjacent_find() is meaningless

    -

    Section: 25.1.8 [alg.adjacent.find] Status: WP - Submitter: Angelika Langer Date: 2000-05-15

    -

    View all issues with WP status.

    -

    Discussion:

    -

    The complexity section of adjacent_find is defective:

    - -
    -
    template <class ForwardIterator>
-ForwardIterator adjacent_find(ForwardIterator first, ForwardIterator last
-                              BinaryPredicate pred);
-
    - -

    -1- Returns: The first iterator i such that both i and i + 1 are in -the range [first, last) for which the following corresponding -conditions hold: *i == *(i + 1), pred(*i, *(i + 1)) != false. Returns -last if no such iterator is found.

    - -

    -2- Complexity: Exactly find(first, last, value) - first applications -of the corresponding predicate. -

    -
    - -

    In the Complexity section, it is not defined what "value" -is supposed to mean. My best guess is that "value" means an -object for which one of the conditions pred(*i,value) or -pred(value,*i) is true, where i is the iterator defined in the Returns -section. However, the value type of the input sequence need not be -equality-comparable and for this reason the term find(first, last, -value) - first is meaningless.

    - -

    A term such as find_if(first, last, bind2nd(pred,*i)) - first or -find_if(first, last, bind1st(pred,*i)) - first might come closer to -the intended specification. Binders can only be applied to function -objects that have the function call operator declared const, which is -not required of predicates because they can have non-const data -members. For this reason, a specification using a binder could only be -an "as-if" specification.

    - - -

    Proposed resolution:

    -

    Change the complexity section in 25.1.8 [alg.adjacent.find] to:

    -

    -For a nonempty range, exactly min((i - first) + 1, -(last - first) - 1) applications of the -corresponding predicate, where i is adjacent_find's -return value. -

    - -

    [Copenhagen: the original resolution specified an upper -bound. The LWG preferred an exact count.]

    - - - - - - - -
    -

    241. Does unique_copy() require CopyConstructible and Assignable?

    -

    Section: 25.2.9 [alg.unique] Status: WP - Submitter: Angelika Langer Date: 2000-05-15

    -

    View all other issues in [alg.unique].

    -

    View all issues with WP status.

    -

    Discussion:

    - -

    Some popular implementations of unique_copy() create temporary -copies of values in the input sequence, at least if the input iterator -is a pointer. Such an implementation is built on the assumption that -the value type is CopyConstructible and Assignable.

    - -

    It is common practice in the standard that algorithms explicitly -specify any additional requirements that they impose on any of the -types used by the algorithm. An example of an algorithm that creates -temporary copies and correctly specifies the additional requirements -is accumulate(), 26.4.1 [rand.req].

    - -

    Since the specifications of unique() and unique_copy() do not -require CopyConstructible and Assignable of the InputIterator's value -type the above mentioned implementations are not standard-compliant. I -cannot judge whether this is a defect in the standard or a defect in -the implementations.

    - - -

    Proposed resolution:

    -

    In 25.2.8 change:

    - -

    --4- Requires: The ranges [first, last) and [result, result+(last-first)) -shall not overlap. -

    - -

    to:

    - -
    -

    -4- Requires: The ranges [first, last) and [result, - result+(last-first)) shall not overlap. The expression *result = - *first must be valid. If neither InputIterator nor OutputIterator - meets the requirements of forward iterator then the value type of - InputIterator must be copy constructible. Otherwise copy - constructible is not required.

    -
    - -

    [Redmond: the original proposed resolution didn't impose an -explicit requirement that the iterator's value type must be copy -constructible, on the grounds that an input iterator's value type must -always be copy constructible. Not everyone in the LWG thought that -this requirement was clear from table 72. It has been suggested that -it might be possible to implement unique_copy without -requiring assignability, although current implementations do impose -that requirement. Howard provided new wording.]

    - - -

    [ -Curaçao: The LWG changed the PR editorially to specify -"neither...nor...meet..." as clearer than -"both...and...do not meet...". Change believed to be so -minor as not to require re-review. -]

    - - - - - - - - -
    -

    242. Side effects of function objects

    -

    Section: 25.2.4 [alg.transform], 26.4 [rand] Status: WP - Submitter: Angelika Langer Date: 2000-05-15

    -

    View all other issues in [alg.transform].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    The algorithms transform(), accumulate(), inner_product(), -partial_sum(), and adjacent_difference() require that the function -object supplied to them shall not have any side effects.

    - -

    The standard defines a side effect in 1.9 [intro.execution] as:

    -

    -7- Accessing an object designated by a volatile lvalue (basic.lval), -modifying an object, calling a library I/O function, or calling a function -that does any of those operations are all side effects, which are changes -in the state of the execution environment.

    - -

    As a consequence, the function call operator of a function object supplied -to any of the algorithms listed above cannot modify data members, cannot -invoke any function that has a side effect, and cannot even create and -modify temporary objects.  It is difficult to imagine a function object -that is still useful under these severe limitations. For instance, any -non-trivial transformator supplied to transform() might involve creation -and modification of temporaries, which is prohibited according to the current -wording of the standard.

    - -

    On the other hand, popular implementations of these algorithms exhibit -uniform and predictable behavior when invoked with a side-effect-producing -function objects. It looks like the strong requirement is not needed for -efficient implementation of these algorithms.

    - -

    The requirement of  side-effect-free function objects could be -replaced by a more relaxed basic requirement (which would hold for all -function objects supplied to any algorithm in the standard library):

    -

    A function objects supplied to an algorithm shall not invalidate -any iterator or sequence that is used by the algorithm. Invalidation of -the sequence includes destruction of the sorting order if the algorithm -relies on the sorting order (see section 25.3 - Sorting and related operations -[lib.alg.sorting]).

    - -

    I can't judge whether it is intended that the function objects supplied -to transform(), accumulate(), inner_product(), partial_sum(), or adjacent_difference() -shall not modify sequence elements through dereferenced iterators.

    - -

    It is debatable whether this issue is a defect or a change request. -Since the consequences for user-supplied function objects are drastic and -limit the usefulness of the algorithms significantly I would consider it -a defect.

    - - -

    Proposed resolution:

    - -

    Things to notice about these changes:

    - -
      -
    1. The fully-closed ("[]" as opposed to half-closed "[)" ranges - are intentional. we want to prevent side-effects from - invalidating the end iterators.
      2. - -
    2. That has the unintentional side-effect of prohibiting - modification of the end element as a side-effect. This could - conceivably be significant in some cases.
      3. - -
    3. The wording also prevents side-effects from modifying elements - of the output sequence. I can't imagine why anyone would want - to do this, but it is arguably a restriction that implementors - don't need to place on users.
      4. - -
    4. Lifting the restrictions imposed in #2 and #3 above is possible - and simple, but would require more verbiage.
      5. -
    - -

    Change 25.2.3/2 from:

    - -

    - -2- Requires: op and binary_op shall not have any side effects. -

    - -

    to:

    - -

    - -2- Requires: in the ranges [first1, last1], [first2, first2 + - (last1 - first1)] and [result, result + (last1- first1)], op and - binary_op shall neither modify elements nor invalidate iterators or - subranges. - [Footnote: The use of fully closed ranges is intentional --end footnote] -

    - - -

    Change 25.2.3/2 from:

    - -

    - -2- Requires: op and binary_op shall not have any side effects. -

    - -

    to:

    - -

    - -2- Requires: op and binary_op shall not invalidate iterators or - subranges, or modify elements in the ranges [first1, last1], - [first2, first2 + (last1 - first1)], and [result, result + (last1 - - first1)]. - [Footnote: The use of fully closed ranges is intentional --end footnote] -

    - - -

    Change 26.4.1/2 from:

    - -

    - -2- Requires: T must meet the requirements of CopyConstructible - (lib.copyconstructible) and Assignable (lib.container.requirements) - types. binary_op shall not cause side effects. -

    - -

    to:

    - -

    - -2- Requires: T must meet the requirements of CopyConstructible - (lib.copyconstructible) and Assignable - (lib.container.requirements) types. In the range [first, last], - binary_op shall neither modify elements nor invalidate iterators - or subranges. - [Footnote: The use of a fully closed range is intentional --end footnote] -

    - -

    Change 26.4.2/2 from:

    - -

    - -2- Requires: T must meet the requirements of CopyConstructible - (lib.copyconstructible) and Assignable (lib.container.requirements) - types. binary_op1 and binary_op2 shall not cause side effects. -

    - -

    to:

    - -

    - -2- Requires: T must meet the requirements of CopyConstructible - (lib.copyconstructible) and Assignable (lib.container.requirements) - types. In the ranges [first, last] and [first2, first2 + (last - - first)], binary_op1 and binary_op2 shall neither modify elements - nor invalidate iterators or subranges. - [Footnote: The use of fully closed ranges is intentional --end footnote] -

    - - -

    Change 26.4.3/4 from:

    - -

    - -4- Requires: binary_op is expected not to have any side effects. -

    - -

    to:

    - -

    - -4- Requires: In the ranges [first, last] and [result, result + - (last - first)], binary_op shall neither modify elements nor - invalidate iterators or subranges. - [Footnote: The use of fully closed ranges is intentional --end footnote] -

    - -

    Change 26.4.4/2 from:

    - -

    - -2- Requires: binary_op shall not have any side effects. -

    - -

    to:

    - -

    - -2- Requires: In the ranges [first, last] and [result, result + - (last - first)], binary_op shall neither modify elements nor - invalidate iterators or subranges. - [Footnote: The use of fully closed ranges is intentional --end footnote] -

    - -

    [Toronto: Dave Abrahams supplied wording.]

    - - -

    [Copenhagen: Proposed resolution was modified slightly. Matt -added footnotes pointing out that the use of closed ranges was -intentional.]

    - - - - - - - -
    -

    243. get and getline when sentry reports failure

    -

    Section: 27.6.1.3 [istream.unformatted] Status: WP - Submitter: Martin Sebor Date: 2000-05-15

    -

    View all other issues in [istream.unformatted].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    basic_istream<>::get(), and basic_istream<>::getline(), -are unclear with respect to the behavior and side-effects of the named -functions in case of an error.

    - -

    27.6.1.3, p1 states that "... If the sentry object returns -true, when converted to a value of type bool, the function endeavors -to obtain the requested input..." It is not clear from this (or -the rest of the paragraph) what precisely the behavior should be when -the sentry ctor exits by throwing an exception or when the sentry -object returns false. In particular, what is the number of characters -extracted that gcount() returns supposed to be?

    - -

    27.6.1.3 p8 and p19 say about the effects of get() and getline(): -"... In any case, it then stores a null character (using -charT()) into the next successive location of the array." Is not -clear whether this sentence applies if either of the conditions above -holds (i.e., when sentry fails).

    - - -

    Proposed resolution:

    -

    Add to 27.6.1.3, p1 after the sentence

    - -

    -"... If the sentry object returns true, when converted to a value of -type bool, the function endeavors to obtain the requested input." -

    - -

    the following

    - - -

    -"Otherwise, if the sentry constructor exits by throwing an exception or -if the sentry object returns false, when converted to a value of type -bool, the function returns without attempting to obtain any input. In -either case the number of extracted characters is set to 0; unformatted -input functions taking a character array of non-zero size as an argument -shall also store a null character (using charT()) in the first location -of the array." -

    - - -

    Rationale:

    -

    Although the general philosophy of the input functions is that the -argument should not be modified upon failure, getline -historically added a terminating null unconditionally. Most -implementations still do that. Earlier versions of the draft standard -had language that made this an unambiguous requirement; those words -were moved to a place where their context made them less clear. See -Jerry Schwarz's message c++std-lib-7618.

    - - - - -
    -

    247. vector, deque::insert complexity

    -

    Section: 23.2.6.4 [vector.modifiers] Status: WP - Submitter: Lisa Lippincott Date: 2000-06-06

    -

    View all other issues in [vector.modifiers].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    Paragraph 2 of 23.2.6.4 [vector.modifiers] describes the complexity -of vector::insert:

    - -

    - Complexity: If first and last are forward iterators, bidirectional - iterators, or random access iterators, the complexity is linear in - the number of elements in the range [first, last) plus the distance - to the end of the vector. If they are input iterators, the complexity - is proportional to the number of elements in the range [first, last) - times the distance to the end of the vector. -

    - -

    First, this fails to address the non-iterator forms of -insert.

    - -

    Second, the complexity for input iterators misses an edge case -- -it requires that an arbitrary number of elements can be added at -the end of a vector in constant time.

    - -

    I looked to see if deque had a similar problem, and was -surprised to find that deque places no requirement on the -complexity of inserting multiple elements (23.2.2.3 [deque.modifiers], -paragraph 3):

    - -

    - Complexity: In the worst case, inserting a single element into a - deque takes time linear in the minimum of the distance from the - insertion point to the beginning of the deque and the distance - from the insertion point to the end of the deque. Inserting a - single element either at the beginning or end of a deque always - takes constant time and causes a single call to the copy constructor - of T. -

    - - -

    Proposed resolution:

    - -

    Change Paragraph 2 of 23.2.6.4 [vector.modifiers] to

    -

    - Complexity: The complexity is linear in the number of elements - inserted plus the distance to the end of the vector. -

    - -

    [For input iterators, one may achieve this complexity by first - inserting at the end of the vector, and then using - rotate.]

    - - -

    Change 23.2.2.3 [deque.modifiers], paragraph 3, to:

    - -

    - Complexity: The complexity is linear in the number of elements - inserted plus the shorter of the distances to the beginning and - end of the deque. Inserting a single element at either the - beginning or the end of a deque causes a single call to the copy - constructor of T. -

    - - - -

    Rationale:

    -

    This is a real defect, and proposed resolution fixes it: some - complexities aren't specified that should be. This proposed - resolution does constrain deque implementations (it rules out the - most naive possible implementations), but the LWG doesn't see a - reason to permit that implementation.

    - - - - - -
    -

    248. time_get fails to set eofbit

    -

    Section: 22.2.5 [category.time] Status: WP - Submitter: Martin Sebor Date: 2000-06-22

    -

    View all issues with WP status.

    -

    Discussion:

    -

    There is no requirement that any of time_get member functions set -ios::eofbit when they reach the end iterator while parsing their input. -Since members of both the num_get and money_get facets are required to -do so (22.2.2.1.2, and 22.2.6.1.2, respectively), time_get members -should follow the same requirement for consistency.

    - - -

    Proposed resolution:

    -

    Add paragraph 2 to section 22.2.5.1 with the following text:

    - -

    -If the end iterator is reached during parsing by any of the get() -member functions, the member sets ios_base::eofbit in err. -

    - - -

    Rationale:

    -

    Two alternative resolutions were proposed. The LWG chose this one -because it was more consistent with the way eof is described for other -input facets.

    - - - - -
    -

    250. splicing invalidates iterators

    -

    Section: 23.2.4.4 [list.ops] Status: WP - Submitter: Brian Parker Date: 2000-07-14

    -

    View all other issues in [list.ops].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -Section 23.2.4.4 [list.ops] states that -

    -
      void splice(iterator position, list<T, Allocator>& x);
-
    -

    -invalidates all iterators and references to list x. -

    - -

    -This is unnecessary and defeats an important feature of splice. In -fact, the SGI STL guarantees that iterators to x remain valid -after splice. -

    - - -

    Proposed resolution:

    - -

    Add a footnote to 23.2.4.4 [list.ops], paragraph 1:

    -

    -[Footnote: As specified in [default.con.req], paragraphs -4-5, the semantics described in this clause applies only to the case -where allocators compare equal. --end footnote] -

    - -

    In 23.2.4.4 [list.ops], replace paragraph 4 with:

    -

    -Effects: Inserts the contents of x before position and x becomes -empty. Pointers and references to the moved elements of x now refer to -those same elements but as members of *this. Iterators referring to the -moved elements will continue to refer to their elements, but they now -behave as iterators into *this, not into x. -

    - -

    In 23.2.4.4 [list.ops], replace paragraph 7 with:

    -

    -Effects: Inserts an element pointed to by i from list x before -position and removes the element from x. The result is unchanged if -position == i or position == ++i. Pointers and references to *i continue -to refer to this same element but as a member of *this. Iterators to *i -(including i itself) continue to refer to the same element, but now -behave as iterators into *this, not into x. -

    - -

    In 23.2.4.4 [list.ops], replace paragraph 12 with:

    -

    -Requires: [first, last) is a valid range in x. The result is -undefined if position is an iterator in the range [first, last). -Pointers and references to the moved elements of x now refer to those -same elements but as members of *this. Iterators referring to the moved -elements will continue to refer to their elements, but they now behave as -iterators into *this, not into x. -

    - -

    [pre-Copenhagen: Howard provided wording.]

    - - - -

    Rationale:

    -

    The original proposed resolution said that iterators and references -would remain "valid". The new proposed resolution clarifies what that -means. Note that this only applies to the case of equal allocators. -From [default.con.req] paragraph 4, the behavior of list when -allocators compare nonequal is outside the scope of the standard.

    - - - - -
    -

    251. basic_stringbuf missing allocator_type

    -

    Section: 27.7.1 [stringbuf] Status: WP - Submitter: Martin Sebor Date: 2000-07-28

    -

    View all issues with WP status.

    -

    Discussion:

    -

    The synopsis for the template class basic_stringbuf -doesn't list a typedef for the template parameter -Allocator. This makes it impossible to determine the type of -the allocator at compile time. It's also inconsistent with all other -template classes in the library that do provide a typedef for the -Allocator parameter.

    - - -

    Proposed resolution:

    -

    Add to the synopses of the class templates basic_stringbuf (27.7.1), -basic_istringstream (27.7.2), basic_ostringstream (27.7.3), and -basic_stringstream (27.7.4) the typedef:

    -
      typedef Allocator allocator_type;
-
    - - - - -
    -

    252. missing casts/C-style casts used in iostreams

    -

    Section: 27.7 [string.streams] Status: WP - Submitter: Martin Sebor Date: 2000-07-28

    -

    View all other issues in [string.streams].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    27.7.2.2, p1 uses a C-style cast rather than the more appropriate -const_cast<> in the Returns clause for basic_istringstream<>::rdbuf(). -The same C-style cast is being used in 27.7.3.2, p1, D.7.2.2, p1, and -D.7.3.2, p1, and perhaps elsewhere. 27.7.6, p1 and D.7.2.2, p1 are missing -the cast altogether.

    - -

    C-style casts have not been deprecated, so the first part of this -issue is stylistic rather than a matter of correctness.

    - - -

    Proposed resolution:

    -

    In 27.7.2.2, p1 replace

    -
      -1- Returns: (basic_stringbuf<charT,traits,Allocator>*)&sb.
    - -

    with

    -
      -1- Returns: const_cast<basic_stringbuf<charT,traits,Allocator>*>(&sb).
    - - -

    In 27.7.3.2, p1 replace

    -
      -1- Returns: (basic_stringbuf<charT,traits,Allocator>*)&sb.
    - -

    with

    -
      -1- Returns: const_cast<basic_stringbuf<charT,traits,Allocator>*>(&sb).
    - -

    In 27.7.6, p1, replace

    -
      -1- Returns: &sb
    - -

    with

    -
      -1- Returns: const_cast<basic_stringbuf<charT,traits,Allocator>*>(&sb).
    - -

    In D.7.2.2, p1 replace

    -
      -2- Returns: &sb.
    - -

    with

    -
      -2- Returns: const_cast<strstreambuf*>(&sb).
    - - - - -
    -

    253. valarray helper functions are almost entirely useless

    -

    Section: 26.5.2.1 [valarray.cons], 26.5.2.2 [valarray.assign] Status: WP - Submitter: Robert Klarer Date: 2000-07-31

    -

    View other active issues in [valarray.cons].

    -

    View all other issues in [valarray.cons].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    This discussion is adapted from message c++std-lib-7056 posted -November 11, 1999. I don't think that anyone can reasonably claim -that the problem described below is NAD.

    - -

    These valarray constructors can never be called:

    - -
       template <class T>
-         valarray<T>::valarray(const slice_array<T> &);
-   template <class T>
-         valarray<T>::valarray(const gslice_array<T> &);
-   template <class T>
-         valarray<T>::valarray(const mask_array<T> &);
-   template <class T>
-         valarray<T>::valarray(const indirect_array<T> &);
-
    - -

    Similarly, these valarray assignment operators cannot be -called:

    - -
         template <class T>
-     valarray<T> valarray<T>::operator=(const slice_array<T> &);
-     template <class T>
-     valarray<T> valarray<T>::operator=(const gslice_array<T> &);
-     template <class T>
-     valarray<T> valarray<T>::operator=(const mask_array<T> &);
-     template <class T>
-     valarray<T> valarray<T>::operator=(const indirect_array<T> &);
-
    - -

    Please consider the following example:

    - -
       #include <valarray>
-   using namespace std;
-
-   int main()
-   {
-       valarray<double> va1(12);
-       valarray<double> va2(va1[slice(1,4,3)]); // line 1
-   }
-
    - - -

    Since the valarray va1 is non-const, the result of the sub-expression -va1[slice(1,4,3)] at line 1 is an rvalue of type const -std::slice_array<double>. This slice_array rvalue is then used to -construct va2. The constructor that is used to construct va2 is -declared like this:

    - -
         template <class T>
-     valarray<T>::valarray(const slice_array<T> &);
-
    - -

    Notice the constructor's const reference parameter. When the -constructor is called, a slice_array must be bound to this reference. -The rules for binding an rvalue to a const reference are in 8.5.3, -paragraph 5 (see also 13.3.3.1.4). Specifically, paragraph 5 -indicates that a second slice_array rvalue is constructed (in this -case copy-constructed) from the first one; it is this second rvalue -that is bound to the reference parameter. Paragraph 5 also requires -that the constructor that is used for this purpose be callable, -regardless of whether the second rvalue is elided. The -copy-constructor in this case is not callable, however, because it is -private. Therefore, the compiler should report an error.

    - -

    Since slice_arrays are always rvalues, the valarray constructor that has a -parameter of type const slice_array<T> & can never be called. The -same reasoning applies to the three other constructors and the four -assignment operators that are listed at the beginning of this post. -Furthermore, since these functions cannot be called, the valarray helper -classes are almost entirely useless.

    - - -

    Proposed resolution:

    -

    slice_array:

    -
      -
    • Make the copy constructor and copy-assignment operator declarations - public in the slice_array class template definition in 26.5.5 [template.slice.array]
      • -
    • remove paragraph 3 of 26.5.5 [template.slice.array]
      • -
    • remove the copy constructor declaration from [cons.slice.arr]
      • -
    • change paragraph 1 of [cons.slice.arr] to read "This constructor is declared - to be private. This constructor need not be defined."
      • -
    • remove the first sentence of paragraph 1 of 26.5.5.1 [slice.arr.assign]
      • -
    • Change the first three words of the second sentence of paragraph 1 of - 26.5.5.1 [slice.arr.assign] to "These assignment operators have"
      • -
    - -

    gslice_array:

    -
      -
    • Make the copy constructor and copy-assignment operator declarations - public in the gslice_array class template definition in 26.5.7 [template.gslice.array]
      • -
    • remove the note in paragraph 3 of 26.5.7 [template.gslice.array]
      • -
    • remove the copy constructor declaration from [gslice.array.cons]
      • -
    • change paragraph 1 of [gslice.array.cons] to read "This constructor is declared - to be private. This constructor need not be defined."
      • -
    • remove the first sentence of paragraph 1 of 26.5.7.1 [gslice.array.assign]
      • -
    • Change the first three words of the second sentence of paragraph 1 of - 26.5.7.1 [gslice.array.assign] to "These assignment operators have"
      • -
    - -

    mask_array:

    -
      -
    • Make the copy constructor and copy-assignment operator declarations - public in the mask_array class template definition in 26.5.8 [template.mask.array]
      • -
    • remove the note in paragraph 2 of 26.5.8 [template.mask.array]
      • -
    • remove the copy constructor declaration from [mask.array.cons]
      • -
    • change paragraph 1 of [mask.array.cons] to read "This constructor is declared - to be private. This constructor need not be defined."
      • -
    • remove the first sentence of paragraph 1 of 26.5.8.1 [mask.array.assign]
      • -
    • Change the first three words of the second sentence of paragraph 1 of - 26.5.8.1 [mask.array.assign] to "These assignment operators have"
      • -
    - -

    indirect_array:

    -
      -
    • Make the copy constructor and copy-assignment operator declarations - public in the indirect_array class definition in 26.5.9 [template.indirect.array]
      • -
    • remove the note in paragraph 2 of 26.5.9 [template.indirect.array]
      • -
    • remove the copy constructor declaration from [indirect.array.cons]
      • -
    • change the descriptive text in [indirect.array.cons] to read "This constructor is - declared to be private. This constructor need not be defined."
      • -
    • remove the first sentence of paragraph 1 of 26.5.9.1 [indirect.array.assign]
      • -
    • Change the first three words of the second sentence of paragraph 1 of - 26.5.9.1 [indirect.array.assign] to "These assignment operators have"
      • -
    -

    [Proposed resolution was modified in Santa Cruz: explicitly make -copy constructor and copy assignment operators public, instead of -removing them.]

    - - - -

    Rationale:

    -

    Keeping the valarray constructors private is untenable. Merely -making valarray a friend of the helper classes isn't good enough, -because access to the copy constructor is checked in the user's -environment.

    - -

    Making the assignment operator public is not strictly necessary to -solve this problem. A majority of the LWG (straw poll: 13-4) -believed we should make the assignment operators public, in addition -to the copy constructors, for reasons of symmetry and user -expectation.

    - - - - - -
    -

    254. Exception types in clause 19 are constructed from std::string

    -

    Section: 19.1 [std.exceptions], 27.4.2.1.1 [ios::failure] Status: WP - Submitter: Dave Abrahams Date: 2000-08-01

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -Many of the standard exception types which implementations are -required to throw are constructed with a const std::string& -parameter. For example: -

    - -
         19.1.5  Class out_of_range                          [lib.out.of.range]
-     namespace std {
-       class out_of_range : public logic_error {
-       public:
-         explicit out_of_range(const string& what_arg);
-       };
-     }
-
-   1 The class out_of_range defines the type of objects  thrown  as  excep-
-     tions to report an argument value not in its expected range.
-
-     out_of_range(const string& what_arg);
-
-     Effects:
-       Constructs an object of class out_of_range.
-     Postcondition:
-       strcmp(what(), what_arg.c_str()) == 0.
-
    - -

    -There are at least two problems with this: -

    -
      -
    1. A program which is low on memory may end up throwing -std::bad_alloc instead of out_of_range because memory runs out while -constructing the exception object.
      2. -
    2. An obvious implementation which stores a std::string data member -may end up invoking terminate() during exception unwinding because the -exception object allocates memory (or rather fails to) as it is being -copied.
      3. -
    - -

    -There may be no cure for (1) other than changing the interface to -out_of_range, though one could reasonably argue that (1) is not a -defect. Personally I don't care that much if out-of-memory is reported -when I only have 20 bytes left, in the case when out_of_range would -have been reported. People who use exception-specifications might care -a lot, though. -

    - -

    -There is a cure for (2), but it isn't completely obvious. I think a -note for implementors should be made in the standard. Avoiding -possible termination in this case shouldn't be left up to chance. The -cure is to use a reference-counted "string" implementation -in the exception object. I am not necessarily referring to a -std::string here; any simple reference-counting scheme for a NTBS -would do. -

    - -

    Further discussion, in email:

    - -

    -...I'm not so concerned about (1). After all, a library implementation -can add const char* constructors as an extension, and users don't -need to avail themselves of the standard exceptions, though this is -a lame position to be forced into. FWIW, std::exception and -std::bad_alloc don't require a temporary basic_string. -

    - -

    -...I don't think the fixed-size buffer is a solution to the problem, -strictly speaking, because you can't satisfy the postcondition -
    -   strcmp(what(), what_arg.c_str()) == 0 -
    -For all values of what_arg (i.e. very long values). That means that -the only truly conforming solution requires a dynamic allocation. -

    - -

    Further discussion, from Redmond:

    - -

    The most important progress we made at the Redmond meeting was -realizing that there are two separable issues here: the const -string& constructor, and the copy constructor. If a user writes -something like throw std::out_of_range("foo"), the const -string& constructor is invoked before anything gets thrown. The -copy constructor is potentially invoked during stack unwinding.

    - -

    The copy constructor is a more serious problem, becuase failure -during stack unwinding invokes terminate. The copy -constructor must be nothrow. Curaçao: Howard thinks this -requirement may already be present.

    - -

    The fundamental problem is that it's difficult to get the nothrow -requirement to work well with the requirement that the exception -objects store a string of unbounded size, particularly if you also try -to make the const string& constructor nothrow. Options discussed -include:

    - -
      -
    • Limit the size of a string that exception objects are required to -throw: change the postconditions of 19.1.2 [domain.error] paragraph 3 -and 19.1.6 [runtime.error] paragraph 3 to something like this: -"strncmp(what(), what_arg._str(), N) == 0, where N is an -implementation defined constant no smaller than 256".
      • -
    • Allow the const string& constructor to throw, but not the -copy constructor. It's the implementor's responsibility to get it -right. (An implementor might use a simple refcount class.)
      • -
    • Compromise between the two: an implementation is not allowed to -throw if the string's length is less than some N, but, if it doesn't -throw, the string must compare equal to the argument.
      • -
    • Add a new constructor that takes a const char*
      • -
    - -

    (Not all of these options are mutually exclusive.)

    - - - -

    Proposed resolution:

    - -

    -Change 19.1.1 [logic.error] -

    - -
    -
    namespace std {
-  class logic_error : public exception {
-  public:
-    explicit logic_error(const string& what_arg);
-    explicit logic_error(const char* what_arg);
-  };
-}
-
    -

    ...

    -

    -logic_error(const char* what_arg); -

    -
    -

    --4- Effects: Constructs an object of class logic_error. -

    -

    --5- Postcondition: strcmp(what(), what_arg) == 0. -

    -
    - -
    - -

    -Change 19.1.2 [domain.error] -

    - -
    -
    namespace std {
-  class domain_error : public logic_error {
-  public:
-    explicit domain_error(const string& what_arg);
-    explicit domain_error(const char* what_arg);
-  };
-}
-
    -

    ...

    -

    -domain_error(const char* what_arg); -

    -
    -

    --4- Effects: Constructs an object of class domain_error. -

    -

    --5- Postcondition: strcmp(what(), what_arg) == 0. -

    - -
    -
    - -

    -Change 19.1.3 [invalid.argument] -

    - -
    -
    namespace std {
-  class invalid_argument : public logic_error {
-  public:
-    explicit invalid_argument(const string& what_arg);
-    explicit invalid_argument(const char* what_arg);
-  };
-}
-
    -

    ...

    -

    -invalid_argument(const char* what_arg); -

    -
    -

    --4- Effects: Constructs an object of class invalid_argument. -

    -

    --5- Postcondition: strcmp(what(), what_arg) == 0. -

    -
    - -
    - -

    -Change 19.1.4 [length.error] -

    - -
    -
    namespace std {
-  class length_error : public logic_error {
-  public:
-    explicit length_error(const string& what_arg);
-    explicit length_error(const char* what_arg);
-  };
-}
-
    -

    ...

    -

    -length_error(const char* what_arg); -

    -
    -

    --4- Effects: Constructs an object of class length_error. -

    -

    --5- Postcondition: strcmp(what(), what_arg) == 0. -

    -
    - -
    - -

    -Change 19.1.5 [out.of.range] -

    - -
    -
    namespace std {
-  class out_of_range : public logic_error {
-  public:
-    explicit out_of_range(const string& what_arg);
-    explicit out_of_range(const char* what_arg);
-  };
-}
-
    -

    ...

    -

    -out_of_range(const char* what_arg); -

    -
    -

    --4- Effects: Constructs an object of class out_of_range. -

    -

    --5- Postcondition: strcmp(what(), what_arg) == 0. -

    -
    - -
    - -

    -Change 19.1.6 [runtime.error] -

    - -
    -
    namespace std {
-  class runtime_error : public exception {
-  public:
-    explicit runtime_error(const string& what_arg);
-    explicit runtime_error(const char* what_arg);
-  };
-}
-
    -

    ...

    -

    -runtime_error(const char* what_arg); -

    -
    -

    --4- Effects: Constructs an object of class runtime_error. -

    -

    --5- Postcondition: strcmp(what(), what_arg) == 0. -

    -
    - -
    - -

    -Change 19.1.7 [range.error] -

    - -
    -
    namespace std {
-  class range_error : public runtime_error {
-  public:
-    explicit range_error(const string& what_arg);
-    explicit range_error(const char* what_arg);
-  };
-}
-
    -

    ...

    -

    -range_error(const char* what_arg); -

    -
    -

    --4- Effects: Constructs an object of class range_error. -

    -

    --5- Postcondition: strcmp(what(), what_arg) == 0. -

    -
    - -
    - -

    -Change 19.1.8 [overflow.error] -

    - -
    -
    namespace std {
-  class overflow_error : public runtime_error {
-  public:
-    explicit overflow_error(const string& what_arg);
-    explicit overflow_error(const char* what_arg);
-  };
-}
-
    -

    ...

    -

    -overflow_error(const char* what_arg); -

    -
    -

    --4- Effects: Constructs an object of class overflow_error. -

    -

    --5- Postcondition: strcmp(what(), what_arg) == 0. -

    -
    - -
    - -

    -Change 19.1.9 [underflow.error] -

    - -
    -
    namespace std {
-  class underflow_error : public runtime_error {
-  public:
-    explicit underflow_error(const string& what_arg);
-    explicit underflow_error(const char* what_arg);
-  };
-}
-
    -

    ...

    -

    -underflow_error(const char* what_arg); -

    -
    -

    --4- Effects: Constructs an object of class underflow_error. -

    -

    --5- Postcondition: strcmp(what(), what_arg) == 0. -

    -
    - -
    - -

    -Change 27.4.2.1.1 [ios::failure] -

    - -
    -
    namespace std {
-  class ios_base::failure : public exception {
-  public:
-    explicit failure(const string& msg);
-    explicit failure(const char* msg);
-    virtual const char* what() const throw();
-};
-}
-
    -

    ...

    -

    -failure(const char* msg); -

    -
    -

    --4- Effects: Constructs an object of class failure. -

    -

    --5- Postcondition: strcmp(what(), msg) == 0. -

    -
    - -
    - - - -

    Rationale:

    - -

    Throwing a bad_alloc while trying to construct a message for another -exception-derived class is not necessarily a bad thing. And the -bad_alloc constructor already has a no throw spec on it (18.4.2.1).

    - -

    Future:

    - -

    All involved would like to see const char* constructors added, but -this should probably be done for C++0X as opposed to a DR.

    - -

    I believe the no throw specs currently decorating these functions -could be improved by some kind of static no throw spec checking -mechanism (in a future C++ language). As they stand, the copy -constructors might fail via a call to unexpected. I think what is -intended here is that the copy constructors can't fail.

    - -

    [Pre-Sydney: reopened at the request of Howard Hinnant. - Post-Redmond: James Kanze noticed that the copy constructors of - exception-derived classes do not have nothrow clauses. Those - classes have no copy constructors declared, meaning the - compiler-generated implicit copy constructors are used, and those - compiler-generated constructors might in principle throw anything.]

    - - -

    [ -Batavia: Merged copy constructor and assignment operator spec into exception -and added ios::failure into the proposed resolution. -]

    - - -

    [ -Oxford: The proposed resolution simply addresses the issue of constructing -the exception objects with const char* and string literals without -the need to explicit include or construct a std::string. -]

    - - - - - - - -
    -

    256. typo in 27.4.4.2, p17: copy_event does not exist

    -

    Section: 27.4.4.2 [basic.ios.members] Status: WP - Submitter: Martin Sebor Date: 2000-08-21

    -

    View other active issues in [basic.ios.members].

    -

    View all other issues in [basic.ios.members].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -27.4.4.2, p17 says -

    - -

    --17- Before copying any parts of rhs, calls each registered callback -pair (fn,index) as (*fn)(erase_event,*this,index). After all parts but -exceptions() have been replaced, calls each callback pair that was -copied from rhs as (*fn)(copy_event,*this,index). -

    - -

    -The name copy_event isn't defined anywhere. The intended name was -copyfmt_event. -

    - - -

    Proposed resolution:

    -

    Replace copy_event with copyfmt_event in the named paragraph.

    - - - - -
    -

    258. Missing allocator requirement

    -

    Section: 20.1.2 [allocator.requirements] Status: WP - Submitter: Matt Austern Date: 2000-08-22

    -

    View other active issues in [allocator.requirements].

    -

    View all other issues in [allocator.requirements].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -From lib-7752: -

    - -

    -I've been assuming (and probably everyone else has been assuming) that -allocator instances have a particular property, and I don't think that -property can be deduced from anything in Table 32. -

    - -

    -I think we have to assume that allocator type conversion is a -homomorphism. That is, if x1 and x2 are of type X, where -X::value_type is T, and if type Y is X::template -rebind<U>::other, then Y(x1) == Y(x2) if and only if x1 == x2. -

    - -

    -Further discussion: Howard Hinnant writes, in lib-7757: -

    - -

    -I think I can prove that this is not provable by Table 32. And I agree -it needs to be true except for the "and only if". If x1 != x2, I see no -reason why it can't be true that Y(x1) == Y(x2). Admittedly I can't -think of a practical instance where this would happen, or be valuable. -But I also don't see a need to add that extra restriction. I think we -only need: -

    - -

    - if (x1 == x2) then Y(x1) == Y(x2) -

    - -

    -If we decide that == on allocators is transitive, then I think I can -prove the above. But I don't think == is necessarily transitive on -allocators. That is: -

    - -

    -Given x1 == x2 and x2 == x3, this does not mean x1 == x3. -

    - -

    Example:

    - -
    -

    -x1 can deallocate pointers from: x1, x2, x3
    -x2 can deallocate pointers from: x1, x2, x4
    -x3 can deallocate pointers from: x1, x3
    -x4 can deallocate pointers from: x2, x4 -

    - -

    -x1 == x2, and x2 == x4, but x1 != x4 -

    -
    -

    [Toronto: LWG members offered multiple opinions. One -opinion is that it should not be required that x1 == x2 -implies Y(x1) == Y(x2), and that it should not even be -required that X(x1) == x1. Another opinion is that -the second line from the bottom in table 32 already implies the -desired property. This issue should be considered in light of -other issues related to allocator instances.]

    - - - -

    Proposed resolution:

    -

    -Accept proposed wording from -N2436 part 3. -

    - - -

    [Lillehammer: Same conclusion as before: this should be - considered as part of an allocator redesign, not solved on its own.]

    - - -

    [ -Batavia: An allocator redesign is not forthcoming and thus we fixed this one issue. -]

    - - -

    [ -Toronto: Reopened at the request of the project editor (Pete) because the proposed -wording did not fit within the indicated table. The intent of the resolution remains -unchanged. Pablo to work with Pete on improved wording. -]

    - - -

    [ -Kona (2007): The LWG adopted the proposed resolution of N2387 for this issue which -was subsequently split out into a separate paper N2436 for the purposes of voting. -The resolution in N2436 addresses this issue. The LWG voted to accelerate this -issue to Ready status to be voted into the WP at Kona. -]

    - - - - - -
    -

    259. basic_string::operator[] and const correctness

    -

    Section: 21.3.4 [string.capacity] Status: WP - Submitter: Chris Newton Date: 2000-08-27

    -

    View all other issues in [string.capacity].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -Paraphrased from a message that Chris Newton posted to comp.std.c++: -

    - -

    -The standard's description of basic_string<>::operator[] -seems to violate const correctness. -

    - -

    -The standard (21.3.4/1) says that "If pos < size(), -returns data()[pos]." The types don't work. The -return value of data() is const charT*, but -operator[] has a non-const version whose return type is reference. -

    - - -

    Proposed resolution:

    -

    -In section 21.3.4, paragraph 1, change -"data()[pos]" to "*(begin() + -pos)". -

    - - - - -
    -

    260. Inconsistent return type of istream_iterator::operator++(int)

    -

    Section: 24.5.1.2 [istream.iterator.ops] Status: WP - Submitter: Martin Sebor Date: 2000-08-27

    -

    View all other issues in [istream.iterator.ops].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    The synopsis of istream_iterator::operator++(int) in 24.5.1 shows -it as returning the iterator by value. 24.5.1.2, p5 shows the same -operator as returning the iterator by reference. That's incorrect -given the Effects clause below (since a temporary is returned). The -`&' is probably just a typo.

    - - -

    Proposed resolution:

    -

    Change the declaration in 24.5.1.2, p5 from

    - 
     istream_iterator<T,charT,traits,Distance>& operator++(int);
-
    -

    to

    - 
     istream_iterator<T,charT,traits,Distance> operator++(int);
-
    -

    (that is, remove the `&').

    - - - - -
    -

    261. Missing description of istream_iterator::operator!=

    -

    Section: 24.5.1.2 [istream.iterator.ops] Status: WP - Submitter: Martin Sebor Date: 2000-08-27

    -

    View all other issues in [istream.iterator.ops].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -24.5.1, p3 lists the synopsis for -

    - -
       template <class T, class charT, class traits, class Distance>
-        bool operator!=(const istream_iterator<T,charT,traits,Distance>& x,
-                        const istream_iterator<T,charT,traits,Distance>& y);
-
    - -

    -but there is no description of what the operator does (i.e., no Effects -or Returns clause) in 24.5.1.2. -

    - - -

    Proposed resolution:

    -

    -Add paragraph 7 to the end of section 24.5.1.2 with the following text: -

    - -
       template <class T, class charT, class traits, class Distance>
-        bool operator!=(const istream_iterator<T,charT,traits,Distance>& x,
-                        const istream_iterator<T,charT,traits,Distance>& y);
-
    - -

    -7- Returns: !(x == y).

    - - - - -
    -

    262. Bitmask operator ~ specified incorrectly

    -

    Section: 17.3.2.1.2 [bitmask.types] Status: WP - Submitter: Beman Dawes Date: 2000-09-03

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -The ~ operation should be applied after the cast to int_type. -

    - - -

    Proposed resolution:

    -

    -Change 17.3.2.1.2 [lib.bitmask.types] operator~ from: -

    - -
       bitmask operator~ ( bitmask X )
-     { return static_cast< bitmask>(static_cast<int_type>(~ X)); }
-
    - -

    -to: -

    - -
       bitmask operator~ ( bitmask X )
-     { return static_cast< bitmask>(~static_cast<int_type>(X)); }
-
    - - - - -
    -

    263. Severe restriction on basic_string reference counting

    -

    Section: 21.3 [basic.string] Status: WP - Submitter: Kevlin Henney Date: 2000-09-04

    -

    View other active issues in [basic.string].

    -

    View all other issues in [basic.string].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -The note in paragraph 6 suggests that the invalidation rules for -references, pointers, and iterators in paragraph 5 permit a reference- -counted implementation (actually, according to paragraph 6, they permit -a "reference counted implementation", but this is a minor editorial fix). -

    - -

    -However, the last sub-bullet is so worded as to make a reference-counted -implementation unviable. In the following example none of the -conditions for iterator invalidation are satisfied: -

    - -
        // first example: "*******************" should be printed twice
-    string original = "some arbitrary text", copy = original;
-    const string & alias = original;
-
-    string::const_iterator i = alias.begin(), e = alias.end();
-    for(string::iterator j = original.begin(); j != original.end(); ++j)
-        *j = '*';
-    while(i != e)
-        cout << *i++;
-    cout << endl;
-    cout << original << endl;
-
    - -

    -Similarly, in the following example: -

    - -
        // second example: "some arbitrary text" should be printed out
-    string original = "some arbitrary text", copy = original;
-    const string & alias = original;
-
-    string::const_iterator i = alias.begin();
-    original.begin();
-    while(i != alias.end())
-        cout << *i++;
-
    - -

    -I have tested this on three string implementations, two of which were -reference counted. The reference-counted implementations gave -"surprising behavior" because they invalidated iterators on -the first call to non-const begin since construction. The current -wording does not permit such invalidation because it does not take -into account the first call since construction, only the first call -since various member and non-member function calls. -

    - - -

    Proposed resolution:

    -

    -Change the following sentence in 21.3 paragraph 5 from -

    - -

    - Subsequent to any of the above uses except the forms of insert() and - erase() which return iterators, the first call to non-const member - functions operator[](), at(), begin(), rbegin(), end(), or rend(). -

    - -

    to

    - -

    - Following construction or any of the above uses, except the forms of - insert() and erase() that return iterators, the first call to non- - const member functions operator[](), at(), begin(), rbegin(), end(), - or rend(). -

    - - - - -
    -

    264. Associative container insert(i, j) complexity requirements are not feasible.

    -

    Section: 23.1.4 [associative.reqmts] Status: WP - Submitter: John Potter Date: 2000-09-07

    -

    View all other issues in [associative.reqmts].

    -

    View all issues with WP status.

    -

    Duplicate of: 102

    -

    Discussion:

    -

    -Table 69 requires linear time if [i, j) is sorted. Sorted is necessary but not sufficient. -Consider inserting a sorted range of even integers into a set<int> containing the odd -integers in the same range. -

    - -

    Related issue: 102

    - - -

    Proposed resolution:

    -

    -In Table 69, in section 23.1.2, change the complexity clause for -insertion of a range from "N log(size() + N) (N is the distance -from i to j) in general; linear if [i, j) is sorted according to -value_comp()" to "N log(size() + N), where N is the distance -from i to j". -

    - -

    [Copenhagen: Minor fix in proposed resolution: fixed unbalanced -parens in the revised wording.]

    - - - - -

    Rationale:

    -

    -Testing for valid insertions could be less efficient than simply -inserting the elements when the range is not both sorted and between -two adjacent existing elements; this could be a QOI issue. -

    - -

    -The LWG considered two other options: (a) specifying that the -complexity was linear if [i, j) is sorted according to value_comp() -and between two adjacent existing elements; or (b) changing to -Klog(size() + N) + (N - K) (N is the distance from i to j and K is the -number of elements which do not insert immediately after the previous -element from [i, j) including the first). The LWG felt that, since -we can't guarantee linear time complexity whenever the range to be -inserted is sorted, it's more trouble than it's worth to say that it's -linear in some special cases. -

    - - - - -
    -

    265. std::pair::pair() effects overly restrictive

    -

    Section: 20.2.3 [pairs] Status: WP - Submitter: Martin Sebor Date: 2000-09-11

    -

    View all other issues in [pairs].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -I don't see any requirements on the types of the elements of the -std::pair container in 20.2.2. From the descriptions of the member -functions it appears that they must at least satisfy the requirements of -20.1.3 [lib.copyconstructible] and 20.1.4 [lib.default.con.req], and in -the case of the [in]equality operators also the requirements of 20.1.1 -[lib.equalitycomparable] and 20.1.2 [lib.lessthancomparable]. -

    - -

    -I believe that the the CopyConstructible requirement is unnecessary in -the case of 20.2.2, p2. -

    - - -

    Proposed resolution:

    -

    Change the Effects clause in 20.2.2, p2 from

    - -

    --2- Effects: Initializes its members as if implemented: pair() : -first(T1()), second(T2()) {} -

    - -

    to

    - -

    --2- Effects: Initializes its members as if implemented: pair() : -first(), second() {} -

    - - -

    Rationale:

    -

    The existing specification of pair's constructor appears to be a -historical artifact: there was concern that pair's members be properly -zero-initialized when they are built-in types. At one time there was -uncertainty about whether they would be zero-initialized if the -default constructor was written the obvious way. This has been -clarified by core issue 178, and there is no longer any doubt that -the straightforward implementation is correct.

    - - - - -
    -

    266. bad_exception::~bad_exception() missing Effects clause

    -

    Section: 18.7.2.1 [bad.exception] Status: WP - Submitter: Martin Sebor Date: 2000-09-24

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -The synopsis for std::bad_exception lists the function ~bad_exception() -but there is no description of what the function does (the Effects -clause is missing). -

    - - -

    Proposed resolution:

    -

    -Remove the destructor from the class synopses of -bad_alloc (18.5.2.1 [bad.alloc]), -bad_cast (18.6.2 [bad.cast]), -bad_typeid (18.6.3 [bad.typeid]), -and bad_exception (18.7.2.1 [bad.exception]). -

    - - -

    Rationale:

    -

    -This is a general problem with the exception classes in clause 18. -The proposed resolution is to remove the destructors from the class -synopses, rather than to document the destructors' behavior, because -removing them is more consistent with how exception classes are -described in clause 19. -

    - - - - -
    -

    268. Typo in locale synopsis

    -

    Section: 22.1.1 [locale] Status: WP - Submitter: Martin Sebor Date: 2000-10-05

    -

    View all other issues in [locale].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    The synopsis of the class std::locale in 22.1.1 contains two typos: -the semicolons after the declarations of the default ctor -locale::locale() and the copy ctor locale::locale(const locale&) -are missing.

    - - -

    Proposed resolution:

    -

    Add the missing semicolons, i.e., change

    - -
        //  construct/copy/destroy:
-        locale() throw()
-        locale(const locale& other) throw()
-
    - -

    in the synopsis in 22.1.1 to

    - -
        //  construct/copy/destroy:
-        locale() throw();
-        locale(const locale& other) throw();
-
    - - - - -
    -

    270. Binary search requirements overly strict

    -

    Section: 25.3.3 [alg.binary.search] Status: WP - Submitter: Matt Austern Date: 2000-10-18

    -

    View all other issues in [alg.binary.search].

    -

    View all issues with WP status.

    -

    Duplicate of: 472

    -

    Discussion:

    -

    -Each of the four binary search algorithms (lower_bound, upper_bound, -equal_range, binary_search) has a form that allows the user to pass a -comparison function object. According to 25.3, paragraph 2, that -comparison function object has to be a strict weak ordering. -

    - -

    -This requirement is slightly too strict. Suppose we are searching -through a sequence containing objects of type X, where X is some -large record with an integer key. We might reasonably want to look -up a record by key, in which case we would want to write something -like this: -

    -
        struct key_comp {
-      bool operator()(const X& x, int n) const {
-        return x.key() < n;
-      }
-    }
-
-    std::lower_bound(first, last, 47, key_comp());
-
    - -

    -key_comp is not a strict weak ordering, but there is no reason to -prohibit its use in lower_bound. -

    - -

    -There's no difficulty in implementing lower_bound so that it allows -the use of something like key_comp. (It will probably work unless an -implementor takes special pains to forbid it.) What's difficult is -formulating language in the standard to specify what kind of -comparison function is acceptable. We need a notion that's slightly -more general than that of a strict weak ordering, one that can encompass -a comparison function that involves different types. Expressing that -notion may be complicated. -

    - -

    Additional questions raised at the Toronto meeting:

    -
      -
    • Do we really want to specify what ordering the implementor must - use when calling the function object? The standard gives - specific expressions when describing these algorithms, but it also - says that other expressions (with different argument order) are - equivalent.
      • -
    • If we are specifying ordering, note that the standard uses both - orderings when describing equal_range.
      • -
    • Are we talking about requiring these algorithms to work properly - when passed a binary function object whose two argument types - are not the same, or are we talking about requirements when - they are passed a binary function object with several overloaded - versions of operator()?
      • -
    • The definition of a strict weak ordering does not appear to give - any guidance on issues of overloading; it only discusses expressions, - and all of the values in these expressions are of the same type. - Some clarification would seem to be in order.
      • -
    - -

    Additional discussion from Copenhagen:

    -
      -
    • It was generally agreed that there is a real defect here: if -the predicate is merely required to be a Strict Weak Ordering, then -it's possible to pass in a function object with an overloaded -operator(), where the version that's actually called does something -completely inappropriate. (Such as returning a random value.)
      • - -
    • An alternative formulation was presented in a paper distributed by -David Abrahams at the meeting, "Binary Search with Heterogeneous -Comparison", J16-01/0027 = WG21 N1313: Instead of viewing the -predicate as a Strict Weak Ordering acting on a sorted sequence, view -the predicate/value pair as something that partitions a sequence. -This is almost equivalent to saying that we should view binary search -as if we are given a unary predicate and a sequence, such that f(*p) -is true for all p below a specific point and false for all p above it. -The proposed resolution is based on that alternative formulation.
      • -
    - - -

    Proposed resolution:

    - -

    Change 25.3 [lib.alg.sorting] paragraph 3 from:

    - -

    - 3 For all algorithms that take Compare, there is a version that uses - operator< instead. That is, comp(*i, *j) != false defaults to *i < - *j != false. For the algorithms to work correctly, comp has to - induce a strict weak ordering on the values. -

    - -

    to:

    - -

    - 3 For all algorithms that take Compare, there is a version that uses - operator< instead. That is, comp(*i, *j) != false defaults to *i - < *j != false. For algorithms other than those described in - lib.alg.binary.search (25.3.3) to work correctly, comp has to induce - a strict weak ordering on the values. -

    - -

    Add the following paragraph after 25.3 [lib.alg.sorting] paragraph 5:

    - -

    - -6- A sequence [start, finish) is partitioned with respect to an - expression f(e) if there exists an integer n such that - for all 0 <= i < distance(start, finish), f(*(begin+i)) is true if - and only if i < n. -

    - -

    Change 25.3.3 [lib.alg.binary.search] paragraph 1 from:

    - -

    - -1- All of the algorithms in this section are versions of binary - search and assume that the sequence being searched is in order - according to the implied or explicit comparison function. They work - on non-random access iterators minimizing the number of - comparisons, which will be logarithmic for all types of - iterators. They are especially appropriate for random access - iterators, because these algorithms do a logarithmic number of - steps through the data structure. For non-random access iterators - they execute a linear number of steps. -

    - -

    to:

    - -

    - -1- All of the algorithms in this section are versions of binary - search and assume that the sequence being searched is partitioned - with respect to an expression formed by binding the search key to - an argument of the implied or explicit comparison function. They - work on non-random access iterators minimizing the number of - comparisons, which will be logarithmic for all types of - iterators. They are especially appropriate for random access - iterators, because these algorithms do a logarithmic number of - steps through the data structure. For non-random access iterators - they execute a linear number of steps. -

    - -

    Change 25.3.3.1 [lib.lower.bound] paragraph 1 from:

    - -

    - -1- Requires: Type T is LessThanComparable - (lib.lessthancomparable). -

    - -

    to:

    - -

    - -1- Requires: The elements e of [first, last) are partitioned with - respect to the expression e < value or comp(e, value) -

    - - -

    Remove 25.3.3.1 [lib.lower.bound] paragraph 2:

    - -

    - -2- Effects: Finds the first position into which value can be - inserted without violating the ordering. -

    - -

    Change 25.3.3.2 [lib.upper.bound] paragraph 1 from:

    - -

    - -1- Requires: Type T is LessThanComparable (lib.lessthancomparable). -

    - -

    to:

    - -

    - -1- Requires: The elements e of [first, last) are partitioned with - respect to the expression !(value < e) or !comp(value, e) -

    - -

    Remove 25.3.3.2 [lib.upper.bound] paragraph 2:

    - -

    - -2- Effects: Finds the furthermost position into which value can be - inserted without violating the ordering. -

    - -

    Change 25.3.3.3 [lib.equal.range] paragraph 1 from:

    - -

    - -1- Requires: Type T is LessThanComparable - (lib.lessthancomparable). -

    - -

    to:

    - -

    - -1- Requires: The elements e of [first, last) are partitioned with - respect to the expressions e < value and !(value < e) or - comp(e, value) and !comp(value, e). Also, for all elements e of - [first, last), e < value implies !(value < e) or comp(e, - value) implies !comp(value, e) -

    - -

    Change 25.3.3.3 [lib.equal.range] paragraph 2 from:

    - -

    - -2- Effects: Finds the largest subrange [i, j) such that the value - can be inserted at any iterator k in it without violating the - ordering. k satisfies the corresponding conditions: !(*k < value) - && !(value < *k) or comp(*k, value) == false && comp(value, *k) == - false. -

    - -

    to:

    - -
       -2- Returns: 
-         make_pair(lower_bound(first, last, value),
-                   upper_bound(first, last, value))
-       or
-         make_pair(lower_bound(first, last, value, comp),
-                   upper_bound(first, last, value, comp))
-
    - -

    Change 25.3.3.3 [lib.binary.search] paragraph 1 from:

    - -

    - -1- Requires: Type T is LessThanComparable - (lib.lessthancomparable). -

    - -

    to:

    - -

    - -1- Requires: The elements e of [first, last) are partitioned with - respect to the expressions e < value and !(value < e) or comp(e, - value) and !comp(value, e). Also, for all elements e of [first, - last), e < value implies !(value < e) or comp(e, value) implies - !comp(value, e) -

    - -

    [Copenhagen: Dave Abrahams provided this wording]

    - - -

    [Redmond: Minor changes in wording. (Removed "non-negative", and -changed the "other than those described in" wording.) Also, the LWG -decided to accept the "optional" part.]

    - - - - -

    Rationale:

    -

    The proposed resolution reinterprets binary search. Instead of -thinking about searching for a value in a sorted range, we view that -as an important special case of a more general algorithm: searching -for the partition point in a partitioned range.

    - -

    We also add a guarantee that the old wording did not: we ensure -that the upper bound is no earlier than the lower bound, that -the pair returned by equal_range is a valid range, and that the first -part of that pair is the lower bound.

    - - - - - -
    -

    271. basic_iostream missing typedefs

    -

    Section: 27.6.1.5 [iostreamclass] Status: WP - Submitter: Martin Sebor Date: 2000-11-02

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -Class template basic_iostream has no typedefs. The typedefs it -inherits from its base classes can't be used, since (for example) -basic_iostream<T>::traits_type is ambiguous. -

    - - -

    Proposed resolution:

    - -

    Add the following to basic_iostream's class synopsis in -27.6.1.5 [iostreamclass], immediately after public:

    - -
      // types:
-  typedef charT                     char_type;
-  typedef typename traits::int_type int_type;
-  typedef typename traits::pos_type pos_type;
-  typedef typename traits::off_type off_type;
-  typedef traits                    traits_type;
-
    - - - - -
    -

    272. Missing parentheses around subexpression

    -

    Section: 27.4.4.3 [iostate.flags] Status: WP - Submitter: Martin Sebor Date: 2000-11-02

    -

    View all other issues in [iostate.flags].

    -

    View all issues with WP status.

    -

    Duplicate of: 569

    -

    Discussion:

    -

    -27.4.4.3, p4 says about the postcondition of the function: If -rdbuf()!=0 then state == rdstate(); otherwise -rdstate()==state|ios_base::badbit. -

    - -

    -The expression on the right-hand-side of the operator==() needs to be -parenthesized in order for the whole expression to ever evaluate to -anything but non-zero. -

    - - -

    Proposed resolution:

    -

    -Add parentheses like so: rdstate()==(state|ios_base::badbit). -

    - - - - -
    -

    273. Missing ios_base qualification on members of a dependent class

    -

    Section: 27 [input.output] Status: WP - Submitter: Martin Sebor Date: 2000-11-02

    -

    View all other issues in [input.output].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    27.5.2.4.2, p4, and 27.8.1.6, p2, 27.8.1.7, p3, 27.8.1.9, p2, -27.8.1.10, p3 refer to in and/or out w/o ios_base:: qualification. -That's incorrect since the names are members of a dependent base -class (14.6.2 [temp.dep]) and thus not visible.

    - - -

    Proposed resolution:

    -

    Qualify the names with the name of the class of which they are -members, i.e., ios_base.

    - - - - -
    -

    274. a missing/impossible allocator requirement

    -

    Section: 20.1.2 [allocator.requirements] Status: WP - Submitter: Martin Sebor Date: 2000-11-02

    -

    View other active issues in [allocator.requirements].

    -

    View all other issues in [allocator.requirements].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -I see that table 31 in 20.1.5, p3 allows T in std::allocator<T> to be of -any type. But the synopsis in 20.4.1 calls for allocator<>::address() to -be overloaded on reference and const_reference, which is ill-formed for -all T = const U. In other words, this won't work: -

    - -

    -template class std::allocator<const int>; -

    - -

    -The obvious solution is to disallow specializations of allocators on -const types. However, while containers' elements are required to be -assignable (which rules out specializations on const T's), I think that -allocators might perhaps be potentially useful for const values in other -contexts. So if allocators are to allow const types a partial -specialization of std::allocator<const T> would probably have to be -provided. -

    - - -

    Proposed resolution:

    -

    Change the text in row 1, column 2 of table 32 in 20.1.5, p3 from

    - -

    - any type -

    - -

    to

    -

    - any non-const, non-reference type -

    - -

    [Redmond: previous proposed resolution was "any non-const, -non-volatile, non-reference type". Got rid of the "non-volatile".]

    - - - - -

    Rationale:

    -

    -Two resolutions were originally proposed: one that partially -specialized std::allocator for const types, and one that said an -allocator's value type may not be const. The LWG chose the second. -The first wouldn't be appropriate, because allocators are intended for -use by containers, and const value types don't work in containers. -Encouraging the use of allocators with const value types would only -lead to unsafe code. -

    -

    -The original text for proposed resolution 2 was modified so that it -also forbids volatile types and reference types. -

    - -

    [Curaçao: LWG double checked and believes volatile is correctly -excluded from the PR.]

    - - - - - - - -
    -

    275. Wrong type in num_get::get() overloads

    -

    Section: 22.2.2.1.1 [facet.num.get.members] Status: WP - Submitter: Matt Austern Date: 2000-11-02

    -

    View all other issues in [facet.num.get.members].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -In 22.2.2.1.1, we have a list of overloads for num_get<>::get(). -There are eight overloads, all of which are identical except for the -last parameter. The overloads are: -

    -
      -
    • long&
      • -
    • unsigned short&
      • -
    • unsigned int&
      • -
    • unsigned long&
      • -
    • short&
      • -
    • double&
      • -
    • long double&
      • -
    • void*&
      • -
    - -

    -There is a similar list, in 22.2.2.1.2, of overloads for -num_get<>::do_get(). In this list, the last parameter has -the types: -

    -
      -
    • long&
      • -
    • unsigned short&
      • -
    • unsigned int&
      • -
    • unsigned long&
      • -
    • float&
      • -
    • double&
      • -
    • long double&
      • -
    • void*&
      • -
    - -

    -These two lists are not identical. They should be, since -get is supposed to call do_get with exactly -the arguments it was given. -

    - - -

    Proposed resolution:

    -

    In 22.2.2.1.1 [facet.num.get.members], change

    -
      iter_type get(iter_type in, iter_type end, ios_base& str,
-                ios_base::iostate& err, short& val) const;
-
    -

    to

    -
      iter_type get(iter_type in, iter_type end, ios_base& str,
-                ios_base::iostate& err, float& val) const;
-
    - - - - -
    -

    276. Assignable requirement for container value type overly strict

    -

    Section: 23.1 [container.requirements] Status: WP - Submitter: Peter Dimov Date: 2000-11-07

    -

    View other active issues in [container.requirements].

    -

    View all other issues in [container.requirements].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -23.1/3 states that the objects stored in a container must be -Assignable. 23.3.1 [map], paragraph 2, -states that map satisfies all requirements for a container, while in -the same time defining value_type as pair<const Key, T> - a type -that is not Assignable. -

    - -

    -It should be noted that there exists a valid and non-contradictory -interpretation of the current text. The wording in 23.1/3 avoids -mentioning value_type, referring instead to "objects stored in a -container." One might argue that map does not store objects of -type map::value_type, but of map::mapped_type instead, and that the -Assignable requirement applies to map::mapped_type, not -map::value_type. -

    - -

    -However, this makes map a special case (other containers store objects of -type value_type) and the Assignable requirement is needlessly restrictive in -general. -

    - -

    -For example, the proposed resolution of active library issue -103 is to make set::iterator a constant iterator; this -means that no set operations can exploit the fact that the stored -objects are Assignable. -

    - -

    -This is related to, but slightly broader than, closed issue -140. -

    - - -

    Proposed resolution:

    -

    23.1/3: Strike the trailing part of the sentence:

    -

    - , and the additional requirements of Assignable types from 23.1/3 -

    -

    so that it reads:

    -

    - -3- The type of objects stored in these components must meet the - requirements of CopyConstructible types (lib.copyconstructible). -

    - -

    23.1/4: Modify to make clear that this requirement is not for all -containers. Change to:

    - -

    --4- Table 64 defines the Assignable requirement. Some containers -require this property of the types to be stored in the container. T is -the type used to instantiate the container. t is a value of T, and u is -a value of (possibly const) T. -

    - -

    23.1, Table 65: in the first row, change "T is Assignable" to "T is -CopyConstructible".

    - -

    23.2.1/2: Add sentence for Assignable requirement. Change to:

    - -

    --2- A deque satisfies all of the requirements of a container and of a -reversible container (given in tables in lib.container.requirements) and -of a sequence, including the optional sequence requirements -(lib.sequence.reqmts). In addition to the requirements on the stored -object described in 23.1[lib.container.requirements], the stored object -must also meet the requirements of Assignable. Descriptions are -provided here only for operations on deque that are not described in one -of these tables or for operations where there is additional semantic -information. -

    - -

    23.2.2/2: Add Assignable requirement to specific methods of list. -Change to:

    - -
    -

    -2- A list satisfies all of the requirements of a container and of a -reversible container (given in two tables in lib.container.requirements) -and of a sequence, including most of the the optional sequence -requirements (lib.sequence.reqmts). The exceptions are the operator[] -and at member functions, which are not provided. - -[Footnote: These member functions are only provided by containers whose -iterators are random access iterators. --- end foonote] -

    - -

    list does not require the stored type T to be Assignable unless the -following methods are instantiated: - -[Footnote: Implementors are permitted but not required to take advantage -of T's Assignable properties for these methods. -- end foonote] -

    -
         list<T,Allocator>& operator=(const list<T,Allocator>&  x );
-     template <class InputIterator>
-       void assign(InputIterator first, InputIterator last);
-     void assign(size_type n, const T& t);
-
    - - -

    Descriptions are provided here only for operations on list that are not -described in one of these tables or for operations where there is -additional semantic information.

    -
    - -

    23.2.4/2: Add sentence for Assignable requirement. Change to:

    - -

    --2- A vector satisfies all of the requirements of a container and of a -reversible container (given in two tables in lib.container.requirements) -and of a sequence, including most of the optional sequence requirements -(lib.sequence.reqmts). The exceptions are the push_front and pop_front -member functions, which are not provided. In addition to the -requirements on the stored object described in -23.1[lib.container.requirements], the stored object must also meet the -requirements of Assignable. Descriptions are provided here only for -operations on vector that are not described in one of these tables or -for operations where there is additional semantic information. -

    - - -

    Rationale:

    -

    list, set, multiset, map, multimap are able to store non-Assignables. -However, there is some concern about list<T>: -although in general there's no reason for T to be Assignable, some -implementations of the member functions operator= and -assign do rely on that requirement. The LWG does not want -to forbid such implementations.

    - -

    Note that the type stored in a standard container must still satisfy -the requirements of the container's allocator; this rules out, for -example, such types as "const int". See issue 274 -for more details. -

    - -

    In principle we could also relax the "Assignable" requirement for -individual vector member functions, such as -push_back. However, the LWG did not see great value in such -selective relaxation. Doing so would remove implementors' freedom to -implement vector::push_back in terms of -vector::insert.

    - - - - - -
    -

    278. What does iterator validity mean?

    -

    Section: 23.2.4.4 [list.ops] Status: WP - Submitter: P.J. Plauger Date: 2000-11-27

    -

    View all other issues in [list.ops].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -Section 23.2.4.4 [list.ops] states that -

    -
      void splice(iterator position, list<T, Allocator>& x);
-
    -

    -invalidates all iterators and references to list x. -

    - -

    -But what does the C++ Standard mean by "invalidate"? You -can still dereference the iterator to a spliced list element, but -you'd better not use it to delimit a range within the original -list. For the latter operation, it has definitely lost some of its -validity. -

    - -

    -If we accept the proposed resolution to issue 250, -then we'd better clarify that a "valid" iterator need no -longer designate an element within the same container as it once did. -We then have to clarify what we mean by invalidating a past-the-end -iterator, as when a vector or string grows by reallocation. Clearly, -such an iterator has a different kind of validity. Perhaps we should -introduce separate terms for the two kinds of "validity." -

    - - -

    Proposed resolution:

    -

    Add the following text to the end of section 24.1 [iterator.requirements], -after paragraph 5:

    -

    -An invalid iterator is an iterator that may be -singular. [Footnote: This definition applies to pointers, since -pointers are iterators. The effect of dereferencing an iterator that -has been invalidated is undefined.] -

    - -

    [post-Copenhagen: Matt provided wording.]

    - - -

    [Redmond: General agreement with the intent, some objections to -the wording. Dave provided new wording.]

    - - - -

    Rationale:

    -

    This resolution simply defines a term that the Standard uses but - never defines, "invalid", in terms of a term that is defined, - "singular".

    - -

    Why do we say "may be singular", instead of "is singular"? That's - becuase a valid iterator is one that is known to be nonsingular. - Invalidating an iterator means changing it in such a way that it's - no longer known to be nonsingular. An example: inserting an - element into the middle of a vector is correctly said to invalidate - all iterators pointing into the vector. That doesn't necessarily - mean they all become singular.

    - - - - - -
    -

    280. Comparison of reverse_iterator to const reverse_iterator

    -

    Section: 24.4.1 [reverse.iterators] Status: WP - Submitter: Steve Cleary Date: 2000-11-27

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -This came from an email from Steve Cleary to Fergus in reference to -issue 179. The library working group briefly discussed -this in Toronto and believed it should be a separate issue. There was -also some reservations about whether this was a worthwhile problem to -fix. -

    - -

    -Steve said: "Fixing reverse_iterator. std::reverse_iterator can -(and should) be changed to preserve these additional -requirements." He also said in email that it can be done without -breaking user's code: "If you take a look at my suggested -solution, reverse_iterator doesn't have to take two parameters; there -is no danger of breaking existing code, except someone taking the -address of one of the reverse_iterator global operator functions, and -I have to doubt if anyone has ever done that. . . But, just in -case they have, you can leave the old global functions in as well -- -they won't interfere with the two-template-argument functions. With -that, I don't see how any user code could break." -

    - - -

    Proposed resolution:

    -

    -Section: 24.4.1.1 [reverse.iterator] -add/change the following declarations:

    -
      A) Add a templated assignment operator, after the same manner
-        as the templated copy constructor, i.e.:
-
-  template < class U >
-  reverse_iterator < Iterator >& operator=(const reverse_iterator< U >& u);
-
-  B) Make all global functions (except the operator+) have
-  two template parameters instead of one, that is, for
-  operator ==, !=, <, >, <=, >=, - replace:
-
-       template < class Iterator >
-       typename reverse_iterator< Iterator >::difference_type operator-(
-                 const reverse_iterator< Iterator >& x,
-                 const reverse_iterator< Iterator >& y);
-
-  with:
-
-      template < class Iterator1, class Iterator2 >
-      typename reverse_iterator < Iterator1 >::difference_type operator-(
-                 const reverse_iterator < Iterator1 > & x,
-                 const reverse_iterator < Iterator2 > & y);
-
    -

    -Also make the addition/changes for these signatures in -24.4.1.3 [reverse.iter.ops]. -

    - -

    [ -Copenhagen: The LWG is concerned that the proposed resolution -introduces new overloads. Experience shows that introducing -overloads is always risky, and that it would be inappropriate to -make this change without implementation experience. It may be -desirable to provide this feature in a different way. -]

    - - -

    [ -Lillehammer: We now have implementation experience, and agree that -this solution is safe and correct. -]

    - - - - - - - -
    -

    281. std::min() and max() requirements overly restrictive

    -

    Section: 25.3.7 [alg.min.max] Status: WP - Submitter: Martin Sebor Date: 2000-12-02

    -

    View all other issues in [alg.min.max].

    -

    View all issues with WP status.

    -

    Duplicate of: 486

    -

    Discussion:

    -

    The requirements in 25.3.7, p1 and 4 call for T to satisfy the -requirements of LessThanComparable ( [lessthancomparable]) -and CopyConstructible (20.1.1 [utility.arg.requirements]). -Since the functions take and return their arguments and result by -const reference, I believe the CopyConstructible requirement -is unnecessary. -

    - - -

    Proposed resolution:

    -

    Remove the CopyConstructible requirement. Specifically, replace -25.3.7, p1 with

    -

    -1- Requires: Type T is LessThanComparable -( [lessthancomparable]). -

    -

    and replace 25.3.7, p4 with

    -

    -4- Requires: Type T is LessThanComparable -( [lessthancomparable]). -

    - - - - -
    -

    282. What types does numpunct grouping refer to?

    -

    Section: 22.2.2.2.2 [facet.num.put.virtuals] Status: WP - Submitter: Howard Hinnant Date: 2000-12-05

    -

    View all other issues in [facet.num.put.virtuals].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -Paragraph 16 mistakenly singles out integral types for inserting -thousands_sep() characters. This conflicts with the syntax for floating -point numbers described under 22.2.3.1/2. -

    - - -

    Proposed resolution:

    -

    Change paragraph 16 from:

    - -

    -For integral types, punct.thousands_sep() characters are inserted into -the sequence as determined by the value returned by punct.do_grouping() -using the method described in 22.2.3.1.2 [facet.numpunct.virtuals]. -

    - -

    To:

    - -

    -For arithmetic types, punct.thousands_sep() characters are inserted into -the sequence as determined by the value returned by punct.do_grouping() -using the method described in 22.2.3.1.2 [facet.numpunct.virtuals]. -

    - -

    [ -Copenhagen: Opinions were divided about whether this is actually an -inconsistency, but at best it seems to have been unintentional. This -is only an issue for floating-point output: The standard is -unambiguous that implementations must parse thousands_sep characters -when performing floating-point. The standard is also unambiguous that -this requirement does not apply to the "C" locale. -]

    - - -

    [ -A survey of existing practice is needed; it is believed that some -implementations do insert thousands_sep characters for floating-point -output and others fail to insert thousands_sep characters for -floating-point input even though this is unambiguously required by the -standard. -]

    - - -

    [Post-Curaçao: the above proposed resolution is the consensus of -Howard, Bill, Pete, Benjamin, Nathan, Dietmar, Boris, and Martin.]

    - - - - - - -
    -

    283. std::replace() requirement incorrect/insufficient

    -

    Section: 25.2.5 [alg.replace] Status: WP - Submitter: Martin Sebor Date: 2000-12-15

    -

    View all other issues in [alg.replace].

    -

    View all issues with WP status.

    -

    Duplicate of: 483

    -

    Discussion:

    -

    -(revision of the further discussion) -There are a number of problems with the requires clauses for the -algorithms in 25.1 and 25.2. The requires clause of each algorithm -should describe the necessary and sufficient requirements on the inputs -to the algorithm such that the algorithm compiles and runs properly. -Many of the requires clauses fail to do this. Here is a summary of the kinds -of mistakes: -

    - -
      -
    1. -Use of EqualityComparable, which only puts requirements on a single -type, when in fact an equality operator is required between two -different types, typically either T and the iterator's value type -or between the value types of two different iterators. -
      2. -
    2. -Use of Assignable for T when in fact what was needed is Assignable -for the value_type of the iterator, and convertability from T to the -value_type of the iterator. Or for output iterators, the requirement -should be that T is writable to the iterator (output iterators do -not have value types). -
      3. -
    - -

    -Here is the list of algorithms that contain mistakes: -

    - -
      -
    • 25.1.2 std::find
      • -
    • 25.1.6 std::count
      • -
    • 25.1.8 std::equal
      • -
    • 25.1.9 std::search, std::search_n
      • -
    • 25.2.4 std::replace, std::replace_copy
      • -
    • 25.2.5 std::fill
      • -
    • 25.2.7 std::remove, std::remove_copy
      • -
    - -

    -Also, in the requirements for EqualityComparable, the requirement that -the operator be defined for const objects is lacking. -

    - - - -

    Proposed resolution:

    - -

    20.1.1 Change p1 from

    - -

    In Table 28, T is a type to be supplied by a C++ program -instantiating a template, a, b, and c are -values of type T. -

    - -

    to

    - -

    -In Table 28, T is a type to be supplied by a C++ program -instantiating a template, a, b, and c are -values of type const T. -

    - -

    25 Between p8 and p9

    - -

    Add the following sentence:

    - -

    When the description of an algorithm gives an expression such as -*first == value for a condition, it is required that the expression -evaluate to either true or false in boolean contexts.

    - -

    25.1.2 Change p1 by deleting the requires clause.

    - -

    25.1.6 Change p1 by deleting the requires clause.

    - -

    25.1.9

    - -

    Change p4 from

    - -

    -4- Requires: Type T is EqualityComparable -(20.1.1), type Size is convertible to integral type (4.7.12.3). -

    - -

    to

    - -

    -4- Requires: The type Size is convertible to integral -type (4.7.12.3).

    - -

    25.2.4 Change p1 from

    - -

    -1- Requires: Type T is Assignable (23.1 ) (and, for replace(), EqualityComparable (20.1.1 )).

    - -

    to

    - -

    -1- Requires: The expression *first = new_value must be valid.

    - -

    and change p4 from

    - -

    -4- Requires: Type T is Assignable (23.1) (and, -for replace_copy(), EqualityComparable -(20.1.1)). The ranges [first, last) and [result, result + -(last - first)) shall not overlap.

    - -

    to

    - -

    -4- Requires: The results of the expressions *first and -new_value must be writable to the result output iterator. The -ranges [first, last) and [result, result + (last - -first)) shall not overlap.

    - - -

    25.2.5 Change p1 from

    - -

    -1- Requires: Type T is Assignable (23.1). The -type Size is convertible to an integral type (4.7.12.3).

    - -

    to

    - -

    -1- Requires: The expression value must be is writable to -the output iterator. The type Size is convertible to an -integral type (4.7.12.3).

    - -

    25.2.7 Change p1 from

    - -

    -1- Requires: Type T is EqualityComparable (20.1.1).

    - -

    to

    - -

    --1- Requires: The value type of the iterator must be -Assignable (23.1). -

    - - - -

    Rationale:

    -

    -The general idea of the proposed solution is to remove the faulty -requires clauses and let the returns and effects clauses speak for -themselves. That is, the returns clauses contain expressions that must -be valid, and therefore already imply the correct requirements. In -addition, a sentence is added at the beginning of chapter 25 saying -that expressions given as conditions must evaluate to true or false in -a boolean context. An alternative would be to say that the type of -these condition expressions must be literally bool, but that would be -imposing a greater restriction that what the standard currently says -(which is convertible to bool). -

    - - - - - -
    -

    284. unportable example in 20.3.7, p6

    -

    Section: 20.6.7 [comparisons] Status: WP - Submitter: Martin Sebor Date: 2000-12-26

    -

    View all issues with WP status.

    -

    Discussion:

    -

    The example in 20.6.7 [comparisons], p6 shows how to use the C -library function strcmp() with the function pointer adapter -ptr_fun(). But since it's unspecified whether the C library -functions have extern "C" or extern -"C++" linkage [17.4.2.2 [using.linkage]], and since -function pointers with different the language linkage specifications -(7.5 [dcl.link]) are incompatible, whether this example is -well-formed is unspecified. -

    - - -

    Proposed resolution:

    -

    Change 20.6.7 [comparisons] paragraph 6 from:

    -
    -

    [Example:

    - 
        replace_if(v.begin(), v.end(), not1(bind2nd(ptr_fun(strcmp), "C")), "C++");
-
    -

    replaces each C with C++ in sequence v.

    -
    - - -

    to:

    -
    -

    [Example:

    - 
        int compare(const char*, const char*);
-    replace_if(v.begin(), v.end(),
-               not1(bind2nd(ptr_fun(compare), "abc")), "def");
-
    -

    replaces each abc with def in sequence v.

    -
    - -

    Also, remove footnote 215 in that same paragraph.

    - -

    [Copenhagen: Minor change in the proposed resolution. Since this -issue deals in part with C and C++ linkage, it was believed to be too -confusing for the strings in the example to be "C" and "C++". -]

    - - -

    [Redmond: More minor changes. Got rid of the footnote (which -seems to make a sweeping normative requirement, even though footnotes -aren't normative), and changed the sentence after the footnote so that -it corresponds to the new code fragment.]

    - - - - - - -
    -

    285. minor editorial errors in fstream ctors

    -

    Section: 27.8.1.7 [ifstream.cons] Status: WP - Submitter: Martin Sebor Date: 2000-12-31

    -

    View all issues with WP status.

    -

    Discussion:

    -

    27.8.1.7 [ifstream.cons], p2, 27.8.1.11 [ofstream.cons], p2, and -27.8.1.15 [fstream.cons], p2 say about the effects of each constructor: -

    - -

    ... If that function returns a null pointer, calls -setstate(failbit) (which may throw ios_base::failure). -

    - -

    The parenthetical note doesn't apply since the ctors cannot throw an -exception due to the requirement in 27.4.4.1 [basic.ios.cons], p3 -that exceptions() be initialized to ios_base::goodbit. -

    - - -

    Proposed resolution:

    -

    -Strike the parenthetical note from the Effects clause in each of the -paragraphs mentioned above. -

    - - - - -
    -

    286. <cstdlib> requirements missing size_t typedef

    -

    Section: 25.4 [alg.c.library] Status: WP - Submitter: Judy Ward Date: 2000-12-30

    -

    View all other issues in [alg.c.library].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -The <cstdlib> header file contains prototypes for bsearch and -qsort (C++ Standard section 25.4 paragraphs 3 and 4) and other -prototypes (C++ Standard section 21.4 paragraph 1 table 49) that -require the typedef size_t. Yet size_t is not listed in the -<cstdlib> synopsis table 78 in section 25.4. -

    - - -

    Proposed resolution:

    -

    -Add the type size_t to Table 78 (section 25.4) and add -the type size_t <cstdlib> to Table 97 (section C.2). -

    - - -

    Rationale:

    -

    Since size_t is in <stdlib.h>, it must also be in <cstdlib>.

    - - - - - -
    -

    288. <cerrno> requirements missing macro EILSEQ

    -

    Section: 19.3 [errno] Status: WP - Submitter: Judy Ward Date: 2000-12-30

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -ISO/IEC 9899:1990/Amendment1:1994 Section 4.3 States: "The list -of macros defined in <errno.h> is adjusted to include a new -macro, EILSEQ" -

    - -

    -ISO/IEC 14882:1998(E) section 19.3 does not refer -to the above amendment. -

    - - - -

    Proposed resolution:

    -

    -Update Table 26 (section 19.3) "Header <cerrno> synopsis" -and Table 95 (section C.2) "Standard Macros" to include EILSEQ. -

    - - - - - -
    -

    291. Underspecification of set algorithms

    -

    Section: 25.3.5 [alg.set.operations] Status: WP - Submitter: Matt Austern Date: 2001-01-03

    -

    View all other issues in [alg.set.operations].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -The standard library contains four algorithms that compute set -operations on sorted ranges: set_union, set_intersection, -set_difference, and set_symmetric_difference. Each -of these algorithms takes two sorted ranges as inputs, and writes the -output of the appropriate set operation to an output range. The elements -in the output range are sorted. -

    - -

    -The ordinary mathematical definitions are generalized so that they -apply to ranges containing multiple copies of a given element. Two -elements are considered to be "the same" if, according to an -ordering relation provided by the user, neither one is less than the -other. So, for example, if one input range contains five copies of an -element and another contains three, the output range of set_union -will contain five copies, the output range of -set_intersection will contain three, the output range of -set_difference will contain two, and the output range of -set_symmetric_difference will contain two. -

    - -

    -Because two elements can be "the same" for the purposes -of these set algorithms, without being identical in other respects -(consider, for example, strings under case-insensitive comparison), -this raises a number of unanswered questions: -

    - -
      -
    • If we're copying an element that's present in both of the -input ranges, which one do we copy it from?
      • -
    • If there are n copies of an element in the relevant -input range, and the output range will contain fewer copies (say -m) which ones do we choose? The first m, or the last -m, or something else?
      • -
    • Are these operations stable? That is, does a run of equivalent -elements appear in the output range in the same order as as it -appeared in the input range(s)?
      • -
    - -

    -The standard should either answer these questions, or explicitly -say that the answers are unspecified. I prefer the former option, -since, as far as I know, all existing implementations behave the -same way. -

    - - - -

    Proposed resolution:

    - -

    Add the following to the end of 25.3.5.2 [set.union] paragraph 5:

    -

    -If [first1, last1) contains m elements that are equivalent to -each other and [first2, last2) contains n elements that are -equivalent to them, then max(m, n) of these elements -will be copied to the output range: all m of these elements -from [first1, last1), and the last max(n-m, 0) of them from -[first2, last2), in that order. -

    - -

    Add the following to the end of 25.3.5.3 [set.intersection] paragraph 5:

    -

    -If [first1, last1) contains m elements that are equivalent to each -other and [first2, last2) contains n elements that are -equivalent to them, the first min(m, n) of those -elements from [first1, last1) are copied to the output range. -

    - -

    Add a new paragraph, Notes, after 25.3.5.4 [set.difference] -paragraph 4:

    -

    -If [first1, last1) contains m elements that are equivalent to each -other and [first2, last2) contains n elements that are -equivalent to them, the last max(m-n, 0) elements from -[first1, last1) are copied to the output range. -

    - -

    Add a new paragraph, Notes, after 25.3.5.5 [set.symmetric.difference] -paragraph 4:

    -

    -If [first1, last1) contains m elements that are equivalent to -each other and [first2, last2) contains n elements that are -equivalent to them, then |m - n| of those elements will be -copied to the output range: the last m - n of these elements -from [first1, last1) if m > n, and the last n - -m of these elements from [first2, last2) if m < n. -

    - -

    [Santa Cruz: it's believed that this language is clearer than - what's in the Standard. However, it's also believed that the - Standard may already make these guarantees (although not quite in - these words). Bill and Howard will check and see whether they think - that some or all of these changes may be redundant. If so, we may - close this issue as NAD.]

    - - - - -

    Rationale:

    -

    For simple cases, these descriptions are equivalent to what's - already in the Standard. For more complicated cases, they describe - the behavior of existing implementations.

    - - - - - -
    -

    292. effects of a.copyfmt (a)

    -

    Section: 27.4.4.2 [basic.ios.members] Status: WP - Submitter: Martin Sebor Date: 2001-01-05

    -

    View other active issues in [basic.ios.members].

    -

    View all other issues in [basic.ios.members].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    The Effects clause of the member function copyfmt() in -27.4.4.2, p15 doesn't consider the case where the left-hand side -argument is identical to the argument on the right-hand side, that is -(this == &rhs). If the two arguments are identical there -is no need to copy any of the data members or call any callbacks -registered with register_callback(). Also, as Howard Hinnant -points out in message c++std-lib-8149 it appears to be incorrect to -allow the object to fire erase_event followed by -copyfmt_event since the callback handling the latter event -may inadvertently attempt to access memory freed by the former. -

    - - -

    Proposed resolution:

    -

    Change the Effects clause in 27.4.4.2, p15 from

    - -

    --15- Effects:Assigns to the member objects of *this -the corresponding member objects of rhs, except that... -

    - -

    to

    - -

    --15- Effects:If (this == &rhs) does nothing. Otherwise -assigns to the member objects of *this the corresponding member -objects of rhs, except that... -

    - - - - -
    -

    294. User defined macros and standard headers

    -

    Section: 17.4.3.2.1 [macro.names] Status: WP - Submitter: James Kanze Date: 2001-01-11

    -

    View all issues with WP status.

    -

    Discussion:

    -

    Paragraph 2 of 17.4.3.2.1 [macro.names] reads: "A -translation unit that includes a header shall not contain any macros -that define names declared in that header." As I read this, it -would mean that the following program is legal:

    - -
      #define npos 3.14
-  #include <sstream>
-
    - -

    since npos is not defined in <sstream>. It is, however, defined -in <string>, and it is hard to imagine an implementation in -which <sstream> didn't include <string>.

    - -

    I think that this phrase was probably formulated before it was -decided that a standard header may freely include other standard -headers. The phrase would be perfectly appropriate for C, for -example. In light of 17.4.4.1 [res.on.headers] paragraph 1, however, -it isn't stringent enough.

    - - -

    Proposed resolution:

    -

    For 17.4.3.2.1 [macro.names], replace the current wording, which reads:

    -
    -

    Each name defined as a macro in a header is reserved to the - implementation for any use if the translation unit includes - the header.168)

    - -

    A translation unit that includes a header shall not contain any - macros that define names declared or defined in that header. Nor shall - such a translation unit define macros for names lexically - identical to keywords.

    - -

    168) It is not permissible to remove a library macro definition by - using the #undef directive.

    -
    - -

    with the wording:

    - -
    -

    A translation unit that includes a standard library header shall not - #define or #undef names declared in any standard library header.

    - -

    A translation unit shall not #define or #undef names lexically - identical to keywords.

    -
    - -

    [Lillehammer: Beman provided new wording]

    - - - - - - -
    -

    295. Is abs defined in <cmath>?

    -

    Section: 26.7 [c.math] Status: WP - Submitter: Jens Maurer Date: 2001-01-12

    -

    View all other issues in [c.math].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -Table 80 lists the contents of the <cmath> header. It does not -list abs(). However, 26.5, paragraph 6, which lists added -signatures present in <cmath>, does say that several overloads -of abs() should be defined in <cmath>. -

    - - -

    Proposed resolution:

    -

    -Add abs to Table 80. Also, remove the parenthetical list -of functions "(abs(), div(), rand(), srand())" from 26.5 [numarray], -paragraph 1. -

    - -

    [Copenhagen: Modified proposed resolution so that it also gets -rid of that vestigial list of functions in paragraph 1.]

    - - - - -

    Rationale:

    -

    All this DR does is fix a typo; it's uncontroversial. A -separate question is whether we're doing the right thing in -putting some overloads in <cmath> that we aren't also -putting in <cstdlib>. That's issue 323.

    - - - - - -
    -

    297. const_mem_fun_t<>::argument_type should be const T*

    -

    Section: 20.6.8 [logical.operations] Status: WP - Submitter: Martin Sebor Date: 2001-01-06

    -

    View all issues with WP status.

    -

    Discussion:

    -

    The class templates const_mem_fun_t in 20.5.8, p8 and -const_mem_fun1_t -in 20.5.8, p9 derive from unary_function<T*, S>, and -binary_function<T*, -A, S>, respectively. Consequently, their argument_type, and -first_argument_type -members, respectively, are both defined to be T* (non-const). -However, their function call member operator takes a const T* -argument. It is my opinion that argument_type should be const -T* instead, so that one can easily refer to it in generic code. The -example below derived from existing code fails to compile due to the -discrepancy: -

    - -

    template <class T> -
    void foo (typename T::argument_type arg)   // #1 -
    { -
        typename T::result_type (T::*pf) (typename -T::argument_type) -const =   // #2 -
            &T::operator(); -
    } -

    - -

    struct X { /* ... */ };

    - -

    int main () -
    { -
        const X x; -
        foo<std::const_mem_fun_t<void, X> ->(&x);   -// #3 -
    } -

    - -

    #1 foo() takes a plain unqualified X* as an argument -
    #2 the type of the pointer is incompatible with the type of the member -function -
    #3 the address of a constant being passed to a function taking a non-const -X* -

    - - -

    Proposed resolution:

    -

    Replace the top portion of the definition of the class template -const_mem_fun_t in 20.5.8, p8 -

    -

    template <class S, class T> class const_mem_fun_t -
              : public -unary_function<T*, S> { -

    -

    with

    -

    template <class S, class T> class const_mem_fun_t -
              : public -unary_function<const T*, S> { -

    -

    Also replace the top portion of the definition of the class template -const_mem_fun1_t in 20.5.8, p9

    -

    template <class S, class T, class A> class const_mem_fun1_t -
              : public -binary_function<T*, A, S> { -

    -

    with

    -

    template <class S, class T, class A> class const_mem_fun1_t -
              : public -binary_function<const T*, A, S> { -

    - - -

    Rationale:

    -

    This is simply a contradiction: the argument_type typedef, -and the argument type itself, are not the same.

    - - - - - -
    -

    298. ::operator delete[] requirement incorrect/insufficient

    -

    Section: 18.5.1.2 [new.delete.array] Status: WP - Submitter: John A. Pedretti Date: 2001-01-10

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -The default behavior of operator delete[] described in 18.5.1.2, p12 - -namely that for non-null value of ptr, the operator reclaims storage -allocated by the earlier call to the default operator new[] - is not -correct in all cases. Since the specified operator new[] default -behavior is to call operator new (18.5.1.2, p4, p8), which can be -replaced, along with operator delete, by the user, to implement their -own memory management, the specified default behavior of operator -delete[] must be to call operator delete. -

    - - -

    Proposed resolution:

    -

    Change 18.5.1.2, p12 from

    -

    --12- Default behavior:

    -
      -
    • -For a null value of ptr , does nothing. -
      • -
    • -Any other value of ptr shall be a value returned -earlier by a call to the default operator new[](std::size_t). -[Footnote: The value must not have been invalidated by an intervening -call to operator delete[](void*) (17.4.3.8 [res.on.arguments]). ---- end footnote] -For such a non-null value of ptr , reclaims storage -allocated by the earlier call to the default operator new[]. -
      • -
    -
    - -

    to

    - -

    --12- Default behavior: Calls operator -delete(ptr) -or operator delete(ptr, std::nothrow) respectively. -

    -

    and expunge paragraph 13.

    - - - - -
    -

    300. list::merge() specification incomplete

    -

    Section: 23.2.4.4 [list.ops] Status: WP - Submitter: John Pedretti Date: 2001-01-23

    -

    View all other issues in [list.ops].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -The "Effects" clause for list::merge() (23.2.4.4 [list.ops], p23) -appears to be incomplete: it doesn't cover the case where the argument -list is identical to *this (i.e., this == &x). The requirement in the -note in p24 (below) is that x be empty after the merge which is surely -unintended in this case. -

    - - -

    Proposed resolution:

    -

    In 23.2.4.4 [list.ops], replace paragraps 23-25 with:

    -
    -

    -23 Effects: if (&x == this) does nothing; otherwise, merges the two -sorted ranges [begin(), end()) and [x.begin(), x.end()). The result -is a range in which the elements will be sorted in non-decreasing -order according to the ordering defined by comp; that is, for every -iterator i in the range other than the first, the condition comp(*i, -*(i - 1)) will be false. -

    - -

    -24 Notes: Stable: if (&x != this), then for equivalent elements in the -two original ranges, the elements from the original range [begin(), -end()) always precede the elements from the original range [x.begin(), -x.end()). If (&x != this) the range [x.begin(), x.end()) is empty -after the merge. -

    - -

    -25 Complexity: At most size() + x.size() - 1 applications of comp if -(&x ! = this); otherwise, no applications of comp are performed. If -an exception is thrown other than by a comparison there are no -effects. -

    - -
    - -

    [Copenhagen: The original proposed resolution did not fix all of -the problems in 23.2.4.4 [list.ops], p22-25. Three different -paragraphs (23, 24, 25) describe the effects of merge. -Changing p23, without changing the other two, appears to introduce -contradictions. Additionally, "merges the argument list into the -list" is excessively vague.]

    - - -

    [Post-Curaçao: Robert Klarer provided new wording.]

    - - - - - - - -
    -

    301. basic_string template ctor effects clause omits allocator argument

    -

    Section: 21.3.1 [string.require] Status: WP - Submitter: Martin Sebor Date: 2001-01-27

    -

    View all other issues in [string.require].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -The effects clause for the basic_string template ctor in 21.3.1, p15 -leaves out the third argument of type Allocator. I believe this to be -a mistake. -

    - - -

    Proposed resolution:

    -

    Replace

    - -
    -

    -15- Effects: If InputIterator is an integral - type, equivalent to

    - -

    basic_string(static_cast<size_type>(begin), - static_cast<value_type>(end))

    -
    - -

    with

    - -
    -

    -15- Effects: If InputIterator is an integral - type, equivalent to

    - -

    basic_string(static_cast<size_type>(begin), - static_cast<value_type>(end), a)

    -
    - - - - -
    -

    303. Bitset input operator underspecified

    -

    Section: 23.3.5.3 [bitset.operators] Status: WP - Submitter: Matt Austern Date: 2001-02-05

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -In 23.3.5.3, we are told that bitset's input operator -"Extracts up to N (single-byte) characters from -is.", where is is a stream of type -basic_istream<charT, traits>. -

    - -

    -The standard does not say what it means to extract single byte -characters from a stream whose character type, charT, is in -general not a single-byte character type. Existing implementations -differ. -

    - -

    -A reasonable solution will probably involve widen() and/or -narrow(), since they are the supplied mechanism for -converting a single character between char and -arbitrary charT. -

    - -

    Narrowing the input characters is not the same as widening the -literals '0' and '1', because there may be some -locales in which more than one wide character maps to the narrow -character '0'. Narrowing means that alternate -representations may be used for bitset input, widening means that -they may not be.

    - -

    Note that for numeric input, num_get<> -(22.2.2.1.2/8) compares input characters to widened version of narrow -character literals.

    - -

    From Pete Becker, in c++std-lib-8224:

    -
    -

    -Different writing systems can have different representations for the -digits that represent 0 and 1. For example, in the Unicode representation -of the Devanagari script (used in many of the Indic languages) the digit 0 -is 0x0966, and the digit 1 is 0x0967. Calling narrow would translate those -into '0' and '1'. But Unicode also provides the ASCII values 0x0030 and -0x0031 for for the Latin representations of '0' and '1', as well as code -points for the same numeric values in several other scripts (Tamil has no -character for 0, but does have the digits 1-9), and any of these values -would also be narrowed to '0' and '1'. -

    - -

    ...

    - -

    -It's fairly common to intermix both native and Latin -representations of numbers in a document. So I think the rule has to be -that if a wide character represents a digit whose value is 0 then the bit -should be cleared; if it represents a digit whose value is 1 then the bit -should be set; otherwise throw an exception. So in a Devanagari locale, -both 0x0966 and 0x0030 would clear the bit, and both 0x0967 and 0x0031 -would set it. Widen can't do that. It would pick one of those two values, -and exclude the other one. -

    - -
    - -

    From Jens Maurer, in c++std-lib-8233:

    - -
    -

    -Whatever we decide, I would find it most surprising if -bitset conversion worked differently from int conversion -with regard to alternate local representations of -numbers. -

    - -

    Thus, I think the options are:

    -
      -
    • Have a new defect issue for 22.2.2.1.2/8 so that it will -require the use of narrow().
      • - -
    • Have a defect issue for bitset() which describes clearly -that widen() is to be used.
      • -
    -
    - - - -

    Proposed resolution:

    - -

    Replace the first two sentences of paragraph 5 with:

    - -

    - Extracts up to N characters from is. Stores these - characters in a temporary object str of type - basic_string<charT, traits>, then evaluates the - expression x = bitset<N>(str). -

    - -

    Replace the third bullet item in paragraph 5 with:

    -
    • - the next input character is neither is.widen(0) - nor is.widen(1) (in which case the input character - is not extracted). -
    - - - -

    Rationale:

    -

    Input for bitset should work the same way as numeric -input. Using widen does mean that alternative digit -representations will not be recognized, but this was a known -consequence of the design choice.

    - - - - - -
    -

    305. Default behavior of codecvt<wchar_t, char, mbstate_t>::length()

    -

    Section: 22.2.1.5 [locale.codecvt.byname] Status: WP - Submitter: Howard Hinnant Date: 2001-01-24

    -

    View all other issues in [locale.codecvt.byname].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    22.2.1.5/3 introduces codecvt in part with:

    - -

    - codecvt<wchar_t,char,mbstate_t> converts between the native - character sets for tiny and wide characters. Instantiations on - mbstate_t perform conversion between encodings known to the library - implementor. -

    - -

    But 22.2.1.5.2/10 describes do_length in part with:

    - -

    - ... codecvt<wchar_t, char, mbstate_t> ... return(s) the lesser of max and - (from_end-from). -

    - -

    -The semantics of do_in and do_length are linked. What one does must -be consistent with what the other does. 22.2.1.5/3 leads me to -believe that the vendor is allowed to choose the algorithm that -codecvt<wchar_t,char,mbstate_t>::do_in performs so that it makes -his customers happy on a given platform. But 22.2.1.5.2/10 explicitly -says what codecvt<wchar_t,char,mbstate_t>::do_length must -return. And thus indirectly specifies the algorithm that -codecvt<wchar_t,char,mbstate_t>::do_in must perform. I believe -that this is not what was intended and is a defect. -

    - -

    Discussion from the -lib reflector: - -
    This proposal would have the effect of making the semantics of -all of the virtual functions in codecvt<wchar_t, char, -mbstate_t> implementation specified. Is that what we want, or -do we want to mandate specific behavior for the base class virtuals -and leave the implementation specified behavior for the codecvt_byname -derived class? The tradeoff is that former allows implementors to -write a base class that actually does something useful, while the -latter gives users a way to get known and specified---albeit -useless---behavior, and is consistent with the way the standard -handles other facets. It is not clear what the original intention -was.

    - -

    -Nathan has suggest a compromise: a character that is a widened version -of the characters in the basic execution character set must be -converted to a one-byte sequence, but there is no such requirement -for characters that are not part of the basic execution character set. -

    - - -

    Proposed resolution:

    -

    -Change 22.2.1.5.2/5 from: -

    -

    -The instantiations required in Table 51 (lib.locale.category), namely -codecvt<wchar_t,char,mbstate_t> and -codecvt<char,char,mbstate_t>, store no characters. Stores no more -than (to_limit-to) destination elements. It always leaves the to_next -pointer pointing one beyond the last element successfully stored. -

    -

    -to: -

    -

    -Stores no more than (to_limit-to) destination elements, and leaves the -to_next pointer pointing one beyond the last element successfully -stored. codecvt<char,char,mbstate_t> stores no characters. -

    - -

    Change 22.2.1.5.2/10 from:

    - -

    --10- Returns: (from_next-from) where from_next is the largest value in -the range [from,from_end] such that the sequence of values in the -range [from,from_next) represents max or fewer valid complete -characters of type internT. The instantiations required in Table 51 -(21.1.1.1.1), namely codecvt<wchar_t, char, mbstate_t> and -codecvt<char, char, mbstate_t>, return the lesser of max and -(from_end-from). -

    - -

    to:

    - -

    --10- Returns: (from_next-from) where from_next is the largest value in -the range [from,from_end] such that the sequence of values in the range -[from,from_next) represents max or fewer valid complete characters of -type internT. The instantiation codecvt<char, char, mbstate_t> returns -the lesser of max and (from_end-from). -

    - -

    [Redmond: Nathan suggested an alternative resolution: same as -above, but require that, in the default encoding, a character from the -basic execution character set would map to a single external -character. The straw poll was 8-1 in favor of the proposed -resolution.]

    - - - - -

    Rationale:

    -

    The default encoding should be whatever users of a given platform -would expect to be the most natural. This varies from platform to -platform. In many cases there is a preexisting C library, and users -would expect the default encoding to be whatever C uses in the default -"C" locale. We could impose a guarantee like the one Nathan suggested -(a character from the basic execution character set must map to a -single external character), but this would rule out important -encodings that are in common use: it would rule out JIS, for -example, and it would rule out a fixed-width encoding of UCS-4.

    - -

    [Curaçao: fixed rationale typo at the request of Ichiro Koshida; -"shift-JIS" changed to "JIS".]

    - - - - - - - -
    -

    306. offsetof macro and non-POD types

    -

    Section: 18.1 [support.types] Status: WP - Submitter: Steve Clamage Date: 2001-02-21

    -

    View all other issues in [support.types].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    Spliced together from reflector messages c++std-lib-8294 and -8295:

    - -

    18.1, paragraph 5, reads: "The macro offsetof -accepts a restricted set of type arguments in this -International Standard. type shall be a POD structure or a POD -union (clause 9). The result of applying the offsetof macro to a field -that is a static data member or a function member is -undefined."

    - -

    For the POD requirement, it doesn't say "no diagnostic -required" or "undefined behavior". I read 1.4 [intro.compliance], paragraph 1, to mean that a diagnostic is required. -It's not clear whether this requirement was intended. While it's -possible to provide such a diagnostic, the extra complication doesn't -seem to add any value. -

    - - -

    Proposed resolution:

    -

    Change 18.1, paragraph 5, to "If type is not a POD -structure or a POD union the results are undefined."

    - -

    [Copenhagen: straw poll was 7-4 in favor. It was generally -agreed that requiring a diagnostic was inadvertent, but some LWG -members thought that diagnostics should be required whenever -possible.]

    - - - - - - -
    -

    307. Lack of reference typedefs in container adaptors

    -

    Section: 23.2.4 [list] Status: WP - Submitter: Howard Hinnant Date: 2001-03-13

    -

    View all issues with WP status.

    -

    Discussion:

    - -

    From reflector message c++std-lib-8330. See also lib-8317.

    - -

    -The standard is currently inconsistent in 23.2.4.2 [list.capacity] -paragraph 1 and 23.2.4.3 [list.modifiers] paragraph 1. -23.2.3.3/1, for example, says: -

    - -

    --1- Any sequence supporting operations back(), push_back() and pop_back() -can be used to instantiate stack. In particular, vector (lib.vector), list -(lib.list) and deque (lib.deque) can be used. -

    - -

    But this is false: vector<bool> can not be used, because the -container adaptors return a T& rather than using the underlying -container's reference type.

    - -

    This is a contradiction that can be fixed by:

    - -
      -
    1. Modifying these paragraphs to say that vector<bool> - is an exception.
      2. -
    2. Removing the vector<bool> specialization.
      3. -
    3. Changing the return types of stack and priority_queue to use - reference typedef's.
      4. -
    - -

    -I propose 3. This does not preclude option 2 if we choose to do it -later (see issue 96); the issues are independent. Option -3 offers a small step towards support for proxied containers. This -small step fixes a current contradiction, is easy for vendors to -implement, is already implemented in at least one popular lib, and -does not break any code. -

    - - - -

    Proposed resolution:

    -

    Summary: Add reference and const_reference typedefs to queue, -priority_queue and stack. Change return types of "value_type&" to -"reference". Change return types of "const value_type&" to -"const_reference". Details:

    - -

    Change 23.2.3.1/1 from:

    - -
      namespace std {
-    template <class T, class Container = deque<T> >
-    class queue {
-    public:
-      typedef typename Container::value_type            value_type;
-      typedef typename Container::size_type             size_type;
-      typedef          Container                        container_type;
-    protected:
-      Container c;
-
-    public:
-      explicit queue(const Container& = Container());
-
-      bool      empty() const             { return c.empty(); }
-      size_type size()  const             { return c.size(); }
-      value_type&       front()           { return c.front(); }
-      const value_type& front() const     { return c.front(); }
-      value_type&       back()            { return c.back(); }
-      const value_type& back() const      { return c.back(); }
-      void push(const value_type& x)      { c.push_back(x); }
-      void pop()                          { c.pop_front(); }
-    };
-
    - -

    to:

    - -
      namespace std {
-    template <class T, class Container = deque<T> >
-    class queue {
-    public:
-      typedef typename Container::value_type            value_type;
-      typedef typename Container::reference             reference;
-      typedef typename Container::const_reference       const_reference;
-      typedef typename Container::value_type            value_type;
-      typedef typename Container::size_type             size_type;
-      typedef          Container                        container_type;
-    protected:
-      Container c;
-
-    public:
-      explicit queue(const Container& = Container());
-
-      bool      empty() const             { return c.empty(); }
-      size_type size()  const             { return c.size(); }
-      reference         front()           { return c.front(); }
-      const_reference   front() const     { return c.front(); }
-      reference         back()            { return c.back(); }
-      const_reference   back() const      { return c.back(); }
-      void push(const value_type& x)      { c.push_back(x); }
-      void pop()                          { c.pop_front(); }
-    };
-
    - -

    Change 23.2.3.2/1 from:

    - -
      namespace std {
-    template <class T, class Container = vector<T>,
-              class Compare = less<typename Container::value_type> >
-    class priority_queue {
-    public:
-      typedef typename Container::value_type            value_type;
-      typedef typename Container::size_type             size_type;
-      typedef          Container                        container_type;
-    protected:
-      Container c;
-      Compare comp;
-
-    public:
-      explicit priority_queue(const Compare& x = Compare(),
-                              const Container& = Container());
-      template <class InputIterator>
-        priority_queue(InputIterator first, InputIterator last,
-                       const Compare& x = Compare(),
-                       const Container& = Container());
-
-      bool      empty() const       { return c.empty(); }
-      size_type size()  const       { return c.size(); }
-      const value_type& top() const { return c.front(); }
-      void push(const value_type& x);
-      void pop();
-    };
-                                  //  no equality is provided
-  }
-
    - -

    to:

    - -
      namespace std {
-    template <class T, class Container = vector<T>,
-              class Compare = less<typename Container::value_type> >
-    class priority_queue {
-    public:
-      typedef typename Container::value_type            value_type;
-      typedef typename Container::reference             reference;
-      typedef typename Container::const_reference       const_reference;
-      typedef typename Container::size_type             size_type;
-      typedef          Container                        container_type;
-    protected:
-      Container c;
-      Compare comp;
-
-    public:
-      explicit priority_queue(const Compare& x = Compare(),
-                              const Container& = Container());
-      template <class InputIterator>
-        priority_queue(InputIterator first, InputIterator last,
-                       const Compare& x = Compare(),
-                       const Container& = Container());
-
-      bool      empty() const       { return c.empty(); }
-      size_type size()  const       { return c.size(); }
-      const_reference   top() const { return c.front(); }
-      void push(const value_type& x);
-      void pop();
-    };
-                                  //  no equality is provided
-  }
-
    - -

    And change 23.2.3.3/1 from:

    - -
      namespace std {
-    template <class T, class Container = deque<T> >
-    class stack {
-    public:
-      typedef typename Container::value_type            value_type;
-      typedef typename Container::size_type             size_type;
-      typedef          Container                        container_type;
-    protected:
-      Container c;
-
-    public:
-      explicit stack(const Container& = Container());
-
-      bool      empty() const             { return c.empty(); }
-      size_type size()  const             { return c.size(); }
-      value_type&       top()             { return c.back(); }
-      const value_type& top() const       { return c.back(); }
-      void push(const value_type& x)      { c.push_back(x); }
-      void pop()                          { c.pop_back(); }
-    };
-
-    template <class T, class Container>
-      bool operator==(const stack<T, Container>& x,
-                      const stack<T, Container>& y);
-    template <class T, class Container>
-      bool operator< (const stack<T, Container>& x,
-                      const stack<T, Container>& y);
-    template <class T, class Container>
-      bool operator!=(const stack<T, Container>& x,
-                      const stack<T, Container>& y);
-    template <class T, class Container>
-      bool operator> (const stack<T, Container>& x,
-                      const stack<T, Container>& y);
-    template <class T, class Container>
-      bool operator>=(const stack<T, Container>& x,
-                      const stack<T, Container>& y);
-    template <class T, class Container>
-      bool operator<=(const stack<T, Container>& x,
-                      const stack<T, Container>& y);
-  }
-
    - -

    to:

    - -
      namespace std {
-    template <class T, class Container = deque<T> >
-    class stack {
-    public:
-      typedef typename Container::value_type            value_type;
-      typedef typename Container::reference             reference;
-      typedef typename Container::const_reference       const_reference;
-      typedef typename Container::size_type             size_type;
-      typedef          Container                        container_type;
-    protected:
-      Container c;
-
-    public:
-      explicit stack(const Container& = Container());
-
-      bool      empty() const             { return c.empty(); }
-      size_type size()  const             { return c.size(); }
-      reference         top()             { return c.back(); }
-      const_reference   top() const       { return c.back(); }
-      void push(const value_type& x)      { c.push_back(x); }
-      void pop()                          { c.pop_back(); }
-    };
-
-    template <class T, class Container>
-      bool operator==(const stack<T, Container>& x,
-                      const stack<T, Container>& y);
-    template <class T, class Container>
-      bool operator< (const stack<T, Container>& x,
-                      const stack<T, Container>& y);
-    template <class T, class Container>
-      bool operator!=(const stack<T, Container>& x,
-                      const stack<T, Container>& y);
-    template <class T, class Container>
-      bool operator> (const stack<T, Container>& x,
-                      const stack<T, Container>& y);
-    template <class T, class Container>
-      bool operator>=(const stack<T, Container>& x,
-                      const stack<T, Container>& y);
-    template <class T, class Container>
-      bool operator<=(const stack<T, Container>& x,
-                      const stack<T, Container>& y);
-  }
-
    - -

    [Copenhagen: This change was discussed before the IS was released -and it was deliberately not adopted. Nevertheless, the LWG believes -(straw poll: 10-2) that it is a genuine defect.]

    - - - - - - -
    -

    308. Table 82 mentions unrelated headers

    -

    Section: 27 [input.output] Status: WP - Submitter: Martin Sebor Date: 2001-03-15

    -

    View all other issues in [input.output].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -Table 82 in section 27 mentions the header <cstdlib> for String -streams (27.7 [string.streams]) and the headers <cstdio> and -<cwchar> for File streams (27.8 [file.streams]). It's not clear -why these headers are mentioned in this context since they do not -define any of the library entities described by the -subclauses. According to 17.4.1.1 [contents], only such headers -are to be listed in the summary. -

    - - -

    Proposed resolution:

    -

    Remove <cstdlib> and <cwchar> from -Table 82.

    - -

    [Copenhagen: changed the proposed resolution slightly. The -original proposed resolution also said to remove <cstdio> from -Table 82. However, <cstdio> is mentioned several times within -section 27.8 [file.streams], including 27.8.2 [c.files].]

    - - - - - - -
    -

    310. Is errno a macro?

    -

    Section: 17.4.1.2 [headers], 19.3 [errno] Status: WP - Submitter: Steve Clamage Date: 2001-03-21

    -

    View all other issues in [headers].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    - Exactly how should errno be declared in a conforming C++ header? -

    - -

    - The C standard says in 7.1.4 that it is unspecified whether errno is a - macro or an identifier with external linkage. In some implementations - it can be either, depending on compile-time options. (E.g., on - Solaris in multi-threading mode, errno is a macro that expands to a - function call, but is an extern int otherwise. "Unspecified" allows - such variability.) -

    - -

    The C++ standard:

    -
      -
    • 17.4.1.2 says in a note that errno must be macro in C. (false)
      • -
    • 17.4.3.1.3 footnote 166 says errno is reserved as an external - name (true), and implies that it is an identifier.
      • -
    • 19.3 simply lists errno as a macro (by what reasoning?) and goes - on to say that the contents of of C++ <errno.h> are the - same as in C, begging the question.
      • -
    • C.2, table 95 lists errno as a macro, without comment.
      • -
    - -

    I find no other references to errno.

    - -

    We should either explicitly say that errno must be a macro, even - though it need not be a macro in C, or else explicitly leave it - unspecified. We also need to say something about namespace std. - A user who includes <cerrno> needs to know whether to write - errno, or ::errno, or std::errno, or - else <cerrno> is useless.

    - -

    Two acceptable fixes:

    -
      -

    • errno must be a macro. This is trivially satisfied by adding
      -   #define errno (::std::errno)
      - to the headers if errno is not already a macro. You then always - write errno without any scope qualification, and it always expands - to a correct reference. Since it is always a macro, you know to - avoid using errno as a local identifer.

      • -

    • errno is in the global namespace. This fix is inferior, because - ::errno is not guaranteed to be well-formed.

      • -
    - -

    [ - This issue was first raised in 1999, but it slipped through - the cracks. - ]

    - - - -

    Proposed resolution:

    -

    Change the Note in section 17.4.1.2p5 from

    - -

    - Note: the names defined as macros in C include the following: - assert, errno, offsetof, setjmp, va_arg, va_end, and va_start. -

    - -

    to

    - -

    - Note: the names defined as macros in C include the following: - assert, offsetof, setjmp, va_arg, va_end, and va_start. -

    - -

    In section 19.3, change paragraph 2 from

    - -

    - The contents are the same as the Standard C library header - <errno.h>. -

    - -

    to

    - -

    - The contents are the same as the Standard C library header - <errno.h>, except that errno shall be defined as a macro. -

    - - -

    Rationale:

    -

    C++ must not leave it up to the implementation to decide whether or -not a name is a macro; it must explicitly specify exactly which names -are required to be macros. The only one that really works is for it -to be a macro.

    - -

    [Curaçao: additional rationale added.]

    - - - - - - - -
    -

    311. Incorrect wording in basic_ostream class synopsis

    -

    Section: 27.6.2.1 [ostream] Status: WP - Submitter: Andy Sawyer Date: 2001-03-21

    -

    View all other issues in [ostream].

    -

    View all issues with WP status.

    -

    Discussion:

    - -

    In 27.6.2.1 [ostream], the synopsis of class basic_ostream says:

    - -
      // partial specializationss
-  template<class traits>
-    basic_ostream<char,traits>& operator<<( basic_ostream<char,traits>&,
-                                            const char * );
-
    - -

    Problems:

    -
      -
    • Too many 's's at the end of "specializationss"
      • -
    • This is an overload, not a partial specialization
      • -
    - - - -

    Proposed resolution:

    -

    In the synopsis in 27.6.2.1 [ostream], remove the -// partial specializationss comment. Also remove the same -comment (correctly spelled, but still incorrect) from the synopsis in -27.6.2.6.4 [ostream.inserters.character]. -

    - -

    [ -Pre-Redmond: added 27.6.2.6.4 [ostream.inserters.character] because of Martin's -comment in c++std-lib-8939. -]

    - - - - - - - -
    -

    312. Table 27 is missing headers

    -

    Section: 20 [utilities] Status: WP - Submitter: Martin Sebor Date: 2001-03-29

    -

    View all issues with WP status.

    -

    Discussion:

    -

    Table 27 in section 20 lists the header <memory> (only) for -Memory (lib.memory) but neglects to mention the headers -<cstdlib> and <cstring> that are discussed in 20.5.5 [meta.rel].

    - - -

    Proposed resolution:

    -

    Add <cstdlib> and <cstring> to Table 27, in the same row -as <memory>.

    - - - - - -
    -

    315. Bad "range" in list::unique complexity

    -

    Section: 23.2.4.4 [list.ops] Status: WP - Submitter: Andy Sawyer Date: 2001-05-01

    -

    View all other issues in [list.ops].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -23.2.4.4 [list.ops], Para 21 describes the complexity of -list::unique as: "If the range (last - first) is not empty, exactly -(last - first) -1 applications of the corresponding predicate, -otherwise no applications of the predicate)". -

    - -

    -"(last - first)" is not a range. -

    - - -

    Proposed resolution:

    -

    -Change the "range" from (last - first) to [first, last). -

    - - - - -
    -

    316. Vague text in Table 69

    -

    Section: 23.1.4 [associative.reqmts] Status: WP - Submitter: Martin Sebor Date: 2001-05-04

    -

    View all other issues in [associative.reqmts].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    Table 69 says this about a_uniq.insert(t):

    - -

    -inserts t if and only if there is no element in the container with key -equivalent to the key of t. The bool component of the returned pair -indicates whether the insertion takes place and the iterator component of the -pair points to the element with key equivalent to the key of t. -

    - -

    The description should be more specific about exactly how the bool component -indicates whether the insertion takes place.

    - - -

    Proposed resolution:

    -

    Change the text in question to

    - -

    -...The bool component of the returned pair is true if and only if the insertion -takes place... -

    - - - - - -
    -

    317. Instantiation vs. specialization of facets

    -

    Section: 22 [localization] Status: WP - Submitter: Martin Sebor Date: 2001-05-04

    -

    View all other issues in [localization].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -The localization section of the standard refers to specializations of -the facet templates as instantiations even though the required facets -are typically specialized rather than explicitly (or implicitly) -instantiated. In the case of ctype<char> and -ctype_byname<char> (and the wchar_t versions), these facets are -actually required to be specialized. The terminology should be -corrected to make it clear that the standard doesn't mandate explicit -instantiation (the term specialization encompasses both explicit -instantiations and specializations). -

    - - -

    Proposed resolution:

    -

    -In the following paragraphs, replace all occurrences of the word -instantiation or instantiations with specialization or specializations, -respectively: -

    - -

    -22.1.1.1.1, p4, Table 52, 22.2.1.1, p2, 22.2.1.5, p3, 22.2.1.5.1, p5, -22.2.1.5.2, p10, 22.2.2, p2, 22.2.3.1, p1, 22.2.3.1.2, p1, p2 and p3, -22.2.4.1, p1, 22.2.4.1.2, p1, 22,2,5, p1, 22,2,6, p2, 22.2.6.3.2, p7, and -Footnote 242. -

    - -

    And change the text in 22.1.1.1.1, p4 from

    - -

    - An implementation is required to provide those instantiations - for facet templates identified as members of a category, and - for those shown in Table 52: -

    - -

    to

    - -

    - An implementation is required to provide those specializations... -

    - -

    [Nathan will review these changes, and will look for places where -explicit specialization is necessary.]

    - - - - -

    Rationale:

    -

    This is a simple matter of outdated language. The language to -describe templates was clarified during the standardization process, -but the wording in clause 22 was never updated to reflect that -change.

    - - - - - - - -
    -

    318. Misleading comment in definition of numpunct_byname

    -

    Section: 22.2.3.2 [locale.numpunct.byname] Status: WP - Submitter: Martin Sebor Date: 2001-05-12

    -

    View all issues with WP status.

    -

    Discussion:

    -

    The definition of the numpunct_byname template contains the following -comment:

    - -
        namespace std {
-        template <class charT>
-        class numpunct_byname : public numpunct<charT> {
-    // this class is specialized for char and wchar_t.
-        ...
-
    - -

    There is no documentation of the specializations and it seems -conceivable that an implementation will not explicitly specialize the -template at all, but simply provide the primary template.

    - - -

    Proposed resolution:

    -

    Remove the comment from the text in 22.2.3.2 and from the proposed -resolution of library issue 228.

    - - - - -
    -

    319. Storage allocation wording confuses "Required behavior", "Requires"

    -

    Section: 18.5.1.1 [new.delete.single], 18.5.1.2 [new.delete.array] Status: WP - Submitter: Beman Dawes Date: 2001-05-15

    -

    View all other issues in [new.delete.single].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    The standard specifies 17.3.1.3 [structure.specifications] that "Required -behavior" elements describe "the semantics of a function definition -provided by either the implementation or a C++ program."

    - -

    The standard specifies 17.3.1.3 [structure.specifications] that "Requires" -elements describe "the preconditions for calling the function."

    - -

    In the sections noted below, the current wording specifies -"Required Behavior" for what are actually preconditions, and thus -should be specified as "Requires".

    - - - -

    Proposed resolution:

    - -

    In 18.5.1.1 [new.delete.single] Para 12 Change:

    -
    -

    Required behavior: accept a value of ptr that is null or that was - returned by an earlier call ...

    -
    -

    to:

    -
    -

    Requires: the value of ptr is null or the value returned by an - earlier call ...

    -
    - -

    In 18.5.1.2 [new.delete.array] Para 11 Change:

    -
    -

    Required behavior: accept a value of ptr that is null or that was - returned by an earlier call ...

    -
    -

    to:

    -
    -

    Requires: the value of ptr is null or the value returned by an - earlier call ...

    -
    - - - - - -
    -

    320. list::assign overspecified

    -

    Section: 23.2.4.1 [list.cons] Status: WP - Submitter: Howard Hinnant Date: 2001-05-17

    -

    View all other issues in [list.cons].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -Section 23.2.4.1 [list.cons], paragraphs 6-8 specify that list assign (both forms) have -the "effects" of a call to erase followed by a call to insert. -

    - -

    -I would like to document that implementers have the freedom to implement -assign by other methods, as long as the end result is the same and the -exception guarantee is as good or better than the basic guarantee. -

    - -

    -The motivation for this is to use T's assignment operator to recycle -existing nodes in the list instead of erasing them and reallocating -them with new values. It is also worth noting that, with careful -coding, most common cases of assign (everything but assignment with -true input iterators) can elevate the exception safety to strong if -T's assignment has a nothrow guarantee (with no extra memory cost). -Metrowerks does this. However I do not propose that this subtlety be -standardized. It is a QoI issue.

    - -

    Existing practise: -Metrowerks and SGI recycle nodes, Dinkumware and Rogue Wave don't. -

    - - -

    Proposed resolution:

    -

    Change 23.2.4.1 [list.cons]/7 from:

    - -
    -

    Effects:

    - -
       erase(begin(), end());
-   insert(begin(), first, last);
-
    -
    - -

    to:

    - -
    -

    Effects: Replaces the contents of the list with the range [first, last).

    -
    - -

    In 23.1.3 [sequence.reqmts], in Table 67 (sequence requirements), -add two new rows:

    -
          a.assign(i,j)     void      pre: i,j are not iterators into a.
-                                  Replaces elements in a with a copy
-                                  of [i, j).
-
-      a.assign(n,t)     void      pre: t is not a reference into a.
-                                  Replaces elements in a with n copies
-                                  of t.
-
    - -

    Change 23.2.4.1 [list.cons]/8 from:

    - -
    -

    Effects:

    -
       erase(begin(), end());
-   insert(begin(), n, t);
-
    -
    -

    to:

    - -
    -

    Effects: Replaces the contents of the list with n copies of t.

    -
    - -

    [Redmond: Proposed resolution was changed slightly. Previous -version made explicit statement about exception safety, which wasn't -consistent with the way exception safety is expressed elsewhere. -Also, the change in the sequence requirements is new. Without that -change, the proposed resolution would have required that assignment of -a subrange would have to work. That too would have been -overspecification; it would effectively mandate that assignment use a -temporary. Howard provided wording. -]

    - - -

    [Curaçao: Made editorial improvement in wording; changed -"Replaces elements in a with copies of elements in [i, j)." -with "Replaces the elements of a with a copy of [i, j)." -Changes not deemed serious enough to requre rereview.]

    - - - - - - - -
    -

    321. Typo in num_get

    -

    Section: 22.2.2.1.2 [facet.num.get.virtuals] Status: WP - Submitter: Kevin Djang Date: 2001-05-17

    -

    View other active issues in [facet.num.get.virtuals].

    -

    View all other issues in [facet.num.get.virtuals].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -Section 22.2.2.1.2 at p7 states that "A length specifier is added to -the conversion function, if needed, as indicated in Table 56." -However, Table 56 uses the term "length modifier", not "length -specifier". -

    - - -

    Proposed resolution:

    -

    -In 22.2.2.1.2 at p7, change the text "A length specifier is added ..." -to be "A length modifier is added ..." -

    - - -

    Rationale:

    -

    C uses the term "length modifier". We should be consistent.

    - - - - - - -
    -

    322. iterator and const_iterator should have the same value type

    -

    Section: 23.1 [container.requirements] Status: WP - Submitter: Matt Austern Date: 2001-05-17

    -

    View other active issues in [container.requirements].

    -

    View all other issues in [container.requirements].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -It's widely assumed that, if X is a container, -iterator_traits<X::iterator>::value_type and -iterator_traits<X::const_iterator>::value_type should both be -X::value_type. However, this is nowhere stated. The language in -Table 65 is not precise about the iterators' value types (it predates -iterator_traits), and could even be interpreted as saying that -iterator_traits<X::const_iterator>::value_type should be "const -X::value_type". -

    - -

    Related issue: 279.

    - - -

    Proposed resolution:

    -

    In Table 65 ("Container Requirements"), change the return type for -X::iterator to "iterator type whose value type is T". Change the -return type for X::const_iterator to "constant iterator type whose -value type is T".

    - - -

    Rationale:

    -

    -This belongs as a container requirement, rather than an iterator -requirement, because the whole notion of iterator/const_iterator -pairs is specific to containers' iterator. -

    -

    -It is existing practice that (for example) -iterator_traits<list<int>::const_iterator>::value_type -is "int", rather than "const int". This is consistent with -the way that const pointers are handled: the standard already -requires that iterator_traits<const int*>::value_type is int. -

    - - - - - -
    -

    324. Do output iterators have value types?

    -

    Section: 24.1.2 [output.iterators] Status: WP - Submitter: Dave Abrahams Date: 2001-06-07

    -

    View all other issues in [output.iterators].

    -

    View all issues with WP status.

    -

    Discussion:

    - -

    Table 73 suggests that output iterators have value types. It -requires the expression "*a = t". Additionally, although Table 73 -never lists "a = t" or "X(a) = t" in the "expressions" column, it -contains a note saying that "a = t" and "X(a) = t" have equivalent -(but nowhere specified!) semantics.

    - -

    According to 24.1/9, t is supposed to be "a value of value type -T":

    - -

    - In the following sections, a and b denote values of X, n denotes a - value of the difference type Distance, u, tmp, and m denote - identifiers, r denotes a value of X&, t denotes a value of - value type T. -

    - -

    Two other parts of the standard that are relevant to whether -output iterators have value types:

    - -
      -
    • 24.1/1 says "All iterators i support the expression *i, - resulting in a value of some class, enumeration, or built-in type - T, called the value type of the iterator".
      • - -
    • - 24.3.1/1, which says "In the case of an output iterator, the types - iterator_traits<Iterator>::difference_type - iterator_traits<Iterator>::value_type are both defined as void." -
      • -
    - -

    The first of these passages suggests that "*i" is supposed to -return a useful value, which contradicts the note in 24.1.2/2 saying -that the only valid use of "*i" for output iterators is in an -expression of the form "*i = t". The second of these passages appears -to contradict Table 73, because it suggests that "*i"'s return value -should be void. The second passage is also broken in the case of a an -iterator type, like non-const pointers, that satisfies both the output -iterator requirements and the forward iterator requirements.

    - -

    What should the standard say about *i's return value when -i is an output iterator, and what should it say about that t is in the -expression "*i = t"? Finally, should the standard say anything about -output iterators' pointer and reference types?

    - - - -

    Proposed resolution:

    -

    24.1 p1, change

    - -
    -

    All iterators i support the expression *i, resulting -in a value of some class, enumeration, or built-in type T, -called the value type of the iterator.

    -
    - -

    to

    - -
    -

    All input iterators i support the expression *i, -resulting in a value of some class, enumeration, or built-in type -T, called the value type of the iterator. All output -iterators support the expression *i = o where o is a -value of some type that is in the set of types that are writable to -the particular iterator type of i. -

    -
    - -

    24.1 p9, add

    - -
    -

    o denotes a value of some type that is writable to the -output iterator. -

    -
    - -

    Table 73, change

    - -
    -
    *a = t
-
    -
    - -

    to

    - -
    -
    *r = o
-
    -
    - -

    and change

    - -
    -
    *r++ = t
-
    -
    - -

    to

    - -
    -
    *r++ = o
-
    -
    - -

    [post-Redmond: Jeremy provided wording]

    - - - - -

    Rationale:

    -

    The LWG considered two options: change all of the language that -seems to imply that output iterators have value types, thus making it -clear that output iterators have no value types, or else define value -types for output iterator consistently. The LWG chose the former -option, because it seems clear that output iterators were never -intended to have value types. This was a deliberate design decision, -and any language suggesting otherwise is simply a mistake.

    - -

    A future revision of the standard may wish to revisit this design -decision.

    - - - - - -
    -

    325. Misleading text in moneypunct<>::do_grouping

    -

    Section: 22.2.6.3.2 [locale.moneypunct.virtuals] Status: WP - Submitter: Martin Sebor Date: 2001-07-02

    -

    View all other issues in [locale.moneypunct.virtuals].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    The Returns clause in 22.2.6.3.2, p3 says about -moneypunct<charT>::do_grouping() -

    - -

    - Returns: A pattern defined identically as the result of - numpunct<charT>::do_grouping().241) -

    - -

    Footnote 241 then reads

    - -

    - This is most commonly the value "\003" (not "3"). -

    - -

    -The returns clause seems to imply that the two member functions must -return an identical value which in reality may or may not be true, -since the facets are usually implemented in terms of struct std::lconv -and return the value of the grouping and mon_grouping, respectively. -The footnote also implies that the member function of the moneypunct -facet (rather than the overridden virtual functions in moneypunct_byname) -most commonly return "\003", which contradicts the C standard which -specifies the value of "" for the (most common) C locale. -

    - - - -

    Proposed resolution:

    -

    Replace the text in Returns clause in 22.2.6.3.2, p3 with the following:

    - -

    - Returns: A pattern defined identically as, but not necessarily - equal to, the result of numpunct<charT>::do_grouping().241) -

    - -

    and replace the text in Footnote 241 with the following:

    - -

    - To specify grouping by 3s the value is "\003", not "3". -

    - - -

    Rationale:

    -

    -The fundamental problem is that the description of the locale facet -virtuals serves two purposes: describing the behavior of the base -class, and describing the meaning of and constraints on the behavior -in arbitrary derived classes. The new wording makes that separation a -little bit clearer. The footnote (which is nonnormative) is not -supposed to say what the grouping is in the "C" locale or in any other -locale. It is just a reminder that the values are interpreted as small -integers, not ASCII characters. -

    - - - - -
    -

    327. Typo in time_get facet in table 52

    -

    Section: 22.1.1.1.1 [locale.category] Status: WP - Submitter: Tiki Wan Date: 2001-07-06

    -

    View all other issues in [locale.category].

    -

    View all issues with WP status.

    -

    Duplicate of: 447

    -

    Discussion:

    -

    The wchar_t versions of time_get and -time_get_byname are listed incorrectly in table 52, -required instantiations. In both cases the second template -parameter is given as OutputIterator. It should instead be -InputIterator, since these are input facets.

    - - -

    Proposed resolution:

    -

    -In table 52, required instantiations, in -22.1.1.1.1 [locale.category], change

    -
        time_get<wchar_t, OutputIterator>
-    time_get_byname<wchar_t, OutputIterator>
-
    -

    to

    -
        time_get<wchar_t, InputIterator>
-    time_get_byname<wchar_t, InputIterator>
-
    - -

    [Redmond: Very minor change in proposed resolution. Original had -a typo, wchart instead of wchar_t.]

    - - - - - - -
    -

    328. Bad sprintf format modifier in money_put<>::do_put()

    -

    Section: 22.2.6.2.2 [locale.money.put.virtuals] Status: WP - Submitter: Martin Sebor Date: 2001-07-07

    -

    View all issues with WP status.

    -

    Discussion:

    -

    The sprintf format string , "%.01f" (that's the digit one), in the -description of the do_put() member functions of the money_put facet in -22.2.6.2.2, p1 is incorrect. First, the f format specifier is wrong -for values of type long double, and second, the precision of 01 -doesn't seem to make sense. What was most likely intended was -"%.0Lf"., that is a precision of zero followed by the L length -modifier.

    - - -

    Proposed resolution:

    -

    Change the format string to "%.0Lf".

    - - -

    Rationale:

    Fixes an obvious typo

    - - - - -
    -

    329. vector capacity, reserve and reallocation

    -

    Section: 23.2.6.2 [vector.capacity], 23.2.6.4 [vector.modifiers] Status: WP - Submitter: Anthony Williams Date: 2001-07-13

    -

    View all other issues in [vector.capacity].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -There is an apparent contradiction about which circumstances can cause -a reallocation of a vector in Section 23.2.6.2 [vector.capacity] and -section 23.2.6.4 [vector.modifiers]. -

    - -

    23.2.6.2 [vector.capacity],p5 says:

    -

    -Notes: Reallocation invalidates all the references, pointers, and iterators -referring to the elements in the sequence. It is guaranteed that no -reallocation takes place during insertions that happen after a call to -reserve() until the time when an insertion would make the size of the vector -greater than the size specified in the most recent call to reserve(). -

    - -

    Which implies if I do

    - -
      std::vector<int> vec;
-  vec.reserve(23);
-  vec.reserve(0);
-  vec.insert(vec.end(),1);
-
    - -

    then the implementation may reallocate the vector for the insert, -as the size specified in the previous call to reserve was zero.

    - -

    However, the previous paragraphs (23.2.6.2 [vector.capacity], p1-2) state:

    -
    -

    -(capacity) Returns: The total number of elements the vector -can hold without requiring reallocation -

    -

    -...After reserve(), capacity() is greater or equal to the -argument of reserve if reallocation happens; and equal to the previous value -of capacity() otherwise... -

    -
    - -

    -This implies that vec.capacity() is still 23, and so the insert() -should not require a reallocation, as vec.size() is 0. This is backed -up by 23.2.6.4 [vector.modifiers], p1: -

    -

    -(insert) Notes: Causes reallocation if the new size is greater than the old -capacity. -

    - -

    -Though this doesn't rule out reallocation if the new size is less -than the old capacity, I think the intent is clear. -

    - - - -

    Proposed resolution:

    -

    Change the wording of 23.2.6.2 [vector.capacity] paragraph 5 to:

    - -

    -Notes: Reallocation invalidates all the references, pointers, and -iterators referring to the elements in the sequence. It is guaranteed -that no reallocation takes place during insertions that happen after a -call to reserve() until the time when an insertion would make the size -of the vector greater than the value of capacity(). -

    - -

    [Redmond: original proposed resolution was modified slightly. In -the original, the guarantee was that there would be no reallocation -until the size would be greater than the value of capacity() after the -most recent call to reserve(). The LWG did not believe that the -"after the most recent call to reserve()" added any useful -information.]

    - - - - -

    Rationale:

    -

    There was general agreement that, when reserve() is called twice in -succession and the argument to the second invocation is smaller than -the argument to the first, the intent was for the second invocation to -have no effect. Wording implying that such cases have an effect on -reallocation guarantees was inadvertant.

    - - - - - -
    -

    331. bad declaration of destructor for ios_base::failure

    -

    Section: 27.4.2.1.1 [ios::failure] Status: WP - Submitter: PremAnand M. Rao Date: 2001-08-23

    -

    View all other issues in [ios::failure].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -With the change in 17.4.4.9 [res.on.exception.handling] to state - "An implementation may strengthen the exception-specification for a - non-virtual function by removing listed exceptions." -(issue 119) -and the following declaration of ~failure() in ios_base::failure -

    -
        namespace std {
-       class ios_base::failure : public exception {
-       public:
-           ...
-           virtual ~failure();
-           ...
-       };
-     }
-
    -

    the class failure cannot be implemented since in 18.6.1 [type.info] the destructor of class exception has an empty -exception specification:

    -
        namespace std {
-       class exception {
-       public:
-         ...
-         virtual ~exception() throw();
-         ...
-       };
-     }
-
    - - -

    Proposed resolution:

    -

    Remove the declaration of ~failure().

    - - -

    Rationale:

    -

    The proposed resolution is consistent with the way that destructors -of other classes derived from exception are handled.

    - - - - - - - -
    -

    333. does endl imply synchronization with the device?

    -

    Section: 27.6.2.8 [ostream.manip] Status: WP - Submitter: PremAnand M. Rao Date: 2001-08-27

    -

    View all issues with WP status.

    -

    Discussion:

    -

    A footnote in 27.6.2.8 [ostream.manip] states:

    -

    - [Footnote: The effect of executing cout << endl is to insert a - newline character in the output sequence controlled by cout, then - synchronize it with any external file with which it might be - associated. --- end foonote] -

    - -

    -Does the term "file" here refer to the external device? -This leads to some implementation ambiguity on systems with fully -buffered files where a newline does not cause a flush to the device. -

    - -

    -Choosing to sync with the device leads to significant performance -penalties for each call to endl, while not sync-ing leads to -errors under special circumstances. -

    - -

    -I could not find any other statement that explicitly defined -the behavior one way or the other. -

    - - -

    Proposed resolution:

    -

    Remove footnote 300 from section 27.6.2.8 [ostream.manip].

    - - -

    Rationale:

    -

    We already have normative text saying what endl does: it -inserts a newline character and calls flush. This footnote -is at best redundant, at worst (as this issue says) misleading, -because it appears to make promises about what flush -does.

    - - - - - - - -
    -

    334. map::operator[] specification forces inefficient implementation

    -

    Section: 23.3.1.2 [map.access] Status: WP - Submitter: Andrea Griffini Date: 2001-09-02

    -

    View all other issues in [map.access].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -The current standard describes map::operator[] using a -code example. That code example is however quite -inefficient because it requires several useless copies -of both the passed key_type value and of default -constructed mapped_type instances. -My opinion is that was not meant by the comitee to -require all those temporary copies. -

    - -

    Currently map::operator[] behaviour is specified as:

    -
      Returns:
-    (*((insert(make_pair(x, T()))).first)).second.
-
    - -

    -This specification however uses make_pair that is a -template function of which parameters in this case -will be deduced being of type const key_type& and -const T&. This will create a pair<key_type,T> that -isn't the correct type expected by map::insert so -another copy will be required using the template -conversion constructor available in pair to build -the required pair<const key_type,T> instance. -

    - -

    If we consider calling of key_type copy constructor -and mapped_type default constructor and copy -constructor as observable behaviour (as I think we -should) then the standard is in this place requiring -two copies of a key_type element plus a default -construction and two copy construction of a mapped_type -(supposing the addressed element is already present -in the map; otherwise at least another copy -construction for each type). -

    - -

    A simple (half) solution would be replacing the description with:

    -
      Returns:
-    (*((insert(value_type(x, T()))).first)).second.
-
    - -

    This will remove the wrong typed pair construction that -requires one extra copy of both key and value.

    - -

    However still the using of map::insert requires temporary -objects while the operation, from a logical point of view, -doesn't require any.

    - -

    I think that a better solution would be leaving free an -implementer to use a different approach than map::insert -that, because of its interface, forces default constructed -temporaries and copies in this case. -The best solution in my opinion would be just requiring -map::operator[] to return a reference to the mapped_type -part of the contained element creating a default element -with the specified key if no such an element is already -present in the container. Also a logarithmic complexity -requirement should be specified for the operation. -

    - -

    -This would allow library implementers to write alternative -implementations not using map::insert and reaching optimal -performance in both cases of the addressed element being -present or absent from the map (no temporaries at all and -just the creation of a new pair inside the container if -the element isn't present). -Some implementer has already taken this option but I think -that the current wording of the standard rules that as -non-conforming. -

    - - - -

    Proposed resolution:

    - -

    -Replace 23.3.1.2 [map.access] paragraph 1 with -

    -
    -

    --1- Effects: If there is no key equivalent to x in the map, inserts -value_type(x, T()) into the map. -

    -

    --2- Returns: A reference to the mapped_type corresponding to x in *this. -

    -

    --3- Complexity: logarithmic. -

    -
    - -

    [This is the second option mentioned above. Howard provided -wording. We may also wish to have a blanket statement somewhere in -clause 17 saying that we do not intend the semantics of sample code -fragments to be interpreted as specifing exactly how many copies are -made. See issue 98 for a similar problem.]

    - - - - -

    Rationale:

    -

    -This is the second solution described above; as noted, it is -consistent with existing practice. -

    - -

    Note that we now need to specify the complexity explicitly, because -we are no longer defining operator[] in terms of -insert.

    - - - - - -
    -

    335. minor issue with char_traits, table 37

    -

    Section: 21.1.1 [char.traits.require] Status: WP - Submitter: Andy Sawyer Date: 2001-09-06

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -Table 37, in 21.1.1 [char.traits.require], descibes char_traits::assign -as: -

    -
      X::assign(c,d)   assigns c = d.
-
    - -

    And para 1 says:

    - -

    - [...] c and d denote values of type CharT [...] -

    - -

    -Naturally, if c and d are values, then the assignment is -(effectively) meaningless. It's clearly intended that (in the case of -assign, at least), 'c' is intended to be a reference type. -

    - -

    I did a quick survey of the four implementations I happened to have -lying around, and sure enough they all have signatures:

    -
        assign( charT&, const charT& );
-
    - -

    (or the equivalent). It's also described this way in Nico's book. -(Not to mention the synopses of char_traits<char> in 21.1.3.1 -and char_traits<wchar_t> in 21.1.3.2...) -

    - - -

    Proposed resolution:

    -

    Add the following to 21.1.1 para 1:

    -

    - r denotes an lvalue of CharT -

    - -

    and change the description of assign in the table to:

    -
      X::assign(r,d)   assigns r = d
-
    - - - - - -
    -

    336. Clause 17 lack of references to deprecated headers

    -

    Section: 17 [library] Status: WP - Submitter: Detlef Vollmann Date: 2001-09-05

    -

    View all other issues in [library].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    From c++std-edit-873:

    - -

    17.4.1.2 [headers], Table 11. In this table, the header -<strstream> is missing.

    - -

    This shows a general problem: The whole clause 17 refers quite -often to clauses 18 through 27, but D.7 is also a part of the standard -library (though a deprecated one).

    - - - -

    Proposed resolution:

    - -

    To 17.4.1.2 [headers] Table 11, C++ Library Headers, add -"<strstream>".

    - -

    In the following places, change "clauses 17 through 27" to "clauses -17 through 27 and Annex D":

    - -
      -
    • 1.2 [intro.refs] Normative references/1/footnote 1
      • -
    • 1.3 [intro.defs] Definitions/1
      • -
    • 7 [dcl.dcl] Library introduction/9
      • -
    • 17.3 [description] Method of description (Informative)/1
      • -
    • 17.3.2.1.3 [character.seq] Character sequences/1/bullet 2
      • -
    • 17.3.2.2 [functions.within.classes] Functions within classes/1
      • -
    • 17.3.2.3 [objects.within.classes] Private members/1/(2 places)
      • -
    • 17.4 [requirements] Library-wide requirements/1
      • -
    • 17.4.1.2 [headers] Headers/4
      • -
    • 17.4.3.5 [replacement.functions] Replacement functions/1
      • -
    • 17.4.4.3 [global.functions] Global or non-member functions/2
      • -
    • 17.4.4.7 [protection.within.classes] Protection within classes/1
      • -
    - - - - - - - -
    -

    337. replace_copy_if's template parameter should be InputIterator

    -

    Section: 25.2.5 [alg.replace] Status: WP - Submitter: Detlef Vollmann Date: 2001-09-07

    -

    View all other issues in [alg.replace].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    From c++std-edit-876:

    - -

    -In section 25.2.5 [alg.replace] before p4: The name of the first -parameter of template replace_copy_if should be "InputIterator" -instead of "Iterator". According to 17.3.2.1 [type.descriptions] p1 the -parameter name conveys real normative meaning. -

    - - -

    Proposed resolution:

    -

    Change Iterator to InputIterator.

    - - - - - -
    -

    338. is whitespace allowed between `-' and a digit?

    -

    Section: 22.2 [locale.categories] Status: WP - Submitter: Martin Sebor Date: 2001-09-17

    -

    View other active issues in [locale.categories].

    -

    View all other issues in [locale.categories].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -From Stage 2 processing in 22.2.2.1.2 [facet.num.get.virtuals], p8 and 9 (the -original text or the text corrected by the proposed resolution of -issue 221) it seems clear that no whitespace is allowed -within a number, but 22.2.3.1 [locale.numpunct], p2, which gives the -format for integer and floating point values, says that whitespace is -optional between a plusminus and a sign. -

    - -

    -The text needs to be clarified to either consistently allow or -disallow whitespace between a plusminus and a sign. It might be -worthwhile to consider the fact that the C library stdio facility does -not permit whitespace embedded in numbers and neither does the C or -C++ core language (the syntax of integer-literals is given in 2.13.1 -[lex.icon], that of floating-point-literals in 2.13.3 [lex.fcon] of the -C++ standard). -

    - - -

    Proposed resolution:

    -

    Change the first part of 22.2.3.1 [locale.numpunct] paragraph 2 from:

    -
    -

    -The syntax for number formats is as follows, where digit -represents the radix set specified by the fmtflags argument -value, whitespace is as determined by the facet -ctype<charT> (22.2.1.1), and thousands-sep and -decimal-point are the results of corresponding -numpunct<charT> members. Integer values have the -format: -

    -
      integer   ::= [sign] units
-  sign      ::= plusminus [whitespace]
-  plusminus ::= '+' | '-'
-  units     ::= digits [thousands-sep units]
-  digits    ::= digit [digits]
-
    -
    -

    to:

    -
    -

    -The syntax for number formats is as follows, where digit -represents the radix set specified by the fmtflags argument -value, and thousands-sep and decimal-point are the -results of corresponding numpunct<charT> members. -Integer values have the format: -

    -
      integer   ::= [sign] units
-  sign      ::= plusminus
-  plusminus ::= '+' | '-'
-  units     ::= digits [thousands-sep units]
-  digits    ::= digit [digits]
-
    -
    - - -

    Rationale:

    -

    It's not clear whether the format described in 22.2.3.1 [locale.numpunct] paragraph 2 has any normative weight: nothing in the -standard says how, or whether, it's used. However, there's no reason -for it to differ gratuitously from the very specific description of -numeric processing in 22.2.2.1.2 [facet.num.get.virtuals]. The proposed -resolution removes all mention of "whitespace" from that format.

    - - - - - -
    -

    339. definition of bitmask type restricted to clause 27

    -

    Section: 22.2.1 [category.ctype], 17.3.2.1.2 [bitmask.types] Status: WP - Submitter: Martin Sebor Date: 2001-09-17

    -

    View all other issues in [category.ctype].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    The ctype_category::mask type is declared to be an enum in 22.2.1 -[category.ctype] with p1 then stating that it is a bitmask type, most -likely referring to the definition of bitmask type in 17.3.2.1.2 -[bitmask.types], p1. However, the said definition only applies to -clause 27, making the reference in 22.2.1 somewhat dubious. -

    - - -

    Proposed resolution:

    -

    Clarify 17.3.2.1.2, p1 by changing the current text from

    -

    - Several types defined in clause 27 are bitmask types. Each bitmask type - can be implemented as an enumerated type that overloads certain operators, - as an integer type, or as a bitset (23.3.5 [template.bitset]). -

    -

    to read

    -

    - Several types defined in clauses lib.language.support through - lib.input.output and Annex D are bitmask types. Each bitmask type can - be implemented as an enumerated type that overloads certain operators, - as an integer type, or as a bitset (lib.template.bitset). -

    - -

    -Additionally, change the definition in 22.2.1 to adopt the same -convention as in clause 27 by replacing the existing text with the -following (note, in particluar, the cross-reference to 17.3.2.1.2 in -22.2.1, p1): -

    - -
    -

    22.2.1 The ctype category [lib.category.ctype]

    -
    namespace std {
-    class ctype_base {
-    public:
-        typedef T mask;
-
-        // numeric values are for exposition only.
-        static const mask space = 1 << 0;
-        static const mask print = 1 << 1;
-        static const mask cntrl = 1 << 2;
-        static const mask upper = 1 << 3;
-        static const mask lower = 1 << 4;
-        static const mask alpha = 1 << 5;
-        static const mask digit = 1 << 6;
-        static const mask punct = 1 << 7;
-        static const mask xdigit = 1 << 8;
-        static const mask alnum = alpha | digit;
-        static const mask graph = alnum | punct;
-    };
-}
-
    - -

    The type mask is a bitmask type (17.3.2.1.2 [bitmask.types]).

    -
    - -

    [Curaçao: The LWG notes that T above should be bold-italics to be -consistent with the rest of the standard.]

    - - - - - - - - - -
    -

    340. interpretation of has_facet<Facet>(loc)

    -

    Section: 22.1.1.1.1 [locale.category] Status: WP - Submitter: Martin Sebor Date: 2001-09-18

    -

    View all other issues in [locale.category].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -It's unclear whether 22.1.1.1.1, p3 says that -has_facet<Facet>(loc) returns true for any Facet -from Table 51 or whether it includes Table 52 as well: -

    - -

    -For any locale loc either constructed, or returned by -locale::classic(), and any facet Facet that is a member of a -standard category, has_facet<Facet>(loc) is true. Each -locale member function which takes a locale::category -argument operates on the corresponding set of facets. -

    - -

    -It seems that it comes down to which facets are considered to be members of a -standard category. Intuitively, I would classify all the facets in Table 52 as -members of their respective standard categories, but there are an unbounded set -of them... -

    - -

    -The paragraph implies that, for instance, has_facet<num_put<C, -OutputIterator> >(loc) must always return true. I don't think that's -possible. If it were, then use_facet<num_put<C, OutputIterator> ->(loc) would have to return a reference to a distinct object for each -valid specialization of num_put<C, OutputIteratory>, which is -clearly impossible. -

    - -

    -On the other hand, if none of the facets in Table 52 is a member of a standard -category then none of the locale member functions that operate on entire -categories of facets will work properly. -

    - -

    -It seems that what p3 should mention that it's required (permitted?) -to hold only for specializations of Facet from Table 52 on -C from the set { char, wchar_t }, and -InputIterator and OutputIterator from the set of -{ -{i,o}streambuf_iterator<{char,wchar_t}> -}. -

    - - -

    Proposed resolution:

    -

    In 22.1.1.1.1 [locale.category], paragraph 3, change -"that is a member of a standard category" to "shown in Table 51".

    - - -

    Rationale:

    -

    The facets in Table 52 are an unbounded set. Locales should not be -required to contain an infinite number of facets.

    - -

    It's not necessary to talk about which values of InputIterator and -OutputIterator must be supported. Table 51 already contains a -complete list of the ones we need.

    - - - - - - -
    -

    341. Vector reallocation and swap

    -

    Section: 23.2.6.2 [vector.capacity] Status: WP - Submitter: Anthony Williams Date: 2001-09-27

    -

    View all other issues in [vector.capacity].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    It is a common idiom to reduce the capacity of a vector by swapping it with -an empty one:

    -
      std::vector<SomeType> vec;
-  // fill vec with data
-  std::vector<SomeType>().swap(vec);
-  // vec is now empty, with minimal capacity
-
    - -

    However, the wording of 23.2.6.2 [vector.capacity]paragraph 5 prevents -the capacity of a vector being reduced, following a call to -reserve(). This invalidates the idiom, as swap() is thus prevented -from reducing the capacity. The proposed wording for issue 329 does not affect this. Consequently, the example above -requires the temporary to be expanded to cater for the contents of -vec, and the contents be copied across. This is a linear-time -operation.

    - -

    However, the container requirements state that swap must have constant -complexity (23.1 [container.requirements] note to table 65).

    - -

    This is an important issue, as reallocation affects the validity of -references and iterators.

    - -

    If the wording of 23.2.4.2p5 is taken to be the desired intent, then -references and iterators remain valid after a call to swap, if they refer to -an element before the new end() of the vector into which they originally -pointed, in which case they refer to the element at the same index position. -Iterators and references that referred to an element whose index position -was beyond the new end of the vector are invalidated.

    - -

    If the note to table 65 is taken as the desired intent, then there are two -possibilities with regard to iterators and references:

    - -
      -
    1. All Iterators and references into both vectors are invalidated.
      2. -
    2. Iterators and references into either vector remain valid, and remain -pointing to the same element. Consequently iterators and references that -referred to one vector now refer to the other, and vice-versa.
      3. -
    - - -

    Proposed resolution:

    -

    Add a new paragraph after 23.2.6.2 [vector.capacity] paragraph 5:

    -
    -
      void swap(vector<T,Allocator>& x);
-
    -

    Effects: Exchanges the contents and capacity() of *this -with that of x.

    -

    Complexity: Constant time.

    -
    - -

    [This solves the problem reported for this issue. We may also -have a problem with a circular definition of swap() for other -containers.]

    - - - - -

    Rationale:

    -

    -swap should be constant time. The clear intent is that it should just -do pointer twiddling, and that it should exchange all properties of -the two vectors, including their reallocation guarantees. -

    - - - - - -
    -

    345. type tm in <cwchar>

    -

    Section: 21.5 [c.strings] Status: WP - Submitter: Clark Nelson Date: 2001-10-19

    -

    View all other issues in [c.strings].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    C99, and presumably amendment 1 to C90, specify that <wchar.h> -declares struct tm as an incomplete type. However, table 48 in 21.5 -[c.strings] does not mention the type tm as being declared in -<cwchar>. Is this omission intentional or accidental? -

    - - -

    Proposed resolution:

    -

    In section 21.5 [c.strings], add "tm" to table 48.

    - - - - - -
    -

    346. Some iterator member functions should be const

    -

    Section: 24.1 [iterator.requirements] Status: WP - Submitter: Jeremy Siek Date: 2001-10-20

    -

    View other active issues in [iterator.requirements].

    -

    View all other issues in [iterator.requirements].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    Iterator member functions and operators that do not change the state -of the iterator should be defined as const member functions or as -functions that take iterators either by const reference or by -value. The standard does not explicitly state which functions should -be const. Since this a fairly common mistake, the following changes -are suggested to make this explicit.

    - -

    The tables almost indicate constness properly through naming: r -for non-const and a,b for const iterators. The following changes -make this more explicit and also fix a couple problems.

    - - -

    Proposed resolution:

    -

    In 24.1 [iterator.requirements] Change the first section of p9 from -"In the following sections, a and b denote values of X..." to -"In the following sections, a and b denote values of type const X...".

    - -

    In Table 73, change

    -
        a->m   U&         ...
-
    - -

    to

    - -
        a->m   const U&   ...
-    r->m   U&         ...
-
    - -

    In Table 73 expression column, change

    - -
        *a = t
-
    - -

    to

    - -
        *r = t
-
    - -

    [Redmond: The container requirements should be reviewed to see if -the same problem appears there.]

    - - - - - - - -
    -

    347. locale::category and bitmask requirements

    -

    Section: 22.1.1.1.1 [locale.category] Status: WP - Submitter: P.J. Plauger, Nathan Myers Date: 2001-10-23

    -

    View all other issues in [locale.category].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -In 22.1.1.1.1 [locale.category] paragraph 1, the category members -are described as bitmask elements. In fact, the bitmask requirements -in 17.3.2.1.2 [bitmask.types] don't seem quite right: none -and all are bitmask constants, not bitmask elements.

    - -

    In particular, the requirements for none interact poorly -with the requirement that the LC_* constants from the C library must -be recognizable as C++ locale category constants. LC_* values should -not be mixed with these values to make category values.

    - -

    We have two options for the proposed resolution. Informally: -option 1 removes the requirement that LC_* values be recognized as -category arguments. Option 2 changes the category type so that this -requirement is implementable, by allowing none to be some -value such as 0x1000 instead of 0.

    - -

    Nathan writes: "I believe my proposed resolution [Option 2] merely -re-expresses the status quo more clearly, without introducing any -changes beyond resolving the DR.

    - - - -

    Proposed resolution:

    -

    Replace the first two paragraphs of 22.1.1.1 [locale.types] with:

    -
    -
        typedef int category;
-
    - -

    Valid category values include the locale member bitmask -elements collate, ctype, monetary, -numeric, time, and messages, each of which -represents a single locale category. In addition, locale member -bitmask constant none is defined as zero and represents no -category. And locale member bitmask constant all is defined such that -the expression

    -
        (collate | ctype | monetary | numeric | time | messages | all) == all
-
    -

    -is true, and represents the union of all categories. Further -the expression (X | Y), where X and Y each -represent a single category, represents the union of the two -categories. -

    - -

    -locale member functions expecting a category -argument require one of the category values defined above, or -the union of two or more such values. Such a category -argument identifies a set of locale categories. Each locale category, -in turn, identifies a set of locale facets, including at least those -shown in Table 51: -

    -
    -

    [Curaçao: need input from locale experts.]

    - - - - -

    Rationale:

    - -

    The LWG considered, and rejected, an alternate proposal (described - as "Option 2" in the discussion). The main reason for rejecting it - was that library implementors were concerened about implementation - difficult, given that getting a C++ library to work smoothly with a - separately written C library is already a delicate business. Some - library implementers were also concerned about the issue of adding - extra locale categories.

    - -
    -

    Option 2:
    -Replace the first paragraph of 22.1.1.1 [locale.types] with:

    -
    -

    -Valid category values include the enumerated values. In addition, the -result of applying commutative operators | and & to any two valid -values is valid, and results in the setwise union and intersection, -respectively, of the argument categories. The values all and -none are defined such that for any valid value cat, the -expressions (cat | all == all), (cat & all == cat), -(cat | none == cat) and (cat & none == none) are -true. For non-equal values cat1 and cat2 of the -remaining enumerated values, (cat1 & cat2 == none) is true. -For any valid categories cat1 and cat2, the result -of (cat1 & ~cat2) is valid, and equals the setwise union of -those categories found in cat1 but not found in cat2. -[Footnote: it is not required that all equal the setwise union -of the other enumerated values; implementations may add extra categories.] -

    -
    -
    - - - - - -
    -

    349. Minor typographical error in ostream_iterator

    -

    Section: 24.5.2 [ostream.iterator] Status: WP - Submitter: Andy Sawyer Date: 2001-10-24

    -

    View all issues with WP status.

    -

    Discussion:

    -

    24.5.2 [lib.ostream.iterator] states:

    -
        [...]
-
-    private:
-    // basic_ostream<charT,traits>* out_stream; exposition only
-    // const char* delim; exposition only
-
    - -

    Whilst it's clearly marked "exposition only", I suspect 'delim' -should be of type 'const charT*'.

    - - -

    Proposed resolution:

    -

    -In 24.5.2 [ostream.iterator], replace const char* delim with -const charT* delim. -

    - - - - - -
    -

    352. missing fpos requirements

    -

    Section: 21.1.2 [char.traits.typedefs] Status: WP - Submitter: Martin Sebor Date: 2001-12-02

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -(1) -There are no requirements on the stateT template parameter of -fpos listed in 27.4.3. The interface appears to require that -the type be at least Assignable and CopyConstructible (27.4.3.1, p1), -and I think also DefaultConstructible (to implement the operations in -Table 88). -

    -

    -21.1.2, p3, however, only requires that -char_traits<charT>::state_type meet the requirements of -CopyConstructible types. -

    -

    -(2) -Additionally, the stateT template argument has no -corresponding typedef in fpos which might make it difficult to use in -generic code. -

    - - -

    Proposed resolution:

    -

    -Modify 21.1.2, p4 from -

    -

    - Requires: state_type shall meet the requirements of - CopyConstructible types (20.1.3). -

    -

    - Requires: state_type shall meet the requirements of Assignable - (23.1, p4), CopyConstructible (20.1.3), and - DefaultConstructible (20.1.4) types. -

    - - - -

    Rationale:

    -

    The LWG feels this is two issues, as indicated above. The first is -a defect---std::basic_fstream is unimplementable without these -additional requirements---and the proposed resolution fixes it. The -second is questionable; who would use that typedef? The class -template fpos is used only in a very few places, all of which know the -state type already. Unless motivation is provided, the second should -be considered NAD.

    - - - - - -
    -

    354. Associative container lower/upper bound requirements

    -

    Section: 23.1.4 [associative.reqmts] Status: WP - Submitter: Hans Aberg Date: 2001-12-17

    -

    View all other issues in [associative.reqmts].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -Discussions in the thread "Associative container lower/upper bound -requirements" on comp.std.c++ suggests that there is a defect in the -C++ standard, Table 69 of section 23.1.2, "Associative containers", -[lib.associative.reqmts]. It currently says:

    - -
    -

    -a.find(k): returns an iterator pointing to an element with the key equivalent to -k, or a.end() if such an element is not found. -

    - -

    -a.lower_bound(k): returns an iterator pointing to the first element with -key not less than k. -

    - -

    -a.upper_bound(k): returns an iterator pointing to the first element with -key greater than k. -

    -
    - -

    -We have "or a.end() if such an element is not found" for -find, but not for upper_bound or -lower_bound. As the text stands, one would be forced to -insert a new element into the container and return an iterator to that -in case the sought iterator does not exist, which does not seem to be -the intention (and not possible with the "const" versions). -

    - - -

    Proposed resolution:

    - -

    Change Table 69 of section 23.1.4 [associative.reqmts] indicated entries -to:

    - -
    -

    -a.lower_bound(k): returns an iterator pointing to the first element with -key not less than k, or a.end() if such an element is not found. -

    - -

    -a.upper_bound(k): returns an iterator pointing to the first element with -key greater than k, or a.end() if such an element is not found. -

    -
    - -

    [Curaçao: LWG reviewed PR.]

    - - - - - - - - -
    -

    355. Operational semantics for a.back()

    -

    Section: 23.1.3 [sequence.reqmts] Status: WP - Submitter: Yaroslav Mironov Date: 2002-01-23

    -

    View all other issues in [sequence.reqmts].

    -

    View all issues with WP status.

    -

    Discussion:

    - -

    Table 68 "Optional Sequence Operations" in 23.1.1/12 -specifies operational semantics for "a.back()" as -"*--a.end()", which may be ill-formed [because calling -operator-- on a temporary (the return) of a built-in type is -ill-formed], provided a.end() returns a simple pointer rvalue -(this is almost always the case for std::vector::end(), for -example). Thus, the specification is not only incorrect, it -demonstrates a dangerous construct: "--a.end()" may -successfully compile and run as intended, but after changing the type -of the container or the mode of compilation it may produce -compile-time error.

    - - - -

    Proposed resolution:

    -

    Change the specification in table 68 "Optional Sequence -Operations" in 23.1.1/12 for "a.back()" from

    - - -
    *--a.end()
-
    - -

    to

    - -
      { iterator tmp = a.end(); --tmp; return *tmp; }
-
    - -

    and the specification for "a.pop_back()" from

    - -
    a.erase(--a.end())
-
    - -

    to

    - -
      { iterator tmp = a.end(); --tmp; a.erase(tmp); }
-
    - -

    [Curaçao: LWG changed PR from "{ X::iterator tmp = -a.end(); return *--tmp; }" to "*a.rbegin()", and from -"{ X::iterator tmp = a.end(); a.erase(--tmp); }" to -"a.erase(rbegin())".]

    - - -

    [There is a second possible defect; table 68 "Optional -Sequence Operations" in the "Operational Semantics" -column uses operations present only in the "Reversible -Container" requirements, yet there is no stated dependency -between these separate requirements tables. Ask in Santa Cruz if the -LWG would like a new issue opened.]

    - - -

    [Santa Cruz: the proposed resolution is even worse than what's in - the current standard: erase is undefined for reverse iterator. If - we're going to make the change, we need to define a temporary and - use operator--. Additionally, we don't know how prevalent this is: - do we need to make this change in more than one place? Martin has - volunteered to review the standard and see if this problem occurs - elsewhere.]

    - - -

    [Oxford: Matt provided new wording to address the concerns raised - in Santa Cruz. It does not appear that this problem appears - anywhere else in clauses 23 or 24.]

    - - -

    [Kona: In definition of operational semantics of back(), change -"*tmp" to "return *tmp;"]

    - - - - - - - -
    -

    358. interpreting thousands_sep after a decimal_point

    -

    Section: 22.2.2.1.2 [facet.num.get.virtuals] Status: WP - Submitter: Martin Sebor Date: 2002-03-12

    -

    View other active issues in [facet.num.get.virtuals].

    -

    View all other issues in [facet.num.get.virtuals].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -I don't think thousands_sep is being treated correctly after -decimal_point has been seen. Since grouping applies only to the -integral part of the number, the first such occurrence should, IMO, -terminate Stage 2. (If it does not terminate it, then 22.2.2.1.2, p12 -and 22.2.3.1.2, p3 need to explain how thousands_sep is to be -interpreted in the fractional part of a number.) -

    - -

    -The easiest change I can think of that resolves this issue would be -something like below. -

    - - -

    Proposed resolution:

    -

    -Change the first sentence of 22.2.2.1.2, p9 from -

    - -

    - If discard is true then the position of the character is - remembered, but the character is otherwise ignored. If it is not - discarded, then a check is made to determine if c is allowed as - the next character of an input field of the conversion specifier - returned by stage 1. If so it is accumulated. -

    - -

    to

    - -

    - If discard is true, then if '.' has not yet been - accumulated, then the position of the character is remembered, but - the character is otherwise ignored. Otherwise, if '.' has - already been accumulated, the character is discarded and Stage 2 - terminates. ... -

    - - - -

    Rationale:

    -

    We believe this reflects the intent of the Standard. Thousands sep - characters after the decimal point are not useful in any locale. - Some formatting conventions do group digits that follow the decimal - point, but they usually introduce a different grouping character - instead of reusing the thousand sep character. If we want to add - support for such conventions, we need to do so explicitly.

    - - - - - - -
    -

    359. num_put<>::do_put (..., bool) undocumented

    -

    Section: 22.2.2.2.1 [facet.num.put.members] Status: WP - Submitter: Martin Sebor Date: 2002-03-12

    -

    View all issues with WP status.

    -

    Discussion:

    -

    22.2.2.2.1, p1:

    - - 
        iter_type put (iter_type out, ios_base& str, char_type fill,
-                   bool val) const;
-    ...
-
-    1   Returns: do_put (out, str, fill, val).
-
    - -

    AFAICS, the behavior of do_put (..., bool) is not documented anywhere, -however, 22.2.2.2.2, p23:

    - -
    -
    iter_type put (iter_type out, ios_base& str, char_type fill,
-               bool val) const;
-
    - - -

    Effects: If (str.flags() & ios_base::boolalpha) == 0 then do - out = do_put(out, str, fill, (int)val) - Otherwise do

    -
                 string_type s =
-                 val ? use_facet<ctype<charT> >(loc).truename()
-                     : use_facet<ctype<charT> >(loc).falsename();
-
    -

    and then insert the characters of s into out. out.

    -
    - -

    -This means that the bool overload of do_put() will never be called, -which contradicts the first paragraph. Perhaps the declaration -should read do_put(), and not put()? -

    - -

    -Note also that there is no Returns clause for this function, which -should probably be corrected, just as should the second occurrence -of "out." in the text. -

    - -

    -I think the least invasive change to fix it would be something like -the following: -

    - - -

    Proposed resolution:

    -

    In 22.2.2.2.2 [facet.num.put.virtuals], just above paragraph 1, remove - the bool overload.

    - -

    -In 22.2.2.2.2 [facet.num.put.virtuals], p23, make the following changes -

    - -

    - Replace put() with do_put() in the declaration - of the member function. -

    - -

    - Change the Effects clause to a Returns clause (to - avoid the requirement to call do_put(..., int) from - do_put (..., bool)) - like so: -

    - -

    - 23 Returns: If (str.flags() & - ios_base::boolalpha) == 0 then - do_put (out, str, fill, (long)val) - Otherwise the function obtains a string s as if by

    -
                 string_type s =
-                val ? use_facet<ctype<charT> >(loc).truename()
-                    : use_facet<ctype<charT> >(loc).falsename();
-
    -

    and then inserts each character c of s into out via - *out++ = c - and returns out.

    -
    - - - -

    Rationale:

    -This fixes a couple of obvious typos, and also fixes what appears to -be a requirement of gratuitous inefficiency. -

    - - - - -
    -

    360. locale mandates inefficient implementation

    -

    Section: 22.1.1 [locale] Status: WP - Submitter: Martin Sebor Date: 2002-03-12

    -

    View all other issues in [locale].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -22.1.1, p7 (copied below) allows iostream formatters and extractors -to make assumptions about the values returned from facet members. -However, such assumptions are apparently not guaranteed to hold -in other cases (e.g., when the facet members are being called directly -rather than as a result of iostream calls, or between successive -calls to the same iostream functions with no interevening calls to -imbue(), or even when the facet member functions are called -from other member functions of other facets). This restriction -prevents locale from being implemented efficiently. -

    - - -

    Proposed resolution:

    -

    Change the first sentence in 22.1.1, p7 from

    -

    - In successive calls to a locale facet member function during - a call to an iostream inserter or extractor or a streambuf member - function, the returned result shall be identical. [Note: This - implies that such results may safely be reused without calling - the locale facet member function again, and that member functions - of iostream classes cannot safely call imbue() - themselves, except as specified elsewhere. --end note] -

    - -

    to

    - -

    - In successive calls to a locale facet member function on a facet - object installed in the same locale, the returned result shall be - identical. ... -

    - - - -

    Rationale:

    -

    This change is reasonable becuase it clarifies the intent of this - part of the standard.

    - - - - - -
    -

    362. bind1st/bind2nd type safety

    -

    Section: D.8 [depr.lib.binders] Status: WP - Submitter: Andrew Demkin Date: 2002-04-26

    -

    View all other issues in [depr.lib.binders].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -The definition of bind1st() (D.8 [depr.lib.binders]) can result in -the construction of an unsafe binding between incompatible pointer -types. For example, given a function whose first parameter type is -'pointer to T', it's possible without error to bind an argument of -type 'pointer to U' when U does not derive from T: -

    -
       foo(T*, int);
-
-   struct T {};
-   struct U {};
-
-   U u;
-
-   int* p;
-   int* q;
-
-   for_each(p, q, bind1st(ptr_fun(foo), &u));    // unsafe binding
-
    - -

    -The definition of bind1st() includes a functional-style conversion to -map its argument to the expected argument type of the bound function -(see below): -

    -
      typename Operation::first_argument_type(x)
-
    - -

    A functional-style conversion (D.8 [depr.lib.binders]) is defined to -be -semantically equivalent to an explicit cast expression (D.8 -[depr.lib.binders]), which may (according to 5.4, paragraph 5) be -interpreted -as a reinterpret_cast, thus masking the error. -

    - -

    The problem and proposed change also apply to D.8 [depr.lib.binders].

    - - -

    Proposed resolution:

    -

    Add this sentence to the end of D.8 [depr.lib.binders]/1: - "Binders bind1st and bind2nd are deprecated in - favor of std::tr1::bind."

    - -

    (Notes to editor: (1) when and if tr1::bind is incorporated into - the standard, "std::tr1::bind" should be changed to "std::bind". (2) - 20.5.6 should probably be moved to Annex D.

    - - -

    Rationale:

    -

    There is no point in fixing bind1st and bind2nd. tr1::bind is a - superior solution. It solves this problem and others.

    - - - - - -
    -

    363. Missing exception specification in 27.4.2.1.1

    -

    Section: 27.4.2.1.1 [ios::failure] Status: WP - Submitter: Walter Brown and Marc Paterno Date: 2002-05-20

    -

    View all other issues in [ios::failure].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -The destructor of ios_base::failure should have an empty throw -specification, because the destructor of its base class, exception, is -declared in this way. -

    - - -

    Proposed resolution:

    -

    Change the destructor to

    -
      virtual ~failure() throw();
-
    - - -

    Rationale:

    -

    Fixes an obvious glitch. This is almost editorial.

    - - - - - -
    -

    364. Inconsistent wording in 27.5.2.4.2

    -

    Section: 27.5.2.4.2 [streambuf.virt.buffer] Status: WP - Submitter: Walter Brown, Marc Paterno Date: 2002-05-10

    -

    View all other issues in [streambuf.virt.buffer].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -27.5.2.4.2 [streambuf.virt.buffer] paragraph 1 is inconsistent with the Effects -clause for seekoff. -

    - - -

    Proposed resolution:

    -

    -Make this paragraph, the Effects clause for setbuf, consistent in wording -with the Effects clause for seekoff in paragraph 3 by amending paragraph 1 -to indicate the purpose of setbuf: -

    - -

    Original text:

    - -

    -1 Effects: Performs an operation that is defined separately for each -class derived from basic_streambuf in this clause (27.7.1.3, 27.8.1.4). -

    - -

    Proposed text:

    - -

    -1 Effects: Influences stream buffering in a way that is defined separately -for each class derived from basic_streambuf in this clause -(27.7.1.3, 27.8.1.4). -

    - - - -

    Rationale:

    -

    The LWG doesn't believe there is any normative difference between - the existing wording and what's in the proposed resolution, but the - change may make the intent clearer.

    - - - - - -
    -

    365. Lack of const-qualification in clause 27

    -

    Section: 27 [input.output] Status: WP - Submitter: Walter Brown, Marc Paterno Date: 2002-05-10

    -

    View all other issues in [input.output].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -Some stream and streambuf member functions are declared non-const, -even thought they appear only to report information rather than to -change an object's logical state. They should be declared const. See -document N1360 for details and rationale. -

    - -

    The list of member functions under discussion: in_avail, -showmanyc, tellg, tellp, is_open.

    - -

    Related issue: 73

    - - - -

    Proposed resolution:

    -

    In 27.8.1.5, 27.8.1.7, 27.8.1.8, 27.8.1.10, 27.8.1.11, and 27.8.1.13

    -

    Replace

    -
      bool is_open();
-
    -

    with

    -
      bool is_open() const;
-
    - - -

    Rationale:

    -

    Of the changes proposed in N1360, the only one that is safe is -changing the filestreams' is_open to const. The LWG believed that -this was NAD the first time it considered this issue (issue 73), but now thinks otherwise. The corresponding streambuf -member function, after all,is already const.

    - -

    The other proposed changes are less safe, because some streambuf -functions that appear merely to report a value do actually perform -mutating operations. It's not even clear that they should be -considered "logically const", because streambuf has two interfaces, a -public one and a protected one. These functions may, and often do, -change the state as exposed by the protected interface, even if the -state exposed by the public interface is unchanged.

    - -

    Note that implementers can make this change in a binary compatible -way by providing both overloads; this would be a conforming extension.

    - - - - - - -
    -

    369. io stream objects and static ctors

    -

    Section: 27.3 [iostream.objects] Status: WP - Submitter: Ruslan Abdikeev Date: 2002-07-08

    -

    View all other issues in [iostream.objects].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -Is it safe to use standard iostream objects from constructors of -static objects? Are standard iostream objects constructed and are -their associations established at that time? -

    - -

    Surpisingly enough, Standard does NOT require that.

    - -

    -27.3/2 [lib.iostream.objects] guarantees that standard iostream -objects are constructed and their associations are established before -the body of main() begins execution. It also refers to ios_base::Init -class as the panacea for constructors of static objects. -

    - -

    -However, there's nothing in 27.3 [lib.iostream.objects], -in 27.4.2 [lib.ios.base], and in 27.4.2.1.6 [lib.ios::Init], -that would require implementations to allow access to standard -iostream objects from constructors of static objects. -

    - -

    Details:

    - -

    Core text refers to some magic object ios_base::Init, which will -be discussed below:

    - -

    - "The [standard iostream] objects are constructed, and their - associations are established at some time prior to or during - first time an object of class basic_ios<charT,traits>::Init - is constructed, and in any case before the body of main - begins execution." (27.3/2 [lib.iostream.objects]) -

    - -

    -The first non-normative footnote encourages implementations -to initialize standard iostream objects earlier than required. -

    - -

    However, the second non-normative footnote makes an explicit -and unsupported claim:

    - -

    - "Constructors and destructors for static objects can access these - [standard iostream] objects to read input from stdin or write output - to stdout or stderr." (27.3/2 footnote 265 [lib.iostream.objects]) -

    - -

    -The only bit of magic is related to that ios_base::Init class. AFAIK, -the rationale behind ios_base::Init was to bring an instance of this -class to each translation unit which #included <iostream> or -related header. Such an inclusion would support the claim of footnote -quoted above, because in order to use some standard iostream object it -is necessary to #include <iostream>. -

    - -

    -However, while Standard explicitly describes ios_base::Init as -an appropriate class for doing the trick, I failed to found a -mention of an _instance_ of ios_base::Init in Standard. -

    - - -

    Proposed resolution:

    - -

    Add to 27.3 [iostream.objects], p2, immediately before the last sentence -of the paragraph, the following two sentences:

    - -

    -If a translation unit includes <iostream>, or explicitly -constructs an ios_base::Init object, these stream objects shall -be constructed before dynamic initialization of non-local -objects defined later in that translation unit, and these stream -objects shall be destroyed after the destruction of dynamically -initialized non-local objects defined later in that translation unit. -

    - -

    [Lillehammer: Matt provided wording.]

    - -

    [Mont Tremblant: Matt provided revised wording.]

    - - - -

    Rationale:

    -

    -The original proposed resolution unconditionally required -implementations to define an ios_base::Init object of some -implementation-defined name in the header <iostream>. That's an -overspecification. First, defining the object may be unnecessary -and even detrimental to performance if an implementation can -guarantee that the 8 standard iostream objects will be initialized -before any other user-defined object in a program. Second, there -is no need to require implementations to document the name of the -object.

    - -

    -The new proposed resolution gives users guidance on what they need to -do to ensure that stream objects are constructed during startup.

    - - - - - -
    -

    370. Minor error in basic_istream::get

    -

    Section: 27.6.1.3 [istream.unformatted] Status: WP - Submitter: Ray Lischner Date: 2002-07-15

    -

    View all other issues in [istream.unformatted].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    Defect report for description of basic_istream::get (section -27.6.1.3 [istream.unformatted]), paragraph 15. The description for the -get function -with the following signature:

    - -
      basic_istream<charT,traits>& get(basic_streambuf<char_type,traits>&
-  sb);
-
    - -

    is incorrect. It reads

    - -

    - Effects: Calls get(s,n,widen('\n')) -

    - -

    which I believe should be:

    - -

    - Effects: Calls get(sb,widen('\n')) -

    - - -

    Proposed resolution:

    -

    Change the Effects paragraph to:

    -

    - Effects: Calls get(sb,this->widen('\n')) -

    - -

    [Pre-Oxford: Minor correction from Howard: replaced 'widen' - with 'this->widen'.]

    - - - - -

    Rationale:

    Fixes an obvious typo.

    - - - - -
    -

    371. Stability of multiset and multimap member functions

    -

    Section: 23.1 [container.requirements] Status: WP - Submitter: Frank Compagner Date: 2002-07-20

    -

    View other active issues in [container.requirements].

    -

    View all other issues in [container.requirements].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -The requirements for multiset and multimap containers (23.1 -[lib.containers.requirements], 23.1.2 [lib.associative.reqmnts], -23.3.2 [lib.multimap] and 23.3.4 [lib.multiset]) make no mention of -the stability of the required (mutating) member functions. It appears -the standard allows these functions to reorder equivalent elements of -the container at will, yet the pervasive red-black tree implementation -appears to provide stable behaviour. -

    - -

    This is of most concern when considering the behaviour of erase(). -A stability requirement would guarantee the correct working of the -following 'idiom' that removes elements based on a certain predicate -function. -

    - -
      multimap<int, int> m;
-  multimap<int, int>::iterator i = m.begin();
-  while (i != m.end()) {
-      if (pred(i))
-          m.erase (i++);
-      else
-          ++i;
-  }
-
    - -

    -Although clause 23.1.2/8 guarantees that i remains a valid iterator -througout this loop, absence of the stability requirement could -potentially result in elements being skipped. This would make -this code incorrect, and, furthermore, means that there is no way -of erasing these elements without iterating first over the entire -container, and second over the elements to be erased. This would -be unfortunate, and have a negative impact on both performance and -code simplicity. -

    - -

    -If the stability requirement is intended, it should be made explicit -(probably through an extra paragraph in clause 23.1.2). -

    -

    -If it turns out stability cannot be guaranteed, i'd argue that a -remark or footnote is called for (also somewhere in clause 23.1.2) to -warn against relying on stable behaviour (as demonstrated by the code -above). If most implementations will display stable behaviour, any -problems emerging on an implementation without stable behaviour will -be hard to track down by users. This would also make the need for an -erase_if() member function that much greater. -

    - -

    This issue is somewhat related to LWG issue 130.

    - - - -

    Proposed resolution:

    - -

    Add the following to the end of 23.1.4 [associative.reqmts] paragraph 4: -"For multiset and multimap, insertand erase - are stable: they preserve the relative ordering of equivalent - elements.

    - -

    [Lillehammer: Matt provided wording]

    - -

    [Joe Gottman points out that the provided wording does not address -multimap and multiset. N1780 also addresses this issue and suggests -wording.]

    - - -

    [Mont Tremblant: Changed set and map to multiset and multimap.]

    - - - - -

    Rationale:

    -

    The LWG agrees that this guarantee is necessary for common user - idioms to work, and that all existing implementations provide this - property. Note that this resolution guarantees stability for - multimap and multiset, not for all associative containers in - general.

    - - - - - - -
    -

    373. Are basic_istream and basic_ostream to use (exceptions()&badbit) != 0 ?

    -

    Section: 27.6.1.2.1 [istream.formatted.reqmts], 27.6.2.6.1 [ostream.formatted.reqmts] Status: WP - Submitter: Keith Baker Date: 2002-07-23

    -

    View all other issues in [istream.formatted.reqmts].

    -

    View all issues with WP status.

    -

    Discussion:

    - -

    -In 27.6.1.2.1 [istream.formatted.reqmts] and 27.6.2.6.1 [ostream.formatted.reqmts] -(exception()&badbit) != 0 is used in testing for rethrow, yet -exception() is the constructor to class std::exception in 18.6.1 [type.info] that has no return type. Should member function -exceptions() found in 27.4.4 [ios] be used instead? -

    - - - -

    Proposed resolution:

    -

    -In 27.6.1.2.1 [istream.formatted.reqmts] and 27.6.2.6.1 [ostream.formatted.reqmts], change -"(exception()&badbit) != 0" to "(exceptions()&badbit) != 0". -

    - - -

    Rationale:

    -

    Fixes an obvious typo.

    - - - - - -
    -

    375. basic_ios should be ios_base in 27.7.1.3

    -

    Section: 27.7.1.4 [stringbuf.virtuals] Status: WP - Submitter: Ray Lischner Date: 2002-08-14

    -

    View all other issues in [stringbuf.virtuals].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -In Section 27.7.1.4 [stringbuf.virtuals]: Table 90, Table 91, and paragraph -14 all contain references to "basic_ios::" which should be -"ios_base::". -

    - - -

    Proposed resolution:

    -

    -Change all references to "basic_ios" in Table 90, Table 91, and -paragraph 14 to "ios_base". -

    - - -

    Rationale:

    Fixes an obvious typo.

    - - - - -
    -

    376. basic_streambuf semantics

    -

    Section: 27.7.1.4 [stringbuf.virtuals] Status: WP - Submitter: Ray Lischner Date: 2002-08-14

    -

    View all other issues in [stringbuf.virtuals].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -In Section 27.7.1.4 [stringbuf.virtuals], Table 90, the implication is that -the four conditions should be mutually exclusive, but they are not. -The first two cases, as written, are subcases of the third.

    - -

    -As written, it is unclear what should be the result if cases 1 and 2 -are both true, but case 3 is false. -

    - - - -

    Proposed resolution:

    - -

    Rewrite these conditions as:

    -
    -

    - (which & (ios_base::in|ios_base::out)) == ios_base::in -

    - -

    - (which & (ios_base::in|ios_base::out)) == ios_base::out -

    - -

    - (which & (ios_base::in|ios_base::out)) == -(ios_base::in|ios_base::out) - and way == either ios_base::beg or ios_base::end -

    - -

    Otherwise

    -
    - - - -

    Rationale:

    -

    It's clear what we wanted to say, we just failed to say it. This - fixes it.

    - - - - - -
    -

    379. nonsensical ctype::do_widen() requirement

    -

    Section: 22.2.1.1.2 [locale.ctype.virtuals] Status: WP - Submitter: Martin Sebor Date: 2002-09-06

    -

    View all other issues in [locale.ctype.virtuals].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -The last sentence in 22.2.1.1.2, p11 below doesn't seem to make sense. -

    -
      charT do_widen (char c) const;
-
-  -11- Effects: Applies the simplest reasonable transformation from
-       a char value or sequence of char values to the corresponding
-       charT value or values. The only characters for which unique
-       transformations are required are those in the basic source
-       character set (2.2). For any named ctype category with a
-       ctype<charT> facet ctw and valid ctype_base::mask value
-       M (is(M, c) || !ctw.is(M, do_widen(c))) is true.
-
    -

    -Shouldn't the last sentence instead read -

    -
           For any named ctype category with a ctype<char> facet ctc
-       and valid ctype_base::mask value M
-       (ctc.is(M, c) || !is(M, do_widen(c))) is true.
-
    -

    -I.e., if the narrow character c is not a member of a class of -characters then neither is the widened form of c. (To paraphrase -footnote 224.) -

    - - -

    Proposed resolution:

    -

    -Replace the last sentence of 22.2.1.1.2 [locale.ctype.virtuals], p11 with the -following text: -

    -
           For any named ctype category with a ctype<char> facet ctc
-       and valid ctype_base::mask value M,
-       (ctc.is(M, c) || !is(M, do_widen(c))) is true.
-
    - -

    [Kona: Minor edit. Added a comma after the M for clarity.]

    - - - - -

    Rationale:

    -

    The LWG believes this is just a typo, and that this is the correct fix.

    - - - - - -
    -

    380. typos in codecvt tables 53 and 54

    -

    Section: 22.2.1.5 [locale.codecvt.byname] Status: WP - Submitter: Martin Sebor Date: 2002-09-06

    -

    View all other issues in [locale.codecvt.byname].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -Tables 53 and 54 in 22.2.1.5 [locale.codecvt.byname] are both titled "convert -result values," when surely "do_in/do_out result values" must have -been intended for Table 53 and "do_unshift result values" for Table -54. -

    -

    -Table 54, row 3 says that the meaning of partial is "more characters -needed to be supplied to complete termination." The function is not -supplied any characters, it is given a buffer which it fills with -characters or, more precisely, destination elements (i.e., an escape -sequence). So partial means that space for more than (to_limit - to) -destination elements was needed to terminate a sequence given the -value of state. -

    - - -

    Proposed resolution:

    -

    -Change the title of Table 53 to "do_in/do_out result values" and -the title of Table 54 to "do_unshift result values." -

    -

    -Change the text in Table 54, row 3 (the partial row), under the -heading Meaning, to "space for more than (to_limit - to) destination -elements was needed to terminate a sequence given the value of state." -

    - - - - -
    -

    381. detection of invalid mbstate_t in codecvt

    -

    Section: 22.2.1.5 [locale.codecvt.byname] Status: WP - Submitter: Martin Sebor Date: 2002-09-06

    -

    View all other issues in [locale.codecvt.byname].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -All but one codecvt member functions that take a state_type argument -list as one of their preconditions that the state_type argument have -a valid value. However, according to 22.2.1.5.2, p6, -codecvt::do_unshift() is the only codecvt member that is supposed to -return error if the state_type object is invalid. -

    - -

    -It seems to me that the treatment of state_type by all codecvt member -functions should be the same and the current requirements should be -changed. Since the detection of invalid state_type values may be -difficult in general or computationally expensive in some specific -cases, I propose the following: -

    - - -

    Proposed resolution:

    -

    -Add a new paragraph before 22.2.1.5.2, p5, and after the function -declaration below -

    -
        result do_unshift(stateT& state,
-    externT* to, externT* to_limit, externT*& to_next) const;
-
    -

    -as follows: -

    -
        Requires: (to <= to_end) well defined and true; state initialized,
-    if at the beginning of a sequence, or else equal to the result of
-    converting the preceding characters in the sequence.
-
    -

    -and change the text in Table 54, row 4, the error row, under -the heading Meaning, from -

    -
        state has invalid value
-
    -

    -to -

    -
        an unspecified error has occurred
-
    - - -

    Rationale:

    -

    The intent is that implementations should not be required to detect -invalid state values; such a requirement appears nowhere else. An -invalid state value is a precondition violation, i.e. undefined -behavior. Implementations that do choose to detect invalid state -values, or that choose to detect any other kind of error, may return -error as an indication.

    - - - - - -
    -

    383. Bidirectional iterator assertion typo

    -

    Section: 24.1.4 [bidirectional.iterators] Status: WP - Submitter: ysapir (submitted via comp.std.c++) Date: 2002-10-17

    -

    View all other issues in [bidirectional.iterators].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -Following a discussion on the boost list regarding end iterators and -the possibility of performing operator--() on them, it seems to me -that there is a typo in the standard. This typo has nothing to do -with that discussion. -

    - -

    -I have checked this newsgroup, as well as attempted a search of the -Active/Defect/Closed Issues List on the site for the words "s is -derefer" so I believe this has not been proposed before. Furthermore, -the "Lists by Index" mentions only DR 299 on section -24.1.4, and DR 299 is not related to this issue. -

    - -

    -The standard makes the following assertion on bidirectional iterators, -in section 24.1.4 [lib.bidirectional.iterators], Table 75: -

    - -
                             operational  assertion/note
-expression  return type   semantics    pre/post-condition
-
---r          X&                        pre: there exists s such
-                                       that r == ++s.
-                                       post: s is dereferenceable.
-                                       --(++r) == r.
-                                       --r == --s implies r == s.
-                                       &r == &--r.
-
    - -

    -(See http://aspn.activestate.com/ASPN/Mail/Message/boost/1395763.) -

    - -

    -In particular, "s is dereferenceable" seems to be in error. It seems -that the intention was to say "r is dereferenceable". -

    - -

    -If it were to say "r is dereferenceable" it would -make perfect sense. Since s must be dereferenceable prior to -operator++, then the natural result of operator-- (to undo operator++) -would be to make r dereferenceable. Furthermore, without other -assertions, and basing only on precondition and postconditions, we -could not otherwise know this. So it is also interesting information. -

    - - - -

    Proposed resolution:

    -

    -Change the guarantee to "postcondition: r is dereferenceable." -

    - - -

    Rationale:

    Fixes an obvious typo

    - - - - -
    -

    384. equal_range has unimplementable runtime complexity

    -

    Section: 25.3.3.3 [equal.range] Status: WP - Submitter: Hans Bos Date: 2002-10-18

    -

    View all other issues in [equal.range].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -Section 25.3.3.3 [equal.range] -states that at most 2 * log(last - first) + 1 -comparisons are allowed for equal_range. -

    - -

    It is not possible to implement equal_range with these constraints.

    - -

    In a range of one element as in:

    -
        int x = 1;
-    equal_range(&x, &x + 1, 1)
-
    - -

    it is easy to see that at least 2 comparison operations are needed.

    - -

    For this case at most 2 * log(1) + 1 = 1 comparison is allowed.

    - -

    I have checked a few libraries and they all use the same (nonconforming) -algorithm for equal_range that has a complexity of

    -
         2* log(distance(first, last)) + 2.
-
    -

    I guess this is the algorithm that the standard assumes for equal_range.

    - -

    -It is easy to see that 2 * log(distance) + 2 comparisons are enough -since equal range can be implemented with lower_bound and upper_bound -(both log(distance) + 1). -

    - -

    -I think it is better to require something like 2log(distance) + O(1) (or -even logarithmic as multiset::equal_range). -Then an implementation has more room to optimize for certain cases (e.g. -have log(distance) characteristics when at most match is found in the range -but 2log(distance) + 4 for the worst case). -

    - - - -

    Proposed resolution:

    -

    In 25.3.3.1 [lower.bound]/4, change log(last - first) + 1 -to log2(last - first) + O(1).

    - -

    In 25.3.3.2 [upper.bound]/4, change log(last - first) + 1 -to log2(last - first) + O(1).

    - -

    In 25.3.3.3 [equal.range]/4, change 2*log(last - first) + 1 -to 2*log2(last - first) + O(1).

    - -

    [Matt provided wording]

    - - - -

    Rationale:

    -

    The LWG considered just saying O(log n) for all three, but - decided that threw away too much valuable information. The fact - that lower_bound is twice as fast as equal_range is important. - However, it's better to allow an arbitrary additive constant than to - specify an exact count. An exact count would have to - involve floor or ceil. It would be too easy to - get this wrong, and don't provide any substantial value for users.

    - - - - -
    -

    386. Reverse iterator's operator[] has impossible return type

    -

    Section: 24.4.1.3.11 [reverse.iter.op-=] Status: DR - Submitter: Matt Austern Date: 2002-10-23

    -

    View all issues with DR status.

    -

    Discussion:

    -

    In 24.4.1.3.11 [reverse.iter.op-=], reverse_iterator<>::operator[] -is specified as having a return type of reverse_iterator::reference, -which is the same as iterator_traits<Iterator>::reference. -(Where Iterator is the underlying iterator type.)

    - -

    The trouble is that Iterator's own operator[] doesn't - necessarily have a return type - of iterator_traits<Iterator>::reference. Its - return type is merely required to be convertible - to Iterator's value type. The return type specified for - reverse_iterator's operator[] would thus appear to be impossible.

    - -

    With the resolution of issue 299, the type of - a[n] will continue to be required (for random access - iterators) to be convertible to the value type, and also a[n] = - t will be a valid expression. Implementations of - reverse_iterator will likely need to return a proxy from - operator[] to meet these requirements. As mentioned in the - comment from Dave Abrahams, the simplest way to specify that - reverse_iterator meet this requirement to just mandate - it and leave the return type of operator[] unspecified.

    - - - -

    Proposed resolution:

    - -

    In 24.4.1.2 [reverse.iter.requirements] change:

    - -
    -
    reference operator[](difference_type n) const;
-
    -
    - -

    to:

    - -
    -
    unspecified operator[](difference_type n) const; // see 24.1.5 [random.access.iterators]
-
    -
    - - - - -

    [ -Comments from Dave Abrahams: IMO we should resolve 386 by just saying - that the return type of reverse_iterator's operator[] is - unspecified, allowing the random access iterator requirements to - impose an appropriate return type. If we accept 299's proposed - resolution (and I think we should), the return type will be - readable and writable, which is about as good as we can do. -]

    - - - - - - -
    -

    389. Const overload of valarray::operator[] returns by value

    -

    Section: 26.5.2.3 [valarray.access] Status: WP - Submitter: Gabriel Dos Reis Date: 2002-11-08

    -

    View all other issues in [valarray.access].

    -

    View all issues with WP status.

    -

    Duplicate of: 77

    -

    Discussion:

    -

    Consider the following program:

    -
        #include <iostream>
-    #include <ostream>
-    #include <vector>
-    #include <valarray>
-    #include <algorithm>
-    #include <iterator>
-    template<typename Array>
-    void print(const Array& a)
-    {
-    using namespace std;
-    typedef typename Array::value_type T;
-    copy(&a[0], &a[0] + a.size(),
-    ostream_iterator<T>(std::cout, " "));
-    }
-    template<typename T, unsigned N>
-    unsigned size(T(&)[N]) { return N; }
-    int main()
-    {
-    double array[] = { 0.89, 9.3, 7, 6.23 };
-    std::vector<double> v(array, array + size(array));
-    std::valarray<double> w(array, size(array));
-    print(v); // #1
-    std::cout << std::endl;
-    print(w); // #2
-    std::cout << std::endl;
-    }
-
    - -

    While the call numbered #1 succeeds, the call numbered #2 fails -because the const version of the member function -valarray<T>::operator[](size_t) returns a value instead of a -const-reference. That seems to be so for no apparent reason, no -benefit. Not only does that defeats users' expectation but it also -does hinder existing software (written either in C or Fortran) -integration within programs written in C++. There is no reason why -subscripting an expression of type valarray<T> that is const-qualified -should not return a const T&.

    - - -

    Proposed resolution:

    -

    In the class synopsis in 26.5.2 [template.valarray], and in -26.5.2.3 [valarray.access] just above paragraph 1, change

    -
      T operator[](size_t const);
-
    -

    to

    -
      const T& operator[](size_t const);
-
    - -

    [Kona: fixed a minor typo: put semicolon at the end of the line - wehre it belongs.]

    - - - - -

    Rationale:

    -

    Return by value seems to serve no purpose. Valaray was explicitly -designed to have a specified layout so that it could easily be -integrated with libraries in other languages, and return by value -defeats that purpose. It is believed that this change will have no -impact on allowable optimizations.

    - - - - - -
    -

    391. non-member functions specified as const

    -

    Section: 22.1.3.2 [conversions] Status: WP - Submitter: James Kanze Date: 2002-12-10

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -The specifications of toupper and tolower both specify the functions as -const, althought they are not member functions, and are not specified as -const in the header file synopsis in section 22.1 [locales]. -

    - - -

    Proposed resolution:

    -

    In 22.1.3.2 [conversions], remove const from the function - declarations of std::toupper and std::tolower

    - - -

    Rationale:

    Fixes an obvious typo

    - - - - -
    -

    395. inconsistencies in the definitions of rand() and random_shuffle()

    -

    Section: 26.7 [c.math] Status: WP - Submitter: James Kanze Date: 2003-01-03

    -

    View all other issues in [c.math].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -In 26.7 [c.math], the C++ standard refers to the C standard for the -definition of rand(); in the C standard, it is written that "The -implementation shall behave as if no library function calls the rand -function." -

    - -

    -In 25.2.12 [alg.random.shuffle], there is no specification as to -how the two parameter version of the function generates its random -value. I believe that all current implementations in fact call rand() -(in contradiction with the requirement avove); if an implementation does -not call rand(), there is the question of how whatever random generator -it does use is seeded. Something is missing. -

    - - - -

    Proposed resolution:

    -

    -In [lib.c.math], add a paragraph specifying that the C definition of -rand shal be modified to say that "Unless otherwise specified, the -implementation shall behave as if no library function calls the rand -function." -

    - -

    -In [lib.alg.random.shuffle], add a sentence to the effect that "In -the two argument form of the function, the underlying source of -random numbers is implementation defined. [Note: in particular, an -implementation is permitted to use rand.] -

    - - -

    Rationale:

    -

    The original proposed resolution proposed requiring the - two-argument from of random_shuffle to - use rand. We don't want to do that, because some existing - implementations already use something else: gcc - uses lrand48, for example. Using rand presents a - problem if the number of elements in the sequence is greater than - RAND_MAX.

    - - - - - -
    -

    400. redundant type cast in lib.allocator.members

    -

    Section: 20.7.5.1 [allocator.members] Status: WP - Submitter: Markus Mauhart Date: 2003-02-27

    -

    View all other issues in [allocator.members].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -20.7.5.1 [allocator.members] allocator members, contains -the following 3 lines: -

    - -
      12 Returns: new((void *) p) T( val)
-     void destroy(pointer p);
-  13 Returns: ((T*) p)->~T()
-
    - -

    -The type cast "(T*) p" in the last line is redundant cause -we know that std::allocator<T>::pointer is a typedef for T*. -

    - - -

    Proposed resolution:

    -

    -Replace "((T*) p)" with "p". -

    - - -

    Rationale:

    Just a typo, this is really editorial.

    - - - - -
    -

    401. incorrect type casts in table 32 in lib.allocator.requirements

    -

    Section: 20.1.2 [allocator.requirements] Status: WP - Submitter: Markus Mauhart Date: 2003-02-27

    -

    View other active issues in [allocator.requirements].

    -

    View all other issues in [allocator.requirements].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -I think that in par2 of [default.con.req] the last two -lines of table 32 contain two incorrect type casts. The lines are ... -

    - -
      a.construct(p,t)   Effect: new((void*)p) T(t)
-  a.destroy(p)       Effect: ((T*)p)?->~T()
-
    - -

    -.... with the prerequisits coming from the preceding two paragraphs, especially -from table 31: -

    - -
      alloc<T>             a     ;// an allocator for T
-  alloc<T>::pointer    p     ;// random access iterator
-                              // (may be different from T*)
-  alloc<T>::reference  r = *p;// T&
-  T const&             t     ;
-
    - -

    -For that two type casts ("(void*)p" and "(T*)p") to be well-formed -this would require then conversions to T* and void* for all -alloc<T>::pointer, so it would implicitely introduce extra -requirements for alloc<T>::pointer, additionally to the only -current requirement (being a random access iterator). -

    - - -

    Proposed resolution:

    - -

    -Accept proposed wording from -N2436 part 1. -

    - -

    -Note: Actually I would prefer to replace "((T*)p)?->dtor_name" with -"p?->dtor_name", but AFAICS this is not possible cause of an omission -in 13.5.6 [over.ref] (for which I have filed another DR on 29.11.2002). -

    - -

    [Kona: The LWG thinks this is somewhere on the border between - Open and NAD. The intend is clear: construct constructs an - object at the location p. It's reading too much into the - description to think that literally calling new is - required. Tweaking this description is low priority until we can do - a thorough review of allocators, and, in particular, allocators with - non-default pointer types.]

    - - -

    [ -Batavia: Proposed resolution changed to less code and more description. -]

    - - -

    [ -post Oxford: This would be rendered NAD Editorial by acceptance of -N2257. -]

    - - -

    [ -Kona (2007): The LWG adopted the proposed resolution of N2387 for this issue which -was subsequently split out into a separate paper N2436 for the purposes of voting. -The resolution in N2436 addresses this issue. The LWG voted to accelerate this -issue to Ready status to be voted into the WP at Kona. -]

    - - - - - - - -
    -

    402. wrong new expression in [some_]allocator::construct

    -

    Section: 20.1.2 [allocator.requirements], 20.7.5.1 [allocator.members] Status: WP - Submitter: Markus Mauhart Date: 2003-02-27

    -

    View other active issues in [allocator.requirements].

    -

    View all other issues in [allocator.requirements].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -This applies to the new expression that is contained in both par12 of -20.7.5.1 [allocator.members] and in par2 (table 32) of [default.con.req]. -I think this new expression is wrong, involving unintended side -effects. -

    - - -

    20.7.5.1 [allocator.members] contains the following 3 lines:

    - -
      11 Returns: the largest value N for which the call allocate(N,0) might succeed.
-     void construct(pointer p, const_reference val);
-  12 Returns: new((void *) p) T( val)
-
    - - -

    [default.con.req] in table 32 has the following line:

    -
      a.construct(p,t)   Effect: new((void*)p) T(t)
-
    - -

    -.... with the prerequisits coming from the preceding two paragraphs, -especially from table 31: -

    - -
      alloc<T>             a     ;// an allocator for T
-  alloc<T>::pointer    p     ;// random access iterator
-                              // (may be different from T*)
-  alloc<T>::reference  r = *p;// T&
-  T const&             t     ;
-
    - -

    -Cause of using "new" but not "::new", any existing "T::operator new" -function will hide the global placement new function. When there is no -"T::operator new" with adequate signature, -every_alloc<T>::construct(..) is ill-formed, and most -std::container<T,every_alloc<T>> use it; a workaround -would be adding placement new and delete functions with adequate -signature and semantic to class T, but class T might come from another -party. Maybe even worse is the case when T has placement new and -delete functions with adequate signature but with "unknown" semantic: -I dont like to speculate about it, but whoever implements -any_container<T,any_alloc> and wants to use construct(..) -probably must think about it. -

    - - -

    Proposed resolution:

    -

    -Replace "new" with "::new" in both cases. -

    - - - - - - - -
    -

    403. basic_string::swap should not throw exceptions

    -

    Section: 21.3.6.8 [string::swap] Status: WP - Submitter: Beman Dawes Date: 2003-03-25

    -

    View all other issues in [string::swap].

    -

    View all issues with WP status.

    -

    Discussion:

    - -

    -std::basic_string, 21.3 [basic.string] paragraph 2 says that -basic_string "conforms to the requirements of a Sequence, as specified -in (23.1.1)." The sequence requirements specified in (23.1.1) to not -include any prohibition on swap members throwing exceptions. -

    - -

    -Section 23.1 [container.requirements] paragraph 10 does limit conditions under -which exceptions may be thrown, but applies only to "all container -types defined in this clause" and so excludes basic_string::swap -because it is defined elsewhere. -

    - -

    -Eric Niebler points out that 21.3 [basic.string] paragraph 5 explicitly -permits basic_string::swap to invalidates iterators, which is -disallowed by 23.1 [container.requirements] paragraph 10. Thus the standard would -be contradictory if it were read or extended to read as having -basic_string meet 23.1 [container.requirements] paragraph 10 requirements. -

    - -

    -Yet several LWG members have expressed the belief that the original -intent was that basic_string::swap should not throw exceptions as -specified by 23.1 [container.requirements] paragraph 10, and that the standard is -unclear on this issue. The complexity of basic_string::swap is -specified as "constant time", indicating the intent was to avoid -copying (which could cause a bad_alloc or other exception). An -important use of swap is to ensure that exceptions are not thrown in -exception-safe code. -

    - -

    -Note: There remains long standing concern over whether or not it is -possible to reasonably meet the 23.1 [container.requirements] paragraph 10 swap -requirements when allocators are unequal. The specification of -basic_string::swap exception requirements is in no way intended to -address, prejudice, or otherwise impact that concern. -

    - - - - - - - -

    Proposed resolution:

    -

    -In 21.3.6.8 [string::swap], add a throws clause: -

    - -

    -Throws: Shall not throw exceptions. -

    - - - - - -
    -

    404. May a replacement allocation function be declared inline?

    -

    Section: 17.4.3.5 [replacement.functions], 18.5.1 [new.delete] Status: WP - Submitter: Matt Austern Date: 2003-04-24

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -The eight basic dynamic memory allocation functions (single-object -and array versions of ::operator new and ::operator delete, in the -ordinary and nothrow forms) are replaceable. A C++ program may -provide an alternative definition for any of them, which will be used -in preference to the implementation's definition. -

    - -

    -Three different parts of the standard mention requirements on -replacement functions: 17.4.3.5 [replacement.functions], 18.5.1.1 [new.delete.single] -and 18.5.1.2 [new.delete.array], and 3.7.2 [basic.stc.auto]. -

    - -

    None of these three places say whether a replacement function may - be declared inline. 18.5.1.1 [new.delete.single] paragraph 2 specifies a - signature for the replacement function, but that's not enough: - the inline specifier is not part of a function's signature. - One might also reason from 7.1.2 [dcl.fct.spec] paragraph 2, which - requires that "an inline function shall be defined in every - translation unit in which it is used," but this may not be quite - specific enough either. We should either explicitly allow or - explicitly forbid inline replacement memory allocation - functions.

    - - -

    Proposed resolution:

    -

    -Add a new sentence to the end of 17.4.3.5 [replacement.functions] paragraph 3: -"The program's definitions shall not be specified as inline. -No diagnostic is required." -

    - -

    [Kona: added "no diagnostic is required"]

    - - - - -

    Rationale:

    -

    -The fact that inline isn't mentioned appears to have been -nothing more than an oversight. Existing implementations do not -permit inline functions as replacement memory allocation functions. -Providing this functionality would be difficult in some cases, and is -believed to be of limited value. -

    - - - - - -
    -

    405. qsort and POD

    -

    Section: 25.4 [alg.c.library] Status: WP - Submitter: Ray Lischner Date: 2003-04-08

    -

    View all other issues in [alg.c.library].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -Section 25.4 [alg.c.library] describes bsearch and qsort, from the C -standard library. Paragraph 4 does not list any restrictions on qsort, -but it should limit the base parameter to point to POD. Presumably, -qsort sorts the array by copying bytes, which requires POD. -

    - - -

    Proposed resolution:

    -

    -In 25.4 [alg.c.library] paragraph 4, just after the declarations and -before the nonnormative note, add these words: "both of which have the -same behavior as the original declaration. The behavior is undefined -unless the objects in the array pointed to by base are of POD -type." -

    - -

    [Something along these lines is clearly necessary. Matt - provided wording.]

    - - - - - - -
    -

    406. vector::insert(s) exception safety

    -

    Section: 23.2.6.4 [vector.modifiers] Status: DR - Submitter: Dave Abrahams Date: 2003-04-27

    -

    View all other issues in [vector.modifiers].

    -

    View all issues with DR status.

    -

    Discussion:

    -

    -There is a possible defect in the standard: the standard text was -never intended to prevent arbitrary ForwardIterators, whose operations -may throw exceptions, from being passed, and it also wasn't intended -to require a temporary buffer in the case where ForwardIterators were -passed (and I think most implementations don't use one). As is, the -standard appears to impose requirements that aren't met by any -existing implementation. -

    - - -

    Proposed resolution:

    -

    Replace 23.2.6.4 [vector.modifiers] paragraph 1 with:

    -

    - 1- Notes: Causes reallocation if the new size is greater than the - old capacity. If no reallocation happens, all the iterators and - references before the insertion point remain valid. If an exception - is thrown other than by the copy constructor or assignment operator - of T or by any InputIterator operation there are no effects. -

    - -

    [We probably need to say something similar for deque.]

    - - - - - - - -
    -

    407. Can singular iterators be destroyed?

    -

    Section: 24.1 [iterator.requirements] Status: WP - Submitter: Nathan Myers Date: 2003-06-03

    -

    View other active issues in [iterator.requirements].

    -

    View all other issues in [iterator.requirements].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -Clause 24.1 [iterator.requirements], paragraph 5, says that the only expression -that is defined for a singular iterator is "an assignment of a -non-singular value to an iterator that holds a singular value". This -means that destroying a singular iterator (e.g. letting an automatic -variable go out of scope) is technically undefined behavior. This -seems overly strict, and probably unintentional. -

    - - -

    Proposed resolution:

    -

    -Change the sentence in question to "... the only exceptions are -destroying an iterator that holds a singular value, or the assignment -of a non-singular value to an iterator that holds a singular value." -

    - - - - - -
    -

    409. Closing an fstream should clear error state

    -

    Section: 27.8.1.9 [ifstream.members], 27.8.1.13 [ofstream.members] Status: DR - Submitter: Nathan Myers Date: 2003-06-03

    -

    View all other issues in [ifstream.members].

    -

    View all issues with DR status.

    -

    Discussion:

    -

    -A strict reading of 27.8.1 [fstreams] shows that opening or -closing a basic_[io]fstream does not affect the error bits. This -means, for example, that if you read through a file up to EOF, and -then close the stream and reopen it at the beginning of the file, -the EOF bit in the stream's error state is still set. This is -counterintuitive. -

    -

    -The LWG considered this issue once before, as issue 22, -and put in a footnote to clarify that the strict reading was indeed -correct. We did that because we believed the standard was -unambiguous and consistent, and that we should not make architectural -changes in a TC. Now that we're working on a new revision of the -language, those considerations no longer apply. -

    - - -

    Proposed resolution:

    - -

    Change 27.8.1.9 [ifstream.members], para. 3 from:

    - -

    -Calls rdbuf()->open(s,mode|in). If that function returns a null -pointer, calls setstate(failbit) (which may throw ios_base::failure -[Footnote: (lib.iostate.flags)]. -

    - -

    to:

    - -

    Calls rdbuf()->open(s,mode|in). If that function -returns a null pointer, calls setstate(failbit) (which may throw -ios_base::failure [Footnote: (lib.iostate.flags)), else calls clear(). -

    - -

    Change 27.8.1.13 [ofstream.members], para. 3 from:

    - -

    Calls rdbuf()->open(s,mode|out). If that function -returns a null pointer, calls setstate(failbit) (which may throw -ios_base::failure [Footnote: (lib.iostate.flags)). -

    - -

    to:

    - -

    Calls rdbuf()->open(s,mode|out). If that function -returns a null pointer, calls setstate(failbit) (which may throw -ios_base::failure [Footnote: (lib.iostate.flags)), else calls clear(). -

    - -

    Change 27.8.1.17 [fstream.members], para. 3 from:

    - -

    Calls rdbuf()->open(s,mode), If that function returns -a null pointer, calls setstate(failbit), (which may throw -ios_base::failure). (lib.iostate.flags) ) -

    - -

    to:

    - -

    Calls rdbuf()->open(s,mode), If that function returns -a null pointer, calls setstate(failbit), (which may throw -ios_base::failure). (lib.iostate.flags) ), else calls clear(). -

    - - - -

    [Kona: the LWG agrees this is a good idea. Post-Kona: Bill -provided wording. He suggests having open, not close, clear the error -flags.]

    - - -

    [Post-Sydney: Howard provided a new proposed resolution. The - old one didn't make sense because it proposed to fix this at the - level of basic_filebuf, which doesn't have access to the stream's - error state. Howard's proposed resolution fixes this at the level - of the three fstream class template instead.]

    - - - - - - - - -
    -

    410. Missing semantics for stack and queue comparison operators

    -

    Section: 23.2.4.1 [list.cons], 23.2.4.3 [list.modifiers] Status: WP - Submitter: Hans Bos Date: 2003-06-07

    -

    View all other issues in [list.cons].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -Sections 23.2.4.1 [list.cons] and 23.2.4.3 [list.modifiers] list -comparison operators (==, !=, <, <=, >, =>) for queue and -stack. Only the semantics for queue::operator== (23.2.4.1 [list.cons] par2) and queue::operator< (23.2.4.1 [list.cons] -par3) are defined. -

    - - -

    Proposed resolution:

    - -

    Add the following new paragraphs after 23.2.4.1 [list.cons] - paragraph 3:

    - -
    - -
      operator!=
-
    -

    Returns: x.c != y.c

    - -
      operator>
-
    -

    Returns: x.c > y.c

    - -
      operator<=
-
    -

    Returns: x.c <= y.c

    - -
      operator>=
-
    -

    Returns: x.c >= y.c

    - -
    - -

    Add the following paragraphs at the end of 23.2.4.3 [list.modifiers]:

    - -
    - -
      operator==
-
    -

    Returns: x.c == y.c

    - -
      operator<
-
    -

    Returns: x.c < y.c

    - -
      operator!=
-
    -

    Returns: x.c != y.c

    - -
      operator>
-
    -

    Returns: x.c > y.c

    - -
      operator<=
-
    -

    Returns: x.c <= y.c

    - -
      operator>=
-
    -

    Returns: x.c >= y.c

    - -
    - - -

    [Kona: Matt provided wording.]

    - - - - -

    Rationale:

    -

    There isn't any real doubt about what these operators are -supposed to do, but we ought to spell it out.

    - - - - - -
    -

    411. Wrong names of set member functions

    -

    Section: 25.3.5 [alg.set.operations] Status: WP - Submitter: Daniel Frey Date: 2003-07-09

    -

    View all other issues in [alg.set.operations].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -25.3.5 [alg.set.operations] paragraph 1 reads: -"The semantics of the set operations are generalized to multisets in a -standard way by defining union() to contain the maximum number of -occurrences of every element, intersection() to contain the minimum, and -so on." -

    - -

    -This is wrong. The name of the functions are set_union() and -set_intersection(), not union() and intersection(). -

    - - -

    Proposed resolution:

    -

    Change that sentence to use the correct names.

    - - - - - -
    -

    412. Typo in 27.4.4.3

    -

    Section: 27.4.4.3 [iostate.flags] Status: WP - Submitter: Martin Sebor Date: 2003-07-10

    -

    View all other issues in [iostate.flags].

    -

    View all issues with WP status.

    -

    Duplicate of: 429

    -

    Discussion:

    -

    -The Effects clause in 27.4.4.3 [iostate.flags] paragraph 5 says that the -function only throws if the respective bits are already set prior to -the function call. That's obviously not the intent. The typo ought to -be corrected and the text reworded as: "If (state & -exceptions()) == 0, returns. ..." -

    - - -

    Proposed resolution:

    -

    -In 27.4.4.3 [iostate.flags] paragraph 5, replace "If (rdstate() & -exceptions()) == 0" with "If ((state | (rdbuf() ? goodbit : badbit)) -& exceptions()) == 0". -

    - -

    [Kona: the original proposed resolution wasn't quite right. We - really do mean rdstate(); the ambiguity is that the wording in the - standard doesn't make it clear whether we mean rdstate() before - setting the new state, or rdsate() after setting it. We intend the - latter, of course. Post-Kona: Martin provided wording.]

    - - - - - - - -
    -

    413. Proposed resolution to LDR#64 still wrong

    -

    Section: 27.6.1.2.3 [istream::extractors] Status: DR - Submitter: Bo Persson Date: 2003-07-13

    -

    View all other issues in [istream::extractors].

    -

    View all issues with DR status.

    -

    Discussion:

    -

    -The second sentence of the proposed resolution says: -

    - -

    -"If it inserted no characters because it caught an exception thrown -while extracting characters from sb and ..." -

    - -

    -However, we are not extracting from sb, but extracting from the -basic_istream (*this) and inserting into sb. I can't really tell if -"extracting" or "sb" is a typo. -

    - -

    [ -Sydney: Definitely a real issue. We are, indeed, extracting characters -from an istream and not from sb. The problem was there in the FDIS and -wasn't fixed by issue 64. Probably what was intended was -to have *this instead of sb. We're talking about the exception flag -state of a basic_istream object, and there's only one basic_istream -object in this discussion, so that would be a consistent -interpretation. (But we need to be careful: the exception policy of -this member function must be consistent with that of other -extractors.) PJP will provide wording. -]

    - - - - -

    Proposed resolution:

    -

    Change the sentence from:

    - -

    -If it inserted no characters because it caught an exception thrown -while extracting characters from sb and failbit is on in exceptions(), -then the caught exception is rethrown. -

    - -

    to:

    - -

    -If it inserted no characters because it caught an exception thrown -while extracting characters from *this and failbit is on in exceptions(), -then the caught exception is rethrown. -

    - - - - - -
    -

    414. Which iterators are invalidated by v.erase()?

    -

    Section: 23.2.6.4 [vector.modifiers] Status: WP - Submitter: Matt Austern Date: 2003-08-19

    -

    View all other issues in [vector.modifiers].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -Consider the following code fragment: -

    -
    -
    int A[8] = { 1,3,5,7,9,8,4,2 };
-std::vector<int> v(A, A+8);
-
-std::vector<int>::iterator i1 = v.begin() + 3;
-std::vector<int>::iterator i2 = v.begin() + 4;
-v.erase(i1);
-
    -
    - -

    -Which iterators are invalidated by v.erase(i1): i1, i2, -both, or neither? -

    - -

    -On all existing implementations that I know of, the status of i1 and -i2 is the same: both of them will be iterators that point to some -elements of the vector (albeit not the same elements they did -before). You won't get a crash if you use them. Depending on -exactly what you mean by "invalidate", you might say that neither one -has been invalidated because they still point to something, -or you might say that both have been invalidated because in both -cases the elements they point to have been changed out from under the -iterator. -

    - -

    -The standard doesn't say either of those things. It says that erase -invalidates all iterators and references "after the point of the -erase". This doesn't include i1, since it's at the point of the -erase instead of after it. I can't think of any sensible definition -of invalidation by which one can say that i2 is invalidated but i1 -isn't. -

    - -

    -(This issue is important if you try to reason about iterator validity -based only on the guarantees in the standard, rather than reasoning -from typical implementation techniques. Strict debugging modes, -which some programmers find useful, do not use typical implementation -techniques.) -

    - - -

    Proposed resolution:

    -

    -In 23.2.6.4 [vector.modifiers] paragraph 3, change "Invalidates all the -iterators and references after the point of the erase" to -"Invalidates iterators and references at or after the point of the -erase". -

    - - -

    Rationale:

    -

    I believe this was essentially a typographical error, and that it - was taken for granted that erasing an element invalidates iterators - that point to it. The effects clause in question treats iterators - and references in parallel, and it would seem counterintuitive to - say that a reference to an erased value remains valid.

    - - - - - -
    -

    415. behavior of std::ws

    -

    Section: 27.6.1.4 [istream.manip] Status: WP - Submitter: Martin Sebor Date: 2003-09-18

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -According to 27.6.1.4, the ws() manipulator is not required to construct -the sentry object. The manipulator is also not a member function so the -text in 27.6.1, p1 through 4 that describes the exception policy for -istream member functions does not apply. That seems inconsistent with -the rest of extractors and all the other input functions (i.e., ws will -not cause a tied stream to be flushed before extraction, it doesn't check -the stream's exceptions or catch exceptions thrown during input, and it -doesn't affect the stream's gcount). -

    - - -

    Proposed resolution:

    -

    -Add to 27.6.1.4 [istream.manip], immediately before the first sentence -of paragraph 1, the following text: -

    - -

    - Behaves as an unformatted input function (as described in - 27.6.1.3, paragraph 1), except that it does not count the number - of characters extracted and does not affect the value returned by - subsequent calls to is.gcount(). After constructing a sentry - object... -

    - -

    [Post-Kona: Martin provided wording]

    - - - - - - -
    -

    416. definitions of XXX_MIN and XXX_MAX macros in climits

    -

    Section: 18.2.2 [c.limits] Status: WP - Submitter: Martin Sebor Date: 2003-09-18

    -

    View all issues with WP status.

    -

    Discussion:

    -

    - -Given two overloads of the function foo(), one taking an argument of type -int and the other taking a long, which one will the call foo(LONG_MAX) -resolve to? The expected answer should be foo(long), but whether that -is true depends on the #defintion of the LONG_MAX macro, specifically -its type. This issue is about the fact that the type of these macros -is not actually required to be the same as the the type each respective -limit. -
    - -Section 18.2.2 of the C++ Standard does not specify the exact types of -the XXX_MIN and XXX_MAX macros #defined in the <climits> and <limits.h> -headers such as INT_MAX and LONG_MAX and instead defers to the C standard. -
    - -Section 5.2.4.2.1, p1 of the C standard specifies that "The values [of -these constants] shall be replaced by constant expressions suitable for use -in #if preprocessing directives. Moreover, except for CHAR_BIT and MB_LEN_MAX, -the following shall be replaced by expressions that have the same type as -would an expression that is an object of the corresponding type converted -according to the integer promotions." -
    - -The "corresponding type converted according to the integer promotions" for -LONG_MAX is, according to 6.4.4.1, p5 of the C standard, the type of long -converted to the first of the following set of types that can represent it: -int, long int, long long int. So on an implementation where (sizeof(long) -== sizeof(int)) this type is actually int, while on an implementation where -(sizeof(long) > sizeof(int)) holds this type will be long. -
    - -This is not an issue in C since the type of the macro cannot be detected -by any conforming C program, but it presents a portability problem in C++ -where the actual type is easily detectable by overload resolution. - -

    -

    [Kona: the LWG does not believe this is a defect. The C macro - definitions are what they are; we've got a better - mechanism, std::numeric_limits, that is specified more - precisely than the C limit macros. At most we should add a - nonnormative note recommending that users who care about the exact - types of limit quantities should use <limits> instead of - <climits>.]

    - - - - -

    Proposed resolution:

    - -

    -Change 18.2.2 [c.limits], paragraph 2: -

    - -

    --2- The contents are the same as the Standard C library header <limits.h>. -[Note: The types of the macros in <climits> are not guaranteed -to match the type to which they refer.--end note] -

    - - - - - -
    -

    420. is std::FILE a complete type?

    -

    Section: 27.8.1 [fstreams] Status: WP - Submitter: Martin Sebor Date: 2003-09-18

    -

    View all other issues in [fstreams].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -7.19.1, p2, of C99 requires that the FILE type only be declared in -<stdio.h>. None of the (implementation-defined) members of the -struct is mentioned anywhere for obvious reasons. -

    - -

    -C++ says in 27.8.1, p2 that FILE is a type that's defined in <cstdio>. Is -it really the intent that FILE be a complete type or is an implementation -allowed to just declare it without providing a full definition? -

    - - -

    Proposed resolution:

    -

    In the first sentence of 27.8.1 [fstreams] paragraph 2, change - "defined" to "declared".

    - - -

    Rationale:

    -

    We don't want to impose any restrictions beyond what the C standard - already says. We don't want to make anything implementation defined, - because that imposes new requirements in implementations.

    - - - - - -
    -

    422. explicit specializations of member functions of class templates

    -

    Section: 17.4.3.2 [reserved.names] Status: WP - Submitter: Martin Sebor Date: 2003-09-18

    -

    View all other issues in [reserved.names].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -It has been suggested that 17.4.3.1, p1 may or may not allow programs to -explicitly specialize members of standard templates on user-defined types. -The answer to the question might have an impact where library requirements -are given using the "as if" rule. I.e., if programs are allowed to specialize -member functions they will be able to detect an implementation's strict -conformance to Effects clauses that describe the behavior of the function -in terms of the other member function (the one explicitly specialized by -the program) by relying on the "as if" rule. -

    - - -

    Proposed resolution:

    - -

    - Add the following sentence to 17.4.3.2 [reserved.names], p1: -

    - -

    -It is undefined for a C++ program to add declarations or definitions to -namespace std or namespaces within namespace std unless otherwise specified. A -program may add template specializations for any standard library template to -namespace std. Such a specialization (complete or partial) of a standard library -template results in undefined behavior unless the declaration depends on a -user-defined type of external linkage and unless the specialization meets the -standard library requirements for the original template.168) -A program has undefined behavior if it declares -

    -
      -
    • an explicit specialization of any member function of a standard - library class template, or
      • -
    • an explicit specialization of any member function template of a - standard library class or class template, or
      • -
    • an explicit or partial specialization of any member class - template of a standard library class or class template.
      • -
    -

    -A program may explicitly instantiate any templates in the standard library only -if the declaration depends on the name of a user-defined type of external -linkage and the instantiation meets the standard library requirements for the -original template. -

    - -

    [Kona: straw poll was 6-1 that user programs should not be - allowed to specialize individual member functions of standard - library class templates, and that doing so invokes undefined - behavior. Post-Kona: Martin provided wording.]

    - - -

    [Sydney: The LWG agrees that the standard shouldn't permit users -to specialize individual member functions unless they specialize the -whole class, but we're not sure these words say what we want them to; -they could be read as prohibiting the specialization of any standard -library class templates. We need to consult with CWG to make sure we -use the right wording.]

    - - - - - - -
    -

    425. return value of std::get_temporary_buffer

    -

    Section: 20.7.8 [temporary.buffer] Status: WP - Submitter: Martin Sebor Date: 2003-09-18

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -The standard is not clear about the requirements on the value returned from -a call to get_temporary_buffer(0). In particular, it fails to specify whether -the call should return a distinct pointer each time it is called (like -operator new), or whether the value is unspecified (as if returned by -malloc). The standard also fails to mention what the required behavior -is when the argument is less than 0. -

    - - -

    Proposed resolution:

    -

    Change 20.5.3 [meta.help] paragraph 2 from "...or a pair of 0 -values if no storage can be obtained" to "...or a pair of 0 values if -no storage can be obtained or if n <= 0."

    -

    [Kona: Matt provided wording]

    - - - - - -
    -

    426. search_n(), fill_n(), and generate_n() with negative n

    -

    Section: 25.1.12 [alg.search], 25.2.6 [alg.fill], 25.2.7 [alg.generate] Status: WP - Submitter: Martin Sebor Date: 2003-09-18

    -

    View all other issues in [alg.search].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -The complexity requirements for these function templates are incorrect -(or don't even make sense) for negative n:

    - -

    25.1.9, p7 (search_n): -
    -Complexity: At most (last1 - first1) * count applications -of the corresponding predicate.

    - -

    25.2.5, p3 (fill_n): -
    -Complexity: Exactly last - first (or n) assignments.

    - -

    25.2.6, p3 (generate_n): -
    -Complexity: Exactly last - first (or n) assignments.

    - -

    -In addition, the Requirements or the Effects clauses for the latter two -templates don't say anything about the behavior when n is negative. -

    - - -

    Proposed resolution:

    -

    Change 25.1.9, p7 to

    - -

    -Complexity: At most (last1 - first1) * count applications -of the corresponding predicate if count is positive, -or 0 otherwise. -

    - -

    Change 25.2.5, p2 to

    -

    -Effects: Assigns value through all the iterators in the range [first, -last), or [first, first + n) if n is positive, none otherwise. -

    - -

    Change 25.2.5, p3 to:

    -

    -Complexity: Exactly last - first (or n if n is positive, -or 0 otherwise) assignments. -

    - -

    -Change 25.2.6, p1 -to (notice the correction for the misspelled "through"): -

    -

    -Effects: Invokes the function object genand assigns the return -value of gen through all the iterators in the range [first, last), -or [first, first + n) if n is positive, or [first, first) -otherwise. -

    - -

    Change 25.2.6, p3 to:

    -

    -Complexity: Exactly last - first (or n if n is positive, -or 0 otherwise) assignments. -

    - - -

    Rationale:

    -

    Informally, we want to say that whenever we see a negative number - we treat it the same as if it were zero. We believe the above - changes do that (although they may not be the minimal way of saying - so). The LWG considered and rejected the alternative of saying that - negative numbers are undefined behavior.

    - - - - - -
    -

    428. string::erase(iterator) validity

    -

    Section: 21.3.6.5 [string::erase] Status: WP - Submitter: Martin Sebor Date: 2003-09-18

    -

    View all other issues in [string::erase].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -23.1.1, p3 along with Table 67 specify as a prerequisite for a.erase(q) -that q must be a valid dereferenceable iterator into the sequence a. -

    - -

    -However, 21.3.5.5, p5 describing string::erase(p) only requires that -p be a valid iterator. -

    - -

    -This may be interepreted as a relaxation of the general requirement, -which is most likely not the intent. -

    - - -

    Proposed resolution:

    -

    Remove 21.3.6.5 [string::erase] paragraph 5.

    - - -

    Rationale:

    -

    The LWG considered two options: changing the string requirements to - match the general container requirements, or just removing the - erroneous string requirements altogether. The LWG chose the latter - option, on the grounds that duplicating text always risks the - possibility that it might be duplicated incorrectly.

    - - - - - -
    -

    432. stringbuf::overflow() makes only one write position available

    -

    Section: 27.7.1.4 [stringbuf.virtuals] Status: WP - Submitter: Christian W Brock Date: 2003-09-24

    -

    View all other issues in [stringbuf.virtuals].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    27.7.1.3 par 8 says:

    -

    -Notes: The function can make a write position available only if - ( mode & ios_base::out) != 0. To make a write position - available, the function reallocates (or initially allocates) an - array object with a sufficient number of elements to hold the - current array object (if any), plus one additional write position. - If ( mode & ios_base::in) != 0, the function alters the read end - pointer egptr() to point just past the new write position (as - does the write end pointer epptr()). -

    - -

    -The sentences "plus one additional write position." and especially - "(as does the write end pointer epptr())" COULD by interpreted - (and is interpreted by at least my library vendor) as: -

    - -

    - post-condition: epptr() == pptr()+1 -

    - -

    -This WOULD force sputc() to call the virtual overflow() each time. -

    - -

    The proposed change also affects Defect Report 169.

    - - - -

    Proposed resolution:

    -

    27.7.1.1/2 Change:

    - -

    -2- Notes: The function allocates no array object. -

    - -

    -to: -

    - -

    -2- Postcondition: str() == "". -

    - -

    -27.7.1.1/3 Change: -

    - -
    -

    --3- Effects: Constructs an object of class basic_stringbuf, -initializing the base class with basic_streambuf() -(lib.streambuf.cons), and initializing mode with which . Then copies -the content of str into the basic_stringbuf underlying character -sequence and initializes the input and output sequences according to -which. If which & ios_base::out is true, initializes the output -sequence with the underlying sequence. If which & ios_base::in is -true, initializes the input sequence with the underlying sequence. -

    -
    - -

    to:

    - -
    -

    --3- Effects: Constructs an object of class basic_stringbuf, -initializing the base class with basic_streambuf() -(lib.streambuf.cons), and initializing mode with which. Then copies -the content of str into the basic_stringbuf underlying character -sequence. If which & ios_base::out is true, initializes the output -sequence such that pbase() points to the first underlying character, -epptr() points one past the last underlying character, and if (which & -ios_base::ate) is true, pptr() is set equal to -epptr() else pptr() is set equal to pbase(). If which & ios_base::in -is true, initializes the input sequence such that eback() and gptr() -point to the first underlying character and egptr() points one past -the last underlying character. -

    -
    - -

    27.7.1.2/1 Change:

    - -
    -

    --1- Returns: A basic_string object whose content is equal to the -basic_stringbuf underlying character sequence. If the buffer is only -created in input mode, the underlying character sequence is equal to -the input sequence; otherwise, it is equal to the output sequence. In -case of an empty underlying character sequence, the function returns -basic_string<charT,traits,Allocator>(). -

    -
    - -

    to:

    - -
    -

    --1- Returns: A basic_string object whose content is equal to the -basic_stringbuf underlying character sequence. If the basic_stringbuf -was created only in input mode, the resultant basic_string contains -the character sequence in the range [eback(), egptr()). If the -basic_stringbuf was created with (which & ios_base::out) being true -then the resultant basic_string contains the character sequence in the -range [pbase(), high_mark) where high_mark represents the position one -past the highest initialized character in the buffer. Characters can -be initialized either through writing to the stream, or by -constructing the basic_stringbuf with a basic_string, or by calling -the str(basic_string) member function. In the case of calling the -str(basic_string) member function, all characters initialized prior to -the call are now considered uninitialized (except for those -characters re-initialized by the new basic_string). Otherwise the -basic_stringbuf has been created in neither input nor output mode and -a zero length basic_string is returned. -

    -
    - -

    -27.7.1.2/2 Change: -

    - -
    -

    --2- Effects: If the basic_stringbuf's underlying character sequence is -not empty, deallocates it. Then copies the content of s into the -basic_stringbuf underlying character sequence and initializes the -input and output sequences according to the mode stored when creating -the basic_stringbuf object. If (mode&ios_base::out) is true, then -initializes the output sequence with the underlying sequence. If -(mode&ios_base::in) is true, then initializes the input sequence with -the underlying sequence. -

    -
    - -

    to:

    - -
    -

    --2- Effects: Copies the content of s into the basic_stringbuf -underlying character sequence. If mode & ios_base::out is true, -initializes the output sequence such that pbase() points to the first -underlying character, epptr() points one past the last underlying -character, and if (mode & ios_base::ate) is true, -pptr() is set equal to epptr() else pptr() is set equal to pbase(). If -mode & ios_base::in is true, initializes the input sequence such that -eback() and gptr() point to the first underlying character and egptr() -points one past the last underlying character. -

    -
    - -

    Remove 27.2.1.2/3. (Same rationale as issue 238: incorrect and unnecessary.)

    - -

    27.7.1.3/1 Change:

    - -
    -

    -1- Returns: If the input sequence has a read position available, -returns traits::to_int_type(*gptr()). Otherwise, returns -traits::eof(). -

    -
    - -

    to:

    - -
    -

    -1- Returns: If the input sequence has a read position available, -returns traits::to_int_type(*gptr()). Otherwise, returns -traits::eof(). Any character in the underlying buffer which has been -initialized is considered to be part of the input sequence. -

    -
    - -

    27.7.1.3/9 Change:

    - -
    -

    --9- Notes: The function can make a write position available only if ( -mode & ios_base::out) != 0. To make a write position available, the -function reallocates (or initially allocates) an array object with a -sufficient number of elements to hold the current array object (if -any), plus one additional write position. If ( mode & ios_base::in) != -0, the function alters the read end pointer egptr() to point just past -the new write position (as does the write end pointer epptr()). -

    -
    - -

    to:

    - -
    -

    --9- The function can make a write position available only if ( mode & -ios_base::out) != 0. To make a write position available, the function -reallocates (or initially allocates) an array object with a sufficient -number of elements to hold the current array object (if any), plus one -additional write position. If ( mode & ios_base::in) != 0, the -function alters the read end pointer egptr() to point just past the -new write position. -

    -
    - -

    27.7.1.3/12 Change:

    - -
    -

    --12- _ If (newoff + off) < 0, or (xend - xbeg) < (newoff + off), the -positioning operation fails. Otherwise, the function assigns xbeg + -newoff + off to the next pointer xnext . -

    -
    - -

    to:

    - -
    -

    --12- _ If (newoff + off) < 0, or if (newoff + off) refers to an -uninitialized character (as defined in 27.7.1.3 [stringbuf.members] -paragraph 1), the positioning operation fails. Otherwise, the function -assigns xbeg + newoff + off to the next pointer xnext . -

    -
    - -

    [post-Kona: Howard provided wording. At Kona the LWG agreed that - something along these lines was a good idea, but the original - proposed resolution didn't say enough about the effect of various - member functions on the underlying character sequences.]

    - - - - -

    Rationale:

    -

    The current basic_stringbuf description is over-constrained in such -a way as to prohibit vendors from making this the high-performance -in-memory stream it was meant to be. The fundamental problem is that -the pointers: eback(), gptr(), egptr(), pbase(), pptr(), epptr() are -observable from a derived client, and the current description -restricts the range [pbase(), epptr()) from being grown geometrically. -This change allows, but does not require, geometric growth of this -range.

    - -

    Backwards compatibility issues: These changes will break code that -derives from basic_stringbuf, observes epptr(), and depends upon -[pbase(), epptr()) growing by one character on each call to overflow() -(i.e. test suites). Otherwise there are no backwards compatibility -issues.

    - -

    27.7.1.1/2: The non-normative note is non-binding, and if it were -binding, would be over specification. The recommended change focuses -on the important observable fact.

    - -

    27.7.1.1/3: This change does two things: 1. It describes exactly -what must happen in terms of the sequences. The terms "input -sequence" and "output sequence" are not well defined. 2. It -introduces a common extension: open with app or ate mode. I concur -with issue 238 that paragraph 4 is both wrong and unnecessary.

    - -

    27.7.1.2/1: This change is the crux of the efficiency issue. The -resultant basic_string is not dependent upon epptr(), and thus -implementors are free to grow the underlying buffer geometrically -during overflow() *and* place epptr() at the end of that buffer.

    - -

    27.7.1.2/2: Made consistent with the proposed 27.7.1.1/3.

    - -

    27.7.1.3/1: Clarifies that characters written to the stream beyond -the initially specified string are available for reading in an i/o -basic_streambuf.

    - -

    27.7.1.3/9: Made normative by removing "Notes:", and removed the -trailing parenthetical comment concerning epptr().

    - -

    27.7.1.3/12: Restricting the positioning to [xbeg, xend) is no -longer allowable since [pbase(), epptr()) may now contain -uninitialized characters. Positioning is only allowable over the -initialized range.

    - - - - - -
    -

    434. bitset::to_string() hard to use

    -

    Section: 23.3.5.2 [bitset.members] Status: DR - Submitter: Martin Sebor Date: 2003-10-15

    -

    View all other issues in [bitset.members].

    -

    View all issues with DR status.

    -

    Discussion:

    -

    -It has been pointed out a number of times that the bitset to_string() member -function template is tedious to use since callers must explicitly specify the -entire template argument list (3 arguments). At least two implementations -provide a number of overloads of this template to make it easier to use. -

    - - - -

    Proposed resolution:

    -

    In order to allow callers to specify no template arguments at all, just the -first one (charT), or the first 2 (charT and traits), in addition to all -three template arguments, add the following three overloads to both the -interface (declarations only) of the class template bitset as well as to -section 23.3.5.2, immediately after p34, the Returns clause of the existing -to_string() member function template:

    - -
        template <class charT, class traits>
-    basic_string<charT, traits, allocator<charT> >
-    to_string () const;
-
-    -34.1- Returns: to_string<charT, traits, allocator<charT> >().
-
-    template <class charT>
-    basic_string<charT, char_traits<charT>, allocator<charT> >
-    to_string () const;
-
-    -34.2- Returns: to_string<charT, char_traits<charT>, allocator<charT> >().
-
-    basic_string<char, char_traits<char>, allocator<char> >
-    to_string () const;
-
-    -34.3- Returns: to_string<char, char_traits<char>, allocator<char> >().
-
    - -

    [Kona: the LWG agrees that this is an improvement over the - status quo. Dietmar thought about an alternative using a proxy - object but now believes that the proposed resolution above is the - right choice. -]

    - - - - - - - - -
    -

    435. bug in DR 25

    -

    Section: 21.3.8.9 [string.io] Status: WP - Submitter: Martin Sebor Date: 2003-10-15

    -

    View all other issues in [string.io].

    -

    View all issues with WP status.

    -

    Discussion:

    - -

    -It has been pointed out that the proposed resolution in DR 25 may not be -quite up to snuff:
    -http://gcc.gnu.org/ml/libstdc++/2003-09/msg00147.html -http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#25
    -

    - -

    -It looks like Petur is right. The complete corrected text is copied below. -I think we may have have been confused by the reference to 22.2.2.2.2 and -the subsequent description of `n' which actually talks about the second -argument to sputn(), not about the number of fill characters to pad with. -

    - -

    -So the question is: was the original text correct? If the intent was to -follow classic iostreams then it most likely wasn't, since setting width() -to less than the length of the string doesn't truncate it on output. This -is also the behavior of most implementations (except for SGI's standard -iostreams where the operator does truncate). -

    - - - -

    Proposed resolution:

    -

    Change the text in 21.3.7.9, p4 from

    -

    - If bool(k) is true, inserts characters as if by calling - os.rdbuf()->sputn(str.data(), n), padding as described in stage 3 - of lib.facet.num.put.virtuals, where n is the larger of os.width() - and str.size(); -

    -

    to

    -

    - If bool(k) is true, determines padding as described in - lib.facet.num.put.virtuals, and then inserts the resulting - sequence of characters seq as if by calling - os.rdbuf()->sputn(seq, n), where n is the larger of - os.width() and str.size(); -

    - -

    [Kona: it appears that neither the original wording, DR25, nor the - proposed resolution, is quite what we want. We want to say that - the string will be output, padded to os.width() if necessary. We - don't want to duplicate the padding rules in clause 22, because - they're complicated, but we need to be careful because they weren't - quite written with quite this case in mind. We need to say what - the character sequence is, and then defer to clause 22. Post-Kona: - Benjamin provided wording.]

    - - - - - - - -
    -

    436. are cv-qualified facet types valid facets?

    -

    Section: 22.1.1.1.2 [locale.facet] Status: WP - Submitter: Martin Sebor Date: 2003-10-15

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -Is "const std::ctype<char>" a valid template argument to has_facet, use_facet, -and the locale template ctor? And if so, does it designate the same Facet as -the non-const "std::ctype<char>?" What about "volatile std::ctype<char>?" -Different implementations behave differently: some fail to compile, others -accept such types but behave inconsistently. -

    - - -

    Proposed resolution:

    -

    Change 22.1.1.1.2, p1 to read:

    - -

    Template parameters in this clause which are required to be facets -are those named Facet in declarations. A program that passes a type -that is not a facet, or a type that refers to volatile-qualified -facet, as an (explicit or deduced) template parameter to a locale -function expecting a facet, is ill-formed. A const-qualified facet is -a valid template argument to any locale function that expects a Facet -template parameter.

    - -

    [Kona: changed the last sentence from a footnote to normative -text.]

    - - - - - - -
    -

    438. Ambiguity in the "do the right thing" clause

    -

    Section: 23.1.3 [sequence.reqmts] Status: DR - Submitter: Howard Hinnant Date: 2003-10-20

    -

    View all other issues in [sequence.reqmts].

    -

    View all issues with DR status.

    -

    Discussion:

    - -

    Section 23.1.3 [sequence.reqmts], paragraphs 9-11, fixed up the problem -noticed with statements like:

    -
    vector<int> v(10, 1);
-
    - -

    The intent of the above statement was to construct with:

    -
    vector(size_type, const value_type&);
-
    - -

    but early implementations failed to compile as they bound to:

    -
    template <class InputIterator>
-vector(InputIterator f, InputIterator l);
-
    -

    instead.

    - -

    Paragraphs 9-11 say that if InputIterator is an integral type, then the -member template constructor will have the same effect as:

    -
    vector<static_cast<size_type>(f), static_cast<value_type>(l));
-
    -

    (and similarly for the other member template functions of sequences).

    - -

    There is also a note that describes one implementation technique:

    -

    - One way that sequence implementors can satisfy this requirement is to - specialize the member template for every integral type. -

    - -

    This might look something like:

    -
    -
    template <class T>
-struct vector
-{
-     typedef unsigned size_type;
-
-     explicit vector(size_type) {}
-     vector(size_type, const T&) {}
-
-     template <class I>
-     vector(I, I);
-
-     // ...
-};
-
-template <class T>
-template <class I>
-vector<T>::vector(I, I) { ... }
-
-template <>
-template <>
-vector<int>::vector(int, int) { ... }
-
-template <>
-template <>
-vector<int>::vector(unsigned, unsigned) { ... }
-
-//  ...
-
    -
    - -

    Label this solution 'A'.

    - -

    The standard also says:

    -

    - Less cumbersome implementation techniques also exist. -

    -

    -A popular technique is to not specialize as above, but instead catch -every call with the member template, detect the type of InputIterator, -and then redirect to the correct logic. Something like: -

    -
    -
    template <class T>
-template <class I>
-vector<T>::vector(I f, I l)
-{
-     choose_init(f, l, int2type<is_integral<I>::value>());
-}
-
-template <class T>
-template <class I>
-vector<T>::choose_init(I f, I l, int2type<false>)
-{
-    // construct with iterators
-}
-
-template <class T>
-template <class I>
-vector<T>::choose_init(I f, I l, int2type<true>)
-{
-    size_type sz = static_cast<size_type>(f);
-    value_type v = static_cast<value_type>(l);
-    // construct with sz,v
-}
-
    -
    - -

    Label this solution 'B'.

    - -

    Both of these solutions solve the case the standard specifically -mentions:

    -
    vector<int> v(10, 1);  // ok, vector size 10, initialized to 1
-
    - -

    -However, (and here is the problem), the two solutions have different -behavior in some cases where the value_type of the sequence is not an -integral type. For example consider: -

    -
         pair<char, char>                     p('a', 'b');
-     vector<vector<pair<char, char> > >   d('a', 'b');
-
    -

    -The second line of this snippet is likely an error. Solution A catches -the error and refuses to compile. The reason is that there is no -specialization of the member template constructor that looks like: -

    -
    template <>
-template <>
-vector<vector<pair<char, char> > >::vector(char, char) { ... }
-
    - -

    -So the expression binds to the unspecialized member template -constructor, and then fails (compile time) because char is not an -InputIterator. -

    - -

    -Solution B compiles the above example though. 'a' is casted to an -unsigned integral type and used to size the outer vector. 'b' is -static casted to the inner vector using it's explicit constructor: -

    - -
    explicit vector(size_type n);
-
    - -

    -and so you end up with a static_cast<size_type>('a') by -static_cast<size_type>('b') matrix. -

    - -

    -It is certainly possible that this is what the coder intended. But the -explicit qualifier on the inner vector has been thwarted at any rate. -

    - -

    -The standard is not clear whether the expression: -

    - -
         vector<vector<pair<char, char> > >   d('a', 'b');
-
    - -

    -(and similar expressions) are: -

    - -
      -
    1. undefined behavior.
      2. -
    2. illegal and must be rejected.
      3. -
    3. legal and must be accepted.
      4. -
    - -

    My preference is listed in the order presented.

    - -

    There are still other techniques for implementing the requirements of -paragraphs 9-11, namely the "restricted template technique" (e.g. -enable_if). This technique is the most compact and easy way of coding -the requirements, and has the behavior of #2 (rejects the above -expression). -

    - -

    -Choosing 1 would allow all implementation techniques I'm aware of. -Choosing 2 would allow only solution 'A' and the enable_if technique. -Choosing 3 would allow only solution 'B'. -

    - -

    -Possible wording for a future standard if we wanted to actively reject -the expression above would be to change "static_cast" in paragraphs -9-11 to "implicit_cast" where that is defined by: -

    - -
    -
    template <class T, class U>
-inline
-T implicit_cast(const U& u)
-{
-     return u;
-}
-
    -
    - - - -

    Proposed resolution:

    - -

    Replace 23.1.3 [sequence.reqmts] paragraphs 9 - 11 with:

    - -

    For every sequence defined in this clause and in clause lib.strings:

    - -
      -
    • -

      If the constructor

      - 
             template <class InputIterator>
-       X(InputIterator f, InputIterator l,
-         const allocator_type& a = allocator_type())
-
      -

      is called with a type InputIterator that does not qualify as - an input iterator, then the constructor will behave as if the - overloaded constructor:

      - 
             X(size_type, const value_type& = value_type(),
-         const allocator_type& = allocator_type())
-
      -

      were called instead, with the arguments static_cast<size_type>(f), l and a, respectively.

      -
      • - -
    • -

      If the member functions of the forms:

      - 
             template <class InputIterator>          //  such as  insert()
-       rt fx1(iterator p, InputIterator f, InputIterator l);
-
-       template <class InputIterator>          //  such as  append(), assign()
-       rt fx2(InputIterator f, InputIterator l);
-
-       template <class InputIterator>          //  such as  replace()
-       rt fx3(iterator i1, iterator i2, InputIterator f, InputIterator l);
-
      -

      are called with a type InputIterator that does not qualify as - an input iterator, then these functions will behave as if the - overloaded member functions:

      - 
             rt fx1(iterator, size_type, const value_type&);
-
-       rt fx2(size_type, const value_type&);
-
-       rt fx3(iterator, iterator, size_type, const value_type&);
-
      -

      were called instead, with the same arguments.

      -
      • -
    - -

    In the previous paragraph the alternative binding will fail if f -is not implicitly convertible to X::size_type or if l is not implicitly -convertible to X::value_type.

    - -

    -The extent to which an implementation determines that a type cannot be -an input iterator is unspecified, except that as a minimum integral -types shall not qualify as input iterators. -

    - - - -

    [ -Kona: agreed that the current standard requires v('a', 'b') -to be accepted, and also agreed that this is surprising behavior. The -LWG considered several options, including something like -implicit_cast, which doesn't appear to be quite what we want. We -considered Howards three options: allow acceptance or rejection, -require rejection as a compile time error, and require acceptance. By -straw poll (1-6-1), we chose to require a compile time error. -Post-Kona: Howard provided wording. -]

    - - -

    [ -Sydney: The LWG agreed with this general direction, but there was some -discomfort with the wording in the original proposed resolution. -Howard submitted new wording, and we will review this again in -Redmond. -]

    - - -

    [Redmond: one very small change in wording: the first argument - is cast to size_t. This fixes the problem of something like - vector<vector<int> >(5, 5), where int is not - implicitly convertible to the value type.]

    - - - - -

    Rationale:

    -

    The proposed resolution fixes:

    - -
      vector<int> v(10, 1);
-
    - -

    -since as integral types 10 and 1 must be disqualified as input -iterators and therefore the (size,value) constructor is called (as -if).

    - -

    The proposed resolution breaks:

    - -
      vector<vector<T> > v(10, 1);
-
    - -

    -because the integral type 1 is not *implicitly* convertible to -vector<T>. The wording above requires a diagnostic.

    - -

    -The proposed resolution leaves the behavior of the following code -unspecified. -

    - -
      struct A
-  {
-    operator int () const {return 10;}
-  };
-
-  struct B
-  {
-    B(A) {}
-  };
-
-  vector<B> v(A(), A());
-
    - -

    -The implementation may or may not detect that A is not an input -iterator and employee the (size,value) constructor. Note though that -in the above example if the B(A) constructor is qualified explicit, -then the implementation must reject the constructor as A is no longer -implicitly convertible to B. -

    - - - - - -
    -

    441. Is fpos::state const?

    -

    Section: 27.4.3 [fpos] Status: WP - Submitter: Vincent Leloup Date: 2003-11-17

    -

    View all other issues in [fpos].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -In section 27.4.3.1 [fpos.members] fpos<stateT>::state() is declared -non const, but in section 27.4.3 [fpos] it is declared const. -

    - - -

    Proposed resolution:

    -

    -In section 27.4.3.1 [fpos.members], change the declaration of -fpos<stateT>::state() to const. -

    - - - - - -
    -

    442. sentry::operator bool() inconsistent signature

    -

    Section: 27.6.2.4 [ostream::sentry] Status: WP - Submitter: Vincent Leloup Date: 2003-11-18

    -

    View other active issues in [ostream::sentry].

    -

    View all other issues in [ostream::sentry].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -In section 27.6.2.4 [ostream::sentry] paragraph 4, in description part -basic_ostream<charT, traits>::sentry::operator bool() is declared -as non const, but in section 27.6.2.3, in synopsis it is declared -const. -

    - - -

    Proposed resolution:

    -

    -In section 27.6.2.4 [ostream::sentry] paragraph 4, change the declaration -of sentry::operator bool() to const. -

    - - - - - -
    -

    443. filebuf::close() inconsistent use of EOF

    -

    Section: 27.8.1.4 [filebuf.members] Status: WP - Submitter: Vincent Leloup Date: 2003-11-20

    -

    View all other issues in [filebuf.members].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -In section 27.8.1.4 [filebuf.members] par6, in effects description of -basic_filebuf<charT, traits>::close(), overflow(EOF) is used twice; -should be overflow(traits::eof()). -

    - - -

    Proposed resolution:

    -

    -Change overflow(EOF) to overflow(traits::eof()). -

    - - - - - -
    -

    444. Bad use of casts in fstream

    -

    Section: 27.8.1 [fstreams] Status: DR - Submitter: Vincent Leloup Date: 2003-11-20

    -

    View all other issues in [fstreams].

    -

    View all issues with DR status.

    -

    Discussion:

    -

    27.8.1.9 [ifstream.members] p1, 27.8.1.13 [ofstream.members] p1, -27.8.1.17 [fstream.members] p1 seems have same problem as exposed in -LWG issue -252. -

    - - -

    Proposed resolution:

    - -

    [Sydney: Genuine defect. 27.8.1.13 needs a cast to cast away - constness. The other two places are stylistic: we could change the - C-style casts to const_cast. Post-Sydney: Howard provided wording. -]

    - - -

    Change 27.8.1.7/1 from:

    -

    - Returns: (basic_filebuf<charT,traits>*)&sb. -

    - -

    to:

    -

    - Returns: const_cast<basic_filebuf<charT,traits>*>(&sb). -

    - -

    Change 27.8.1.10/1 from:

    -

    - Returns: (basic_filebuf<charT,traits>*)&sb. -

    - -

    to:

    -

    - Returns: const_cast<basic_filebuf<charT,traits>*>(&sb). -

    - -

    Change 27.8.1.13/1 from:

    -

    - Returns: &sb. -

    - -

    to:

    -

    - Returns: const_cast<basic_filebuf<charT,traits>*>(&sb). -

    - - - - - - - - -
    -

    445. iterator_traits::reference unspecified for some iterator categories

    -

    Section: 24.3.1 [iterator.traits] Status: DR - Submitter: Dave Abrahams Date: 2003-12-09

    -

    View all issues with DR status.

    -

    Discussion:

    -

    -The standard places no restrictions at all on the reference type -of input, output, or forward iterators (for forward iterators it -only specifies that *x must be value_type& and doesn't mention -the reference type). Bidirectional iterators' reference type is -restricted only by implication, since the base iterator's -reference type is used as the return type of reverse_iterator's -operator*, which must be T& in order to be a conforming forward -iterator. -

    - -

    -Here's what I think we ought to be able to expect from an input -or forward iterator's reference type R, where a is an iterator -and V is its value_type -

    - -
      -
    • - *a is convertible to R -
      • - -
    • - R is convertible to V -
      • - -
    • - static_cast<V>(static_cast<R>(*a)) is equivalent to - static_cast<V>(*a) -
      • -
    - -

    A mutable forward iterator ought to satisfy, for x of type V:

    - 
          { R r = *a; r = x; } is equivalent to *a = x;
-
    - -

    -I think these requirements capture existing container iterators -(including vector<bool>'s), but render istream_iterator invalid; -its reference type would have to be changed to a constant -reference. -

    - - -

    -(Jeremy Siek) During the discussion in Sydney, it was felt that a -simpler long term solution for this was needed. The solution proposed -was to require reference to be the same type as *a -and pointer to be the same type as a->. Most -iterators in the Standard Library already meet this requirement. Some -iterators are output iterators, and do not need to meet the -requirement, and others are only specified through the general -iterator requirements (which will change with this resolution). The -sole case where there is an explicit definition of the reference type -that will need to change is istreambuf_iterator which returns -charT from operator* but has a reference type of -charT&. We propose changing the reference type of -istreambuf_iterator to charT. -

    - -

    The other option for resolving the issue with pointer, - mentioned in the note below, is to remove pointer - altogether. I prefer placing requirements on pointer to - removing it for two reasons. First, pointer will become - useful for implementing iterator adaptors and in particular, - reverse_iterator will become more well defined. Second, - removing pointer is a rather drastic and publicly-visible - action to take.

    - -

    The proposed resolution technically enlarges the requirements for -iterators, which means there are existing iterators (such as -istreambuf_iterator, and potentially some programmer-defined -iterators) that will no longer meet the requirements. Will this break -existing code? The scenario in which it would is if an algorithm -implementation (say in the Standard Library) is changed to rely on -iterator_traits::reference, and then is used with one of the -iterators that do not have an appropriately defined -iterator_traits::reference. -

    - - -

    The proposed resolution makes one other subtle change. Previously, -it was required that output iterators have a difference_type -and value_type of void, which means that a forward -iterator could not be an output iterator. This is clearly a mistake, -so I've changed the wording to say that those types may be -void. -

    - - - -

    Proposed resolution:

    - -

    In 24.3.1 [iterator.traits], after:

    - -

    -be defined as the iterator's difference type, value type and iterator -category, respectively. -

    - -

    add

    - -

    -In addition, the types

    -
    iterator_traits<Iterator>::reference
-iterator_traits<Iterator>::pointer
-
    -

    must be defined as the iterator's reference and pointer types, that -is, the same type as the type of *a and a->, -respectively.

    -
    - -

    In 24.3.1 [iterator.traits], change:

    - -

    -In the case of an output iterator, the types

    -
    iterator_traits<Iterator>::difference_type
-iterator_traits<Iterator>::value_type
-
    -

    are both defined as void.

    -
    - -

    to:

    -

    -In the case of an output iterator, the types

    -
    iterator_traits<Iterator>::difference_type
-iterator_traits<Iterator>::value_type
-iterator_traits<Iterator>::reference
-iterator_traits<Iterator>::pointer
-
    -

    may be defined as void.

    -
    - -

    In 24.5.3 [istreambuf.iterator], change:

    -
    -
    typename traits::off_type, charT*, charT&>
-
    -
    -

    to:

    -
    -
    typename traits::off_type, charT*, charT>
-
    -
    - -

    [ -Redmond: there was concern in Sydney that this might not be the only place -where things were underspecified and needed to be changed. Jeremy -reviewed iterators in the standard and confirmed that nothing else -needed to be changed. -]

    - - - - - - - - - -
    -

    448. Random Access Iterators over abstract classes

    -

    Section: 24.1.5 [random.access.iterators] Status: WP - Submitter: Dave Abrahams Date: 2004-01-07

    -

    View all other issues in [random.access.iterators].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -Table 76, the random access iterator requirement table, says that the -return type of a[n] must be "convertible to T". When an iterator's -value_type T is an abstract class, nothing is convertible to T. -Surely this isn't an intended restriction? -

    - - -

    Proposed resolution:

    -

    -Change the return type to "convertible to T const&". -

    - - - - - -
    -

    449. Library Issue 306 Goes Too Far

    -

    Section: 18.1 [support.types] Status: WP - Submitter: Pete Becker Date: 2004-01-15

    -

    View all other issues in [support.types].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    Original text:

    -

    -The macro offsetof accepts a restricted set of type arguments in this -International Standard. type shall be a POD structure or a POD union -(clause 9). The result of applying the offsetof macro to a field that -is a static data member or a function member is undefined." -

    - -

    Revised text:

    -

    -"If type is not a POD structure or a POD union the results are undefined." -

    - -

    -Looks to me like the revised text should have replaced only the second -sentence. It doesn't make sense standing alone. -

    - - - -

    Proposed resolution:

    -

    Change 18.1, paragraph 5, to:

    - -

    -The macro offsetof accepts a restricted set of type arguments in this -International Standard. If type is not a POD structure or a POD union -the results are undefined. The result of applying the offsetof macro -to a field that is a static data member or a function member is -undefined." -

    - - - - - -
    -

    453. basic_stringbuf::seekoff need not always fail for an empty stream

    -

    Section: 27.7.1.4 [stringbuf.virtuals] Status: WP - Submitter: Bill Plauger Date: 2004-01-30

    -

    View all other issues in [stringbuf.virtuals].

    -

    View all issues with WP status.

    -

    Discussion:

    -
      pos_type basic_stringbuf::seekoff(off_type, ios_base::seekdir,
-                                    ios_base::openmode);
-
    -

    -is obliged to fail if nothing has been inserted into the stream. This -is unnecessary and undesirable. It should be permissible to seek to -an effective offset of zero.

    - -

    [ - Sydney: Agreed that this is an annoying problem: seeking to zero should be - legal. Bill will provide wording. -]

    - - - - -

    Proposed resolution:

    -

    Change the sentence from:

    -

    -For a sequence to be positioned, if its next pointer (either -gptr() or pptr()) is a null pointer, the positioning operation -fails. -

    - -

    to:

    - -

    -For a sequence to be positioned, if its next pointer (either -gptr() or pptr()) is a null pointer and the new offset newoff -is nonzero, the positioning operation fails. -

    - - - - - -
    -

    455. cerr::tie() and wcerr::tie() are overspecified

    -

    Section: 27.3 [iostream.objects] Status: DR - Submitter: Bill Plauger Date: 2004-01-30

    -

    View all other issues in [iostream.objects].

    -

    View all issues with DR status.

    -

    Discussion:

    -

    -Both cerr::tie() and wcerr::tie() are obliged to be null at program -startup. This is overspecification and overkill. It is both traditional -and useful to tie cerr to cout, to ensure that standard output is drained -whenever an error message is written. This behavior should at least be -permitted if not required. Same for wcerr::tie(). -

    - - -

    Proposed resolution:

    - -

    Add to the description of cerr:

    -

    -After the object cerr is initialized, cerr.tie() returns &cout. -Its state is otherwise the same as required for basic_ios<char>::init -(lib.basic.ios.cons). -

    - -

    Add to the description of wcerr:

    - -

    -After the object wcerr is initialized, wcerr.tie() returns &wcout. -Its state is otherwise the same as required for basic_ios<wchar_t>::init -(lib.basic.ios.cons). -

    - -

    [Sydney: straw poll (3-1): we should require, not just - permit, cout and cerr to be tied on startup. Pre-Redmond: Bill will - provide wording.]

    - - - - - - -
    -

    456. Traditional C header files are overspecified

    -

    Section: 17.4.1.2 [headers] Status: WP - Submitter: Bill Plauger Date: 2004-01-30

    -

    View all other issues in [headers].

    -

    View all issues with WP status.

    -

    Discussion:

    - -

    The C++ Standard effectively requires that the traditional C headers -(of the form <xxx.h>) be defined in terms of the newer C++ -headers (of the form <cxxx>). Clauses 17.4.1.2/4 and D.5 combine -to require that:

    - -
      -
    • Including the header <cxxx> declares a C name in namespace std.
      • - -
    • Including the header <xxx.h> declares a C name in namespace std - (effectively by including <cxxx>), then imports it into the global - namespace with an individual using declaration.
      • -
    - -

    -The rules were left in this form despited repeated and heated objections -from several compiler vendors. The C headers are often beyond the direct -control of C++ implementors. In some organizations, it's all they can do -to get a few #ifdef __cplusplus tests added. Third-party library vendors -can perhaps wrap the C headers. But neither of these approaches supports -the drastic restructuring required by the C++ Standard. As a result, it is -still widespread practice to ignore this conformance requirement, nearly -seven years after the committee last debated this topic. Instead, what is -often implemented is: -

    - -
      -
    • Including the header <xxx.h> declares a C name in the - global namespace.
      • - -
    • Including the header <cxxx> declares a C name in the - global namespace (effectively by including <xxx.h>), then - imports it into namespace std with an individual using declaration.
      • -
    - -

    -The practical benefit for implementors with the second approach is that -they can use existing C library headers, as they are pretty much obliged -to do. The practical cost for programmers facing a mix of implementations -is that they have to assume weaker rules:

    - -
      -
    • If you want to assuredly declare a C name in the global - namespace, include <xxx.h>. You may or may not also get the - declaration in namespace std.
      • - -
    • If you want to assuredly declare a C name in namespace std, - include <cxxx>. You may or may not also get the declaration in - the global namespace.
      • -
    - -

    -There also exists the possibility of subtle differences due to -Koenig lookup, but there are so few non-builtin types defined in the C -headers that I've yet to see an example of any real problems in this -area. -

    - -

    -It is worth observing that the rate at which programmers fall afoul of -these differences has remained small, at least as measured by newsgroup -postings and our own bug reports. (By an overwhelming margin, the -commonest problem is still that programmers include <string> and can't -understand why the typename string isn't defined -- this a decade after -the committee invented namespace std, nominally for the benefit of all -programmers.) -

    - -

    -We should accept the fact that we made a serious mistake and rectify it, -however belatedly, by explicitly allowing either of the two schemes for -declaring C names in headers. -

    - -

    [Sydney: This issue has been debated many times, and will - certainly have to be discussed in full committee before any action - can be taken. However, the preliminary sentiment of the LWG was in - favor of the change. (6 yes, 0 no, 2 abstain) Robert Klarer - suggests that we might also want to undeprecate the - C-style .h headers.]

    - - - - -

    Proposed resolution:

    -

    -Add to 17.4.1.2 [headers], para. 4: -

    - -

    -Except as noted in clauses 18 through 27 and Annex D, the contents of each -header cname shall be the same as that of the corresponding header -name.h, as specified in ISO/IEC 9899:1990 Programming Languages C (Clause -7), or ISO/IEC:1990 Programming Languages-C AMENDMENT 1: C Integrity, (Clause -7), as appropriate, as if by inclusion. In the C++ Standard Library, however, -the declarations and definitions (except for names which are defined -as macros in C) are within namespace scope (3.3.5) of the namespace std. -It is unspecified whether these names are first declared within the global -namespace scope and are then injected into namespace std by explicit -using-declarations (7.3.3 [namespace.udecl]). -

    - -

    -Change D.5 [depr.c.headers], para. 2-3: -

    - -
    -

    --2- Every C header, each of which has a name of the form name.h, behaves -as if each name placed in the Standard library namespace by the corresponding -cname header is also placed within the global -namespace scope. of the namespace std and is followed -by an explicit using-declaration (7.3.3 [namespace.udecl]). -It is unspecified whether these names are first declared or defined within -namespace scope (3.3.5 [basic.scope.namespace]) of the namespace -std and are then injected into the global namespace scope by explicit -using-declarations (7.3.3 [namespace.udecl]). -

    -

    --3- [Example: The header <cstdlib> assuredly -provides its declarations and definitions within the namespace std. -It may also provide these names within the global namespace. The -header <stdlib.h> makes these available also in -assuredly provides the same declarations and definitions within the -global namespace, much as in the C Standard. It may also provide these -names within the namespace std. -- end example] -

    -
    - - - - - -
    -

    457. bitset constructor: incorrect number of initialized bits

    -

    Section: 23.3.5.1 [bitset.cons] Status: DR - Submitter: Dag Henriksson Date: 2004-01-30

    -

    View all other issues in [bitset.cons].

    -

    View all issues with DR status.

    -

    Discussion:

    -

    -The constructor from unsigned long says it initializes "the first M -bit positions to the corresponding bit values in val. M is the smaller -of N and the value CHAR_BIT * sizeof(unsigned long)." -

    - -

    -Object-representation vs. value-representation strikes again. CHAR_BIT * -sizeof (unsigned long) does not give us the number of bits an unsigned long -uses to hold the value. Thus, the first M bit position above is not -guaranteed to have any corresponding bit values in val. -

    - - -

    Proposed resolution:

    -

    In 23.3.5.1 [bitset.cons] paragraph 2, change "M is the smaller of - N and the value CHAR_BIT * sizeof (unsigned long). (249)" to - "M is the smaller of N and the number of bits in - the value representation (section 3.9 [basic.types]) of unsigned - long." -

    - - - - - -
    -

    460. Default modes missing from basic_fstream member specifications

    -

    Section: 27.8.1 [fstreams] Status: DR - Submitter: Ben Hutchings Date: 2004-04-01

    -

    View all other issues in [fstreams].

    -

    View all issues with DR status.

    -

    Discussion:

    -

    -The second parameters of the non-default constructor and of the open -member function for basic_fstream, named "mode", are optional -according to the class declaration in 27.8.1.11 [lib.fstream]. The -specifications of these members in 27.8.1.12 [lib.fstream.cons] and -27.8.1.13 lib.fstream.members] disagree with this, though the -constructor declaration has the "explicit" function-specifier implying -that it is intended to be callable with one argument. -

    - - -

    Proposed resolution:

    -

    In 27.8.1.15 [fstream.cons], change

    -
      explicit basic_fstream(const char* s, ios_base::openmode mode); 
-
    -

    to

    -
      explicit basic_fstream(const char* s,
-                         ios_base::openmode mode = ios_base::in|ios_base::out);
-
    -

    In 27.8.1.17 [fstream.members], change

    -
      void open(const char*s, ios_base::openmode mode); 
-
    -

    to

    -
      void open(const char*s,
-            ios_base::openmode mode = ios_base::in|ios_base::out);
-
    - - - - - -
    -

    461. time_get hard or impossible to implement

    -

    Section: 22.2.5.1.2 [locale.time.get.virtuals] Status: WP - Submitter: Bill Plauger Date: 2004-03-23

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -Template time_get currently contains difficult, if not impossible, -requirements for do_date_order, do_get_time, and do_get_date. All require -the implementation to scan a field generated by the %x or %X conversion -specifier in strftime. Yes, do_date_order can always return no_order, but -that doesn't help the other functions. The problem is that %x can be -nearly anything, and it can vary widely with locales. It's horribly -onerous to have to parse "third sunday after Michaelmas in the year of -our Lord two thousand and three," but that's what we currently ask of -do_get_date. More practically, it leads some people to think that if -%x produces 10.2.04, we should know to look for dots as separators. Still -not easy. -

    - -

    -Note that this is the opposite effect from the intent stated in the -footnote earlier in this subclause: -

    - -

    -"In other words, user confirmation is required for reliable parsing of -user-entered dates and times, but machine-generated formats can be -parsed reliably. This allows parsers to be aggressive about interpreting -user variations on standard formats." -

    - -

    -We should give both implementers and users an easier and more reliable -alternative: provide a (short) list of alternative delimiters and say -what the default date order is for no_order. For backward compatibility, -and maximum latitude, we can permit an implementation to parse whatever -%x or %X generates, but we shouldn't require it. -

    - - -

    Proposed resolution:

    - -

    In the description:

    -
    iter_type do_get_time(iter_type s, iter_type end, ios_base& str,
-        ios_base::iostate& err, tm* t) const;
-
    - -

    -2 Effects: Reads characters starting at suntil it has extracted those -struct tm members, and remaining format characters, used by -time_put<>::put to produce the format specified by 'X', or until it -encounters an error or end of sequence. -

    - -

    change: 'X'

    - -

    to: "%H:%M:%S"

    - - -

    Change

    -
    iter_type do_get_date(iter_type s, iter_type end, ios_base& str,
-        ios_base::iostate& err, tm* t) const;
-
-4 Effects: Reads characters starting at s until it has extracted those
-struct tm members, and remaining format characters, used by
-time_put<>::put to produce the format specified by 'x', or until it
-encounters an error.
-
    - -

    to

    -
    iter_type do_get_date(iter_type s, iter_type end, ios_base& str,
-        ios_base::iostate& err, tm* t) const;
-
    - -

    -4 Effects: Reads characters starting at s until it has extracted those -struct tm members, and remaining format characters, used by -time_put<>::put to produce one of the following formats, or until it -encounters an error. The format depends on the value returned by -date_order() as follows: -

    - -
            date_order()  format
-
-        no_order      "%m/%d/%y"
-        dmy           "%d/%m/%y"
-        mdy           "%m/%d/%y"
-        ymd           "%y/%m/%d"
-        ydm           "%y/%d/%m"
-
    -

    -An implementation may also accept additional implementation-defined formats. -

    - -

    [Redmond: agreed that this is a real problem. The solution is - probably to match C99's parsing rules. Bill provided wording. -]

    - - - - - - - -
    -

    464. Suggestion for new member functions in standard containers

    -

    Section: 23.2.6 [vector], 23.3.1 [map] Status: WP - Submitter: Thorsten Ottosen Date: 2004-05-12

    -

    View all other issues in [vector].

    -

    View all issues with WP status.

    -

    Discussion:

    - -

    To add slightly more convenience to vector<T> and map<Key,T> we should consider to add

    -
      -
    1. add vector<T>::data() member (const and non-const version) -semantics: if( empty() ) return 0; else return buffer_;
      2. -
    2. add map<Key,T>::at( const Key& k ) member (const and non-const version) -semantics: iterator i = find( k ); if( i != end() ) return *i; else throw range_error();
      3. -
    - -

    Rationale:

    - -
      -
    • To obtain a pointer to the vector's buffer, one must use either -operator[]() (which can give undefined behavior for empty vectors) or -at() (which will then throw if the vector is empty).
      • -
    • tr1::array<T,sz> already has a data() member
      • -
    • e cannot use operator[]() when T is not DefaultDonstructible
      • -
    • Neither when the map is const.
      • -
    • when we want to make sure we don't add an element accidently
      • -
    • when it should be considered an error if a key is not in the map
      • -
    - - - -

    Proposed resolution:

    -

    In 23.2.6 [vector], add the following to the vector - synopsis after "element access" and before "modifiers":

    -
      // [lib.vector.data] data access
-  pointer       data();
-  const_pointer data() const;
-
    - -

    Add a new subsection of 23.2.6 [vector]:

    -
    -

    23.2.4.x vector data access

    -
       pointer       data();
-   const_pointer data() const;
-
    -

    Returns: A pointer such that [data(), data() + size()) is a valid - range. For a non-empty vector, data() == &front().

    -

    Complexity: Constant time.

    -

    Throws: Nothing.

    -
    - -

    In 23.3.1 [map], add the following to the map -synopsis immediately after the line for operator[]:

    -
      T&       at(const key_type& x);
-  const T& at(const key_type& x) const;
-
    - -

    Add the following to 23.3.1.2 [map.access]:

    -
    -
      T&       at(const key_type& x);
-  const T& at(const key_type& x) const;
-
    - -

    Returns: A reference to the element whose key is equivalent - to x, if such an element is present in the map.

    -

    Throws: out_of_range if no such element is present.

    - -
    - - - -

    Rationale:

    -

    Neither of these additions provides any new functionality but the - LWG agreed that they are convenient, especially for novices. The - exception type chosen for at, std::out_of_range, - was chosen to match vector::at.

    - - - - - -
    -

    465. Contents of <ciso646>

    -

    Section: 17.4.1.2 [headers] Status: WP - Submitter: Steve Clamage Date: 2004-06-03

    -

    View all other issues in [headers].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    C header <iso646.h> defines macros for some operators, such as -not_eq for !=.

    - -

    Section 17.4.1.2 [headers] "Headers" says that except as noted in -clauses 18 through 27, the <cname> C++ header contents are the same -as the C header <name.h>. In particular, table 12 lists -<ciso646> as a C++ header.

    - -

    I don't find any other mention of <ciso646>, or any mention of -<iso646.h>, in clauses 17 thorough 27. That implies that the -contents of <ciso646> are the same as C header <iso646.h>.

    - -

    Annex C (informative, not normative) in [diff.header.iso646.h] C.2.2.2 -"Header <iso646.h>" says that the alternative tokens are not -defined as macros in <ciso646>, but does not mention the contents -of <iso646.h>.

    - -

    I don't find any normative text to support C.2.2.2.

    - - - -

    Proposed resolution:

    -

    Add to section 17.4.1.2 Headers [lib.headers] a new paragraph after - paragraph 6 (the one about functions must be functions):

    - -
    -

    Identifiers that are keywords or operators in C++ shall not be defined -as macros in C++ standard library headers. -[Footnote:In particular, including the standard header <iso646.h> -or <ciso646> has no effect.

    -
    - -

    [post-Redmond: Steve provided wording.]

    - - - - - - - -
    -

    467. char_traits::lt(), compare(), and memcmp()

    -

    Section: 21.1.3.1 [char.traits.specializations.char] Status: WP - Submitter: Martin Sebor Date: 2004-06-28

    -

    View all issues with WP status.

    -

    Discussion:

    - -

    -Table 37 describes the requirements on Traits::compare() in terms of -those on Traits::lt(). 21.1.3.1, p6 requires char_traits<char>::lt() -to yield the same result as operator<(char, char). -

    - -

    -Most, if not all, implementations of char_traits<char>::compare() -call memcmp() for efficiency. However, the C standard requires both -memcmp() and strcmp() to interpret characters under comparison as -unsigned, regardless of the signedness of char. As a result, all -these char_traits implementations fail to meet the requirement -imposed by Table 37 on compare() when char is signed. -

    - - -

    Read email thread starting with c++std-lib-13499 for more.

    - - -

    Proposed resolution:

    - - -

    Change 21.1.3.1, p6 from

    -

    - The two-argument members assign, eq, and lt are defined identically - to the built-in operators =, ==, and < respectively. -

    -

    to

    -

    - The two-argument member assign is defined identically to - the built-in operator =. The two - argument members eq and lt are defined identically to - the built-in operators == and < for type unsigned char. -

    - -

    [Redmond: The LWG agreed with this general direction, but we - also need to change eq to be consistent with this change. - Post-Redmond: Martin provided wording.]

    - - - - - - -
    -

    468. unexpected consequences of ios_base::operator void*()

    -

    Section: 27.4.4.3 [iostate.flags] Status: WP - Submitter: Martin Sebor Date: 2004-06-28

    -

    View all other issues in [iostate.flags].

    -

    View all issues with WP status.

    -

    Discussion:

    - -

    The program below is required to compile but when run it typically -produces unexpected results due to the user-defined conversion from -std::cout or any object derived from basic_ios to void*. -

    - -
        #include <cassert>
-    #include <iostream>
-
-    int main ()
-    {
-        assert (std::cin.tie () == std::cout);
-        // calls std::cout.ios::operator void*()
-    }
-
    - - -

    Proposed resolution:

    - -

    -Replace std::basic_ios<charT, traits>::operator void*() with another -conversion operator to some unspecified type that is guaranteed not -to be convertible to any other type except for bool (a pointer-to-member -might be one such suitable type). In addition, make it clear that the -pointer type need not be a pointer to a complete type and when non-null, -the value need not be valid. -

    - -

    Specifically, change in [lib.ios] the signature of

    -
        operator void*() const;
-
    -

    to

    -
        operator unspecified-bool-type() const;
-
    -

    and change [lib.iostate.flags], p1 from

    -
        operator void*() const;
-
    -

    to

    -
    operator unspecified-bool-type() const;
-
-     -1- Returns: if fail() then a value that will evaluate false in a
-      boolean context; otherwise a value that will evaluate true in a
-      boolean context. The value type returned shall not be
-      convertible to int.
-
-     -2- [Note: This conversion can be used in contexts where a bool
-      is expected (e.g., an if condition); however, implicit
-      conversions (e.g., to int) that can occur with bool are not
-      allowed, eliminating some sources of user error. One possible
-      implementation choice for this type is pointer-to-member.  - end
-      note]
-
    - -

    [Redmond: 5-4 straw poll in favor of doing this.]

    - -

    [Lillehammer: Doug provided revised wording for - "unspecified-bool-type".]

    - - - - - - - - -
    -

    469. vector<bool> ill-formed relational operators

    -

    Section: 23.2.6 [vector] Status: DR - Submitter: Martin Sebor Date: 2004-06-28

    -

    View all other issues in [vector].

    -

    View all issues with DR status.

    -

    Discussion:

    - -

    -The overloads of relational operators for vector<bool> specified -in [lib.vector.bool] are redundant (they are semantically identical -to those provided for the vector primary template) and may even be -diagnosed as ill-formed (refer to Daveed Vandevoorde's explanation -in c++std-lib-13647). -

    - - - -

    Proposed resolution:

    -

    -Remove all overloads of overloads of relational operators for -vector<bool> from [lib.vector.bool]. -

    - - - - -
    -

    474. confusing Footnote 297

    -

    Section: 27.6.2.6.4 [ostream.inserters.character] Status: WP - Submitter: Martin Sebor Date: 2004-07-01

    -

    View all other issues in [ostream.inserters.character].

    -

    View all issues with WP status.

    -

    Discussion:

    - -

    -I think Footnote 297 is confused. The paragraph it applies to seems -quite clear in that widen() is only called if the object is not a char -stream (i.e., not basic_ostream<char>), so it's irrelevant what the -value of widen(c) is otherwise. -

    - - -

    Proposed resolution:

    -

    -I propose to strike the Footnote. -

    - - - - -
    -

    475. May the function object passed to for_each modify the elements of the iterated sequence?

    -

    Section: 25.1.4 [alg.foreach] Status: WP - Submitter: Stephan T. Lavavej, Jaakko Jarvi Date: 2004-07-09

    -

    View all other issues in [alg.foreach].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -It is not clear whether the function object passed to for_each is allowed to -modify the elements of the sequence being iterated over. -

    - -

    -for_each is classified without explanation in [lib.alg.nonmodifying], "25.1 -Non-modifying sequence operations". 'Non-modifying sequence operation' is -never defined. -

    - -

    -25(5) says: "If an algorithm's Effects section says that a value pointed to -by any iterator passed as an argument is modified, then that algorithm has -an additional type requirement: The type of that argument shall satisfy the -requirements of a mutable iterator (24.1)." -

    - -

    for_each's Effects section does not mention whether arguments can be -modified:

    - -

    - "Effects: Applies f to the result of dereferencing every iterator in the - range [first, last), starting from first and proceeding to last - 1." -

    - -

    -Every other algorithm in [lib.alg.nonmodifying] is "really" non-modifying in -the sense that neither the algorithms themselves nor the function objects -passed to the algorithms may modify the sequences or elements in any way. -This DR affects only for_each. -

    - -

    -We suspect that for_each's classification in "non-modifying sequence -operations" means that the algorithm itself does not inherently modify the -sequence or the elements in the sequence, but that the function object -passed to it may modify the elements it operates on. -

    - -

    -The original STL document by Stepanov and Lee explicitly prohibited the -function object from modifying its argument. -The "obvious" implementation of for_each found in several standard library -implementations, however, does not impose this restriction. -As a result, we suspect that the use of for_each with function objects that modify -their arguments is wide-spread. -If the restriction was reinstated, all such code would become non-conforming. -Further, none of the other algorithms in the Standard -could serve the purpose of for_each (transform does not guarantee the order in -which its function object is called). -

    - -

    -We suggest that the standard be clarified to explicitly allow the function object -passed to for_each modify its argument.

    - - - -

    Proposed resolution:

    -

    Add a nonnormative note to the Effects in 25.1.4 [alg.foreach]: If -the type of 'first' satisfies the requirements of a mutable iterator, -'f' may apply nonconstant functions through the dereferenced iterators -passed to it. -

    - - - -

    Rationale:

    -

    The LWG believes that nothing in the standard prohibits function - objects that modify the sequence elements. The problem is that - for_each is in a secion entitled "nonmutating algorithms", and the - title may be confusing. A nonnormative note should clarify that.

    - - - - - -
    -

    478. Should forward iterator requirements table have a line for r->m?

    -

    Section: 24.1.3 [forward.iterators] Status: WP - Submitter: Dave Abrahams Date: 2004-07-11

    -

    View all other issues in [forward.iterators].

    -

    View all issues with WP status.

    -

    Duplicate of: 477

    -

    Discussion:

    -

    -The Forward Iterator requirements table contains the following: -

    -
     expression  return type         operational  precondition
-                                  semantics
-  ==========  ==================  ===========  ==========================
-  a->m        U& if X is mutable, (*a).m       pre: (*a).m is well-defined.
-              otherwise const U&
-
-  r->m        U&                  (*r).m       pre: (*r).m is well-defined.
-
    - -

    The second line may be unnecessary. Paragraph 11 of - [lib.iterator.requirements] says: -

    - -

    - In the following sections, a and b denote values of type const X, n - denotes a value of the difference type Distance, u, tmp, and m - denote identifiers, r denotes a value of X&, t denotes a value of - value type T, o denotes a value of some type that is writable to - the output iterator. -

    - -

    -Because operators can be overloaded on an iterator's const-ness, the -current requirements allow iterators to make many of the operations -specified using the identifiers a and b invalid for non-const -iterators.

    - -

    Related issue: 477

    - - -

    Proposed resolution:

    - -

    Remove the "r->m" line from the Forward Iterator requirements -table. Change

    -

    - "const X" -

    - -

    to

    - -

    - "X or const X" -

    - -

    in paragraph 11 of [lib.iterator.requirements].

    - - - - -

    Rationale:

    -

    -This is a defect because it constrains an lvalue to returning a modifiable lvalue. -

    - - - - - -
    -

    488. rotate throws away useful information

    -

    Section: 25.2.11 [alg.rotate] Status: WP - Submitter: Howard Hinnant Date: 2004-11-22

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -rotate takes 3 iterators: first, middle and last which point into a -sequence, and rearranges the sequence such that the subrange [middle, -last) is now at the beginning of the sequence and the subrange [first, -middle) follows. The return type is void. -

    - -

    -In many use cases of rotate, the client needs to know where the -subrange [first, middle) starts after the rotate is performed. This -might look like: -

    -
      rotate(first, middle, last);
-  Iterator i = advance(first, distance(middle, last));
-
    - -

    -Unless the iterators are random access, the computation to find the -start of the subrange [first, middle) has linear complexity. However, -it is not difficult for rotate to return this information with -negligible additional computation expense. So the client could code: -

    -
      Iterator i = rotate(first, middle, last);
-
    - -

    -and the resulting program becomes significantly more efficient. -

    - -

    -While the backwards compatibility hit with this change is not zero, it -is very small (similar to that of lwg 130), and there is -a significant benefit to the change. -

    - - - -

    Proposed resolution:

    -

    In 25 [algorithms] p2, change:

    - -
      template<class ForwardIterator>
-    void ForwardIterator rotate(ForwardIterator first, ForwardIterator middle,
-                ForwardIterator last);
-
    - -

    In 25.2.11 [alg.rotate], change:

    - -
      template<class ForwardIterator>
-    void ForwardIterator rotate(ForwardIterator first, ForwardIterator middle,
-                ForwardIterator last);
-
    - -

    In 25.2.11 [alg.rotate] insert a new paragraph after p1:

    - -
    -

    Returns: first + (last - middle).

    -
    - -

    [ -The LWG agrees with this idea, but has one quibble: we want to make -sure not to give the impression that the function "advance" is -actually called, just that the nth iterator is returned. (Calling -advance is observable behavior, since users can specialize it for -their own iterators.) Howard will provide wording. -]

    - - -

    [Howard provided wording for mid-meeting-mailing Jun. 2005.]

    - - -

    [ -Toronto: moved to Ready. -]

    - - - - - - - -
    -

    495. Clause 22 template parameter requirements

    -

    Section: 22 [localization] Status: WP - Submitter: Beman Dawes Date: 2005-01-10

    -

    View all other issues in [localization].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    It appears that there are no requirements specified for many of the -template parameters in clause 22. It looks like this issue has never -come up, except perhaps for Facet.

    - -

    Clause 22 isn't even listed in 17.3.2.1 [lib.type.descriptions], -either, which is the wording that allows requirements on template -parameters to be identified by name.

    - -

    So one issue is that 17.3.2.1 [lib.type.descriptions] Should be -changed to cover clause 22. A better change, which will cover us in -the future, would be to say that it applies to all the library -clauses. Then if a template gets added to any library clause we are -covered.

    - -

    charT, InputIterator, and other names with requirements defined -elsewhere are fine, assuming the 17.3.2.1 [lib.type.descriptions] fix. -But there are a few template arguments names which I don't think have -requirements given elsewhere:

    - -
      -
    • internT and externT. The fix is to add wording saying that internT -and externT must meet the same requirements as template arguments -named charT.
      • - -
    • stateT. I'm not sure about this one. There already is some wording, -but it seems a bit vague.
      • - -
    • Intl. [lib.locale.moneypunct.byname] The fix for this one is to -rename "Intl" to "International". The name is important because other -text identifies the requirements for the name International but not -for Intl.
      • -
    - -

    Proposed resolution:

    -

    Change 17.3.2.1 [type.descriptions], paragraph 1, from:

    -

    -The Requirements subclauses may describe names that are used to -specify constraints on template arguments.153) These names are used in -clauses 20, 23, 25, and 26 to describe the types that may be supplied -as arguments by a C++ program when instantiating template components -from the library. -

    -

    to:

    -

    -The Requirements subclauses may describe names that are used to -specify constraints on template arguments.153) These names are used in -library clauses to describe the types that may be supplied as -arguments by a C++ program when instantiating template components from -the library. -

    - -

    In the front matter of class 22, locales, add:

    -

    -Template parameter types internT and externT shall meet the -requirements of charT (described in 21 [strings]). -

    - - -

    Rationale:

    -

    - Again, a blanket clause isn't blanket enough. Also, we've got a - couple of names that we don't have blanket requirement statements - for. The only issue is what to do about stateT. This wording is - thin, but probably adequate.

    - - - - - -
    -

    496. Illegal use of "T" in vector<bool>

    -

    Section: 23.2.6 [vector] Status: WP - Submitter: richard@ex-parrot.com Date: 2005-02-10

    -

    View all other issues in [vector].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -In the synopsis of the std::vector<bool> specialisation in 23.2.6 [vector], -the non-template assign() function has the signature

    - -
      void assign( size_type n, const T& t );
-
    - -

    The type, T, is not defined in this context.

    - - -

    Proposed resolution:

    -

    Replace "T" with "value_type".

    - - - - - -
    -

    497. meaning of numeric_limits::traps for floating point types

    -

    Section: 18.2.1.2 [numeric.limits.members] Status: WP - Submitter: Martin Sebor Date: 2005-03-02

    -

    View all other issues in [numeric.limits.members].

    -

    View all issues with WP status.

    -

    Discussion:

    - -

    18.2.1.2, p59 says this much about the traps member of numeric_limits:

    - -
    -

    static const bool traps;
    --59- true if trapping is implemented for the type.204) -
    -Footnote 204: Required by LIA-1. -

    -
    - -

    It's not clear what is meant by "is implemented" here.

    - -

    -In the context of floating point numbers it seems reasonable to expect -to be able to use traps to determine whether a program can "safely" use -infinity(), quiet_NaN(), etc., in arithmetic expressions, that is -without causing a trap (i.e., on UNIX without having to worry about -getting a signal). When traps is true, I would expect any of the -operations in section 7 of IEEE 754 to cause a trap (and my program -to get a SIGFPE). So, for example, on Alpha, I would expect traps -to be true by default (unless I compiled my program with the -ieee -option), false by default on most other popular architectures, -including IA64, MIPS, PA-RISC, PPC, SPARC, and x86 which require -traps to be explicitly enabled by the program. -

    - -

    -Another possible interpretation of p59 is that traps should be true -on any implementation that supports traps regardless of whether they -are enabled by default or not. I don't think such an interpretation -makes the traps member very useful, even though that is how traps is -implemented on several platforms. It is also the only way to implement -traps on platforms that allow programs to enable and disable trapping -at runtime. -

    - - -

    Proposed resolution:

    -

    Change p59 to read:

    -

    True if, at program startup, there exists a value of the type that - would cause an arithmetic operation using that value to trap.

    - - -

    Rationale:

    -

    - Real issue, since trapping can be turned on and off. Unclear what a - static query can say about a dynamic issue. The real advice we should - give users is to use cfenv for these sorts of queries. But this new - proposed resolution is at least consistent and slightly better than - nothing.

    - - - - - -
    -

    505. Result_type in random distribution requirements

    -

    Section: 26.4.1 [rand.req], TR1 5.1.1 [tr.rand.req] Status: WP - Submitter: Walter Brown Date: 2005-07-03

    -

    View all other issues in [rand.req].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -Table 17: Random distribution requirements -

    -

    -Row 1 requires that each random distribution provide a nested type "input_type"; -this type denotes the type of the values that the distribution consumes. -

    -

    -Inspection of all distributions in [tr.rand.dist] reveals that each distribution -provides a second typedef ("result_type") that denotes the type of the values the -distribution produces when called. -

    - - -

    Proposed resolution:

    -

    -It seems to me that this is also a requirement -for all distributions and should therefore be indicated as such via a new second -row to this table 17: -

    - - -
    X::result_typeT---compile-time
    - -

    [ -Berlin: Voted to WP. N1932 adopts the proposed resolution: see Table 5 row 1. -]

    - - - - - - - -
    -

    507. Missing requirement for variate_generator::operator()

    -

    Section: 26.4 [rand], TR1 5.1.3 [tr.rand.var] Status: WP - Submitter: Walter Brown Date: 2005-07-03

    -

    View all other issues in [rand].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -Paragraph 11 of [tr.rand.var] equires that the member template -

    -
    template<class T> result_type operator() (T value);
-
    -

    -return -

    -
    distribution()(e, value)
-
    -

    -However, not all distributions have an operator() with a corresponding signature. -

    - -

    [ -Berlin: As a working group we voted in favor of N1932 which makes this moot: -variate_generator has been eliminated. Then in full committee we voted to give -this issue WP status (mistakenly). -]

    - - - - -

    Proposed resolution:

    -

    -We therefore recommend that we insert the following precondition before paragraph 11: -

    -

    -Precondition: distribution().operator()(e,value) is well-formed. -

    - - - - - -
    -

    508. Bad parameters for ranlux64_base_01

    -

    Section: 26.4.5 [rand.predef], TR1 5.1.5 [tr.rand.predef] Status: WP - Submitter: Walter Brown Date: 2005-07-03

    -

    View all other issues in [rand.predef].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -The fifth of these engines with predefined parameters, ranlux64_base_01, -appears to have an unintentional error for which there is a simple correction. -The two pre-defined subtract_with_carry_01 engines are given as: -

    -
    typedef subtract_with_carry_01<float,  24, 10, 24> ranlux_base_01;
-typedef subtract_with_carry_01<double, 48, 10, 24> ranlux64_base_01;
-
    -

    -We demonstrate below that ranlux64_base_01 fails to meet the intent of the -random number generation proposal, but that the simple correction to -

    -
    typedef subtract_with_carry_01<double, 48,  5, 12> ranlux64_base_01;
-
    -

    -does meet the intent of defining well-known good parameterizations. -

    -

    -The ranlux64_base_01 engine as presented fails to meet the intent for -predefined engines, stated in proposal N1398 (section E): -

    -

    -In order to make good random numbers available to a large number of library -users, this proposal not only defines generic random-number engines, but also -provides a number of predefined well-known good parameterizations for those. -

    -

    -The predefined ranlux_base_01 engine has been proven [1,2,3] to have a very -long period and so meets this criterion. This property makes it suitable for -use in the excellent discard_block engines defined subsequently. The proof -of long period relies on the fact (proven in [1]) that 2**(w*r) - 2**(w*s) -+ 1 is prime (w, r, and s are template parameters to subtract_with_carry_01, -as defined in [tr.rand.eng.sub1]). -

    -

    -The ranlux64_base_01 engine as presented in [tr.rand.predef] uses w=48, r=24, s=10. -For these numbers, the combination 2**(w*r)-2**(w*s)+1 is non-prime (though -explicit factorization would be a challenge). In consequence, while it is -certainly possible for some seeding states that this engine would have a very -long period, it is not at all "well-known" that this is the case. The intent -in the N1398 proposal involved the base of the ranlux64 engine, which finds heavy -use in the physics community. This is isomorphic to the predefined ranlux_base_01, -but exploits the ability of double variables to hold (at least) 48 bits of mantissa, -to deliver 48 random bits at a time rather than 24. -

    - - -

    Proposed resolution:

    -

    -To achieve this intended behavior, the correct template parameteriztion would be: -

    -
    typedef subtract_with_carry_01<double, 48, 5, 12> ranlux64_base_01;
-
    -

    -The sequence of mantissa bits delivered by this is isomorphic (treating each -double as having the bits of two floats) to that delivered by ranlux_base_01. -

    -

    -References: -

    -
      -
    1. F. James, Comput. Phys. Commun. 60(1990) 329
      2. -
    2. G. Marsaglia and A. Zaman, Ann. Appl. Prob 1(1991) 462
      3. -
    3. M. Luscher, Comput. Phys. Commun. 79(1994) 100-110
      4. -
    - -

    [ -Berlin: Voted to WP. N1932 adopts the proposed resolution in 26.3.5, -just above paragraph 5. -]

    - - - - - - - -
    -

    518. Are insert and erase stable for unordered_multiset and unordered_multimap?

    -

    Section: 23.1.5 [unord.req], TR1 6.3.1 [tr.unord.req] Status: WP - Submitter: Matt Austern Date: 2005-07-03

    -

    View other active issues in [unord.req].

    -

    View all other issues in [unord.req].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -Issue 371 deals with stability of multiset/multimap under insert and erase -(i.e. do they preserve the relative order in ranges of equal elements). -The same issue applies to unordered_multiset and unordered_multimap. -

    -

    [ -Moved to open (from review): There is no resolution. -]

    - - -

    [ -Toronto: We have a resolution now. Moved to Review. Some concern was noted -as to whether this conflicted with existing practice or not. An additional -concern was in specifying (partial) ordering for an unordered container. -]

    - - - - -

    Proposed resolution:

    -

    -Wording for the proposed resolution is taken from the equivalent text for associative containers. -

    - -

    -Change 23.1.5 [unord.req], Unordered associative containers, paragraph 6 to: -

    - -

    -An unordered associative container supports unique keys if it may -contain at most one element for each key. Otherwise, it supports equivalent -keys. unordered_set and unordered_map support -unique keys. unordered_multiset and unordered_multimap -support equivalent keys. In containers that support equivalent keys, elements -with equivalent keys are adjacent to each other. For -unordered_multiset -and unordered_multimap, insert and erase -preserve the relative ordering of equivalent elements. -

    - -

    -Change 23.1.5 [unord.req], Unordered associative containers, paragraph 8 to: -

    - -
    -

    The elements of an unordered associative container are organized into -buckets. Keys with the same hash code appear in the same bucket. The number -of buckets is automatically increased as elements are added to an unordered -associative container, so that the average number of elements per bucket is kept -below a bound. Rehashing invalidates iterators, changes ordering between -elements, and changes which buckets elements appear in, but does not invalidate -pointers or references to elements. For unordered_multiset -and unordered_multimap, rehashing -preserves the relative ordering of equivalent elements.

    -
    - - - - - - -
    -

    519. Data() undocumented

    -

    Section: 23.2.1 [array], TR1 6.2.2 [tr.array.array] Status: WP - Submitter: Pete Becker Date: 2005-07-03

    -

    View other active issues in [array].

    -

    View all other issues in [array].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -array<>::data() is present in the class synopsis, but not documented. -

    - - -

    Proposed resolution:

    -

    -Add a new section, after 6.2.2.3: -

    -
    T*       data()
-const T* data() const;
-
    -

    -Returns: elems. -

    -

    -Change 6.2.2.4/2 to: -

    -

    -In the case where N == 0, begin() == end(). The return value -of data() is unspecified. -

    - - - - - -
    -

    520. Result_of and pointers to data members

    -

    Section: 20.6.11.1 [func.bind], TR1 3.6 [tr.func.bind] Status: WP - Submitter: Pete Becker Date: 2005-07-03

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -In the original proposal for binders, the return type of bind() when -called with a pointer to member data as it's callable object was -defined to be mem_fn(ptr); when Peter Dimov and I unified the -descriptions of the TR1 function objects we hoisted the descriptions -of return types into the INVOKE pseudo-function and into result_of. -Unfortunately, we left pointer to member data out of result_of, so -bind doesn't have any specified behavior when called with a pointer -to member data. -

    - - -

    Proposed resolution:

    -

    [ -Pete and Peter will provide wording. -]

    - - -

    -In 20.5.4 [lib.func.ret] ([tr.func.ret]) p3 add the following bullet after bullet 2: -

    -
      -
    1. If F is a member data pointer type R T::*, type -shall be cv R& when T1 is cv U1&, -R otherwise.
      2. -
    - -

    [ -Peter provided wording. -]

    - - - - - - - -
    -

    521. Garbled requirements for argument_type in reference_wrapper

    -

    Section: 20.6.5 [refwrap], TR1 2.1.2 [tr.util.refwrp.refwrp] Status: WP - Submitter: Pete Becker Date: 2005-07-03

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -2.1.2/3, second bullet item currently says that reference_wrapper<T> is -derived from unary_function<T, R> if T is: -

    -

    -a pointer to member function type with cv-qualifier cv and no arguments; -the type T1 is cv T* and R is the return type of the pointer to member function; -

    -

    -The type of T1 can't be cv T*, 'cause that's a pointer to a pointer to member -function. It should be a pointer to the class that T is a pointer to member of. -Like this: -

    -

    -a pointer to a member function R T0::f() cv (where cv represents the member -function's cv-qualifiers); the type T1 is cv T0* -

    -

    -Similarly, bullet item 2 in 2.1.2/4 should be: -

    -

    -a pointer to a member function R T0::f(T2) cv (where cv represents the member -function's cv-qualifiers); the type T1 is cv T0* -

    - - -

    Proposed resolution:

    - -

    -Change bullet item 2 in 2.1.2/3: -

    - -
    -
      -
    • -a pointer to member function type with cv-qualifier cv and no arguments; -the type T1 is cv T* and R is the return -type of the pointer to member function R T0::f() cv -(where cv represents the member function's cv-qualifiers); -the type T1 is cv T0* -
      • -
    -
    - -

    -Change bullet item 2 in 2.1.2/4: -

    - -
    -
      -
    • -a pointer to member function with cv-qualifier cv and taking one argument -of type T2; the type T1 is cv T* and -R is the return type of the pointer to member function -R T0::f(T2) cv (where cv represents the member -function's cv-qualifiers); the type T1 is cv T0* -
      • -
    -
    - - - - - - -
    -

    524. regex named character classes and case-insensitivity don't mix

    -

    Section: 28 [re] Status: WP - Submitter: Eric Niebler Date: 2005-07-01

    -

    View all other issues in [re].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -This defect is also being discussed on the Boost developers list. The -full discussion can be found here: -http://lists.boost.org/boost/2005/07/29546.php -

    -

    --- Begin original message -- -

    -

    -Also, I may have found another issue, closely related to the one under -discussion. It regards case-insensitive matching of named character -classes. The regex_traits<> provides two functions for working with -named char classes: lookup_classname and isctype. To match a char class -such as [[:alpha:]], you pass "alpha" to lookup_classname and get a -bitmask. Later, you pass a char and the bitmask to isctype and get a -bool yes/no answer. -

    -

    -But how does case-insensitivity work in this scenario? Suppose we're -doing a case-insensitive match on [[:lower:]]. It should behave as if it -were [[:lower:][:upper:]], right? But there doesn't seem to be enough -smarts in the regex_traits interface to do this. -

    -

    -Imagine I write a traits class which recognizes [[:fubar:]], and the -"fubar" char class happens to be case-sensitive. How is the regex engine -to know that? And how should it do a case-insensitive match of a -character against the [[:fubar:]] char class? John, can you confirm this -is a legitimate problem? -

    -

    -I see two options: -

    -

    -1) Add a bool icase parameter to lookup_classname. Then, -lookup_classname( "upper", true ) will know to return lower|upper -instead of just upper. -

    -

    -2) Add a isctype_nocase function -

    -

    -I prefer (1) because the extra computation happens at the time the -pattern is compiled rather than when it is executed. -

    -

    --- End original message -- -

    - -

    -For what it's worth, John has also expressed his preference for option -(1) above. -

    - - -

    Proposed resolution:

    -

    -Adopt the proposed resolution in -N2409. -

    - - -

    [ -Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue. -The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona. -]

    - - - - - -
    -

    527. tr1::bind has lost its Throws clause

    -

    Section: 20.6.11.1.3 [func.bind.bind], TR1 3.6.3 [tr.func.bind.bind] Status: WP - Submitter: Peter Dimov Date: 2005-10-01

    -

    View other active issues in [func.bind.bind].

    -

    View all other issues in [func.bind.bind].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -The original bind proposal gives the guarantee that tr1::bind(f, t1, -..., tN) does not throw when the copy constructors of f, t1, ..., tN -don't. -

    - -

    -This guarantee is not present in the final version of TR1. -

    - -

    -I'm pretty certain that we never removed it on purpose. Editorial omission? :-) -

    - -

    [ -Berlin: not quite editorial, needs proposed wording. -]

    - -

    [ -Batavia: Doug to translate wording to variadic templates. -]

    - - -

    [ -Toronto: We agree but aren't quite happy with the wording. The "t"'s no -longer refer to anything. Alan to provide improved wording. -]

    - - - -

    [ -Pre-Bellevue: Alisdair provided wording. -]

    - - -

    -TR1 proposed resolution: -

    - -
    -

    -In TR1 3.6.3 [tr.func.bind.bind], add a new paragraph after p2: -

    -

    -Throws: Nothing unless one of the copy constructors of f, t1, t2, ..., tN -throws an exception. -

    - -

    -Add a new paragraph after p4: -

    -

    -Throws: nothing unless one of the copy constructors of f, t1, t2, ..., tN -throws an exception. -

    - -
    - - - -

    Proposed resolution:

    -

    -In 20.6.11.1.3 [func.bind.bind], add a new paragraph after p2: -

    - -
    -Throws: Nothing unless the copy constructor of F or of one of the types -in the BoundArgs... pack expansion throws an exception. -
    - -

    -In 20.6.11.1.3 [func.bind.bind], add a new paragraph after p4: -

    - -
    -Throws: Nothing unless the copy constructor of F or of one of the types -in the BoundArgs... pack expansion throws an exception. -
    - - - - - - -
    -

    530. Must elements of a string be contiguous?

    -

    Section: 21.3 [basic.string] Status: WP - Submitter: Matt Austern Date: 2005-11-15

    -

    View other active issues in [basic.string].

    -

    View all other issues in [basic.string].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    Issue 69, which was incorporated into C++03, mandated - that the elements of a vector must be stored in contiguous memory. - Should the same also apply to basic_string?

    - -

    We almost require contiguity already. Clause 23.3.4 [multiset] - defines operator[] as data()[pos]. What's missing - is a similar guarantee if we access the string's elements via the - iterator interface.

    - -

    Given the existence of data(), and the definition of - operator[] and at in terms of data, - I don't believe it's possible to write a useful and standard- - conforming basic_string that isn't contiguous. I'm not - aware of any non-contiguous implementation. We should just require - it. -

    - - -

    Proposed resolution:

    -

    Add the following text to the end of 21.3 [basic.string], -paragraph 2.

    - -
    -

    The characters in a string are stored contiguously, meaning that if - s is a basic_string<charT, Allocator>, then - it obeys the identity - &*(s.begin() + n) == &*s.begin() + n - for all 0 <= n < s.size(). -

    -
    - - -

    Rationale:

    -

    -Not standardizing this existing practice does not give implementors more -freedom. We thought it might a decade ago. But the vendors have spoken -both with their implementations, and with their voice at the LWG -meetings. The implementations are going to be contiguous no matter what -the standard says. So the standard might as well give string clients -more design choices. -

    - - - - - -
    -

    531. array forms of unformatted input functions

    -

    Section: 27.6.1.3 [istream.unformatted] Status: WP - Submitter: Martin Sebor Date: 2005-11-23

    -

    View all other issues in [istream.unformatted].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -The array forms of unformatted input functions don't seem to have well-defined -semantics for zero-element arrays in a couple of cases. The affected ones -(istream::get() and istream::getline()) are supposed to -terminate when (n - 1) characters are stored, which obviously can -never be true when (n == 0) holds to start with. See -c++std-lib-16071. -

    - - -

    Proposed resolution:

    -

    -I suggest changing 27.6.1.3, p7 (istream::get()), bullet 1 to read: -

    -
      -
    • - (n < 1) is true or (n - 1) characters - are stored; -
      • -
    -

    -Change 27.6.1.3, p9: -

    - -

    -If the function stores no characters, it calls setstate(failbit) (which -may throw ios_base::failure (27.4.4.3)). In any case, if (n -> 0) is true it then stores a null character into the next -successive location of the array. -

    - -

    - -and similarly p17 (istream::getline()), bullet 3 to: - -

    -
      -
    • - (n < 1) is true or (n - 1) characters - are stored (in which case the function calls - setstate(failbit)). -
      • -
    - -

    - -In addition, to clarify that istream::getline() must not store the -terminating NUL character unless the the array has non-zero size, Robert -Klarer suggests in c++std-lib-16082 to change 27.6.1.3, p20 to read: - -

    -

    - -In any case, provided (n > 0) is true, it then stores a null character -(using charT()) into the next successive location of the array. - -

    - -

    [ -post-Redmond: Pete noticed that the current resolution for get requires -writing to out of bounds memory when n == 0. Martin provided fix. -]

    - - - - - - - -
    -

    533. typo in 2.2.3.10/1

    -

    Section: 20.7.12.2.11 [util.smartptr.getdeleter], TR1 2.2.3.10 [tr.util.smartptr.getdeleter] Status: DR - Submitter: Paolo Carlini Date: 2005-11-09

    -

    View all other issues in [util.smartptr.getdeleter].

    -

    View all issues with DR status.

    -

    Discussion:

    -

    -I'm seeing something that looks like a typo. The Return of get_deleter -says: -

    -

    -If *this owns a deleter d... -

    -

    -but get_deleter is a free function! -

    - - -

    Proposed resolution:

    -

    -Therefore, I think should be: -

    -

    -If *this p owns a deleter d... -

    - - - - - -
    -

    534. Missing basic_string members

    -

    Section: 21.3 [basic.string] Status: WP - Submitter: Alisdair Meredith Date: 2005-11-16

    -

    View other active issues in [basic.string].

    -

    View all other issues in [basic.string].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -OK, we all know std::basic_string is bloated and already has way too -many members. However, I propose it is missing 3 useful members that -are often expected by users believing it is a close approximation of the -container concept. All 3 are listed in table 71 as 'optional' -

    - -

    -i/ pop_back. -

    - -

    -This is the one I feel most strongly about, as I only just discovered it -was missing as we are switching to a more conforming standard library -<g> -

    - -

    -I find it particularly inconsistent to support push_back, but not -pop_back. -

    - -

    -ii/ back. -

    - -

    -There are certainly cases where I want to examine the last character of -a string before deciding to append, or to trim trailing path separators -from directory names etc. *rbegin() somehow feels inelegant. -

    - -

    -iii/ front -

    - -

    -This one I don't feel strongly about, but if I can get the first two, -this one feels that it should be added as a 'me too' for consistency. -

    - -

    -I believe this would be similarly useful to the data() member recently -added to vector, or at() member added to the maps. -

    - - -

    Proposed resolution:

    -

    -Add the following members to definition of class template basic_string, 21.3p7 -

    -
    void pop_back ()
-
-const charT & front() const
-charT & front()
-
-const charT & back() const
-charT & back()
-
    -

    -Add the following paragraphs to basic_string description -

    - -

    -21.3.4p5 -

    -
    -
    const charT & front() const
-charT & front()
-
    -

    -Precondition: !empty() -

    -

    -Effects: Equivalent to operator[](0). -

    -
    - -

    -21.3.4p6 -

    -
    -
    const charT & back() const
-charT & back()
-
    -

    -Precondition: !empty() -

    -

    -Effects: Equivalent to operator[]( size() - 1). -

    -
    - -

    -21.3.5.5p10 -

    -
    -
    void pop_back ()
-
    -

    -Precondition: !empty() -

    -

    -Effects: Equivalent to erase( size() - 1, 1 ). -

    -
    - -

    -Update Table 71: (optional sequence operations) -Add basic_string to the list of containers for the following operations. -

    -
    a.front()
-a.back()
-a.push_back()
-a.pop_back()
-a[n]
-
    - -

    [ -Berlin: Has support. Alisdair provided wording. -]

    - - - - - - -
    -

    535. std::string::swap specification poorly worded

    -

    Section: 21.3.6.8 [string::swap] Status: WP - Submitter: Beman Dawes Date: 2005-12-14

    -

    View all other issues in [string::swap].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -std::string::swap currently says for effects and postcondition: -

    - -
    -

    -Effects: Swaps the contents of the two strings. -

    - -

    -Postcondition: *this contains the characters that were in s, -s contains the characters that were in *this. -

    -
    - -

    -Specifying both Effects and Postcondition seems redundant, and the postcondition -needs to be made stronger. Users would be unhappy if the characters were not in -the same order after the swap. -

    - - -

    Proposed resolution:

    -
    -

    -Effects: Swaps the contents of the two strings. -

    - -

    -Postcondition: *this contains the same sequence of -characters that were was in s, -s contains the same sequence of characters that -were was in *this. -

    -
    - - - - - -
    -

    537. Typos in the signatures in 27.6.1.3/42-43 and 27.6.2.4

    -

    Section: 27.6.1.3 [istream.unformatted] Status: WP - Submitter: Paolo Carlini Date: 2006-02-12

    -

    View all other issues in [istream.unformatted].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -In the most recent working draft, I'm still seeing: -

    - -
    seekg(off_type& off, ios_base::seekdir dir)
-
    - -

    -and -

    - -
    seekp(pos_type& pos)
-
-seekp(off_type& off, ios_base::seekdir dir)
-
    - -

    -that is, by reference off and pos arguments. -

    - - -

    Proposed resolution:

    -

    -After 27.6.1.3p42 change: -

    - -
    basic_istream<charT,traits>& seekg(off_type& off, ios_base::seekdir dir);
-
    - -

    -After 27.6.2.4p1 change: -

    - -
    basic_ostream<charT,traits>& seekp(pos_type& pos);
-
    - -

    -After 27.6.2.4p3 change: -

    - -
    basic_ostream<charT,traits>& seekp(off_type& off, ios_base::seekdir dir);
-
    - - - - - -
    -

    538. 241 again: Does unique_copy() require CopyConstructible and Assignable?

    -

    Section: 25.2.9 [alg.unique] Status: WP - Submitter: Howard Hinnant Date: 2006-02-09

    -

    View all other issues in [alg.unique].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -I believe I botched the resolution of - -241 "Does unique_copy() require CopyConstructible and Assignable?" which now -has WP status. -

    - -

    -This talks about unique_copy requirements and currently reads: -

    - -

    --5- Requires: The ranges [first, last) and -[result, result+(last-first)) -shall not overlap. The expression *result = *first shall -be valid. If neither InputIterator nor OutputIterator meets the -requirements of forward iterator then the value type of InputIterator -must be CopyConstructible (20.1.3). Otherwise CopyConstructible is not required. -

    - -

    -The problem (which Paolo discovered) is that when the iterators are at their -most restrictive (InputIterator, OutputIterator), then we want -InputIterator::value_type to be both CopyConstructible and -CopyAssignable (for the most efficient implementation). However this -proposed resolution only makes it clear that it is CopyConstructible, -and that one can assign from *first to *result. -This latter requirement does not necessarily imply that you can: -

    - -
    *first = *first;
-
    - - -

    Proposed resolution:

    -

    --5- Requires: The ranges [first, last) and -[result, result+(last-first)) -shall not overlap. The expression *result = *first -shall -be valid. If neither InputIterator nor OutputIterator meets the -requirements of forward iterator then the value type -value_type of InputIterator -must be CopyConstructible (20.1.3) and Assignable. -Otherwise CopyConstructible is not required. -

    - - - - - -
    -

    540. shared_ptr<void>::operator*()

    -

    Section: 20.7.12.2.5 [util.smartptr.shared.obs], TR1 2.2.3.5 [tr.util.smartptr.shared.obs] Status: WP - Submitter: Martin Sebor Date: 2005-10-15

    -

    View all other issues in [util.smartptr.shared.obs].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -I'm trying to reconcile the note in tr.util.smartptr.shared.obs, p6 -that talks about the operator*() member function of shared_ptr: -

    - -

    - Notes: When T is void, attempting to instantiate this member function - renders the program ill-formed. [Note: Instantiating shared_ptr<void> - does not necessarily result in instantiating this member function. - --end note] -

    - -

    -with the requirement in temp.inst, p1: -

    - -

    - The implicit instantiation of a class template specialization causes - the implicit instantiation of the declarations, but not of the - definitions... -

    - -

    -I assume that what the note is really trying to say is that -"instantiating shared_ptr<void> *must not* result in instantiating -this member function." That is, that this function must not be -declared a member of shared_ptr<void>. Is my interpretation -correct? -

    - - -

    Proposed resolution:

    -

    -Change 2.2.3.5p6 -

    - -

    --6- Notes: When T is void, attempting to instantiate -this member function renders the program ill-formed. [Note: -Instantiating shared_ptr<void> does not necessarily result in -instantiating this member function. --end note] it is -unspecified whether this member function is declared or not, and if so, what its -return type is, except that the declaration (although not necessarily the -definition) of the function shall be well-formed. -

    - - - - - - -
    -

    541. shared_ptr template assignment and void

    -

    Section: 20.7.12.2 [util.smartptr.shared], TR1 2.2.3 [tr.util.smartptr.shared] Status: WP - Submitter: Martin Sebor Date: 2005-10-16

    -

    View other active issues in [util.smartptr.shared].

    -

    View all other issues in [util.smartptr.shared].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -Is the void specialization of the template assignment operator taking -a shared_ptr<void> as an argument supposed be well-formed? -

    -

    -I.e., is this snippet well-formed: -

    -
    shared_ptr<void> p;
-p.operator=<void>(p);
-
    - -

    -Gcc complains about auto_ptr<void>::operator*() returning a reference -to void. I suspect it's because shared_ptr has two template assignment -operators, one of which takes auto_ptr, and the auto_ptr template gets -implicitly instantiated in the process of overload resolution. -

    - -

    -The only way I see around it is to do the same trick with auto_ptr<void> -operator*() as with the same operator in shared_ptr<void>. -

    - -

    -PS Strangely enough, the EDG front end doesn't mind the code, even -though in a small test case (below) I can reproduce the error with -it as well. -

    - -
    template <class T>
-struct A { T& operator*() { return *(T*)0; } };
-
-template <class T>
-struct B {
-    void operator= (const B&) { }
-    template <class U>
-    void operator= (const B<U>&) { }
-    template <class U>
-    void operator= (const A<U>&) { }
-};
-
-int main ()
-{
-    B<void> b;
-    b.operator=<void>(b);
-}
-
    - - -

    Proposed resolution:

    -

    -In [lib.memory] change: -

    -
    template<class X> class auto_ptr;
-template<> class auto_ptr<void>;
-
    - -

    -In [lib.auto.ptr]/2 add the following before the last closing brace: -

    - -
    template<> class auto_ptr<void>
-{
-public:
-    typedef void element_type;
-};
-
    - - - - - - -
    -

    542. shared_ptr observers

    -

    Section: 20.7.12.2.5 [util.smartptr.shared.obs], TR1 2.2.3.5 [tr.util.smartptr.shared.obs] Status: WP - Submitter: Martin Sebor Date: 2005-10-18

    -

    View all other issues in [util.smartptr.shared.obs].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -Peter Dimov wrote: -To: C++ libraries mailing list -Message c++std-lib-15614 -[...] -The intent is for both use_count() and unique() to work in a threaded environment. -They are intrinsically prone to race conditions, but they never return garbage. -

    - -

    -This is a crucial piece of information that I really wish were -captured in the text. Having this in a non-normative note would -have made everything crystal clear to me and probably stopped -me from ever starting this discussion :) Instead, the sentence -in p12 "use only for debugging and testing purposes, not for -production code" very strongly suggests that implementations -can and even are encouraged to return garbage (when threads -are involved) for performance reasons. -

    -

    -How about adding an informative note along these lines: -

    -

    - Note: Implementations are encouraged to provide well-defined - behavior for use_count() and unique() even in the presence of - multiple threads. -

    -

    -I don't necessarily insist on the exact wording, just that we -capture the intent. -

    - - -

    Proposed resolution:

    -

    -Change 20.7.12.2.5 [util.smartptr.shared.obs] p12: -

    -

    -[Note: use_count() is not necessarily efficient. Use only for -debugging and testing purposes, not for production code. --end note] -

    - -

    -Change 20.7.12.3.5 [util.smartptr.weak.obs] p3: -

    -

    -[Note: use_count() is not necessarily efficient. Use only for -debugging and testing purposes, not for production code. --end note] -

    - - - - - -
    -

    543. valarray slice default constructor

    -

    Section: 26.5.4 [class.slice] Status: WP - Submitter: Howard Hinnant Date: 2005-11-03

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -If one explicitly constructs a slice or glice with the default -constructor, does the standard require this slice to have any usable -state? It says "creates a slice which specifies no elements", which -could be interpreted two ways: -

    -
      -
    1. There are no elements to which the slice refers (i.e. undefined).
      2. -
    2. The slice specifies an array with no elements in it (i.e. defined).
      3. -
    -

    -Here is a bit of code to illustrate: -

    -
    #include <iostream>
-#include <valarray>
-
-int main()
-{
-    std::valarray<int> v(10);
-    std::valarray<int> v2 = v[std::slice()];
-    std::cout << "v[slice()].size() = " << v2.size() << '\n';
-}
-
    - -

    -Is the behavior undefined? Or should the output be: -

    - -
    v[slice()].size() = 0
-
    - -

    -There is a similar question and wording for gslice at 26.3.6.1p1. -

    - - -

    Proposed resolution:

    - -

    [Martin suggests removing the second sentence in 26.5.4.1 [cons.slice] as well.]

    - - -

    -Change 26.5.4.1 [cons.slice]: -

    - -

    -1 - The default constructor for slice creates a slice -which specifies no elements. The default constructor is equivalent to -slice(0, 0, 0). A default constructor is provided only to permit -the declaration of arrays of slices. The constructor with arguments for a slice -takes a start, length, and stride parameter. -

    - -

    -Change 26.5.6.1 [gslice.cons]: -

    - -

    -1 - The default constructor creates a gslice which specifies no -elements. The default constructor is equivalent to gslice(0, -valarray<size_t>(), valarray<size_t>()). The constructor -with arguments builds a gslice based on a specification of start, -lengths, and strides, as explained in the previous section. -

    - - - - - - -
    -

    545. When is a deleter deleted?

    -

    Section: 20.7.12.2.11 [util.smartptr.getdeleter], TR1 2.2.3.2 [tr.util.smartptr.shared.dest] Status: WP - Submitter: Matt Austern Date: 2006-01-10

    -

    View all other issues in [util.smartptr.getdeleter].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -The description of ~shared_ptr doesn't say when the shared_ptr's deleter, if -any, is destroyed. In principle there are two possibilities: it is destroyed -unconditionally whenever ~shared_ptr is executed (which, from an implementation -standpoint, means that the deleter is copied whenever the shared_ptr is copied), -or it is destroyed immediately after the owned pointer is destroyed (which, from -an implementation standpoint, means that the deleter object is shared between -instances). We should say which it is. -

    - - -

    Proposed resolution:

    -

    -Add after the first sentence of 20.7.12.2.11 [util.smartptr.getdeleter]/1: -

    -
    -

    -The returned pointer remains valid as long as there exists a shared_ptr instance -that owns d. -

    -

    -[Note: it is unspecified whether the pointer remains valid longer than that. -This can happen if the implementation doesn't destroy the deleter until all -weak_ptr instances in the ownership group are destroyed. -- end note] -

    -
    - - - - - -
    -

    550. What should the return type of pow(float,int) be?

    -

    Section: 26.7 [c.math] Status: WP - Submitter: Howard Hinnant Date: 2006-01-12

    -

    View all other issues in [c.math].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -Assuming we adopt the -C -compatibility package from C99 what should be the return type of the -following signature be: -

    -
    ?  pow(float, int);
-
    -

    -C++03 says that the return type should be float. - -TR1 and C90/99 say the return type should be double. This can put -clients into a situation where C++03 provides answers that are not as high -quality as C90/C99/TR1. For example: -

    -
    #include <math.h>
-
-int main()
-{
-    float x = 2080703.375F;
-    double y = pow(x, 2);
-}
-
    -

    -Assuming an IEEE 32 bit float and IEEE 64 bit double, C90/C99/TR1 all suggest: -

    - -
    y = 4329326534736.390625
-
    - -

    -which is exactly right. While C++98/C++03 demands: -

    - -
    y = 4329326510080.
-
    - -

    -which is only approximately right. -

    - -

    -I recommend that C++0X adopt the mixed mode arithmetic already adopted by -Fortran, C and TR1 and make the return type of pow(float,int) be -double. -

    - -

    [ -Kona (2007): Other functions that are affected by this issue include -ldexp, scalbln, and scalbn. We also believe that there is a typo in -26.7/10: float nexttoward(float, long double); [sic] should be float -nexttoward(float, float); Proposed Disposition: Review (the proposed -resolution appears above, rather than below, the heading "Proposed -resolution") -]

    - - -

    [ -

    -Howard, post Kona: -

    -
    -

    -Unfortunately I strongly disagree with a part of the resolution -from Kona. I am moving from New to Open instead of to Review because I do not believe -we have consensus on the intent of the resolution. -

    -

    -This issue does not include ldexp, scalbln, and scalbn because -the second integral parameter in each of these signatures (from C99) is not a -generic parameter according to C99 7.22p2. The corresponding C++ overloads are -intended (as far as I know) to correspond directly to C99's definition of generic parameter. -

    -

    -For similar reasons, I do not believe that the second long double parameter of -nexttoward, nor the return type of this function, is in error. I believe the -correct signature is: -

    -
    -
    float nexttoward(float, long double);
-
    -
    -

    -which is what both the C++0X working paper and C99 state (as far as I currently understand). -

    -

    -This is really only about pow(float, int). And this is because C++98 took one -route (with pow only) and C99 took another (with many math functions in <tgmath.h>. -The proposed resolution basically says: C++98 got it wrong and C99 got it right; let's go with C99. -

    -
    -]

    - - -

    [ -Bellevue: -]

    - - -
    -This signature was not picked up from C99. Instead, if one types -pow(2.0f,2), the promotion rules will invoke "double pow(double, -double)", which generally gives special treatment for integral -exponents, preserving full accuracy of the result. New proposed -wording provided. -
    - - -

    Proposed resolution:

    -

    -Change 26.7 [c.math] p10: -

    - -
    -

    -The added signatures are: -

    -
    ...
-float pow(float, int);
-...
-double pow(double, int);
-...
-long double pow(long double, int);
-
    -
    - - - - - - -
    -

    551. <ccomplex>

    -

    Section: 26.3.11 [cmplxh], TR1 8.3 [tr.c99.cmplxh] Status: WP - Submitter: Howard Hinnant Date: 2006-01-23

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -Previously xxx.h was parsable by C++. But in the case of C99's <complex.h> -it isn't. Otherwise we could model it just like <string.h>, <cstring>, <string>: -

    - -
      -
    • <string> : C++ API in namespace std
      • -
    • <cstring> : C API in namespace std
      • -
    • <string.h> : C API in global namespace
      • -
    - -

    -In the case of C's complex, the C API won't compile in C++. So we have: -

    - -
      -
    • <complex> : C++ API in namespace std
      • -
    • <ccomplex> : ?
      • -
    • <complex.h> : ?
      • -
    - -

    -The ? can't refer to the C API. TR1 currently says: -

    - -
      -
    • <complex> : C++ API in namespace std
      • -
    • <ccomplex> : C++ API in namespace std
      • -
    • <complex.h> : C++ API in global namespace
      • -
    - - - -

    Proposed resolution:

    -

    -Change 26.3.11 [cmplxh]: -

    - -
    -

    -The header behaves as if it includes the header -<ccomplex>., and provides sufficient using -declarations to declare in the global namespace all function and type names -declared or defined in the neader <complex>. -[Note: <complex.h> does not promote any interface -into the global namespace as there is no C interface to promote. --end -note] -

    -
    - - - - - - -
    -

    552. random_shuffle and its generator

    -

    Section: 25.2.12 [alg.random.shuffle] Status: WP - Submitter: Martin Sebor Date: 2006-01-25

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -...is specified to shuffle its range by calling swap but not how -(or even that) it's supposed to use the RandomNumberGenerator -argument passed to it. -

    -

    -Shouldn't we require that the generator object actually be used -by the algorithm to obtain a series of random numbers and specify -how many times its operator() should be invoked by the algorithm? -

    - -

    -See N2391 and -N2423 -for some further discussion. -

    - - - -

    Proposed resolution:

    -

    -Adopt the proposed resolution in -N2423. -

    - - -

    [ -Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue. -The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona. -]

    - - - - - -
    -

    559. numeric_limits<const T>

    -

    Section: 18.2.1 [limits] Status: WP - Submitter: Martin Sebor Date: 2006-02-19

    -

    View all other issues in [limits].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    - -18.2.1 [limits], p2 requires implementations to provide specializations of the -numeric_limits template for each scalar type. While this -could be interepreted to include cv-qualified forms of such types such -an interepretation is not reflected in the synopsis of the -<limits> header. - -

    -

    - -The absence of specializations of the template on cv-qualified forms -of fundamental types makes numeric_limits difficult to -use in generic code where the constness (or volatility) of a type is -not always immediately apparent. In such contexts, the primary -template ends up being instantiated instead of the provided -specialization, typically yielding unexpected behavior. - -

    -

    - -Require that specializations of numeric_limits on -cv-qualified fundamental types have the same semantics as those on the -unqualifed forms of the same types. - -

    - - -

    Proposed resolution:

    -

    - -Add to the synopsis of the <limits> header, -immediately below the declaration of the primary template, the -following: -

    - -
    -template <class T> class numeric_limits<const T>;
-template <class T> class numeric_limits<volatile T>;
-template <class T> class numeric_limits<const volatile T>;
-
-
    - -

    - -Add a new paragraph to the end of 18.2.1.1 [numeric.limits], with the following -text: - -

    -

    - --new-para- The value of each member of a numeric_limits -specialization on a cv-qualified T is equal to the value of the same -member of numeric_limits<T>. - -

    - -

    [ -Portland: Martin will clarify that user-defined types get cv-specializations -automatically. -]

    - - - - - - - -
    -

    561. inserter overly generic

    -

    Section: 24.4.2.6.5 [inserter] Status: WP - Submitter: Howard Hinnant Date: 2006-02-21

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -The declaration of std::inserter is: -

    - -
    template <class Container, class Iterator>
-insert_iterator<Container>
-inserter(Container& x, Iterator i);
-
    - -

    -The template parameter Iterator in this function is completely unrelated -to the template parameter Container when it doesn't need to be. This -causes the code to be overly generic. That is, any type at all can be deduced -as Iterator, whether or not it makes sense. Now the same is true of -Container. However, for every free (unconstrained) template parameter -one has in a signature, the opportunity for a mistaken binding grows geometrically. -

    - -

    -It would be much better if inserter had the following signature instead: -

    - -
    template <class Container>
-insert_iterator<Container>
-inserter(Container& x, typename Container::iterator i);
-
    - -

    -Now there is only one free template parameter. And the second argument to -inserter must be implicitly convertible to the container's iterator, -else the call will not be a viable overload (allowing other functions in the -overload set to take precedence). Furthermore, the first parameter must have a -nested type named iterator, or again the binding to std::inserter -is not viable. Contrast this with the current situation -where any type can bind to Container or Iterator and those -types need not be anything closely related to containers or iterators. -

    - -

    -This can adversely impact well written code. Consider: -

    - -
    #include <iterator>
-#include <string>
-
-namespace my
-{
-
-template <class String>
-struct my_type {};
-
-struct my_container
-{
-template <class String>
-void push_back(const my_type<String>&);
-};
-
-template <class String>
-void inserter(const my_type<String>& m, my_container& c) {c.push_back(m);}
-
-}  // my
-
-int main()
-{
-    my::my_container c;
-    my::my_type<std::string> m;
-    inserter(m, c);
-}
-
    - -

    -Today this code fails because the call to inserter binds to -std::inserter instead of to my::inserter. However with the -proposed change std::inserter will no longer be a viable function which -leaves only my::inserter in the overload resolution set. Everything -works as the client intends. -

    - -

    -To make matters a little more insidious, the above example works today if you -simply change the first argument to an rvalue: -

    - -
        inserter(my::my_type(), c);
-
    - -

    -It will also work if instantiated with some string type other than -std::string (or any other std type). It will also work if -<iterator> happens to not get included. -

    - -

    -And it will fail again for such inocuous reaons as my_type or -my_container privately deriving from any std type. -

    - -

    -It seems unfortunate that such simple changes in the client's code can result -in such radically differing behavior. -

    - - - -

    Proposed resolution:

    -

    -Change 24.2: -

    - -

    -24.2 Header <iterator> synopsis -

    -
    ...
-template <class Container, class Iterator>
-   insert_iterator<Container> inserter(Container& x, Iterator typename Container::iterator i);
-...
-
    -
    - -

    -Change 24.4.2.5: -

    - -

    -24.4.2.5 Class template insert_iterator

    -
    ...
-template <class Container, class Iterator>
-   insert_iterator<Container> inserter(Container& x, Iterator typename Container::iterator i);
-...
-
    -
    - -

    -Change 24.4.2.6.5: -

    - -
    -

    -24.4.2.6.5 inserter -

    -
    template <class Container, class Inserter>
-   insert_iterator<Container> inserter(Container& x, Inserter typename Container::iterator i);
-
    -

    --1- Returns: insert_iterator<Container>(x,typename Container::iterator(i)). -

    -
    - - - -

    [ -Kona (2007): This issue will probably be addressed as a part of the -concepts overhaul of the library anyway, but the proposed resolution is -correct in the absence of concepts. Proposed Disposition: Ready -]

    - - - - - -
    -

    562. stringbuf ctor inefficient

    -

    Section: 27.7 [string.streams] Status: WP - Submitter: Martin Sebor Date: 2006-02-23

    -

    View all other issues in [string.streams].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    - -For better efficiency, the requirement on the stringbuf ctor that -takes a string argument should be loosened up to let it set -epptr() beyond just one past the last initialized -character just like overflow() has been changed to be -allowed to do (see issue 432). That way the first call to -sputc() on an object won't necessarily cause a call to -overflow. The corresponding change should be made to the -string overload of the str() member function. - -

    - - -

    Proposed resolution:

    -

    - -Change 27.7.1.1, p3 of the Working Draft, N1804, as follows: - -

    - -
    explicit basic_stringbuf(const basic_string<charT,traits,Allocator>& str,
-               ios_base::openmode which = ios_base::in | ios_base::out);
-
    - -

    --3- Effects: Constructs an object of class basic_stringbuf, -initializing the base class with basic_streambuf() -(27.5.2.1), and initializing mode with which. -Then calls str(s). copies the content of -str into the basic_stringbuf underlying character -sequence. If which & ios_base::out is true, initializes the -output sequence such that pbase() points to the first underlying -character, epptr() points one past the last underlying character, and -pptr() is equal to epptr() if which & ios_base::ate -is true, otherwise pptr() is equal to pbase(). If -which & ios_base::in is true, initializes the input sequence such -that eback() and gptr() point to the first underlying -character and egptr() points one past the last underlying character. -

    -
    - -

    - -Change the Effects clause of the str() in 27.7.1.2, p2 to -read: - -

    -
    -

    --2- Effects: Copies the contents of s into the -basic_stringbuf underlying character sequence and -initializes the input and output sequences according to mode. -If -mode & ios_base::out is true, initializes the output -sequence such that pbase() points to the first underlying character, -epptr() points one past the last underlying character, and pptr() -is equal to epptr() if mode & ios_base::in -is true, otherwise pptr() is equal to pbase(). If -mode & ios_base::in is true, initializes the input sequence -such that eback() and gptr() point to the first underlying -character and egptr() points one past the last underlying character. -

    - -

    - --3- Postconditions: If mode & ios_base::out is true, -pbase() points to the first underlying character and -(epptr() >= pbase() + s.size()) holds; in addition, if -mode & ios_base::in is true, (pptr() == pbase() -+ s.data()) holds, otherwise (pptr() == pbase()) -is true. If mode & ios_base::in is true, -eback() points to the first underlying character, and -(gptr() == eback()) and (egptr() == eback() + -s.size()) hold. - -

    -
    - - -

    [ -Kona (2007) Moved to Ready. -]

    - - - - - -
    -

    563. stringbuf seeking from end

    -

    Section: 27.7.1.4 [stringbuf.virtuals] Status: WP - Submitter: Martin Sebor Date: 2006-02-23

    -

    View all other issues in [stringbuf.virtuals].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -According to Table 92 (unchanged by issue 432), when (way == -end) the newoff value in out mode is computed as -the difference between epptr() and pbase(). -

    -

    - -This value isn't meaningful unless the value of epptr() -can be precisely controlled by a program. That used to be possible -until we accepted the resolution of issue 432, but since then the -requirements on overflow() have been relaxed to allow it -to make more than 1 write position available (i.e., by setting -epptr() to some unspecified value past -pptr()). So after the first call to -overflow() positioning the output sequence relative to -end will have unspecified results. - -

    -

    - -In addition, in in|out mode, since (egptr() == -epptr()) need not hold, there are two different possible values -for newoff: epptr() - pbase() and -egptr() - eback(). - -

    - - -

    Proposed resolution:

    -

    - -Change the newoff column in the last row of Table 94 to -read: - -

    -

    - -the end high mark pointer minus the beginning -pointer (xend high_mark - xbeg). - -

    - - -

    [ -Kona (2007) Moved to Ready. -]

    - - - - - -
    -

    566. array forms of unformatted input function undefined for zero-element arrays

    -

    Section: 27.6.1.3 [istream.unformatted] Status: WP - Submitter: Martin Sebor Date: 2006-02-23

    -

    View all other issues in [istream.unformatted].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    - -The array forms of unformatted input functions don't have well-defined -semantics for zero-element arrays in a couple of cases. The affected -ones (istream::get() and getline()) are supposed to -terminate when (n - 1) characters are stored, which obviously -can never be true when (n == 0) to start with. - -

    - - -

    Proposed resolution:

    -

    - -I propose the following changes (references are relative to the -Working Draft (document N1804). - -

    -

    - -Change 27.6.1.3, p8 (istream::get()), bullet 1 as follows: - -

    -
    -

    - -if (n < 1) is true or (n - 1) -characters are stored; - -

    -
    -

    - -Similarly, change 27.6.1.3, p18 (istream::getline()), bullet -3 as follows: - -

    -
    -

    - -(n < 1) is true or (n - 1) characters -are stored (in which case the function calls -setstate(failbit)). - -

    -
    -

    - -Finally, change p21 as follows: - -

    -
    -

    - -In any case, provided (n > 0) is true, it then -stores a null character (using charT()) into the next successive -location of the array. - -

    -
    - - - - - -
    -

    567. streambuf inserter and extractor should be unformatted

    -

    Section: 27.6 [iostream.format] Status: WP - Submitter: Martin Sebor Date: 2006-02-25

    -

    View all other issues in [iostream.format].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    - -Issue 60 explicitly made the extractor and inserter operators that -take a basic_streambuf* argument formatted input and output -functions, respectively. I believe that's wrong, certainly in the -case of the extractor, since formatted functions begin by extracting -and discarding whitespace. The extractor should not discard any -characters. - -

    - - -

    Proposed resolution:

    -

    - -I propose to change each operator to behave as unformatted input and -output function, respectively. The changes below are relative to the -working draft document number N1804. - -

    -

    - -Specifically, change 27.6.1.2.3, p14 as follows: - -

    - -
    -

    - -Effects: Behaves as an unformatted input function -(as described in 27.6.1.2.127.6.1.3, paragraph -1). - -

    -
    -

    - -And change 27.6.2.5.3, p7 as follows: - -

    - -
    -

    - -Effects: Behaves as an unformatted output function -(as described in 27.6.2.5.127.6.2.6, paragraph -1). - -

    -
    - - -

    [ -Kona (2007): Proposed Disposition: Ready -]

    - - - - - -
    -

    574. DR 369 Contradicts Text

    -

    Section: 27.3 [iostream.objects] Status: WP - Submitter: Pete Becker Date: 2006-04-18

    -

    View all other issues in [iostream.objects].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -lib.iostream.objects requires that the standard stream objects are never -destroyed, and it requires that they be destroyed. -

    -

    -DR 369 adds words to say that we really mean for ios_base::Init objects to force -construction of standard stream objects. It ends, though, with the phrase "these -stream objects shall be destroyed after the destruction of dynamically ...". -However, the rule for destruction is stated in the standard: "The objects are -not destroyed during program execution." -

    - - -

    Proposed resolution:

    -

    -Change 27.3 [iostream.objects]/1: -

    - -
    -

    --2- The objects are constructed and the associations are established at -some time prior to or during the first time an object of class -ios_base::Init is constructed, and in any case before the body of main -begins execution.290) The objects are not destroyed during program -execution.291) If a translation unit includes <iostream&t; or explicitly -constructs an ios_base::Init object, these stream objects shall be -constructed before dynamic initialization of non-local objects defined -later in that translation unit, and these stream objects shall be -destroyed after the destruction of dynamically initialized non-local -objects defined later in that translation unit. -

    -
    - - -

    [ -Kona (2007): From 27.3 [iostream.objects]/2, strike the words "...and these stream objects -shall be destroyed after the destruction of dynamically initialized -non-local objects defined later in that translation unit." Proposed -Disposition: Review -]

    - - - - - -
    -

    575. the specification of ~shared_ptr is MT-unfriendly, makes implementation assumptions

    -

    Section: 20.7.12.2.2 [util.smartptr.shared.dest], TR1 2.2.3.2 [tr.util.smartptr.shared.dest] Status: WP - Submitter: Peter Dimov Date: 2006-04-23

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -[tr.util.smartptr.shared.dest] says in its second bullet: -

    - -

    -"If *this shares ownership with another shared_ptr instance (use_count() > 1), -decrements that instance's use count." -

    - -

    -The problem with this formulation is that it presupposes the existence of an -"use count" variable that can be decremented and that is part of the state of a -shared_ptr instance (because of the "that instance's use count".) -

    - -

    -This is contrary to the spirit of the rest of the specification that carefully -avoids to require an use count variable. Instead, use_count() is specified to -return a value, a number of instances. -

    - -

    -In multithreaded code, the usual implicit assumption is that a shared variable -should not be accessed by more than one thread without explicit synchronization, -and by introducing the concept of an "use count" variable, the current wording -implies that two shared_ptr instances that share ownership cannot be destroyed -simultaneously. -

    - -

    -In addition, if we allow the interpretation that an use count variable is part -of shared_ptr's state, this would lead to other undesirable consequences WRT -multiple threads. For example, -

    - -
    p1 = p2;
-
    - -

    -would now visibly modify the state of p2, a "write" operation, requiring a lock. -

    - - -

    Proposed resolution:

    -

    -Change the first two bullets of [lib.util.smartptr.shared.dest]/1 to: -

    - -
    -
      -
    • If *this is empty or shares ownership with another -shared_ptr instance (use_count() > 1), there are no side effects.
      • -
    • If *this shares ownership with another shared_ptr instance -(use_count() > 1), decrements that instance's use count.
      • -
    -
    - -

    -Add the following paragraph after [lib.util.smartptr.shared.dest]/1: -

    - -

    -[Note: since the destruction of *this decreases the number of instances in -*this's ownership group by one, all shared_ptr instances that share ownership -with *this will report an use_count() that is one lower than its previous value -after *this is destroyed. --end note] -

    - - - - - -
    -

    576. find_first_of is overconstrained

    -

    Section: 25.1.7 [alg.find.first.of] Status: WP - Submitter: Doug Gregor Date: 2006-04-25

    -

    View all other issues in [alg.find.first.of].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -In 25.1.4 Find First [lib.alg.find.first], the two iterator type parameters to -find_first_of are specified to require Forward Iterators, as follows: -

    - -
    template<class ForwardIterator1, class ForwardIterator2>
-  ForwardIterator1
-  find_first_of(ForwardIterator1 first1, ForwardIterator1 last1,
-                        ForwardIterator2 first2, ForwardIterator2 last2);
-template<class ForwardIterator1, class ForwardIterator2,
-                  class BinaryPredicate>
-ForwardIterator1
-  find_first_of(ForwardIterator1 first1, ForwardIterator1 last1,
-                         ForwardIterator2 first2, ForwardIterator2 last2,
-                        BinaryPredicate pred);
-
    - -

    -However, ForwardIterator1 need not actually be a Forward Iterator; an Input -Iterator suffices, because we do not need the multi-pass property of the Forward -Iterator or a true reference. -

    - - -

    Proposed resolution:

    -

    -Change the declarations of find_first_of to: -

    - -
    template<class ForwardIterator1InputIterator1, class ForwardIterator2>
-  ForwardIterator1InputIterator1
-  find_first_of(ForwardIterator1InputIterator1 first1, ForwardIterator1InputIterator1 last1,
-                        ForwardIterator2 first2, ForwardIterator2 last2);
-template<class ForwardIterator1InputIterator1, class ForwardIterator2,
-                  class BinaryPredicate>
-ForwardIterator1InputIterator1
-  find_first_of(ForwardIterator1InputIterator1 first1, ForwardIterator1InputIterator1 last1,
-                         ForwardIterator2 first2, ForwardIterator2 last2,
-                        BinaryPredicate pred);
-
    - - - - - - -
    -

    577. upper_bound(first, last, ...) cannot return last

    -

    Section: 25.3.3.2 [upper.bound] Status: WP - Submitter: Seungbeom Kim Date: 2006-05-03

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -ISO/IEC 14882:2003 says: -

    - -
    -

    -25.3.3.2 upper_bound -

    -

    -Returns: The furthermost iterator i in the range -[first, last) such that -for any iterator j in the range [first, i) the following corresponding -conditions hold: !(value < *j) or comp(value, *j) == false. -

    -
    - -

    -From the description above, upper_bound cannot return last, since it's -not in the interval [first, last). This seems to be a typo, because if -value is greater than or equal to any other values in the range, or if -the range is empty, returning last seems to be the intended behaviour. -The corresponding interval for lower_bound is also [first, last]. -

    - - -

    Proposed resolution:

    -

    -Change [lib.upper.bound]: -

    - -
    -

    -Returns: The furthermost iterator i in the range -[first, last)] such that -for any iterator j in the range [first, i) the following corresponding -conditions hold: !(value < *j) or comp(value, *j) == false. -

    -
    - - - - - - -
    -

    578. purpose of hint to allocator::allocate()

    -

    Section: 20.7.5.1 [allocator.members] Status: WP - Submitter: Martin Sebor Date: 2006-05-17

    -

    View all other issues in [allocator.members].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    - -The description of the allocator member function -allocate() requires that the hint argument be -either 0 or a value previously returned from allocate(). -Footnote 227 further suggests that containers may pass the address of -an adjacent element as this argument. - -

    -

    - -I believe that either the footnote is wrong or the normative -requirement that the argument be a value previously returned from a -call to allocate() is wrong. The latter is supported by -the resolution to issue 20-004 proposed in c++std-lib-3736 by Nathan -Myers. In addition, the hint is an ordinary void* and not the -pointer type returned by allocate(), with -the two types potentially being incompatible and the requirement -impossible to satisfy. - -

    -

    - -See also c++std-lib-14323 for some more context on where this came up -(again). - -

    - - -

    Proposed resolution:

    -

    - -Remove the requirement in 20.6.1.1, p4 that the hint be a value -previously returned from allocate(). Specifically, change -the paragraph as follows: - -

    -

    -Requires: hint either 0 or previously obtained from member -allocate and not yet passed to member deallocate. -The value hint may be used by an implementation to help improve performance -223). [Note: The value hint may be used by an -implementation to help improve performance. -- end note] -

    -

    -[Footnote: 223)In a container member function, the address of an -adjacent element is often a good choice to pass for this argument. -

    - - - - -
    -

    581. flush() not unformatted function

    -

    Section: 27.6.2.7 [ostream.unformatted] Status: WP - Submitter: Martin Sebor Date: 2006-06-14

    -

    View all other issues in [ostream.unformatted].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    - -The resolution of issue 60 changed basic_ostream::flush() -so as not to require it to behave as an unformatted output function. -That has at least two in my opinion problematic consequences: - -

    -

    - -First, flush() now calls rdbuf()->pubsync() -unconditionally, without regard to the state of the stream. I can't -think of any reason why flush() should behave differently -from the vast majority of stream functions in this respect. - -

    -

    - -Second, flush() is not required to catch exceptions from -pubsync() or set badbit in response to such -events. That doesn't seem right either, as most other stream functions -do so. - -

    - - -

    Proposed resolution:

    -

    - -I propose to revert the resolution of issue 60 with respect to -flush(). Specifically, I propose to change 27.6.2.6, p7 -as follows: - -

    - -

    -Effects: Behaves as an unformatted output function (as described -in 27.6.2.6, paragraph 1). If rdbuf() is not a null -pointer, constructs a sentry object. If this object returns -true when converted to a value of type bool the function -calls rdbuf()->pubsync(). If that function returns --1 calls setstate(badbit) (which may throw -ios_base::failure (27.4.4.3)). Otherwise, if the -sentry object returns false, does nothing.Does -not behave as an unformatted output function (as described in -27.6.2.6, paragraph 1). -

    - - - -

    [ -Kona (2007): Proposed Disposition: Ready -]

    - - - - - -
    -

    586. string inserter not a formatted function

    -

    Section: 21.3.8.9 [string.io] Status: WP - Submitter: Martin Sebor Date: 2006-06-22

    -

    View all other issues in [string.io].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    - -Section and paragraph numbers in this paper are relative to the -working draft document number N2009 from 4/21/2006. - -

    - -

    - -The basic_string extractor in 21.3.7.9, p1 is clearly -required to behave as a formatted input function, as is the -std::getline() overload for string described in p7. - -

    -

    - -However, the basic_string inserter described in p5 of the -same section has no such requirement. This has implications on how the -operator responds to exceptions thrown from xsputn() -(formatted output functions are required to set badbit -and swallow the exception unless badbit is also set in -exceptions(); the string inserter doesn't have any such -requirement). - -

    -

    - -I don't see anything in the spec for the string inserter that would -justify requiring it to treat exceptions differently from all other -similar operators. (If it did, I think it should be made this explicit -by saying that the operator "does not behave as a formatted output -function" as has been made customary by the adoption of the resolution -of issue 60). - -

    - - -

    Proposed resolution:

    -

    - -I propose to change the Effects clause in 21.3.7.9, p5, as follows: - -

    -
    -

    - -Effects: Begins by constructing a sentry object k as if k -were constructed by typename basic_ostream<charT, -traits>::sentry k (os). If bool(k) is -true, Behaves as a formatted output function -(27.6.2.5.1). After constructing a sentry object, if -this object returns true when converted to a value of -type bool, determines padding as described in -22.2.2.2.2, then inserts the resulting sequence of characters -seq as if by calling os.rdbuf()->sputn(seq , -n), where n is the larger of -os.width() and str.size(); then calls -os.width(0). If the call to sputn fails, calls -os.setstate(ios_base::failbit). - -

    -
    -

    - -This proposed resilution assumes the resolution of issue 394 (i.e., -that all formatted output functions are required to set -ios_base::badbit in response to any kind of streambuf -failure), and implicitly assumes that a return value of -sputn(seq, n) other than n -indicates a failure. - -

    - - - - -
    -

    589. Requirements on iterators of member template functions of containers

    -

    Section: 23.1 [container.requirements] Status: WP - Submitter: Peter Dimov Date: 2006-08-02

    -

    View other active issues in [container.requirements].

    -

    View all other issues in [container.requirements].

    -

    View all issues with WP status.

    -

    Duplicate of: 536

    -

    Discussion:

    -

    -There appears to be no requirements on the InputIterators used in sequences in 23.1.1 in -terms of their value_type, and the requirements in 23.1.2 appear to be overly strict -(requires InputIterator::value_type be the same type as the container's value_type). -

    - - -

    Proposed resolution:

    -

    -Change 23.1.1 p3: -

    - -

    -In Tables 82 and 83, X denotes a sequence class, a denotes a -value of X, i and j denote iterators satisfying input -iterator requirements and refer to elements implicitly -convertible to value_type, [i, j) denotes a valid -range, n denotes a value of X::size_type, p denotes a -valid iterator to a, q denotes a valid dereferenceable -iterator to a, [q1, q2) denotes a valid range in a, -and t denotes a value of X::value_type. -

    - -

    -Change 23.1.2 p7: -

    - -

    -In Table 84, X is an associative container class, a is a value -of X, a_uniq is a value of X when X supports -unique keys, and a_eq is a value of X when X supports -multiple keys, i and j satisfy input iterator requirements and -refer to elements of implicitly convertible to -value_type, [i, j) is a valid range, p is a valid -iterator to a, q is a valid dereferenceable iterator to -a, [q1, q2) is a valid range in a, t is a -value of X::value_type, k is a value of X::key_type -and c is a value of type X::key_compare. -

    - - - -

    Rationale:

    -

    -Concepts will probably come in and rewrite this section anyway. But just in case it is -easy to fix this up as a safety net and as a clear statement of intent. -

    - - - - - -
    -

    593. __STDC_CONSTANT_MACROS

    -

    Section: 18.3 [cstdint], TR1 8.22 [tr.c99.cstdint] Status: WP - Submitter: Walter Brown Date: 2006-08-28

    -

    View all other issues in [cstdint].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -Clause 18.3 of the current Working Paper (N2009) deals with the new C++ headers -<cstdint> and <stdint.h>. These are of course based on the C99 header -<stdint.h>, and were part of TR1. -

    - -

    -Per 18.3.1/1, these headers define a number of macros and function macros. -While the WP does not mention __STDC_CONSTANT_MACROS in this context, C99 -footnotes do mention __STDC_CONSTANT_MACROS. Further, 18.3.1/2 states that "The -header defines all ... macros the same as C99 subclause 7.18." -

    - -

    -Therefore, if I wish to have the above-referenced macros and function macros -defined, must I #define __STDC_CONSTANT_MACROS before I #include <cstdint>, or -does the C++ header define these macros/function macros unconditionally? -

    - - -

    Proposed resolution:

    -

    -To put this issue to rest for C++0X, I propose the following addition to -18.3.1/2 of the Working Paper N2009: -

    - -

    -[Note: The macros defined by <cstdint> are provided unconditionally: in -particular, the symbols __STDC_LIMIT_MACROS and __STDC_CONSTANT_MACROS -(mentioned in C99 footnotes 219, 220, and 222) play no role in C++. --end note] -

    - - - - - -
    -

    595. TR1/C++0x: fabs(complex<T>) redundant / wrongly specified

    -

    Section: 26.3.7 [complex.value.ops] Status: WP - Submitter: Stefan Große Pawig Date: 2006-09-24

    -

    View all other issues in [complex.value.ops].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -TR1 introduced, in the C compatibility chapter, the function -fabs(complex<T>): -

    -
    ----- SNIP -----
-8.1.1 Synopsis                                [tr.c99.cmplx.syn]
-
-  namespace std {
-  namespace tr1 {
-[...]
-  template<class T> complex<T> fabs(const complex<T>& x);
-  } // namespace tr1
-  } // namespace std
-
-[...]
-
-8.1.8 Function fabs                          [tr.c99.cmplx.fabs]
-
-1 Effects: Behaves the same as C99 function cabs, defined in
-  subclause 7.3.8.1.
------ SNIP -----
-
    - -

    -The current C++0X draft document (n2009.pdf) adopted this -definition in chapter 26.3.1 (under the comment // 26.3.7 values) -and 26.3.7/7. -

    -

    -But in C99 (ISO/IEC 9899:1999 as well as the 9899:TC2 draft document -n1124), the referenced subclause reads -

    - -
    ----- SNIP -----
-7.3.8.1 The cabs functions
-
-  Synopsis
-
-1 #include <complex.h>
-  double cabs(double complex z);
-  float cabsf(float complex z);
-  long double cabsl(long double z);
-
-  Description
-
-2 The cabs functions compute the complex absolute value (also called
-  norm, modulus, or magnitude) of z.
-
-  Returns
-
-3 The cabs functions return the complex absolute value.
------ SNIP -----
-
    - -

    -Note that the return type of the cabs*() functions is not a complex -type. Thus, they are equivalent to the already well established - template<class T> T abs(const complex<T>& x); -(26.2.7/2 in ISO/IEC 14882:1998, 26.3.7/2 in the current draft -document n2009.pdf). -

    -

    -So either the return value of fabs() is specified wrongly, or fabs() -does not behave the same as C99's cabs*(). -

    - -Possible Resolutions - -

    -This depends on the intention behind the introduction of fabs(). -

    -

    -If the intention was to provide a /complex/ valued function that -calculates the magnitude of its argument, this should be -explicitly specified. In TR1, the categorization under "C -compatibility" is definitely wrong, since C99 does not provide -such a complex valued function. -

    -

    -Also, it remains questionable if such a complex valued function -is really needed, since complex<T> supports construction and -assignment from real valued arguments. There is no difference -in observable behaviour between -

    -
      complex<double> x, y;
-  y = fabs(x);
-  complex<double> z(fabs(x));
-
    -

    -and -

    -
      complex<double> x, y;
-  y = abs(x);
-  complex<double> z(abs(x));
-
    -

    -If on the other hand the intention was to provide the intended -functionality of C99, fabs() should be either declared deprecated -or (for C++0X) removed from the standard, since the functionality -is already provided by the corresponding overloads of abs(). -

    - -

    [ -Bellevue: -]

    - - -
    -Bill believes that abs() is a suitable overload. We should remove fabs(). -
    - - -

    Proposed resolution:

    - -

    -Change the synopsis in 26.3.1 [complex.synopsis]: -

    - -
    template<class T> complex<T> fabs(const complex<T>&);
-
    - -

    -Remove 26.3.7 [complex.value.ops], p7: -

    - -
    -
    template<class T> complex<T> fabs(const complex<T>& x);
-
    -
    -

    --7- Effects: Behaves the same as C99 function cabs, defined in subclause 7.3.8.1. -

    -
    -
    - - - -

    [ -Kona (2007): Change the return type of fabs(complex) to T. -Proposed Disposition: Ready -]

    - - - - - -
    -

    596. 27.8.1.3 Table 112 omits "a+" and "a+b" modes

    -

    Section: 27.8.1.4 [filebuf.members] Status: WP - Submitter: Thomas Plum Date: 2006-09-26

    -

    View all other issues in [filebuf.members].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -In testing 27.8.1.4 [filebuf.members], Table 112 (in the latest N2009 draft), we invoke -

    -
       ostr.open("somename", ios_base::out | ios_base::in | ios_base::app)
-
    -

    -and we expect the open to fail, because out|in|app is not listed in -Table 92, and just before the table we see very specific words: -

    -

    - If mode is not some combination of flags shown in the table - then the open fails. -

    -

    -But the corresponding table in the C standard, 7.19.5.3, provides two -modes "a+" and "a+b", to which the C++ modes out|in|app and -out|in|app|binary would presumably apply. -

    -

    -We would like to argue that the intent of Table 112 was to match the -semantics of 7.19.5.3 and that the omission of "a+" and "a+b" was -unintentional. (Otherwise there would be valid and useful behaviors -available in C file I/O which are unavailable using C++, for no -valid functional reason.) -

    -

    -We further request that the missing modes be explicitly restored to -the WP, for inclusion in C++0x. -

    - -

    [ -Martin adds: -]

    - - -

    -...besides "a+" and "a+b" the C++ table is also missing a row -for a lone app bit which in at least two current implementation -as well as in Classic Iostreams corresponds to the C stdio "a" -mode and has been traditionally documented as implying ios::out. -Which means the table should also have a row for in|app meaning -the same thing as "a+" already proposed in the issue. -

    - - -

    Proposed resolution:

    -

    -Add to the table "File open modes" in 27.8.1.4 [filebuf.members]: -

    - -
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    File open modes
    ios_base Flag combinationstdio equivalent
    binaryinouttruncapp 
        +     "w"
        +   + "a"
            + "a"
        + +   "w"
      +       "r"
      + +     "r+"
      + + +   "w+"
      + +   + "a+"
      +     + "a+"
    +   +     "wb"
    +   +   + "ab"
    +       + "ab"
    +   + +   "wb"
    + +       "rb"
    + + +     "r+b"
    + + + +   "w+b"
    + + +   + "a+b"
    + +     + "a+b"
    -
    - - - -

    [ -Kona (2007) Added proposed wording and moved to Review. -]

    - - - - - -
    -

    598. Decimal: Conversion to integral should truncate, not round.

    -

    Section: TRDecimal 3.2 [trdec.types.types] Status: TRDec - Submitter: Daniel Krugler Date: 2006-05-28

    -

    View other active issues in [trdec.types.types].

    -

    View all other issues in [trdec.types.types].

    -

    View all issues with TRDec status.

    -

    Discussion:

    - -

    -In a private email, Daniel writes: -

    -
    -

    -I would like to -ask, what where the reason for the decision to -define the semantics of the integral conversion of the decimal types, namely -

    -
    "operator long long() const;
-
-     Returns: Returns the result of the 
-conversion of *this to the type long long, as if 
-performed by the expression llrounddXX(*this)."
-
    -

    -where XX stands for either 32, 64, or 128, -corresponding to the proper decimal type. The -exact meaning of llrounddXX is not given in that -paper, so I compared it to the corresponding -definition given in C99, 2nd edition (ISO 9899), which says in 7.12.9.7 p. 2: -

    -

    -"The lround and llround functions round their -argument to the nearest integer value, -rounding halfway cases away from zero, regardless -of the current rounding direction. [..]" -

    -

    -Now considering the fact that integral conversion -of the usual floating-point types ("4.9 -Floating-integral conversions") has truncation -semantic I wonder why this conversion behaviour -has not been transferred for the decimal types. -

    -
    -

    -Robert comments: -

    -

    -Also, there is a further error in the Returns: clause for converting decimal::decimal128 to long long. It currently calls llroundd64, not llroundd128. -

    - - - -

    Proposed resolution:

    -

    -Change the Returns: clause in 3.2.2.4 to: -

    -

    -Returns: Returns the result of the conversion of *this to the type long long, as if performed by the expression llroundd32(*this) while the decimal rounding direction mode [3.5.2] FE_DEC_TOWARD_ZERO is in effect. -

    -

    -Change the Returns: clause in 3.2.3.4 to: -

    -

    -Returns: Returns the result of the conversion of *this to the type long long, as if performed by the expression llroundd64(*this) while the decimal rounding direction mode [3.5.2] FE_DEC_TOWARD_ZERO is in effect. -

    -

    -Change the Returns: clause in 3.2.4.4 to: -

    -

    -Returns: Returns the result of the conversion of *this to the type long long, as if performed by the expression llroundd64(*this) llroundd128(*this) while the decimal rounding direction mode [3.5.2] FE_DEC_TOWARD_ZERO is in effect. -

    - - - - - - -
    -

    599. Decimal: Say "octets" instead of "bytes."

    -

    Section: TRDecimal 3.1 [trdec.types.encodings] Status: TRDec - Submitter: Daniel Krugler Date: 2006-05-28

    -

    View all issues with TRDec status.

    -

    Discussion:

    -

    -Daniel writes in a private email: -

    - -
    -

    -- 3.1 'Decimal type encodings' says in its note: -

    -
    "this implies that 
-sizeof(std::decimal::decimal32) == 4, 
-sizeof(std::decimal::decimal64) == 8, and 
-sizeof(std::decimal::decimal128) == 16."
-
    -

    -This is a wrong assertion, because the definition -of 'byte' in 1.7 'The C+ + memory model' of ISO -14882 (2nd edition) does not specify that a byte -must be necessarily 8 bits large, which would be -necessary to compare with the specified bit sizes -of the types decimal32, decimal64, and decimal128. -

    -
    - - -

    Proposed resolution:

    -

    -Change 3.1 as follows: -

    -
    -

    -The three decimal encoding formats defined in IEEE-754R correspond to the three decimal floating types as follows: -

    -
      -
    • -decimal32 is a decimal32 number, which is encoded in four consecutive bytes octets (32 bits) -
      • -
    • -decimal64 is a decimal64 number, which is encoded in eight consecutive bytes octets (64 bits) - -
      • -
    • -decimal128 is a decimal128 number, which is encoded in 16 consecutive bytes octets (128 bits) -
      • -
    -

    -[Note: this implies that sizeof(std::decimal::decimal32) == 4, sizeof(std::decimal::decimal64) == 8, and sizeof(std::decimal::decimal128) == 16. --end note] -

    -
    - - - - -
    -

    600. Decimal: Wrong parameters for wcstod* functions

    -

    Section: TRDecimal 3.9 [trdec.types.cwchar] Status: TRDec - Submitter: Daniel Krugler Date: 2006-05-28

    -

    View all issues with TRDec status.

    -

    Discussion:

    -

    -Daniel writes: -

    -

    -- 3.9.1 'Additions to <cwchar>' provides wrong -signatures to the wcstod32, wcstod64, and -wcstod128 functions ([the parameters have type pointer-to-] char instead of wchar_t). -

    - - -

    Proposed resolution:

    -

    -Change "3.9.1 Additions to <cwchar> synopsis" to: -

    -
           namespace std {
-       namespace decimal {
-         // 3.9.2 wcstod functions:
-         decimal32  wcstod32  (const char wchar_t * nptr, char wchar_t ** endptr);
-         decimal64  wcstod64  (const char wchar_t * nptr, char wchar_t ** endptr);
-         decimal128 wcstod128 (const char wchar_t * nptr, char wchar_t ** endptr);
-       }
-       }
-
    - - - - -
    -

    601. Decimal: numeric_limits typos

    -

    Section: TRDecimal 3.3 [trdec.types.limits] Status: TRDec - Submitter: Daniel Krugler Date: 2006-05-28

    -

    View all issues with TRDec status.

    -

    Discussion:

    -

    -Daniel writes in a private email: -

    - -
    -

    -- 3.3 'Additions to header <limits>' contains two -errors in the specialisation of numeric_limits<decimal::decimal128>: -

    -
      -
    1. The static member max() returns DEC128_MIN, this should be DEC128_MAX.
      2. -
    2. The static member digits is assigned to 384, -this should be 34 (Probably mixed up with the -max. exponent for decimal::decimal64).
      3. -
    -
    - - -

    Proposed resolution:

    -

    -In "3.3 Additions to header <limits>" change numeric_limits<decimal::decimal128> as follows: -

    -
            template<> class numeric_limits<decimal::decimal128> {
-          public:
-            static const bool is_specialized = true;
-
-            static decimal::decimal128 min() throw() { return DEC128_MIN; }
-            static decimal::decimal128 max() throw() { return DEC128_MIN; DEC128_MAX; }
-
-            static const int digits       = 384 34;
-            /* ... */
-
    - - - - -
    -

    602. Decimal: "generic floating type" not defined.

    -

    Section: TRDecimal 3 [trdec.types] Status: TRDec - Submitter: Daniel Krugler Date: 2006-05-28

    -

    View all other issues in [trdec.types].

    -

    View all issues with TRDec status.

    -

    Discussion:

    -

    -The document uses the term "generic floating types," but defines it nowhere. -

    - - -

    Proposed resolution:

    -

    -Change the first paragraph of "3 Decimal floating-point types" as follows: -

    -

    -This Technical Report introduces three decimal floating-point types, named -decimal32, decimal64, and decimal128. The set of values of type decimal32 is a -subset of the set of values of type decimal64; the set of values of the type -decimal64 is a subset of the set of values of the type decimal128. Support for -decimal128 is optional. These types supplement the Standard C++ types -float, double, and long double, which are -collectively described as the basic floating types. -

    - - - - -
    -

    603. Decimal: Trivially simplifying decimal classes.

    -

    Section: TRDecimal 3 [trdec.types] Status: TRDec - Submitter: Martin Sebor Date: 2006-05-28

    -

    View all other issues in [trdec.types].

    -

    View all issues with TRDec status.

    -

    Discussion:

    -

    In c++std-lib-17198, Martin writes:

    - -

    -Each of the three classes proposed in the paper (decimal32, decimal64, -and decimal128) explicitly declares and specifies the semantics of its -copy constructor, copy assignment operator, and destructor. Since the -semantics of all three functions are identical to the trivial versions -implicitly generated by the compiler in the absence of any declarations -it is safe to drop them from the spec. This change would make the -proposed classes consistent with other similar classes already in the -standard (e.g., std::complex). -

    - - -

    Proposed resolution:

    -

    -Change "3.2.2 Class decimal32" as follows: -

    -
          namespace std {
-      namespace decimal {
-        class decimal32 {
-          public:
-            // 3.2.2.1 construct/copy/destroy:
-            decimal32();
-            decimal32(const decimal32 & d32);
-            decimal32 & operator=(const decimal32 & d32);
-            ~decimal32();
-            /* ... */
-
    -

    -Change "3.2.2.1 construct/copy/destroy" as follows: -

    -
            decimal32();
-
-    Effects: Constructs an object of type decimal32 with the value 0;
-
-        decimal32(const decimal32 & d32);
-        decimal32 & operator=(const decimal32 & d32);
-
-    Effects: Copies an object of type decimal32.
-
-        ~decimal32();
-
-    Effects: Destroys an object of type decimal32.
-
-
    -

    -Change "3.2.3 Class decimal64" as follows: -

    -
          namespace std {
-      namespace decimal {
-        class decimal64 {
-          public:
-            // 3.2.3.1 construct/copy/destroy:
-            decimal64();
-            decimal64(const decimal64 & d64);
-            decimal64 & operator=(const decimal64 & d64);
-            ~decimal64();
-            /* ... */
-
    -

    -Change "3.2.3.1 construct/copy/destroy" as follows: -

    -
            decimal64();
-
-    Effects: Constructs an object of type decimal64 with the value 0;
-
-        decimal64(const decimal64 & d64);
-        decimal64 & operator=(const decimal64 & d64);
-
-    Effects: Copies an object of type decimal64.
-
-        ~decimal64();
-
-    Effects: Destroys an object of type decimal64.
-
-
    -

    -Change "3.2.4 Class decimal128" as follows: -

    -
          namespace std {
-      namespace decimal {
-        class decimal128 {
-          public:
-            // 3.2.4.1 construct/copy/destroy:
-            decimal128();
-            decimal128(const decimal128 & d128);
-            decimal128 & operator=(const decimal128 & d128);
-            ~decimal128();
-            /* ... */
-
    -

    -Change "3.2.4.1 construct/copy/destroy" as follows: -

    -
            decimal128();
-
-    Effects: Constructs an object of type decimal128 with the value 0;
-
-        decimal128(const decimal128 & d128);
-        decimal128 & operator=(const decimal128 & d128);
-
-    Effects: Copies an object of type decimal128.
-
-        ~decimal128();
-
-    Effects: Destroys an object of type decimal128.
-
-
    - - - - -
    -

    604. Decimal: Storing a reference to a facet unsafe.

    -

    Section: TRDecimal 3 [trdec.types] Status: TRDec - Submitter: Martin Sebor Date: 2006-05-28

    -

    View all other issues in [trdec.types].

    -

    View all issues with TRDec status.

    -

    Discussion:

    -

    -In c++std-lib-17197, Martin writes: -

    -

    -The extended_num_get and extended_num_put facets are designed -to store a reference to a num_get or num_put facet which the -extended facets delegate the parsing and formatting of types -other than decimal. One form of the extended facet's ctor (the -default ctor and the size_t overload) obtains the reference -from the global C++ locale while the other form takes this -reference as an argument. -

    -

    -The problem with storing a reference to a facet in another -object (as opposed to storing the locale object in which the -facet is installed) is that doing so bypasses the reference -counting mechanism designed to prevent a facet that is still -being referenced (i.e., one that is still installed in some -locale) from being destroyed when another locale that contains -it is destroyed. Separating a facet reference from the locale -it comes from van make it cumbersome (and in some cases might -even make it impossible) for programs to prevent invalidating -the reference. (The danger of this design is highlighted in -the paper.) -

    -

    -This problem could be easily avoided by having the extended -facets store a copy of the locale from which they would extract -the base facet either at construction time or when needed. To -make it possible, the forms of ctors of the extended facets that -take a reference to the base facet would need to be changed to -take a locale argument instead. -

    - - -

    Proposed resolution:

    -

    -1. Change the extended_num_get synopsis in 3.10.2 as follows: -

    -
                extended_num_get(const std::num_get<charT, InputIterator> std::locale & b, size_t refs = 0);
-
-            /* ... */
-
-            // const std::num_get<charT, InputIterator> & base;        exposition only
-            // std::locale baseloc;                                    exposition only
-
    -

    -2. Change the description of the above constructor in 3.10.2.1: -

    -
                extended_num_get(const std::num_get<charT, InputIterator> std::locale & b, size_t refs = 0);
-
-
    -
    -

    -Effects: Constructs an extended_num_get facet as if by: -

    -
           extended_num_get(const std::num_get<charT, InputIterator> std::locale & b, size_t refs = 0)
-                : facet(refs), baseloc(b)
-                { /* ... */ }
-
-
    -

    -Notes: Care must be taken by the implementation to ensure that the lifetime of the facet referenced by base exceeds that of the resulting extended_num_get facet. -

    -
    -

    -3. Change the Returns: clause for do_get(iter_type, iter_type, ios_base &, ios_base::iostate &, bool &) const, et al to -

    -

    -Returns: base std::use_facet<std::num_get<charT, InputIterator> >(baseloc).get(in, end, str, err, val). -

    -

    -4. Change the extended_num_put synopsis in 3.10.3 as follows: -

    -
                extended_num_put(const std::num_put<charT, OutputIterator> std::locale & b, size_t refs = 0);
-
-            /* ... */
-
-            // const std::num_put<charT, OutputIterator> & base;       exposition only
-            // std::locale baseloc;                                    exposition only
-
    -

    -5. Change the description of the above constructor in 3.10.3.1: -

    -
                extended_num_put(const std::num_put<charT, OutputIterator> std::locale & b, size_t refs = 0);
-
    -
    -

    -Effects: Constructs an extended_num_put facet as if by: -

    -
           extended_num_put(const std::num_put<charT, OutputIterator> std::locale & b, size_t refs = 0)
-                : facet(refs), baseloc(b)
-                { /* ... */ }
-
-
    -

    -Notes: Care must be taken by the implementation to ensure that the lifetime of the facet referenced by base exceeds that of the resulting extended_num_put facet. -

    -
    -

    -6. Change the Returns: clause for do_put(iter_type, ios_base &, char_type, bool &) const, et al to -

    -

    -Returns: base std::use_facet<std::num_put<charT, OutputIterator> >(baseloc).put(s, f, fill, val). -

    - -

    [ -Redmond: We would prefer to rename "extended" to "decimal". -]

    - - - - - - -
    -

    605. Decimal: <decfloat.h> doesn't live here anymore.

    -

    Section: TRDecimal 3.4 [trdec.types.cdecfloat] Status: TRDec - Submitter: Robert Klarer Date: 2006-10-17

    -

    View all issues with TRDec status.

    -

    Discussion:

    -

    -In Berlin, WG14 decided to drop the <decfloat.h> header. The -contents of that header have been moved into <float.h>. For the -sake of C compatibility, we should make corresponding changes. -

    - - -

    Proposed resolution:

    -

    -1. Change the heading of subclause 3.4, "Headers <cdecfloat> and <decfloat.h>" to "Additions to headers <cfloat> and <float.h>." -

    -

    -2. Change the text of subclause 3.4 as follows: -

    -
    -

    -The standard C++ headers <cfloat> and <float.h> define characteristics of the floating-point types float, double, and long double. Their contents remain unchanged by this Technical Report. -

    -

    -Headers <cdecfloat> and <decfloat.h> define characteristics of the decimal floating-point types decimal32, decimal64, and decimal128. As well, <decfloat.h> defines the convenience typedefs _Decimal32, _Decimal64, and _Decimal128, for compatibilty with the C programming language. -

    -

    -The header <cfloat> is described in [tr.c99.cfloat]. The header <float.h> -is described in [tr.c99.floath]. These headers are extended by this -Technical Report to define characteristics of the decimal -floating-point types decimal32, decimal64, and decimal128. As well, <float.h> is extended to define the convenience typedefs _Decimal32, _Decimal64, and _Decimal128 for compatibility with the C programming language. -

    -
    -

    -3. Change the heading of subclause 3.4.1, "Header <cdecfloat> synopsis" to "Additions to header <cfloat> synopsis." -

    -

    -4. Change the heading of subclause 3.4.2, "Header <decfloat.h> synopsis" to "Additions to header <float.h> synopsis." -

    -

    -5. Change the contents of 3.4.2 as follows: -

    -
          #include <cdecfloat>
-
-      // C-compatibility convenience typedefs:
-
-      typedef std::decimal::decimal32  _Decimal32;
-      typedef std::decimal::decimal64  _Decimal64;
-      typedef std::decimal::decimal128 _Decimal128;
-
    - - - - - -
    -

    607. Concern about short seed vectors

    -

    Section: 26.4.7.1 [rand.util.seedseq] Status: WP - Submitter: Charles Karney Date: 2006-10-26

    -

    View other active issues in [rand.util.seedseq].

    -

    View all other issues in [rand.util.seedseq].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -Short seed vectors of 32-bit quantities all result in different states. However -this is not true of seed vectors of 16-bit (or smaller) quantities. For example -these two seeds -

    - -
    unsigned short seed = {1, 2, 3};
-unsigned short seed = {1, 2, 3, 0};
-
    - -

    -both pack to -

    - -
    unsigned seed = {0x20001, 0x3};
-
    - -

    -yielding the same state. -

    - -

    -See N2391 and -N2423 -for some further discussion. -

    - - -

    Proposed resolution:

    -

    -Adopt the proposed resolution in -N2423. -

    - - -

    [ -Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue. -The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona. -]

    - - - - - -
    -

    608. Unclear seed_seq construction details

    -

    Section: 26.4.7.1 [rand.util.seedseq] Status: WP - Submitter: Charles Karney Date: 2006-10-26

    -

    View other active issues in [rand.util.seedseq].

    -

    View all other issues in [rand.util.seedseq].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -In 26.4.7.1 [rand.util.seedseq] /6, the order of packing the inputs into b and the -treatment of signed quantities is unclear. Better to spell it out. -

    - -

    -See N2391 and -N2423 -for some further discussion. -

    - - -

    Proposed resolution:

    -

    -Adopt the proposed resolution in -N2423. -

    - - -

    [ -Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue. -The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona. -]

    - - - - - -
    -

    609. missing static const

    -

    Section: 26.4.4.2 [rand.adapt.ibits], TR1 5.1 [tr.rand] Status: WP - Submitter: Walter E. Brown Date: 2006-11-02

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -In preparing N2111, an error on my part resulted in the omission of the -following line from the template synopsis in the cited section: -

    - -
    static const size_t word_size = w;
-
    - -

    -(This same constant is found, for example, in 26.4.3.3 [rand.eng.sub].) -

    - - -

    Proposed resolution:

    -

    -Add the above declaration as the first line after the comment in [rand.adapt.ibits] p4: -

    - -
    // engine characteristics
-static const size_t word_size = w;
-
    - -

    -and accept my apologies for the oversight. -

    - - - - - -
    -

    610. Suggested non-normative note for C++0x

    -

    Section: 20.6.15.2.1 [func.wrap.func.con], TR1 3.7.2.1 [tr.func.wrap.func.con] Status: WP - Submitter: Scott Meyers Date: 2006-11-02

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -My suggestion is that implementers of both tr1::function and its -official C++0x successor be explicitly encouraged (but not required) to -optimize for the cases mentioned above, i.e., function pointers and -small function objects. They could do this by using a small internal -buffer akin to the buffer used by implementations of the small string -optimization. (That would make this the small functor optimization -- -SFO :-}) The form of this encouragement could be a note in the standard -akin to footnote 214 of the current standard. -

    - -

    -Dave Abrahams notes: -

    - -

    -"shall not throw exceptions" should really be "nothing," both to be more -grammatical and to be consistent with existing wording in the standard. -

    - -

    -Doug Gregor comments: I think this is a good idea. Currently, implementations of -tr1::function are required to have non-throwing constructors and assignment -operators when the target function object is a function pointer or a -reference_wrapper. The common case, however, is for a tr1::function to store -either an empty function object or a member pointer + an object pointer. -

    -

    -The function implementation in the upcoming Boost 1.34.0 uses the -"SFO", so that the function objects for typical bind expressions like -

    -
    bind(&X::f, this, _1, _2, _3)
-
    - -

    -do not require heap allocation when stored in a boost::function. I -believe Dinkumware's implementation also performs this optimization. -

    - - - -

    Proposed resolution:

    -

    -Revise 20.5.14.2.1 p6 [func.wrap.func.con] to add a note as follows: -

    - -
    -

    -Throws: shall not throw exceptions if f's target is a function -pointer or a function object passed via reference_wrapper. Otherwise, -may throw bad_alloc or any exception thrown by the copy constructor of -the stored function object. -

    -

    -Note: Implementations are encouraged to avoid the use of dynamically -allocated memory for "small" function objects, e.g., where f's target -is an object holding only a pointer or reference to an object and a member -function pointer (a "bound member function"). -

    -
    - - - - - -
    -

    611. Standard library templates and incomplete types

    -

    Section: 17.4.3.7 [res.on.functions] Status: WP - Submitter: Nicola Musatti Date: 2006-11-13

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -In the latest available draft standard -(N2134) -§ 17.4.3.6 [res.on.functions] states: -

    - -
    -

    --1- In certain cases (replacement functions, handler functions, operations on -types used to instantiate standard library template components), the C++ -Standard Library depends on components supplied by a C++ program. If these -components do not meet their requirements, the Standard places no requirements -on the implementation. -

    - -

    --2- In particular, the effects are undefined in the following cases: -

    -

    -[...] -

    -
      -
    • if an incomplete type (3.9) is used as a template argument when -instantiating a template component.
      • -
    -
    - -

    -This is contradicted by § 20.6.6.2/2 [util.smartptr.shared] which -states: -

    - -
    -

    -[...] -

    - -

    -The template parameter T of shared_ptr may be an incomplete type. -

    -
    - - -

    Proposed resolution:

    -

    -Modify the last bullet of § 17.4.3.6/2 [res.on.functions] to allow for -exceptions: -

    - -
    -
      -
    • if an incomplete type (3.9) is used as a template argument when -instantiating a template component, unless specifically allowed for the -component.
      • -
    -
    - - - - - - -
    -

    612. numeric_limits::is_modulo insufficiently defined

    -

    Section: 18.2.1.2 [numeric.limits.members] Status: WP - Submitter: Chris Jefferson Date: 2006-11-10

    -

    View all other issues in [numeric.limits.members].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -18.2.1.2 55 states that "A type is modulo if it is possible to add two -positive numbers together and have a result that wraps around to a -third number that is less". -This seems insufficient for the following reasons: -

    - -
      -
    1. Doesn't define what that value received is.
      2. -
    2. Doesn't state the result is repeatable
      3. -
    3. Doesn't require that doing addition, subtraction and other -operations on all values is defined behaviour.
      4. -
    - -

    [ -Batavia: Related to -N2144. -Pete: is there an ISO definition of modulo? Underflow on signed behavior is undefined. -]

    - - -

    [ -Bellevue: accept resolution, move to ready status. -Does this mandate that is_modulo be true on platforms for which int -happens to b modulo? A: the standard already seems to require that. -]

    - - - -

    Proposed resolution:

    -

    -Suggest 18.2.1.2 [numeric.limits.members], paragraph 57 is amended to: -

    - -

    -A type is modulo if, it is possible to add two positive numbers -and have a result that wraps around to a third number that is less. -given any operation involving +,- or * on values of that type whose value -would fall outside the range [min(), max()], then the value returned -differs from the true value by an integer multiple of (max() - min() + -1). -

    - - - - - - -
    -

    613. max_digits10 missing from numeric_limits

    -

    Section: 18.2.1.5 [numeric.special] Status: WP - Submitter: Bo Persson Date: 2006-11-20

    -

    View all other issues in [numeric.special].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -Section 18.2.1.5 [numeric.special] starts out by saying that "All members shall be provided -for all specializations." -

    -

    -Then it goes on to show specializations for float and bool, where one member -is missing (max_digits10). -

    - -

    -Maarten Kronenburg adds: -

    - -

    -I agree, just adding the comment that the exact number of decimal digits -is digits * ln(radix) / ln(10), where probably this real number is -rounded downward for digits10, and rounded upward for max_digits10 -(when radix=10, then digits10=max_digits10). -Why not add this exact definition also to the standard, so the user -knows what these numbers exactly mean. -

    - -

    -Howard adds: -

    - -

    -For reference, here are the correct formulas from -N1822: -

    - -
    digits10 = floor((digits-1) * log10(2))
-max_digits10 = ceil((1 + digits) * log10(2))
-
    - -

    -We are also missing a statement regarding for what specializations this member has meaning. -

    - - - -

    Proposed resolution:

    -

    -Change and add after 18.2.1.2 [numeric.limits.members], p11: -

    - -
    -
    static const int max_digits10;
    -
    -

    --11- Number of base 10 digits required to ensure that values which -differ by only one epsilon are always differentiated. -

    -

    --12- Meaningful for all floating point types. -

    -
    -
    - -

    -Change 18.2.1.5 [numeric.special], p2: -

    - -
    template<> class numeric_limits<float> { 
-public: 
-  static const bool is_specialized = true; 
-  ...
-  static const int digits10 = 6;
-  static const int max_digits10 = 9;
-  ...
-
    - -

    -Change 18.2.1.5 [numeric.special], p3: -

    - -
    template<> class numeric_limits<bool> { 
-public: 
-  static const bool is_specialized = true; 
-  ...
-  static const int digits10 = 0;
-  static const int max_digits10 = 0;
-  ...
-
    - - - - - - - -
    -

    616. missing 'typename' in ctype_byname

    -

    Section: 22.2.1.2 [locale.ctype.byname] Status: WP - Submitter: Bo Persson Date: 2006-12-16

    -

    View all other issues in [locale.ctype.byname].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -Section 22.2.1.2 defines the ctype_byname class template. It contains the -line -

    - -
    typedef ctype<charT>::mask   mask;
-
    - - - -

    Proposed resolution:

    -

    -as this is a dependent type, it should obviously be -

    - -
    typedef typename ctype<charT>::mask   mask;
-
    - - - - - -
    -

    618. valarray::cshift() effects on empty array

    -

    Section: 26.5.2.7 [valarray.members] Status: WP - Submitter: Gabriel Dos Reis Date: 2007-01-10

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -I would respectfully request an issue be opened with the intention to -clarify the wording for size() == 0 for cshift. -

    - - -

    Proposed resolution:

    -

    -Change 26.5.2.7 [valarray.members], paragraph 10: -

    - -
    - -
    valarray<T> cshift(int n) const;
-
    - -
    -

    -This function returns an object of class valarray<T>, of -length size(), each of whose elements I is -(*this)[(I + n ) % size()]. Thus, if element zero is taken as -the leftmost element, a positive value of n shifts the elements -circularly left n places. that is a circular shift of *this. If -element zero is taken as the leftmost element, a non-negative value of -n shifts the elements circularly left n places and a -negative value of n shifts the elements circularly right --n places. -

    -
    -
    - - - -

    Rationale:

    -

    -We do not believe that there is any real ambiguity about what happens -when size() == 0, but we do believe that spelling this out as a C++ -expression causes more trouble that it solves. The expression is -certainly wrong when n < 0, since the sign of % with negative arguments -is implementation defined. -

    - - -

    [ -Kona (2007) Changed proposed wording, added rationale and set to Review. -]

    - - - - - -
    -

    619. Longjmp wording problem

    -

    Section: 18.9 [support.runtime] Status: WP - Submitter: Lawrence Crowl Date: 2007-01-12

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -The wording for longjmp is confusing. -

    -

    -18.9 [support.runtime] -4- Other runtime support -

    -

    -The function signature longjmp(jmp_buf jbuf, int val) has more restricted -behavior in this International Standard. If any automatic objects would -be destroyed by a thrown exception transferring control to another -(destination) point in the program, then a call to longjmp(jbuf, val) that -the throw point that transfers control to the same (destination) point has -undefined behavior. -

    -

    -Someone at Google thinks that should say "then a call to longjmp(jbuf, val) -*at* the throw point that transfers control". -

    -

    -Bill Gibbons thinks it should say something like "If any automatic objects -would be destroyed by an exception thrown at the point of the longjmp and -caught only at the point of the setjmp, the behavior is undefined." -

    - - -

    Proposed resolution:

    -

    -In general, accept Bill Gibbons' recommendation, -but add "call" to indicate that the undefined behavior -comes from the dynamic call, not from its presence in the code. -In 18.9 [support.runtime] paragraph 4, change -

    - -

    -The function signature longjmp(jmp_buf jbuf, int val) has more -restricted behavior in this International Standard. If any automatic -objects would be destroyed by a thrown exception transferring control to another -(destination) point in the program, then a call to longjmp(jbuf, val) -that the throw point that transfers control to the same (destination) point has -undefined behavior. A setjmp/longjmp call pair has -undefined behavior if replacing the setjmp and longjmp by -catch and throw would destroy any automatic objects. -

    - - - - - -
    -

    620. valid uses of empty valarrays

    -

    Section: 26.5.2.1 [valarray.cons] Status: WP - Submitter: Martin Sebor Date: 2007-01-20

    -

    View other active issues in [valarray.cons].

    -

    View all other issues in [valarray.cons].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    - -The Effects clause for the default valarray ctor -suggests that it is possible to increase the size of an empty -valarray object by calling other non-const member -functions of the class besides resize(). However, such an -interpretation would be contradicted by the requirement on the copy -assignment operator (and apparently also that on the computed -assignments) that the assigned arrays be the same size. See the -reflector discussion starting with c++std-lib-17871. - -

    -

    - -In addition, Footnote 280 uses some questionable normative -language. - -

    - - -

    Proposed resolution:

    -

    - -Reword the Effects clause and Footnote 280 as follows (26.5.2.1 [valarray.cons]): - -

    -
    -

    - -valarray(); - -

    -

    - -Effects: Constructs an object of class -valarray<T>,279) which has zero -length until it is passed into a library function as a modifiable -lvalue or through a non-constant this pointer.280) - -

    -

    - -Postcondition: size() == 0. - -

    -

    - -Footnote 280: This default constructor is essential, since -arrays of valarray are likely to prove useful. -There shall also be a way to change the size of an array after -initialization; this is supplied by the semantics may be -useful. The length of an empty array can be increased after -initialization by means of the resize() member -function. - -

    -
    - - - - - -
    -

    621. non-const copy assignment operators of helper arrays

    -

    Section: 26.5 [numarray] Status: WP - Submitter: Martin Sebor Date: 2007-01-20

    -

    View all other issues in [numarray].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    - -The computed and "fill" assignment operators of valarray -helper array class templates (slice_array, -gslice_array, mask_array, and -indirect_array) are const member functions of each class -template (the latter by the resolution of 123 -since they have reference semantics and thus do not affect -the state of the object on which they are called. However, the copy -assignment operators of these class templates, which also have -reference semantics, are non-const. The absence of constness opens -the door to speculation about whether they really are intended to have -reference semantics (existing implementations vary widely). - -

    - -

    -Pre-Kona, Martin adds: -

    - -

    -I realized that adding the const qualifier to the -functions as I suggested would break the const correctness of the -classes. A few possible solutions come to mind: -

    - -
      -
    1. Add the const qualifier to the return types of these functions.
      2. -
    2. Change the return type of all the functions to void to match -the signatures of all the other assignment operators these classes -define.
      3. -
    3. Prohibit the copy assignment of these classes by declaring the -copy assignment operators private (as is done and documented by -some implementations).
      4. -
    - - - -

    Proposed resolution:

    -

    - -Declare the copy assignment operators of all four helper array -class templates const. - -

    -

    - -Specifically, make the following edits: - -

    -

    - -Change the signature in 26.5.5 [template.slice.array] and -26.5.5.1 [slice.arr.assign] as follows: - -

    - 
    -const slice_array& operator= (const slice_array&) const;
-
-
    -

    - -Change the signature in 26.5.7 [template.gslice.array] and -26.5.7.1 [gslice.array.assign] as follows: - -

    - 
    -const gslice_array& operator= (const gslice_array&) const;
-
-
    -

    - -Change the signature in 26.5.8 [template.mask.array] and 26.5.8.1 [mask.array.assign] as -follows: - -

    - 
    -const mask_array& operator= (const mask_array&) const;
-
-
    -

    - -Change the signature in 26.5.9 [template.indirect.array] and -26.5.9.1 [indirect.array.assign] as follows: - -

    - 
    -const indirect_array& operator= (const indirect_array&) const;
-
-
    - - -

    [ -Kona (2007) Added const qualification to the return types and set to Ready. -]

    - - - - - -
    -

    622. behavior of filebuf dtor and close on error

    -

    Section: 27.8.1.17 [fstream.members] Status: WP - Submitter: Martin Sebor Date: 2007-01-20

    -

    View all issues with WP status.

    -

    Discussion:

    -

    - -basic_filebuf dtor is specified to have the following -straightforward effects: - -

    -

    - -Effects: Destroys an object of class -basic_filebuf. Calls close(). - -

    -

    - -close() does a lot of potentially complicated processing, -including calling overflow() to write out the termination -sequence (to bring the output sequence to its initial shift -state). Since any of the functions called during the processing can -throw an exception, what should the effects of an exception be on the -dtor? Should the dtor catch and swallow it or should it propagate it -to the caller? The text doesn't seem to provide any guidance in this -regard other than the general restriction on throwing (but not -propagating) exceptions from destructors of library classes in -17.4.4.9 [res.on.exception.handling]. - -

    -

    - -Further, the last thing close() is specified to do is -call fclose() to close the FILE pointer. The -last sentence of the Effects clause reads: - -

    -

    - -... If any of the calls to overflow or -std::fclose fails then close fails. - -

    -

    - -This suggests that close() might be required to call -fclose() if and only if none of the calls to -overflow() fails, and avoid closing the FILE -otherwise. This way, if overflow() failed to flush out -the data, the caller would have the opportunity to try to flush it -again (perhaps after trying to deal with whatever problem may have -caused the failure), rather than losing it outright. - -

    -

    - -On the other hand, the function's Postcondition specifies that -is_open() == false, which suggests that it should call -fclose() unconditionally. However, since -Postcondition clauses are specified for many functions in the -standard, including constructors where they obviously cannot apply -after an exception, it's not clear whether this Postcondition -clause is intended to apply even after an exception. - -

    -

    - -It might be worth noting that the traditional behavior (Classic -Iostreams fstream::close() and C fclose()) -is to close the FILE unconditionally, regardless of -errors. - -

    - -

    [ -See 397 and 418 for related issues. -]

    - - - - -

    Proposed resolution:

    -

    - -After discussing this on the reflector (see the thread starting with -c++std-lib-17650) we propose that close() be clarified to -match the traditional behavior, that is to close the FILE -unconditionally, even after errors or exceptions. In addition, we -propose the dtor description be amended so as to explicitly require it -to catch and swallow any exceptions thrown by close(). - -

    -

    - -Specifically, we propose to make the following edits in -27.8.1.4 [filebuf.members]: - -

    -
    - 
    -basic_filebuf<charT,traits>* close();
-
-
    -

    - -Effects: If is_open() == false, returns a null -pointer. If a put area exists, calls -overflow(traits::eof()) to flush characters. If the last -virtual member function called on *this (between -underflow, overflow, seekoff, -and seekpos) was overflow then calls -a_codecvt.unshift (possibly several times) to determine a -termination sequence, inserts those characters and calls -overflow(traits::eof()) again. Finally, regardless -of whether any of the preceding calls fails or throws an exception, -the function it closes the file ("as if" by calling -std::fclose(file)).334) If any of the calls -made by the functionto overflow -or, including std::fclose, -fails then close fails by returning a null pointer. -If one of these calls throws an exception, the exception is caught and -rethrown after closing the file. - -

    -
    -

    - -And to make the following edits in 27.8.1.2 [filebuf.cons]. - -

    -
    - 
    -virtual ~basic_filebuf();
-
-
    -

    - -Effects: Destroys an object of class -basic_filebuf<charT,traits>. Calls -close(). If an exception occurs during the -destruction of the object, including the call to close(), -the exception is caught but not rethrown (see -17.4.4.9 [res.on.exception.handling]). - -

    -
    - - - - - -
    -

    623. pubimbue forbidden to call imbue

    -

    Section: 27.1.1 [iostream.limits.imbue] Status: WP - Submitter: Martin Sebor Date: 2007-01-20

    -

    View all issues with WP status.

    -

    Discussion:

    -

    - -27.1.1 [iostream.limits.imbue] specifies that "no function described in -clause 27 except for ios_base::imbue causes any instance -of basic_ios::imbue or -basic_streambuf::imbue to be called." - -

    -

    - -That contradicts the Effects clause for -basic_streambuf::pubimbue() which requires the function -to do just that: call basic_streambuf::imbue(). - -

    - - -

    Proposed resolution:

    -

    - -To fix this, rephrase the sentence above to allow -pubimbue to do what it was designed to do. Specifically. -change 27.1.1 [iostream.limits.imbue], p1 to read: - -

    -

    - -No function described in clause 27 except for -ios_base::imbue and basic_filebuf::pubimbue -causes any instance of basic_ios::imbue or -basic_streambuf::imbue to be called. ... - -

    - - - - - -
    -

    624. valarray assignment and arrays of unequal length

    -

    Section: 26.5.2.2 [valarray.assign] Status: WP - Submitter: Martin Sebor Date: 2007-01-20

    -

    View all issues with WP status.

    -

    Discussion:

    -

    - -The behavior of the valarray copy assignment operator is -defined only when both sides have the same number of elements and the -spec is explicit about assignments of arrays of unequal lengths having -undefined behavior. - -

    -

    - -However, the generalized subscripting assignment operators overloaded -on slice_array et al (26.5.2.2 [valarray.assign]) don't have any -such restriction, leading the reader to believe that the behavior of -these overloads is well defined regardless of the lengths of the -arguments. - -

    -

    - -For example, based on the reading of the spec the behavior of the -snippet below can be expected to be well-defined: - -

    - 
        const std::slice from_0_to_3 (0, 3, 1);   // refers to elements 0, 1, 2
-    const std::valarray<int> a (1, 3);        // a = { 1, 1, 1 }
-    std::valarray<int>       b (2, 4);        // b = { 2, 2, 2, 2 }
-
-    b = a [from_0_to_3];
-
    -

    - -In practice, b may end up being { 1, 1, 1 }, -{ 1, 1, 1, 2 }, or anything else, indicating that -existing implementations vary. - -

    - -

    -Quoting from Section 3.4, Assignment operators, of Al Vermeulen's -Proposal for Standard C++ Array Classes (see c++std-lib-704; -N0308): -

    -

    - ...if the size of the array on the right hand side of the equal - sign differs from the size of the array on the left, a run time - error occurs. How this error is handled is implementation - dependent; for compilers which support it, throwing an exception - would be reasonable. -

    - -

    -And see more history in -N0280. -

    - -

    - -It has been argued in discussions on the committee's reflector that -the semantics of all valarray assignment operators should -be permitted to be undefined unless the length of the arrays being -assigned is the same as the length of the one being assigned from. See -the thread starting at c++std-lib-17786. - -

    -

    - -In order to reflect such views, the standard must specify that the -size of the array referred to by the argument of the assignment must -match the size of the array under assignment, for example by adding a -Requires clause to 26.5.2.2 [valarray.assign] as follows: - -

    -

    - -Requires: The length of the array to which the argument refers -equals size(). - -

    - -

    - -Note that it's far from clear that such leeway is necessary in order -to implement valarray efficiently. - -

    - - -

    Proposed resolution:

    -

    -Insert new paragraph into 26.5.2.2 [valarray.assign]: -

    - -
    -
    valarray<T>& operator=(const slice_array<T>&); 
-valarray<T>& operator=(const gslice_array<T>&); 
-valarray<T>& operator=(const mask_array<T>&); 
-valarray<T>& operator=(const indirect_array<T>&);
-
    -
    -

    -Requires: The length of the array to which the argument refers -equals size(). -

    -

    -These operators allow the results of a generalized subscripting operation to be assigned directly to a valarray. -

    -
    -
    - - - - - -
    -

    628. Inconsistent definition of basic_regex constructor

    -

    Section: 28.8 [re.regex] Status: WP - Submitter: Bo Persson Date: 2007-01-23

    -

    View all other issues in [re.regex].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -Section 28.8 [re.regex] lists a constructor -

    - -
    template<class InputIterator>
-basic_regex(InputIterator first, InputIterator last,
-                       flag_type f = regex_constants::ECMAScript);
-
    - -

    -However, in section 28.8.2 [re.regex.construct], this constructor takes a -pair of ForwardIterator. -

    - - -

    Proposed resolution:

    -

    -Change 28.8.2 [re.regex.construct]: -

    - -
    template <class ForwardIterator InputIterator>
-  basic_regex(ForwardIterator InputIterator first, ForwardIterator InputIterator last, 
-              flag_type f = regex_constants::ECMAScript);
-
    - - - - - - -
    -

    634. allocator.address() doesn't work for types overloading operator&

    -

    Section: 20.7.5.1 [allocator.members] Status: WP - Submitter: Howard Hinnant Date: 2007-02-07

    -

    View all other issues in [allocator.members].

    -

    View all issues with WP status.

    -

    Duplicate of: 350

    -

    Discussion:

    - -

    -20.7.5.1 [allocator.members] says: -

    -
    -
    pointer address(reference x) const;
    -
    -

    --1- Returns: &x. -

    -
    -
    - -

    -20.7.5.1 [allocator.members] defines CopyConstructible which currently not -only defines the semantics of copy construction, but also restricts what an overloaded -operator& may do. I believe proposals are in the works (such as concepts -and rvalue reference) to decouple these two requirements. Indeed it is not evident -that we should disallow overloading operator& to return something other -than the address of *this. -

    - -

    -An example of when you want to overload operator& to return something -other than the object's address is proxy references such as vector<bool> -(or its replacement, currently code-named bit_vector). Taking the address of -such a proxy reference should logically yield a proxy pointer, which when dereferenced, -yields a copy of the original proxy reference again. -

    - -

    -On the other hand, some code truly needs the address of an object, and not a proxy -(typically for determining the identity of an object compared to a reference object). -boost has long recognized this dilemma and solved it with -boost::addressof. -It appears to me that this would be useful functionality for the default allocator. Adopting -this definition for allocator::address would free the standard of requiring -anything special from types which overload operator&. Issue 580 -is expected to make use of allocator::address mandatory for containers. -

    - - - -

    Proposed resolution:

    -

    -Change 20.7.5.1 [allocator.members]: -

    - -
    -
    pointer address(reference x) const;
    -
    -

    --1- Returns: &x. The actual address of object referenced by x, -even in the presence of an overloaded operator&. -

    -
    - -
    const_pointer address(address(const_reference x) const;
    -
    -

    --2- Returns: &x. The actual address of object referenced by x, -even in the presence of an overloaded operator&. -

    -
    -
    - -

    [ -post Oxford: This would be rendered NAD Editorial by acceptance of -N2257. -]

    - - -

    [ -Kona (2007): The LWG adopted the proposed resolution of N2387 for this issue which -was subsequently split out into a separate paper N2436 for the purposes of voting. -The resolution in N2436 addresses this issue. The LWG voted to accelerate this -issue to Ready status to be voted into the WP at Kona. -]

    - - - - - - - -
    -

    638. deque end invalidation during erase

    -

    Section: 23.2.2.3 [deque.modifiers] Status: WP - Submitter: Steve LoBasso Date: 2007-02-17

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -The standard states at 23.2.2.3 [deque.modifiers]/4: -

    -
    deque erase(...)
-
    -

    -Effects: ... An erase at either end of the deque invalidates only -the iterators and the references to the erased elements. -

    -
    -

    -This does not state that iterators to end will be invalidated. -It needs to be amended in such a way as to account for end invalidation. -

    -

    -Something like: -

    -

    -Any time the last element is erased, iterators to end are invalidated. -

    - -

    -This would handle situations like: -

    -
    erase(begin(), end())
-erase(end() - 1)
-pop_back()
-resize(n, ...) where n < size()
-pop_front() with size() == 1
-
-
    - -

    [ -Post Kona, Steve LoBasso notes: -]

    - - -
    -My only issue with the proposed resolution is that it might not be clear -that pop_front() [where size() == 1] can invalidate past-the-end -iterators. -
    - - - -

    Proposed resolution:

    -

    -Change 23.2.2.3 [deque.modifiers], p4: -

    - -
    -
    iterator erase(const_iterator position); 
-iterator erase(const_iterator first, const_iterator last);
-
    - -
    -

    --4- Effects: An erase in the middle of the deque -invalidates all the iterators and references to elements of the -deque and the past-the-end iterator. An erase at -either end of the deque invalidates only the iterators and the -references to the erased elements, except that erasing at the end -also invalidates the past-the-end iterator. -

    -
    -
    - - - -

    [ -Kona (2007): Proposed wording added and moved to Review. -]

    - - -

    [ -Bellevue: -]

    - - -
    -Note that there is existing code that relies on iterators not being -invalidated, but there are also existing implementations that do -invalidate iterators. Thus, such code is not portable in any case. There -is a pop_front() note, which should possibly be a separate issue. Mike -Spertus to evaluate and, if need be, file an issue. -
    - - - - -
    -

    640. 27.6.2.5.2 does not handle (unsigned) long long

    -

    Section: 27.6.2.6.2 [ostream.inserters.arithmetic] Status: WP - Submitter: Daniel Krügler Date: 2007-02-17

    -

    View all other issues in [ostream.inserters.arithmetic].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -The arithmetic inserters are described in 27.6.2.6.2 [ostream.inserters.arithmetic]. -Although the section starts with a listing of the inserters including -the new ones: -

    - -
    operator<<(long long val );
-operator<<(unsigned long long val );
-
    - -

    -the text in paragraph 1, which describes the corresponding effects -of the inserters, depending on the actual type of val, does not -handle the types long long and unsigned long long. -

    - -

    [ -Alisdair: In addition to the (unsigned) long long problem, that whole paragraph -misses any reference to extended integral types supplied by the -implementation - one of the additions by core a couple of working papers -back. -]

    - - - - -

    Proposed resolution:

    -

    -In 27.6.2.6.2 [ostream.inserters.arithmetic]/1 change the third sentence -

    - -
    -When val is of type bool, long, unsigned -long, long long, unsigned long long, double, -long double, or const void*, the formatting conversion -occurs as if it performed the following code fragment: -
    - - - - - -
    -

    643. Impossible "as if" clauses

    -

    Section: 27.8.1.1 [filebuf], 22.2.2.2.2 [facet.num.put.virtuals] Status: WP - Submitter: Daniel Krügler Date: 2007-02-20

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -The current standard 14882:2003(E) as well as N2134 have the -following -defects: -

    - -

    -27.8.1.1 [filebuf]/5 says: -

    - -
    -

    -In order to support file I/O and multibyte/wide character conversion, conversions are performed using members of a -facet, referred to as a_codecvt in following sections, obtained "as if" by -

    -
    codecvt<charT,char,typename traits::state_type> a_codecvt =
-  use_facet<codecvt<charT,char,typename traits::state_type> >(getloc());
-
    -
    - -

    -use_facet returns a const facet reference and no facet is -copyconstructible, so the codecvt construction should fail to compile. -

    - -

    -A similar issue arises in 22.2.2.2.2 [facet.num.put.virtuals]/15 for num_punct. -

    - - -

    Proposed resolution:

    -

    -In 27.8.1.1 [filebuf]/5 change the "as if" code -

    - -
    const codecvt<charT,char,typename traits::state_type>& a_codecvt =
-  use_facet<codecvt<charT,char,typename traits::state_type> >(getloc());
-
    - -

    -In 22.2.2.2.2 [facet.num.put.virtuals]/15 (This is para 5 in N2134) change -

    - -
    -

    -A local variable punct is initialized via -

    -
    const numpunct<charT>& punct = use_facet< numpunct<charT> >(str.getloc() );
-
    -
    - -

    -(Please note also the additional provided trailing semicolon) -

    - - - - - - -
    -

    646. const incorrect match_result members

    -

    Section: 28.10.4 [re.results.form] Status: WP - Submitter: Daniel Krügler Date: 2007-02-26

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -28.10.4 [re.results.form] (root and para 3) in N2134 defines the two function template -members format as non-const functions, although they are declared -as const in 28.10 [re.results]/3. -

    - - -

    Proposed resolution:

    -

    -Add the missing const specifier to both format overloads described -in section 28.10.4 [re.results.form]. -

    - - - - - -
    -

    650. regex_token_iterator and const correctness

    -

    Section: 28.12.2 [re.tokiter] Status: WP - Submitter: Daniel Krügler Date: 2007-03-05

    -

    View all other issues in [re.tokiter].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -Both the class definition of regex_token_iterator (28.12.2 -[re.tokiter]/6) and the latter member specifications (28.12.2.2 -[re.tokiter.comp]/1+2) declare both comparison operators as -non-const functions. Furtheron, both dereference operators are -unexpectedly also declared as non-const in 28.12.2 [re.tokiter]/6 -as well as in (28.12.2.3 [re.tokiter.deref]/1+2). -

    - - -

    Proposed resolution:

    -

    -1) In (28.12.2 [re.tokiter]/6) change the current declarations -

    - -
    bool operator==(const regex_token_iterator&) const;
-bool operator!=(const regex_token_iterator&) const;
-const value_type& operator*() const;
-const value_type* operator->() const;
-
    - -

    -2) In 28.12.2.2 [re.tokiter.comp] change the following declarations -

    - -
    bool operator==(const regex_token_iterator& right) const;
-bool operator!=(const regex_token_iterator& right) const;
-
    - -

    -3) In 28.12.2.3 [re.tokiter.deref] change the following declarations -

    - -
    const value_type& operator*() const;
-const value_type* operator->() const;
-
    - - -

    [ -Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue (which -is to adopt the proposed wording in this issue). -The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona. -]

    - - - - - -
    -

    651. Missing preconditions for regex_token_iterator c'tors

    -

    Section: 28.12.2.1 [re.tokiter.cnstr] Status: WP - Submitter: Daniel Krügler Date: 2007-03-05

    -

    View all other issues in [re.tokiter.cnstr].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -The text provided in 28.12.2.1 [re.tokiter.cnstr]/2+3 describes -the effects of the three non-default constructors of class -template regex_token_iterator but is does not clarify which values -are legal values for submatch/submatches. This becomes -an issue, if one takes 28.12.2 [re.tokiter]/9 into account, which explains -the notion of a "current match" by saying: -

    - -

    -The current match is (*position).prefix() if subs[N] -== -1, or (*position)[subs[N]] for any other value of -subs[N]. -

    - -

    -It's not clear to me, whether other negative values except -1 -are legal arguments or not - it seems they are not. -

    - - -

    Proposed resolution:

    -

    -Add the following precondition paragraph just before the current -28.12.2.1 [re.tokiter.cnstr]/2: -

    - -

    -Requires: Each of the initialization values of subs must be >= -1. -

    - - -

    [ -Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue (which -is to adopt the proposed wording in this issue). -The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona. -]

    - - - - - -
    -

    652. regex_iterator and const correctness

    -

    Section: 28.12.1 [re.regiter] Status: WP - Submitter: Daniel Krügler Date: 2007-03-05

    -

    View all issues with WP status.

    -

    Discussion:

    -

    Both the class definition of regex_iterator (28.12.1 [re.regiter]/1) -and the latter member specification (28.12.1.2 [re.regiter.comp]/1+2) -declare both comparison operators as -non-const functions. Furtheron, both dereference operators are -unexpectedly also declared as non-const in 28.12.1 [re.regiter]/1 -as well as in (28.12.1.3 [re.regiter.deref]/1+2). -

    - - -

    Proposed resolution:

    -

    -1) In (28.12.1 [re.regiter]/1) change the current declarations -

    - -
    bool operator==(const regex_iterator&) const;
-bool operator!=(const regex_iterator&) const;
-const value_type& operator*() const;
-const value_type* operator->() const;
-
    - -

    -2) In 28.12.1.3 [re.regiter.deref] change the following declarations -

    - -
    const value_type& operator*() const;
-const value_type* operator->() const;
-
    - -

    -3) In 28.12.1.2 [re.regiter.comp] change the following declarations -

    - -
    bool operator==(const regex_iterator& right) const;
-bool operator!=(const regex_iterator& right) const;
-
    - - -

    [ -Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue (which -is to adopt the proposed wording in this issue). -The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona. -]

    - - - - - -
    -

    654. Missing IO roundtrip for random number engines

    -

    Section: 26.4.1.3 [rand.req.eng] Status: WP - Submitter: Daniel Krügler Date: 2007-03-08

    -

    View all other issues in [rand.req.eng].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -Table 98 and para 5 in 26.4.1.3 [rand.req.eng] specify -the IO insertion and extraction semantic of random -number engines. It can be shown, v.i., that the specification -of the extractor cannot guarantee to fulfill the requirement -from para 5: -

    - -

    -If a textual representation written via os << x was -subsequently read via is >> v, then x == v provided that -there have been no intervening invocations of x or of v. -

    - -

    -The problem is, that the extraction process described in -table 98 misses to specify that it will initially set the -if.fmtflags to ios_base::dec, see table 104: -

    - -

    -dec: converts integer input or generates integer output -in decimal base -

    - -

    -Proof: The following small program demonstrates the violation -of requirements (exception safety not fulfilled): -

    - -
    #include <cassert>
-#include <ostream>
-#include <iostream>
-#include <iomanip>
-#include <sstream>
-
-class RanNumEngine {
-  int state;
-public:
-  RanNumEngine() : state(42) {}
-
-  bool operator==(RanNumEngine other) const {
-	  return state == other.state;
-  }
-
-  template <typename Ch, typename Tr>
-  friend std::basic_ostream<Ch, Tr>& operator<<(std::basic_ostream<Ch, Tr>& os, RanNumEngine engine) {
-	Ch old = os.fill(os.widen(' ')); // Sets space character
-	std::ios_base::fmtflags f = os.flags();
-	os << std::dec << std::left << engine.state; // Adds ios_base::dec|ios_base::left
-	os.fill(old); // Undo
-	os.flags(f);
-	return os;
-  }
-
-  template <typename Ch, typename Tr>
-  friend std::basic_istream<Ch, Tr>& operator>>(std::basic_istream<Ch, Tr>& is, RanNumEngine& engine) {
-       // Uncomment only for the fix.
-
-	//std::ios_base::fmtflags f = is.flags();
-	//is >> std::dec;
-	is >> engine.state;
-	//is.flags(f);
-	return is;
-  }
-};
-
-int main() {
-	std::stringstream s;
-	s << std::setfill('#'); // No problem
-        s << std::oct; // Yikes!
-        // Here starts para 5 requirements:
-	RanNumEngine x;
-	s << x;
-	RanNumEngine v;
-	s >> v;
-	assert(x == v); // Fails: 42 == 34
-}
-
    - -

    -A second, minor issue seems to be, that the insertion -description from table 98 unnecessarily requires the -addition of ios_base::fixed (which only influences floating-point -numbers). Its not entirely clear to me whether the proposed -standard does require that the state of random number engines -is stored in integral types or not, but I have the impression -that this is the indent, see e.g. p. 3 -

    - -

    -The specification of each random number engine defines the -size of its state in multiples of the size of its result_type. -

    - -

    -If other types than integrals are supported, then I wonder why -no requirements are specified for the precision of the stream. -

    - -

    -See N2391 and -N2423 -for some further discussion. -

    - - -

    Proposed resolution:

    -

    -Adopt the proposed resolution in -N2423. -

    - - -

    [ -Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue. -The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona. -]

    - - - - - -
    -

    655. Signature of generate_canonical not useful

    -

    Section: 26.4.7.2 [rand.util.canonical] Status: WP - Submitter: Daniel Krügler Date: 2007-03-08

    -

    View all other issues in [rand.util.canonical].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -In 26.4.2 [rand.synopsis] we have the declaration -

    - -
    template<class RealType, class UniformRandomNumberGenerator,
-  size_t bits>
-result_type generate_canonical(UniformRandomNumberGenerator& g);
-
    - -

    -Besides the "result_type" issue (already recognized by Bo Persson -at Sun, 11 Feb 2007 05:26:47 GMT in this group) it's clear, that -the template parameter order is not reasonably choosen: Obviously -one always needs to specify all three parameters, although usually -only two are required, namely the result type RealType and the -wanted bits, because UniformRandomNumberGenerator can usually -be deduced. -

    - -

    -See N2391 and -N2423 -for some further discussion. -

    - - -

    Proposed resolution:

    -

    -Adopt the proposed resolution in -N2423. -

    - - -

    [ -Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue. -The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona. -]

    - - - - - -
    -

    660. Missing Bitwise Operations

    -

    Section: 20.6 [function.objects] Status: WP - Submitter: Beman Dawes Date: 2007-04-02

    -

    View all other issues in [function.objects].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    Section 20.6 [function.objects] provides function -objects for some unary and binary -operations, but others are missing. In a LWG reflector discussion, beginning -with c++std-lib-18078, pros and cons of adding some of the missing operations -were discussed. Bjarne Stroustrup commented "Why standardize what isn't used? -Yes, I see the chicken and egg problems here, but it would be nice to see a -couple of genuine uses before making additions."

    -

    A number of libraries, including Rogue Wave, GNU, Adobe ASL, and Boost, have -already added these functions, either publicly or for internal use. For example, -Doug Gregor commented: "Boost will also add ... (|, &, ^) in 1.35.0, because we -need those function -objects to represent various parallel -collective operations (reductions, prefix reductions, etc.) in the new Message -Passing Interface (MPI) library."

    -

    Because the bitwise operators have the strongest use cases, the proposed -resolution is limited to them.

    - - -

    Proposed resolution:

    -

    To 20.6 [function.objects], Function objects, paragraph 2, add to the header -<functional> synopsis:

    -
    - 
    template <class T> struct bit_and;
-template <class T> struct bit_or;
-template <class T> struct bit_xor;
    -
    -

    At a location in clause 20 to be determined by the Project Editor, add:

    -
    -

    The library provides basic function object classes for all of the bitwise - operators in the language ([expr.bit.and], [expr.or], [exp.xor]).

    - 
    template <class T> struct bit_and : binary_function<T,T,T> {
-  T operator()(const T& x , const T& y ) const;
-};
    -
    -

    operator() returns x & y .

    -
    - 
    template <class T> struct bit_or : binary_function<T,T,T> {
-  T operator()(const T& x , const T& y ) const;
-};
    -
    -

    operator() returns x | y .

    -
    - 
    template <class T> struct bit_xor : binary_function<T,T,T> {
-  T operator()(const T& x , const T& y ) const;
-};
    -
    -

    operator() returns x ^ y .

    -
    -
    - - - - - -
    -

    661. New 27.6.1.2.2 changes make special extractions useless

    -

    Section: 27.6.1.2.2 [istream.formatted.arithmetic] Status: WP - Submitter: Daniel Krügler Date: 2007-04-01

    -

    View all other issues in [istream.formatted.arithmetic].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -To the more drastic changes of 27.6.1.2.2 [istream.formatted.arithmetic] in the current draft N2134 belong -the explicit description of the extraction of the types short and int in -terms of as-if code fragments. -

    - -
      -
    1. -The corresponding as-if extractions in paragraph 2 and 3 will never -result in a change of the operator>> argument val, because the -contents of the local variable lval is in no case written into val. -Furtheron both fragments need a currently missing parentheses in the -beginning of the if-statement to be valid C++. -
      2. -
    2. I would like to ask whether the omission of a similar explicit -extraction of unsigned short and unsigned int in terms of long - -compared to their corresponding new insertions, as described in -27.6.2.6.2 [ostream.inserters.arithmetic], is a deliberate decision or -an -oversight. -
      3. -
    - - -

    Proposed resolution:

    -
      -
    1. -

      -In 27.6.1.2.2 [istream.formatted.arithmetic]/2 change the current as-if code fragment -

      -
      typedef num_get<charT,istreambuf_iterator<charT,traits> > numget;
-iostate err = 0;
-long lval;
-use_facet<numget>(loc).get(*this, 0, *this, err, lval );
-if (err == 0) {
-  && if (lval < numeric_limits<short>::min() || numeric_limits<short>::max() < lval))
-      err = ios_base::failbit;
-  else
-    val = static_cast<short>(lval);
-}
-setstate(err);
-
      - -

      -Similarily in 27.6.1.2.2 [istream.formatted.arithmetic]/3 change the current as-if fragment -

      - -
      typedef num_get<charT,istreambuf_iterator<charT,traits> > numget;
-iostate err = 0;
-long lval;
-use_facet<numget>(loc).get(*this, 0, *this, err, lval );
-if (err == 0) {
-  && if (lval < numeric_limits<int>::min() || numeric_limits<int>::max() < lval))
-      err = ios_base::failbit;
-  else
-    val = static_cast<int>(lval);
-}
-setstate(err);
-
      -
      2. -
    2. ---- -
      3. -
    - - -

    [ -Kona (2007): Note to the editor: the name lval in the call to use_facet -is incorrectly italicized in the code fragments corresponding to -operator>>(short &) and operator >>(int &). Also, val -- which appears -twice on the line with the static_cast in the proposed resolution -- -should be italicized. Also, in response to part two of the issue: this -is deliberate. -]

    - - - - - -
    -

    664. do_unshift for codecvt<char, char, mbstate_t>

    -

    Section: 22.2.1.4.2 [locale.codecvt.virtuals] Status: WP - Submitter: Thomas Plum Date: 2007-04-16

    -

    View all other issues in [locale.codecvt.virtuals].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -22.2.1.4.2 [locale.codecvt.virtuals], para 7 says (regarding do_unshift): -

    - -

    -Effects: Places characters starting at to that should be appended to -terminate a sequence when the current stateT is given by -state.237) Stores no more than (to_limit - -to) destination elements, and leaves the to_next -pointer pointing one beyond the last element successfully stored. -codecvt<char, char, mbstate_t> stores no characters. -

    - -

    -The following objection has been raised: -

    - -

    -Since the C++ Standard permits a nontrivial conversion for the required -instantiations of codecvt, it is overly restrictive to say that -do_unshift must store no characters and return noconv. -

    - -

    -[Plum ref _222152Y50] -

    - - -

    Proposed resolution:

    -

    -Change 22.2.1.4.2 [locale.codecvt.virtuals], p7: -

    - -
    -

    -Effects: Places characters starting at to that should be -appended to terminate a sequence when the current stateT is -given by state.237) Stores no more than (to_limit -to) -destination elements, and leaves the to_next pointer pointing one -beyond the last element successfully stored. codecvt<char, char, -mbstate_t> stores no characters. -

    -
    - - - - - -
    -

    665. do_unshift return value

    -

    Section: 22.2.1.4.2 [locale.codecvt.virtuals] Status: WP - Submitter: Thomas Plum Date: 2007-04-16

    -

    View all other issues in [locale.codecvt.virtuals].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -22.2.1.4.2 [locale.codecvt.virtuals], para 8 says: -

    - -

    -codecvt<char,char,mbstate_t>, returns noconv. -

    - -

    -The following objection has been raised: -

    - -

    -Despite what the C++ Standard -says, unshift can't always return noconv for the default facets, since -they can be nontrivial. At least one implementation does whatever the -C functions do. -

    - -

    -[Plum ref _222152Y62] -

    - - -

    Proposed resolution:

    -

    -Change 22.2.1.4.2 [locale.codecvt.virtuals], p8: -

    - -
    -

    Returns: An enumeration value, as summarized in Table 76:

    -

    ...

    -

    -codecvt<char,char,mbstate_t>, returns noconv. -

    -
    - - - - - - -
    -

    666. moneypunct::do_curr_symbol()

    -

    Section: 22.2.6.3.2 [locale.moneypunct.virtuals] Status: WP - Submitter: Thomas Plum Date: 2007-04-16

    -

    View all other issues in [locale.moneypunct.virtuals].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -22.2.6.3.2 [locale.moneypunct.virtuals], para 4 footnote 257 says -

    - -

    -257) For international -specializations (second template parameter true) this is always four -characters long, usually three letters and a space. -

    - -

    -The following objection has been raised: -

    - -

    -The international currency -symbol is whatever the underlying locale says it is, not necessarily -four characters long. -

    - -

    -[Plum ref _222632Y41] -

    - - -

    Proposed resolution:

    -

    -Change footnote 253 in 22.2.6.3.2 [locale.moneypunct.virtuals]: -

    - -
    -

    -253) For international specializations (second template -parameter true) this is always typically -four characters long, usually three letters and a space. -

    -
    - - - - - -
    -

    672. Swappable requirements need updating

    -

    Section: 20.1.1 [utility.arg.requirements] Status: WP - Submitter: Howard Hinnant Date: 2007-05-04

    -

    View other active issues in [utility.arg.requirements].

    -

    View all other issues in [utility.arg.requirements].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -The current Swappable is: -

    - -
    - - - - - -
    Table 37: Swappable requirements [swappable]
    expressionreturn typepost-condition
    swap(s,t)voidt has the value originally held by u, and u has the value originally -held by t
    -

    -The Swappable requirement is met by satisfying one or more of the following conditions: -

    -
      -
    • -T is Swappable if T satisfies the CopyConstructible requirements (Table 34) -and the CopyAssignable requirements (Table 36); -
      • -
    • -T is Swappable if a namespace scope function named swap exists in the same -namespace as the definition of T, such that the expression swap(t,u) is valid -and has the semantics described in this table. -
      • -
    -
    -
    - -

    -With the passage of rvalue reference into the language, Swappable needs to be updated to -require only MoveConstructible and MoveAssignable. This is a minimum. -

    - -

    -Additionally we may want to support proxy references such that the following code is acceptable: -

    - -
    namespace Mine {
-
-template <class T>
-struct proxy {...};
-
-template <class T>
-struct proxied_iterator
-{
-   typedef T value_type;
-   typedef proxy<T> reference;
-   reference operator*() const;
-   ...
-};
-
-struct A
-{
-   // heavy type, has an optimized swap, maybe isn't even copyable or movable, just swappable
-   void swap(A&);
-   ...
-};
-
-void swap(A&, A&);
-void swap(proxy<A>, A&);
-void swap(A&, proxy<A>);
-void swap(proxy<A>, proxy<A>);
-
-}  // Mine
-
-...
-
-Mine::proxied_iterator<Mine::A> i(...)
-Mine::A a;
-swap(*i1, a);
-
    - -

    -I.e. here is a call to swap which the user enables swapping between a proxy to a class and the class -itself. We do not need to anything in terms of implementation except not block their way with overly -constrained concepts. That is, the Swappable concept should be expanded to allow swapping -between two different types for the case that one is binding to a user-defined swap. -

    - - - -

    Proposed resolution:

    - -

    -Change 20.1.1 [utility.arg.requirements]: -

    - -
    - -

    --1- The template definitions in the C++ Standard Library refer to various -named requirements whose details are set out in tables 31-38. In these -tables, T is a type to be supplied by a C++ program -instantiating a template; a, b, and c are -values of type const T; s and t are modifiable -lvalues of type T; u is a value of type (possibly -const) T; and rv is a non-const -rvalue of type T. -

    - - - - - - - -
    Table 37: Swappable requirements [swappable]
    expressionreturn typepost-condition
    swap(s,t)voidt has the value originally -held by u, and -u has the value originally held -by t
    -

    -The Swappable requirement is met by satisfying one or more of the following conditions: -

    -
      -
    • -T is Swappable if T satisfies the -CopyConstructible MoveConstructible -requirements (Table 34 33) and the CopyAssignable MoveAssignable -requirements (Table 36 35); -
      • -
    • -T is Swappable if a namespace scope function named -swap exists in the same namespace as the definition of -T, such that the expression -swap(t,u) is valid and has the -semantics described in this table. -
      • -
    -
    -
    - - - -

    [ -Kona (2007): We like the change to the Swappable requirements to use -move semantics. The issue relating to the support of proxies is -separable from the one relating to move semantics, and it's bigger than -just swap. We'd like to address only the move semantics changes under -this issue, and open a separated issue (742) to handle proxies. Also, there -may be a third issue, in that the current definition of Swappable does -not permit rvalues to be operands to a swap operation, and Howard's -proposed resolution would allow the right-most operand to be an rvalue, -but it would not allow the left-most operand to be an rvalue (some swap -functions in the library have been overloaded to permit left operands to -swap to be rvalues). -]

    - - - - - -
    -

    673. unique_ptr update

    -

    Section: 20.7.11 [unique.ptr] Status: WP - Submitter: Howard Hinnant Date: 2007-05-04

    -

    View all other issues in [unique.ptr].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -Since the publication of -N1856 -there have been a few small but significant advances which should be included into -unique_ptr. There exists a -example implmenation -for all of these changes. -

    - -
      - -
    • -

      -Even though unique_ptr<void> is not a valid use case (unlike for shared_ptr<void>), -unexpected cases to crop up which require the instantiation of the interface of unique_ptr<void> -even if it is never used. For example see -LWG 541 for how this accidently -happened to auto_ptr. I believe the most robust way to protect unique_ptr against this -type of failure is to augment the return type of unique_ptr<T>:operator*() with -add_lvalue_reference<T>::type. This means that given an instantiated unique_ptr<void> -the act of dereferencing it will simply return void instead of causing a compile time failure. -This is simpler than creating a unique_ptr<void> specialization which isn't robust in the -face of cv-qualified void types. -

      - -

      -This resolution also supports instantiations such as unique_ptr<void, free_deleter> -which could be very useful to the client. -

      - -
      • - -
    • -

      -Efforts have been made to better support containers and smart pointers in shared -memory contexts. One of the key hurdles in such support is not assuming that a -pointer type is actually a T*. This can easily be accomplished -for unique_ptr by having the deleter define the pointer type: -D::pointer. Furthermore this type can easily be defaulted to -T* should the deleter D choose not to define a pointer -type (example implementation -here). -This change has no run time overhead. It has no interface overhead on -authors of custom delter types. It simply allows (but not requires) -authors of custom deleter types to define a smart pointer for the -storage type of unique_ptr if they find such functionality -useful. std::default_delete is an example of a deleter which -defaults pointer to T* by simply ignoring this issue -and not including a pointer typedef. -

      -
      • - -
    • -

      -When the deleter type is a function pointer then it is unsafe to construct -a unique_ptr without specifying the function pointer in the constructor. -This case is easy to check for with a static_assert assuring that the -deleter is not a pointer type in those constructors which do not accept deleters. -

      - -
      unique_ptr<A, void(*)(void*)> p(new A);  // error, no function given to delete the pointer!
-
      - -
      • - -
    - -

    [ -Kona (2007): We don't like the solution given to the first bullet in -light of concepts. The second bullet solves the problem of supporting -fancy pointers for one library component only. The full LWG needs to -decide whether to solve the problem of supporting fancy pointers -piecemeal, or whether a paper addressing the whole library is needed. We -think that the third bullet is correct. -]

    - - -

    [ -Post Kona: Howard adds example user code related to the first bullet: -]

    - - -
    -
    void legacy_code(void*, std::size_t);
-
-void foo(std::size_t N)
-{
-    std::unique_ptr<void, void(*)(void*)> ptr(std::malloc(N), std::free);
-    legacy_code(ptr.get(), N);
-}   // unique_ptr used for exception safety purposes
-
    -
    - -

    -I.e. unique_ptr<void> is a useful tool that we don't want -to disable with concepts. The only part of unique_ptr<void> we -want to disable (with concepts or by other means) are the two member functions: -

    - -
    T& operator*() const;
-T* operator->() const;
-
    - - - -

    Proposed resolution:

    - -

    [ -I am grateful for the generous aid of Peter Dimov and Ion Gaztañaga in helping formulate and review -the proposed resolutions below. -]

    - - -
      -
    • - -

      -Change 20.7.11.2 [unique.ptr.single]: -

      - -
      template <class T, class D = default_delete<T>> class unique_ptr {
-   ...
-   T& typename add_lvalue_reference<T>::type operator*() const;
-   ...
-};
-
      - -

      -Change 20.7.11.2.4 [unique.ptr.single.observers]: -

      - -
      T& typename add_lvalue_reference<T>::type operator*() const;
-
      - -
      • - -
    • -

      -Change 20.7.11.2 [unique.ptr.single]: -

      - -
      template <class T, class D = default_delete<T>> class unique_ptr {
-public:
-  typedef implementation (see description below) pointer;
-   ...
-   explicit unique_ptr(T* pointer p);
-   ...
-   unique_ptr(T* pointer p, implementation defined (see description below) d);
-   unique_ptr(T* pointer p, implementation defined (see description below) d);
-   ...
-   T* pointer operator->() const;
-   T* pointer get() const;
-   ...
-   T* pointer release();
-   void reset(T* pointer p = 0 pointer());
-};
-
      - -

      - --3- If the type remove_reference<D>::type::pointer -exists, then unique_ptr<T, D>::pointer is a typedef to -remove_reference<D>::type::pointer. Otherwise -unique_ptr<T, D>::pointer is a typedef to T*. -The type unique_ptr<T, D>::pointer shall be CopyConstructible -and CopyAssignable. - -

      - -

      -Change 20.7.11.2.1 [unique.ptr.single.ctor]: -

      - -
      unique_ptr(T* pointer p);
-...
-unique_ptr(T* pointer p, implementation defined d); 
-unique_ptr(T* pointer p, implementation defined d); 
-...
-unique_ptr(T* pointer p, const A& d);
-unique_ptr(T* pointer p, A&& d);
-...
-unique_ptr(T* pointer p, A& d); 
-unique_ptr(T* pointer p, A&& d);
-...
-unique_ptr(T* pointer p, const A& d); 
-unique_ptr(T* pointer p, const A&& d);
-...
-
      - -

      --23- Requires: If D is not a reference type, -construction of the deleter D from an rvalue of type E -must shall be well formed and not throw an exception. If D is a -reference type, then E must shall be the same type as D -(diagnostic required). U* unique_ptr<U,E>::pointer -must shall be implicitly convertible to T* -pointer. -

      - -

      --25- Postconditions: get() == value u.get() had before -the construction, modulo any required offset adjustments resulting from -the cast from U* -unique_ptr<U,E>::pointer to T* -pointer. get_deleter() returns a reference to the -internally stored deleter which was constructed from -u.get_deleter(). -

      - -

      -Change 20.7.11.2.3 [unique.ptr.single.asgn]: -

      - -
      -

      --8- Requires: Assignment of the deleter D from an rvalue -D must shall not throw an exception. U* -unique_ptr<U,E>::pointer must shall be implicitly -convertible to T* pointer. -

      -
      - -

      -Change 20.7.11.2.4 [unique.ptr.single.observers]: -

      - -
      -
      T* pointer operator->() const;
      -... -
      T* pointer get() const;
      -
      - -

      -Change 20.7.11.2.5 [unique.ptr.single.modifiers]: -

      - -
      -
      T* pointer release();
      -... -
      void reset(T* pointer p = 0 pointer());
      -
      - -

      -Change 20.7.11.3 [unique.ptr.runtime]: -

      - -
      template <class T, class D> class unique_ptr<T[], D> {
-public:
-  typedef implementation pointer;
-   ...
-   explicit unique_ptr(T* pointer p);
-   ...
-   unique_ptr(T* pointer p, implementation defined d);
-   unique_ptr(T* pointer p, implementation defined d);
-   ...
-   T* pointer get() const;
-   ...
-   T* pointer release();
-   void reset(T* pointer p = 0 pointer());
-};
-
      - -

      -Change 20.7.11.3.1 [unique.ptr.runtime.ctor]: -

      - -
      -
      unique_ptr(T* pointer p);
-unique_ptr(T* pointer p, implementation defined d);
-unique_ptr(T* pointer p, implementation defined d);
-
      - -

      -These constructors behave the same as in the primary template except -that they do not accept pointer types which are convertible to -T* pointer. [Note: One -implementation technique is to create private templated overloads of -these members. -- end note] -

      -
      - -

      -Change 20.7.11.3.3 [unique.ptr.runtime.modifiers]: -

      - -
      -
      void reset(T* pointer p = 0 pointer());
-
      - -

      --1- Requires: Does not accept pointer types which are convertible -to T* pointer (diagnostic -required). [Note: One implementation technique is to create a private -templated overload. -- end note] -

      -
      - -
      • - -
    • - -

      -Change 20.7.11.2.1 [unique.ptr.single.ctor]: -

      - -
      -
      unique_ptr();
      -
      -

      -Requires: D must shall be default constructible, and that -construction must shall not throw an exception. D must shall not be a -reference type or pointer type (diagnostic required). -

      -
      -
      unique_ptr(T* pointer p);
      -
      -

      -Requires: The expression D()(p) must shall be well formed. -The default constructor of D must shall not throw an exception. -D must shall not be a reference type or pointer type (diagnostic -required). -

      -
      -
      - -
      • - -
    - - - - - - -
    -

    674. shared_ptr interface changes for consistency with N1856

    -

    Section: 20.7.12.2 [util.smartptr.shared] Status: WP - Submitter: Peter Dimov Date: 2007-05-05

    -

    View other active issues in [util.smartptr.shared].

    -

    View all other issues in [util.smartptr.shared].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -N1856 does not propose -any changes to shared_ptr. It needs to be updated to use a rvalue reference where appropriate -and to interoperate with unique_ptr as it does with auto_ptr. -

    - - -

    Proposed resolution:

    - -

    -Change 20.7.12.2 [util.smartptr.shared] as follows: -

    - -
    -
    template<class Y> explicit shared_ptr(auto_ptr<Y>&&& r);
-template<class Y, class D> explicit shared_ptr(const unique_ptr<Y,D>& r) = delete;
-template<class Y, class D> explicit shared_ptr(unique_ptr<Y,D>&& r);
-...
-template<class Y> shared_ptr& operator=(auto_ptr<Y>&&& r);
-template<class Y, class D> shared_ptr& operator=(const unique_ptr<Y,D>& r) = delete;
-template<class Y, class D> shared_ptr& operator=(unique_ptr<Y,D>&& r);
    -
    - -

    -Change 20.7.12.2.1 [util.smartptr.shared.const] as follows: -

    - -
    -
    template<class Y> shared_ptr(auto_ptr<Y>&&& r);
    -
    - -

    -Add to 20.7.12.2.1 [util.smartptr.shared.const]: -

    - -
    -
    template<class Y, class D> shared_ptr(unique_ptr<Y, D>&& r);
    -
    - -

    -Effects: Equivalent to shared_ptr( r.release(), r.get_deleter() ) when D is - not a reference type, shared_ptr( r.release(), ref( r.get_deleter() ) ) - otherwise. -

    - -

    -Exception safety: If an exception is thrown, the constructor has no effect. -

    -
    - -
    - -

    -Change 20.7.12.2.3 [util.smartptr.shared.assign] as follows: -

    - -
    -
    template<class Y> shared_ptr& operator=(auto_ptr<Y>&&& r);
    -
    - -

    -Add to 20.7.12.2.3 [util.smartptr.shared.assign]: -

    - -
    -
    template<class Y, class D> shared_ptr& operator=(unique_ptr<Y,D>&& r);
    - -
    -

    --4- Effects: Equivalent to shared_ptr(std::move(r)).swap(*this). -

    -

    --5- Returns: *this. -

    -
    - -
    - - - -

    [ -Kona (2007): We may need to open an issue (743) to deal with the question of -whether shared_ptr needs an rvalue swap. -]

    - - - - - -
    -

    677. Weaknesses in seed_seq::randomize [rand.util.seedseq]

    -

    Section: 26.4.7.1 [rand.util.seedseq] Status: WP - Submitter: Charles Karney Date: 2007-05-15

    -

    View other active issues in [rand.util.seedseq].

    -

    View all other issues in [rand.util.seedseq].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -seed_seq::randomize provides a mechanism for initializing random number -engines which ideally would yield "distant" states when given "close" -seeds. The algorithm for seed_seq::randomize given in the current -Working Draft for C++, -N2284 -(2007-05-08), has 3 weaknesses -

    - -
      -
    1. -

      Collisions in state. Because of the way the state is initialized, - seeds of different lengths may result in the same state. The - current version of seed_seq has the following properties:

      -
        -
      • For a given s <= n, each of the 2^(32s) seed vectors results in a - distinct state.
        • -
      -

      - The proposed algorithm (below) has the considerably stronger - properties:

      -
        -
      • All of the (2^(32n)-1)/(2^32-1) seed vectors of lengths s < n - result in distinct states. -
        • -
      • All of the 2^(32n) seed vectors of length s == n result in - distinct states. -
        • -
      -
      2. -
    2. -

      Poor mixing of v's entropy into the state. Consider v.size() == n - and hold v[n/2] thru v[n-1] fixed while varying v[0] thru v[n/2-1], - a total of 2^(16n) possibilities. Because of the simple recursion - used in seed_seq, begin[n/2] thru begin[n-1] can take on only 2^64 - possible states.

      - -

      The proposed algorithm uses a more complex recursion which results - in much better mixing.

      -
      3. -
    3. seed_seq::randomize is undefined for v.size() == 0. The proposed - algorithm remedies this. -
      4. -
    -

    -The current algorithm for seed_seq::randomize is adapted by me from the -initialization procedure for the Mersenne Twister by Makoto Matsumoto -and Takuji Nishimura. The weakness (2) given above was communicated to -me by Matsumoto last year. -

    -

    -The proposed replacement for seed_seq::randomize is due to Mutsuo Saito, -a student of Matsumoto, and is given in the implementation of the -SIMD-oriented Fast Mersenne Twister random number generator SFMT. -http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/index.html -http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/SFMT-src-1.2.tar.gz -

    -

    -See -Mutsuo Saito, -An Application of Finite Field: Design and Implementation of 128-bit -Instruction-Based Fast Pseudorandom Number Generator, -Master's Thesis, Dept. of Math., Hiroshima University (Feb. 2007) -http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/M062821.pdf -

    -

    -One change has been made here, namely to treat the case of small n -(setting t = (n-1)/2 for n < 7). -

    -

    -Since seed_seq was introduced relatively recently there is little cost -in making this incompatible improvement to it. -

    - -

    -See N2391 and -N2423 -for some further discussion. -

    - - -

    Proposed resolution:

    -

    -Adopt the proposed resolution in -N2423. -

    - - -

    [ -Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue. -The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona. -]

    - - - - - -
    -

    678. Changes for [rand.req.eng]

    -

    Section: 26.4.1.3 [rand.req.eng] Status: WP - Submitter: Charles Karney Date: 2007-05-15

    -

    View all other issues in [rand.req.eng].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -Section 26.4.1.3 [rand.req.eng] Random number engine requirements: -

    - -

    -This change follows naturally from the proposed change to -seed_seq::randomize in 677. -

    - -

    -In table 104 the description of X(q) contains a special treatment of -the case q.size() == 0. This is undesirable for 4 reasons: -

    - -
      -
    1. It replicates the functionality provided by X().
      2. -
    2. It leads to the possibility of a collision in the state provided - by some other X(q) with q.size() > 0.
      3. -
    3. It is inconsistent with the description of the X(q) in -paragraphs 26.4.3.1 [rand.eng.lcong] p5, 26.4.3.2 [rand.eng.mers] p8, and 26.4.3.3 [rand.eng.sub] p10 where -there is no special treatment of q.size() == 0.
      4. -
    4. The proposed replacement for seed_seq::randomize given above - allows for the case q.size() == 0.
      5. -
    - -

    -See N2391 and -N2423 -for some further discussion. -

    - - -

    Proposed resolution:

    -

    -Adopt the proposed resolution in -N2423. -

    - - -

    [ -Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue. -The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona. -]

    - - - - - -
    -

    679. resize parameter by value

    -

    Section: 23.2 [sequences] Status: WP - Submitter: Howard Hinnant Date: 2007-06-11

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -The C++98 standard specifies that one member function alone of the containers -passes its parameter (T) by value instead of by const reference: -

    - -
    void resize(size_type sz, T c = T());
-
    - -

    -This fact has been discussed / debated repeatedly over the years, the first time -being even before C++98 was ratified. The rationale for passing this parameter by -value has been: -

    - -
    -

    -So that self referencing statements are guaranteed to work, for example: -

    -
    v.resize(v.size() + 1, v[0]);
-
    -
    - -

    -However this rationale is not convincing as the signature for push_back is: -

    - -
    void push_back(const T& x);
-
    - -

    -And push_back has similar semantics to resize (append). -And push_back must also work in the self referencing case: -

    - -
    v.push_back(v[0]);  // must work
-
    - -

    -The problem with passing T by value is that it can be significantly more -expensive than passing by reference. The converse is also true, however when it is -true it is usually far less dramatic (e.g. for scalar types). -

    - -

    -Even with move semantics available, passing this parameter by value can be expensive. -Consider for example vector<vector<int>>: -

    - -
    std::vector<int> x(1000);
-std::vector<std::vector<int>> v;
-...
-v.resize(v.size()+1, x);
-
    - -

    -In the pass-by-value case, x is copied once to the parameter of -resize. And then internally, since the code can not know at compile -time by how much resize is growing the vector, x is -usually copied (not moved) a second time from resize's parameter into its proper place -within the vector. -

    - -

    -With pass-by-const-reference, the x in the above example need be copied -only once. In this case, x has an expensive copy constructor and so any -copies that can be saved represents a significant savings. -

    - -

    -If we can be efficient for push_back, we should be efficient for resize -as well. The resize taking a reference parameter has been coded and shipped in the -CodeWarrior library with no reports of problems which I am aware of. -

    - - - -

    Proposed resolution:

    -

    -Change 23.2.2 [deque], p2: -

    - -
    class deque {
-   ...
-   void resize(size_type sz, const T& c);
-
    - -

    -Change 23.2.2.2 [deque.capacity], p3: -

    - -
    void resize(size_type sz, const T& c);
-
    - -

    -Change 23.2.4 [list], p2: -

    - -
    class list {
-   ...
-   void resize(size_type sz, const T& c);
-
    - -

    -Change 23.2.4.2 [list.capacity], p3: -

    - -
    void resize(size_type sz, const T& c);
-
    - -

    -Change 23.2.6 [vector], p2: -

    - -
    class vector {
-   ...
-   void resize(size_type sz, const T& c);
-
    - -

    -Change 23.2.6.2 [vector.capacity], p11: -

    - -
    void resize(size_type sz, const T& c);
-
    - - - - - - -
    -

    680. move_iterator operator-> return

    -

    Section: 24.4.3.1 [move.iterator] Status: WP - Submitter: Howard Hinnant Date: 2007-06-11

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -move_iterator's operator-> return type pointer -does not consistently match the type which is returned in the description -in 24.4.3.3.5 [move.iter.op.ref]. -

    - -
    template <class Iterator>
-class move_iterator {
-public:
-    ...
-    typedef typename iterator_traits<Iterator>::pointer pointer;
-    ...
-    pointer operator->() const {return current;}
-    ...
-private: 
-    Iterator current; // exposition only
-};
-
    - - -

    -There are two possible fixes. -

    - -
      -
    1. pointer operator->() const {return &*current;}
      2. -
    2. typedef Iterator pointer;
      3. -
    - -

    -The first solution is the one chosen by reverse_iterator. A potential -disadvantage of this is it may not work well with iterators which return a -proxy on dereference and that proxy has overloaded operator&(). Proxy -references often need to overloaad operator&() to return a proxy -pointer. That proxy pointer may or may not be the same type as the iterator's -pointer type. -

    - -

    -By simply returning the Iterator and taking advantage of the fact that -the language forwards calls to operator-> automatically until it -finds a non-class type, the second solution avoids the issue of an overloaded -operator&() entirely. -

    - -

    Proposed resolution:

    -

    -Change the synopsis in 24.4.3.1 [move.iterator]: -

    - -
    typedef typename iterator_traits<Iterator>::pointer pointer;
-
    - - - - - - -
    -

    681. Operator functions impossible to compare are defined in [re.submatch.op]

    -

    Section: 28.9.2 [re.submatch.op] Status: WP - Submitter: Nozomu Katoo Date: 2007-05-27

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -In 28.9.2 [re.submatch.op] of N2284, -operator functions numbered 31-42 seem impossible to compare.  E.g.: -

    - -
    -
    template <class BiIter>
-    bool operator==(typename iterator_traits<BiIter>::value_type const& lhs,
-                    const sub_match<BiIter>& rhs);
-
    -
    -

    --31- Returns: lhs == rhs.str(). -

    -
    -
    - -

    -When char* is used as BiIter, iterator_traits<BiIter>::value_type would be -char, so that lhs == rhs.str() ends up comparing a char value and an object -of std::basic_string<char>.  However, the behaviour of comparison between -these two types is not defined in 21.3.8 [string.nonmembers] of N2284. - This applies when wchar_t* is used as BiIter. -

    - - -

    Proposed resolution:

    -

    -Adopt the proposed resolution in -N2409. -

    - - -

    [ -Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue. -The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona. -]

    - - - - - -
    -

    682. basic_regex ctor takes InputIterator or ForwardIterator?

    -

    Section: 28.8.2 [re.regex.construct] Status: WP - Submitter: Eric Niebler Date: 2007-06-03

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -Looking at N2284, 28.8 [re.regex], p3 basic_regex class template synopsis shows this -constructor: -

    -
    template <class InputIterator>
-     basic_regex(InputIterator first, InputIterator last, 
-                 flag_type f = regex_constants::ECMAScript);
-
    - -

    -In 28.8.2 [re.regex.construct], p15, the constructor appears with this signature: -

    - -
    template <class ForwardIterator>
-     basic_regex(ForwardIterator first, ForwardIterator last, 
-                 flag_type f = regex_constants::ECMAScript);
-
    - -

    -ForwardIterator is probably correct, so the synopsis is wrong. -

    - -

    [ -John adds: -]

    - - -
    -

    -I think either could be implemented?  Although an input iterator would -probably require an internal copy of the string being made. -

    -

    -I have no strong feelings either way, although I think my original intent -was InputIterator. -

    -
    - - -

    Proposed resolution:

    -

    -Adopt the proposed resolution in -N2409. -

    - - -

    [ -Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue. -The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona. -]

    - - - - - -
    -

    685. reverse_iterator/move_iterator difference has invalid signatures

    -

    Section: 24.4.1.3.19 [reverse.iter.opdiff], 24.4.3.3.14 [move.iter.nonmember] Status: WP - Submitter: Bo Persson Date: 2007-06-10

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -In C++03 the difference between two reverse_iterators -

    -
    ri1 - ri2
-
    -

    -is possible to compute only if both iterators have the same base -iterator. The result type is the difference_type of the base iterator. -

    -

    -In the current draft, the operator is defined as 24.4.1.3.19 [reverse.iter.opdiff] -

    -
    template<class Iterator1, class Iterator2> 
-typename reverse_iterator<Iterator>::difference_type 
-   operator-(const reverse_iterator<Iterator1>& x, 
-                    const reverse_iterator<Iterator2>& y);
-
    -

    -The return type is the same as the C++03 one, based on the no longer -present Iterator template parameter. -

    -

    -Besides being slightly invalid, should this operator work only when -Iterator1 and Iterator2 has the same difference_type? Or should the -implementation choose one of them? Which one? -

    -

    -The same problem now also appears in operator-() for move_iterator -24.4.3.3.14 [move.iter.nonmember]. -

    - - -

    Proposed resolution:

    -

    -Change the synopsis in 24.4.1.1 [reverse.iterator]: -

    - -
    -
    template <class Iterator1, class Iterator2> 
-  typename reverse_iterator<Iterator>::difference_type auto operator-( 
-    const reverse_iterator<Iterator1>& x, 
-    const reverse_iterator<Iterator2>& y) -> decltype(y.current - x.current);
-
    -
    - -

    -Change 24.4.1.3.19 [reverse.iter.opdiff]: -

    - -
    -
    template <class Iterator1, class Iterator2> 
-  typename reverse_iterator<Iterator>::difference_type auto operator-( 
-    const reverse_iterator<Iterator1>& x, 
-    const reverse_iterator<Iterator2>& y) -> decltype(y.current - x.current);
-
    -
    -

    -Returns: y.current - x.current. -

    -
    -
    - - -

    -Change the synopsis in 24.4.3.1 [move.iterator]: -

    - -
    -
    template <class Iterator1, class Iterator2> 
-  typename move_iterator<Iterator>::difference_type auto operator-( 
-    const move_iterator<Iterator1>& x, 
-    const move_iterator<Iterator2>& y) -> decltype(x.base() - y.base());
-
    -
    - -

    -Change 24.4.3.3.14 [move.iter.nonmember]: -

    - -
    -
    template <class Iterator1, class Iterator2> 
-  typename move_iterator<Iterator>::difference_type auto operator-( 
-    const move_iterator<Iterator1>& x, 
-    const move_iterator<Iterator2>& y) -> decltype(x.base() - y.base());
-
    -
    -

    -Returns: x.base() - y.base(). -

    -
    -
    - -

    [ -Pre Bellevue: This issue needs to wait until the auto -> return language feature -goes in. -]

    - - - - - - - -
    -

    687. shared_ptr conversion constructor not constrained

    -

    Section: 20.7.12.2.1 [util.smartptr.shared.const], 20.7.12.3.1 [util.smartptr.weak.const] Status: WP - Submitter: Peter Dimov Date: 2007-05-10

    -

    View all other issues in [util.smartptr.shared.const].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -Since all conversions from shared_ptr<T> to shared_ptr<U> have the same -rank regardless of the relationship between T and U, reasonable user -code that works with raw pointers fails with shared_ptr: -

    - -
    void f( shared_ptr<void> );
-void f( shared_ptr<int> );
-
-int main()
-{
-  f( shared_ptr<double>() ); // ambiguous
-}
-
    - -

    -Now that we officially have enable_if, we can constrain the constructor -and the corresponding assignment operator to only participate in the -overload resolution when the pointer types are compatible. -

    - - -

    Proposed resolution:

    -

    -In 20.7.12.2.1 [util.smartptr.shared.const], change: -

    - -

    --14- Requires: For the second constructor The -second constructor shall not participate in the overload resolution -unless Y* shall be is implicitly convertible -to T*. -

    - -

    -In 20.7.12.3.1 [util.smartptr.weak.const], change: -

    - -
    -
    template<class Y> weak_ptr(shared_ptr<Y> const& r);
-weak_ptr(weak_ptr const& r);
-template<class Y> weak_ptr(weak_ptr<Y> const& r);
-weak_ptr(weak_ptr const& r);
-template<class Y> weak_ptr(weak_ptr<Y> const& r);
-template<class Y> weak_ptr(shared_ptr<Y> const& r);
-
    -

    --4- Requires: For tThe second and -third constructors, shall not participate in the -overload resolution unless Y* shall be -is implicitly convertible to T*. -

    -
    - - - - - - -
    -

    689. reference_wrapper constructor overly constrained

    -

    Section: 20.6.5.1 [refwrap.const] Status: WP - Submitter: Peter Dimov Date: 2007-05-10

    -

    View all other issues in [refwrap.const].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -The constructor of reference_wrapper is currently explicit. The primary -motivation behind this is the safety problem with respect to rvalues, -which is addressed by the proposed resolution of the previous issue. -Therefore we should consider relaxing the requirements on the -constructor since requests for the implicit conversion keep resurfacing. -

    -

    -Also please see the thread starting at c++std-lib-17398 for some good discussion on this subject. -

    - - -

    Proposed resolution:

    -

    -Remove the explicit from the constructor of reference_wrapper. If the -proposed resolution of the previous issue is accepted, remove the -explicit from the T&& constructor as well to keep them in sync. -

    - - - - - -
    -

    693. std::bitset::all() missing

    -

    Section: 23.3.5 [template.bitset] Status: WP - Submitter: Martin Sebor Date: 2007-06-22

    -

    View all other issues in [template.bitset].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -The bitset class template provides the member function -any() to determine whether an object of the type has any -bits set, and the member function none() to determine -whether all of an object's bits are clear. However, the template does -not provide a corresponding function to discover whether a -bitset object has all its bits set. While it is -possible, even easy, to obtain this information by comparing the -result of count() with the result of size() -for equality (i.e., via b.count() == b.size()) the -operation is less efficient than a member function designed -specifically for that purpose could be. (count() must -count all non-zero bits in a bitset a word at a time -while all() could stop counting as soon as it encountered -the first word with a zero bit). -

    - - -

    Proposed resolution:

    -

    -Add a declaration of the new member function all() to the -defintion of the bitset template in 23.3.5 [template.bitset], p1, -right above the declaration of any() as shown below: -

    - -
    bool operator!=(const bitset<N>& rhs) const;
-bool test(size_t pos) const;
-bool all() const;
-bool any() const;
-bool none() const;
-
    - -

    -Add a description of the new member function to the end of 23.3.5.2 [bitset.members] with the following text: -

    -

    -bool all() const; -

    -
    -Returns: count() == size(). -
    -
    - -

    -In addition, change the description of any() and -none() for consistency with all() as -follows: -

    -

    -bool any() const; -

    -
    -

    -Returns: true if any bit in *this -is onecount() != 0. -

    -
    -

    -bool none() const; -

    -
    -

    -Returns: true if no bit in *this -is onecount() == 0. -

    -
    -
    - - - - - -
    -

    694. std::bitset and long long

    -

    Section: 23.3.5 [template.bitset] Status: WP - Submitter: Martin Sebor Date: 2007-06-22

    -

    View all other issues in [template.bitset].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -Objects of the bitset class template specializations can -be constructed from and explicitly converted to values of the widest -C++ integer type, unsigned long. With the introduction -of long long into the language the template should be -enhanced to make it possible to interoperate with values of this type -as well, or perhaps uintmax_t. See c++std-lib-18274 for -a brief discussion in support of this change. -

    - - -

    Proposed resolution:

    -

    -For simplicity, instead of adding overloads for unsigned long -long and dealing with possible ambiguities in the spec, replace -the bitset ctor that takes an unsigned long -argument with one taking unsigned long long in the -definition of the template as shown below. (The standard permits -implementations to add overloads on other integer types or employ -template tricks to achieve the same effect provided they don't cause -ambiguities or changes in behavior.) -

    -
    -
    // [bitset.cons] constructors:
-bitset();
-bitset(unsigned long long val);
-template<class charT, class traits, class Allocator>
-explicit bitset(
-                const basic_string<charT,traits,Allocator>& str,
-                typename basic_string<charT,traits,Allocator>::size_type pos = 0,
-                typename basic_string<charT,traits,Allocator>::size_type n =
-                    basic_string<charT,traits,Allocator>::npos);
-
    -
    -

    -Make a corresponding change in 23.3.5.1 [bitset.cons], p2: -

    -
    -

    -bitset(unsigned long long val); -

    -
    -Effects: Constructs an object of class bitset<N>, -initializing the first M bit positions to the -corresponding bit values in val. -M is the smaller of N and the -number of bits in the value representation (section [basic.types]) of -unsigned long long. If M < -N is true, the remaining bit -positions are initialized to zero. -
    -
    - -

    -Additionally, introduce a new member function to_ullong() -to make it possible to convert bitset to values of the -new type. Add the following declaration to the definition of the -template, immediate after the declaration of to_ulong() -in 23.3.5 [template.bitset], p1, as shown below: -

    -
    -
    // element access:
-bool operator[](size_t pos) const; // for b[i];
-reference operator[](size_t pos); // for b[i];
-unsigned long to_ulong() const;
-unsigned long long to_ullong() const;
-template <class charT, class traits, class Allocator>
-basic_string<charT, traits, Allocator> to_string() const;
-
    -
    -

    -And add a description of the new member function to 23.3.5.2 [bitset.members], -below the description of the existing to_ulong() (if -possible), with the following text: -

    -
    -

    -unsigned long long to_ullong() const; -

    -
    -Throws: overflow_error if the integral value -x corresponding to the bits in *this -cannot be represented as type unsigned long long. -
    -
    -Returns: x. -
    -
    - - - - - -
    -

    695. ctype<char>::classic_table() not accessible

    -

    Section: 22.2.1.3 [facet.ctype.special] Status: WP - Submitter: Martin Sebor Date: 2007-06-22

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -The ctype<char>::classic_table() static member -function returns a pointer to an array of const -ctype_base::mask objects (enums) that contains -ctype<char>::table_size elements. The table -describes the properties of the character set in the "C" locale (i.e., -whether a character at an index given by its value is alpha, digit, -punct, etc.), and is typically used to initialize the -ctype<char> facet in the classic "C" locale (the -protected ctype<char> member function -table() then returns the same value as -classic_table()). -

    -

    -However, while ctype<char>::table_size (the size of -the table) is a public static const member of the -ctype<char> specialization, the -classic_table() static member function is protected. That -makes getting at the classic data less than convenient (i.e., one has -to create a whole derived class just to get at the masks array). It -makes little sense to expose the size of the table in the public -interface while making the table itself protected, especially when the -table is a constant object. -

    -

    -The same argument can be made for the non-static protected member -function table(). -

    - - -

    Proposed resolution:

    -

    -Make the ctype<char>::classic_table() and -ctype<char>::table() member functions public by -moving their declarations into the public section of the definition of -specialization in 22.2.1.3 [facet.ctype.special] as shown below: -

    -
    -
      static locale::id id;
-  static const size_t table_size = IMPLEMENTATION_DEFINED;
-protected:
-  const mask* table() const throw();
-  static const mask* classic_table() throw();
-protected:
-
-~ctype(); // virtual
-virtual char do_toupper(char c) const;
-
    -
    - - - - - -
    -

    699. N2111 changes min/max

    -

    Section: 26.4 [rand] Status: WP - Submitter: P.J. Plauger Date: 2007-07-01

    -

    View all other issues in [rand].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -N2111 -changes min/max in several places in random from member -functions to static data members. I believe this introduces -a needless backward compatibility problem between C++0X and -TR1. I'd like us to find new names for the static data members, -or perhaps change min/max to constexprs in C++0X. -

    - -

    -See N2391 and -N2423 -for some further discussion. -

    - - -

    Proposed resolution:

    -

    -Adopt the proposed resolution in -N2423. -

    - - -

    [ -Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue. -The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona. -]

    - - - - - -
    -

    700. N1856 defines struct identity

    -

    Section: 20.2.2 [forward] Status: WP - Submitter: P.J. Plauger Date: 2007-07-01

    -

    View other active issues in [forward].

    -

    View all other issues in [forward].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -N1856 -defines struct identity in <utility> which clashes with -the traditional definition of struct identity in <functional> -(not standard, but a common extension from old STL). Be nice -if we could avoid this name clash for backward compatibility. -

    - - -

    Proposed resolution:

    -

    -Change 20.2.2 [forward]: -

    - -
    -
    template <class T> struct identity
-{
-    typedef T type;
-    const T& operator()(const T& x) const;
-};
-
    -
    -
    const T& operator()(const T& x) const;
-
    -
    -

    -Returns: x. -

    -
    -
    - -
    - - - - - - -
    -

    703. map::at() need a complexity specification

    -

    Section: 23.3.1.2 [map.access] Status: WP - Submitter: Joe Gottman Date: 2007-07-03

    -

    View all other issues in [map.access].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -map::at() need a complexity specification. -

    - - -

    Proposed resolution:

    -

    -Add the following to the specification of map::at(), 23.3.1.2 [map.access]: -

    -
    -

    -Complexity: logarithmic. -

    -
    - - - - - -
    -

    705. type-trait decay incompletely specified

    -

    Section: 20.5.7 [meta.trans.other] Status: WP - Submitter: Thorsten Ottosen Date: 2007-07-08

    -

    View other active issues in [meta.trans.other].

    -

    View all other issues in [meta.trans.other].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -The current working draft has a type-trait decay in 20.5.7 [meta.trans.other]. -

    - -

    -Its use is to turn C++03 pass-by-value parameters into efficient C++0x -pass-by-rvalue-reference parameters. However, the current definition -introduces an incompatible change where the cv-qualification of the -parameter type is retained. The deduced type should loose such -cv-qualification, as pass-by-value does. -

    - - -

    Proposed resolution:

    -

    -In 20.5.7 [meta.trans.other] change the last sentence: -

    - -

    -Otherwise the member typedef type equals remove_cv<U>::type. -

    - -

    -In 20.4.1.3 [tuple.creation]/1 change: -

    - -

    -where each Vi in VTypes is X& if, for the -corresponding type Ti in Types, -remove_cv<remove_reference<Ti>::type>::type equals -reference_wrapper<X>, otherwise Vi is -decay<Ti>::type. -Let Ui be decay<Ti>::type for each -Ti in Types. Then each Vi in VTypes -is X& if Ui equals -reference_wrapper<X>, otherwise Vi is -Ui. -

    - - - - - - -
    -

    706. make_pair() should behave as make_tuple() wrt. reference_wrapper()

    -

    Section: 20.2.3 [pairs] Status: WP - Submitter: Thorsten Ottosen Date: 2007-07-08

    -

    View all other issues in [pairs].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -The current draft has make_pair() in 20.2.3 [pairs]/16 -and make_tuple() in 20.4.1.3 [tuple.creation]. -make_tuple() detects the presence of -reference_wrapper<X> arguments and "unwraps" the reference in -such cases. make_pair() would OTOH create a -reference_wrapper<X> member. I suggest that the two -functions are made to behave similar in this respect to minimize -confusion. -

    - - -

    Proposed resolution:

    -

    -In 20.2 [utility] change the synopsis for make_pair() to read -

    - -
    template <class T1, class T2>
-  pair<typename decay<T1>::type V1, typename decay<T2>::type V2> make_pair(T1&&, T2&&);
-
    - -

    -In 20.2.3 [pairs]/16 change the declaration to match the above synopsis. -Then change the 20.2.3 [pairs]/17 to: -

    - -
    -

    -Returns: pair<typename decay<T1>::type V1,typename decay<T2>::type V2>(forward<T1>(x),forward<T2>(y)) where V1 and -V2 are determined as follows: Let Ui be -decay<Ti>::type for each Ti. Then each -Vi is X& if Ui equals -reference_wrapper<X>, otherwise Vi is -Ui. -

    -
    - - - - - - -
    -

    710. Missing postconditions

    -

    Section: 20.7.12.2 [util.smartptr.shared] Status: WP - Submitter: Peter Dimov Date: 2007-08-24

    -

    View other active issues in [util.smartptr.shared].

    -

    View all other issues in [util.smartptr.shared].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -A discussion on -comp.std.c++ -has identified a contradiction in the shared_ptr specification. -The shared_ptr move constructor and the cast functions are -missing postconditions for the get() accessor. -

    - -

    [ -Bellevue: -]

    - - -
    -

    -Move to "ready", adopting the first (Peter's) proposed resolution. -

    -

    -Note to the project editor: there is an editorial issue here. The -wording for the postconditions of the casts is slightly awkward, and the -editor should consider rewording "If w is the return value...", e. g. as -"For a return value w...". -

    -
    - - -

    Proposed resolution:

    -

    -Add to 20.7.12.2.1 [util.smartptr.shared.const]: -

    - -
    -
    shared_ptr(shared_ptr&& r);
-template<class Y> shared_ptr(shared_ptr<Y>&& r);
-
    -
    -

    -Postconditions: *this shall contain the old value of r. r -shall be empty. r.get() == 0. -

    -
    -
    - -

    -Add to 20.7.12.2.10 [util.smartptr.shared.cast]: -

    - -
    -
    template<class T, class U> shared_ptr<T> static_pointer_cast(shared_ptr<U> const& r);
-
    -
    -

    -Postconditions: If w is the return value, -w.get() == static_cast<T*>(r.get()) && w.use_count() == r.use_count(). -

    -
    -
    - -
    -
    template<class T, class U> shared_ptr<T> dynamic_pointer_cast(shared_ptr<U> const& r);
-
    -
    -

    -Postconditions: If w is the return value, w.get() == dynamic_cast<T*>(r.get()). -

    -
    -
    - -
    -
    template<class T, class U> shared_ptr<T> const_pointer_cast(shared_ptr<U> const& r);
-
    -
    -

    -Postconditions: If w is the return value, -w.get() == const_cast<T*>(r.get()) && w.use_count() == r.use_count(). -

    -
    -
    - -

    -Alberto Ganesh Barbati has written an -alternative proposal -where he suggests (among other things) that the casts be respecified in terms of -the aliasing constructor as follows: -

    - -

    -Change 20.7.12.2.10 [util.smartptr.shared.cast]: -

    - -
    -

    --2- Returns: If r is empty, an empty -shared_ptr<T>; otherwise, a shared_ptr<T> -object that stores static_cast<T*>(r.get()) and shares ownership with -r. shared_ptr<T>(r, static_cast<T*>(r.get()). -

    -
    - -
    -

    --6- Returns: -

    -
      -
    • When dynamic_cast<T*>(r.get()) returns a nonzero value, -a shared_ptr<T> object that stores a copy -of it and shares ownership with r;
      • -
    • Otherwise, an empty shared_ptr<T> object.
      • -
    • If p = dynamic_cast<T*>(r.get()) is a non-null pointer, shared_ptr<T>(r, p);
      • -
    • Otherwise, shared_ptr<T>().
      • -
    -
    - -
    -

    --10- Returns: If r is empty, an empty -shared_ptr<T>; otherwise, a shared_ptr<T> -object that stores const_cast<T*>(r.get()) and shares ownership with -r. shared_ptr<T>(r, const_cast<T*>(r.get()). -

    -
    - -

    -This takes care of the missing postconditions for the casts by bringing -in the aliasing constructor postcondition "by reference". -

    - - - - - - -
    -

    712. seed_seq::size no longer useful

    -

    Section: 26.4.7.1 [rand.util.seedseq] Status: WP - Submitter: Marc Paterno Date: 2007-08-25

    -

    View other active issues in [rand.util.seedseq].

    -

    View all other issues in [rand.util.seedseq].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -One of the motivations for incorporating seed_seq::size() -was to simplify the wording -in other parts of 26.4 [rand]. -As a side effect of resolving related issues, -all such references -to seed_seq::size() will have been excised. -More importantly, -the present specification is contradictory, -as "The number of 32-bit units the object can deliver" -is not the same as "the result of v.size()." -

    - -

    -See N2391 and -N2423 -for some further discussion. -

    - - -

    Proposed resolution:

    -

    -Adopt the proposed resolution in -N2423. -

    - - -

    [ -Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue. -The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona. -]

    - - - - - -
    -

    715. minmax_element complexity is too lax

    -

    Section: 25.3.7 [alg.min.max] Status: WP - Submitter: Matt Austern Date: 2007-08-30

    -

    View all other issues in [alg.min.max].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -The complexity for minmax_element (25.3.7 [alg.min.max] par 16) says "At most max(2 * -(last - first ) - 2, 0) applications of the corresponding comparisons", -i.e. the worst case complexity is no better than calling min_element and -max_element separately. This is gratuitously inefficient. There is a -well known technique that does better: see section 9.1 of CLRS -(Introduction to Algorithms, by Cormen, Leiserson, Rivest, and Stein). -

    - - -

    Proposed resolution:

    -

    -Change 25.3.7 [alg.min.max] to: -

    - -
    -
    template<class ForwardIterator> 
-  pair<ForwardIterator, ForwardIterator> 
-    minmax_element(ForwardIterator first , ForwardIterator last); 
-template<class ForwardIterator, class Compare> 
-  pair<ForwardIterator, ForwardIterator> 
-    minmax_element(ForwardIterator first , ForwardIterator last , Compare comp);
-
    -
    -

    -Returns: make_pair(m, M), where m is -min_element(first, last) or min_element(first, last, -comp) the first iterator in [first, -last) such that no iterator in the range refers to a smaller element, and -where M is max_element(first, last) or -max_element(first, last, comp) the last iterator -in [first, last) such that no iterator in the range refers to a larger element. -

    -

    -Complexity: At most max(2 * (last - first ) - 2, 0) -max(⌊(3/2) (N-1)⌋, 0) applications of the -corresponding comparisons predicate, where N is distance(first, last). -

    -
    -
    - - - - - - -
    -

    722. Missing [c.math] functions nanf and nanl

    -

    Section: 26.7 [c.math] Status: WP - Submitter: Daniel Krügler Date: 2007-08-27

    -

    View all other issues in [c.math].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -In the listing of 26.7 [c.math], table 108: Header <cmath> synopsis I miss -the following C99 functions (from 7.12.11.2): -

    - -
    float nanf(const char *tagp);
-long double nanl(const char *tagp);
-
    - -

    -(Note: These functions cannot be overloaded and they are also not -listed anywhere else) -

    - - -

    Proposed resolution:

    -

    -In 26.7 [c.math], table 108, section "Functions", add nanf and nanl -just after the existing entry nan. -

    - - - - - -
    -

    740. Please remove *_ptr<T[N]>

    -

    Section: 20.7.11.4 [unique.ptr.compiletime] Status: WP - Submitter: Herb Sutter Date: 2007-10-04

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -Please don't provide *_ptr<T[N]>. It doesn't enable any useful -bounds-checking (e.g., you could imagine that doing op++ on a -shared_ptr<T[N]> yields a shared_ptr<T[N-1]>, but that promising path -immediately falters on op-- which can't reliably dereference because we -don't know the lower bound). Also, most buffers you'd want to point to -don't have a compile-time known size. -

    - -

    -To enable any bounds-checking would require run-time information, with -the usual triplet: base (lower bound), current offset, and max offset -(upper bound). And I can sympathize with the point of view that you -wouldn't want to require this on *_ptr itself. But please let's not -follow the <T[N]> path, especially not with additional functions to -query the bounds etc., because this sets wrong user expectations by -embarking on a path that doesn't go all the way to bounds checking as it -seems to imply. -

    - -

    -If bounds checking is desired, consider a checked_*_ptr instead (e.g., -checked_shared_ptr). And make the interfaces otherwise identical so that -user code could easily #define/typedef between prepending checked_ on -debug builds and not doing so on release builds (for example). -

    - -

    -Note that some may object that checked_*_ptr may seem to make the smart -pointer more like vector, and we don't want two ways to spell vector. I -don't agree, but if that were true that would be another reason to -remove *_ptr<T[N]> which equally makes the smart pointer more like -std::array. :-) -

    - -

    [ -Bellevue: -]

    - - -
    -

    Suggestion that fixed-size array instantiations are going to fail at -compile time anyway (if we remove specialization) due to pointer decay, -at least that appears to be result from available compilers. -

    -

    -So concerns about about requiring static_assert seem unfounded. -

    -

    After a little more experimentation with compiler, it appears that -fixed size arrays would only work at all if we supply these explicit -specialization. So removing them appears less breaking than originally -thought. -

    -

    -straw poll unanimous move to Ready. -

    -
    - - - -

    Proposed resolution:

    -

    -Change the synopsis under 20.7.11 [unique.ptr] p2: -

    - -
    ...
-template<class T> struct default_delete; 
-template<class T> struct default_delete<T[]>; 
-template<class T, size_t N> struct default_delete<T[N]>;
-
-template<class T, class D = default_delete<T>> class unique_ptr; 
-template<class T, class D> class unique_ptr<T[], D>; 
-template<class T, class D, size_t N> class unique_ptr<T[N], D>;
-...
-
    - -

    -Remove the entire section 20.7.11.1.3 [unique.ptr.dltr.dflt2] default_delete<T[N]>. -

    - -

    -Remove the entire section 20.7.11.4 [unique.ptr.compiletime] unique_ptr for array objects with a compile time length -and its subsections: 20.7.11.4.1 [unique.ptr.compiletime.dtor], 20.7.11.4.2 [unique.ptr.compiletime.observers], -20.7.11.4.3 [unique.ptr.compiletime.modifiers]. -

    - - - - - - -
    -

    743. rvalue swap for shared_ptr

    -

    Section: 20.7.12.2.9 [util.smartptr.shared.spec] Status: WP - Submitter: Howard Hinnant Date: 2007-10-10

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -When the LWG looked at 674 in Kona the following note was made: -

    - -

    -We may need to open an issue to deal with the question of -whether shared_ptr needs an rvalue swap. -

    - -

    -This issue was opened in response to that note. -

    - -

    -I believe allowing rvalue shared_ptrs to swap is both -appropriate, and consistent with how other library components are currently specified. -

    - -

    [ -Bellevue: -]

    - - -
    -

    -Concern that the three signatures for swap is needlessly complicated, -but this issue merely brings shared_ptr into equal complexity with the -rest of the library. Will open a new issue for concern about triplicate -signatures. -

    -

    -Adopt issue as written. -

    -
    - - -

    Proposed resolution:

    -

    -Change the synopsis in 20.7.12.2 [util.smartptr.shared]: -

    - -
    void swap(shared_ptr&& r);
-...
-template<class T> void swap(shared_ptr<T>& a, shared_ptr<T>& b);
-template<class T> void swap(shared_ptr<T>&& a, shared_ptr<T>& b);
-template<class T> void swap(shared_ptr<T>& a, shared_ptr<T>&& b);
-
    - -

    -Change 20.7.12.2.4 [util.smartptr.shared.mod]: -

    - -
    void swap(shared_ptr&& r);
-
    - -

    -Change 20.7.12.2.9 [util.smartptr.shared.spec]: -

    - -
    template<class T> void swap(shared_ptr<T>& a, shared_ptr<T>& b);
-template<class T> void swap(shared_ptr<T>&& a, shared_ptr<T>& b);
-template<class T> void swap(shared_ptr<T>& a, shared_ptr<T>&& b);
-
    - - - - - -
    -

    744. What is the lifetime of an exception pointed to by an exception_ptr?

    -

    Section: 18.7.5 [propagation] Status: WP - Submitter: Alisdair Meredith Date: 2007-10-10

    -

    View other active issues in [propagation].

    -

    View all other issues in [propagation].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -Without some lifetime guarantee, it is hard to know how this type can be -used. Very specifically, I don't see how the current wording would -guarantee and exception_ptr caught at the end of one thread could be safely -stored and rethrown in another thread - the original motivation for this -API. -

    -

    -(Peter Dimov agreed it should be clearer, maybe a non-normative note to -explain?) -

    - -

    [ -Bellevue: -]

    - - -
    -

    -Agree the issue is real. -

    -

    -Intent is lifetime is similar to a shared_ptr (and we might even want to -consider explicitly saying that it is a shared_ptr< unspecified type >). -

    -

    -We expect that most implementations will use shared_ptr, and the -standard should be clear that the exception_ptr type is intended to be -something whose semantics are smart-pointer-like so that the user does -not need to worry about lifetime management. We still need someone to -draught those words - suggest emailing Peter Dimov. -

    -

    -Move to Open. -

    -
    - - -

    Proposed resolution:

    -

    -Change 18.7.5 [propagation]/7: -

    - -
    --7- Returns: An exception_ptr object that refers to the currently -handled exception or a copy of the currently handled exception, or a -null exception_ptr object if no exception is being handled. -The referenced object remains valid at least as long as there is an -exception_ptr that refers to it. -If the function needs to allocate memory and the attempt -fails, it returns an exception_ptr object that refers to an instance of -bad_alloc. It is unspecified whether the return values of two successive -calls to current_exception refer to the same exception object. [Note: -that is, it is unspecified whether current_exception creates a new copy -each time it is called. --end note] -
    - - - - - -
    -

    746. current_exception may fail with bad_alloc

    -

    Section: 18.7.5 [propagation] Status: WP - Submitter: Alisdair Meredith Date: 2007-10-10

    -

    View other active issues in [propagation].

    -

    View all other issues in [propagation].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -I understand that the attempt to copy an exception may run out of memory, -but I believe this is the only part of the standard that mandates failure -with specifically bad_alloc, as opposed to allowing an -implementation-defined type derived from bad_alloc. For instance, the Core -language for a failed new expression is: -

    -
    -

    -Any other allocation function that fails to allocate storage shall indicate -failure only by throwing an exception of a type that would match a handler -(15.3) of type std::bad_alloc (18.5.2.1). -

    -
    -

    -I think we should allow similar freedom here (or add a blanket -compatible-exception freedom paragraph in 17) -

    -

    -I prefer the clause 17 approach myself, and maybe clean up any outstanding -wording that could also rely on it. -

    -

    -Although filed against a specific case, this issue is a problem throughout -the library. -

    - -

    [ -Bellevue: -]

    - - -
    -

    -Is issue bigger than library? -

    -

    -No - Core are already very clear about their wording, which is inspiration for the issue. -

    -

    -While not sold on the original 18.7.5 use case, the generalised 17.4.4.8 wording is the real issue. -

    -

    -Accept the broad view and move to ready -

    -
    - - -

    Proposed resolution:

    -

    -Add the following exemption clause to 17.4.4.9 [res.on.exception.handling]: -

    - -
    -A function may throw a type not listed in its Throws clause so long as it is -derived from a class named in the Throws clause, and would be caught by an -exception handler for the base type. -
    - - - - - -
    -

    749. Currently has_nothrow_copy_constructor<T>::value is true if T has 'a' nothrow copy constructor.

    -

    Section: 20.5.4.3 [meta.unary.prop] Status: WP - Submitter: Alisdair Meredith Date: 2007-10-10

    -

    View all other issues in [meta.unary.prop].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -Unfortunately a class can have multiple copy constructors, and I believe to -be useful this trait should only return true is ALL copy constructors are -no-throw. -

    -

    -For instance: -

    -
    -
    struct awkward {
- awkward( const awkward & ) throw() {}
- awkward( awkward & ) { throw "oops"; } };
-
    -
    - - -

    Proposed resolution:

    -

    -Change 20.5.4.3 [meta.unary.prop]: -

    - -
    -
    has_trivial_copy_constructor
    -
    -T is a trivial type (3.9) or a reference type or a class type with a trivial copy constructor -where all copy constructors are trivial (12.8). -
    -
    - -
    -
    has_trivial_assign
    -
    -T is neither const nor a reference type, and T is a trivial type (3.9) -or a class type with a trivial copy assignment operator where all copy assignment operators are trivial (12.8). -
    -
    - -
    -
    has_nothrow_copy_constructor
    -
    -has_trivial_copy_constructor<T>::value is true or T is a class type with -a where all copy constructors that is are -known not to throw any exceptions or T is an -array of such a class type -
    -
    - -
    -
    has_nothrow_assign
    -
    -T is neither const nor a reference type, and -has_trivial_assign<T>::value is true or T is a class type with a -where all copy -assignment operators takeing an lvalue of type T that is known not to -throw any exceptions or T is an array of such a class type. -
    -
    - - - - - - -
    -

    755. std::vector and std:string lack explicit shrink-to-fit operations

    -

    Section: 23.2.6.2 [vector.capacity], 21.3.4 [string.capacity] Status: WP - Submitter: Beman Dawes Date: 2007-10-31

    -

    View all other issues in [vector.capacity].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -A std::vector can be shrunk-to-fit via the swap idiom: -

    - -
    vector<int> v;
-...
-v.swap(vector<int>(v));  // shrink to fit
-
    -

    -or: -

    -
    vector<int>(v).swap(v);  // shrink to fit
-
    -

    -or: -

    -
    swap(v, vector<int>(v));  // shrink to fit
-
    -
    - -

    -A non-binding request for shrink-to-fit can be made to a std::string via: -

    - -
    string s;
-...
-s.reserve(0);
-
    - -

    -Neither of these is at all obvious to beginners, and even some -experienced C++ programmers are not aware that shrink-to-fit is -trivially available. -

    -

    -Lack of explicit functions to perform these commonly requested -operations makes vector and string less usable for non-experts. Because -the idioms are somewhat obscure, code readability is impaired. It is -also unfortunate that two similar vector-like containers use different -syntax for the same operation. -

    -

    -The proposed resolution addresses these concerns. The proposed function -takes no arguments to keep the solution simple and focused. -

    - - -

    Proposed resolution:

    -

    -To Class template basic_string 21.3 [basic.string] synopsis, -Class template vector 23.2.6 [vector] synopsis, and Class -vector<bool> 23.2.7 [vector.bool] synopsis, add: -

    - -
        
-void shrink_to_fit();
-
    - -

    -To basic_string capacity 21.3.4 [string.capacity] and vector -capacity 23.2.6.2 [vector.capacity], add: -

    - -
    -
    void shrink_to_fit();
-
    -
    -Remarks: shrink_to_fit is a non-binding request to reduce -capacity() to size(). [Note: The request is non-binding to -allow latitude for implementation-specific optimizations. --- end note] -
    -
    - -

    [ -850 has been added to deal with this issue with respect to deque. -]

    - - - - - - -
    -

    759. A reference is not an object

    -

    Section: 23.1 [container.requirements] Status: WP - Submitter: Jens Maurer Date: 2007-11-06

    -

    View other active issues in [container.requirements].

    -

    View all other issues in [container.requirements].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -23.1 [container.requirements] says: -

    - -
    --12- Objects passed to member functions of a container as rvalue references shall not be elements of that container. No -diagnostic required. -
    - -

    -A reference is not an object, but this sentence appears to claim so. -

    - -

    -What is probably meant here: -

    -
    -An object bound to an rvalue -reference parameter of a member function of a container shall not be -an element of that container; no diagnostic required. -
    - - - -

    Proposed resolution:

    -

    -Change 23.1 [container.requirements]: -

    - -
    --12- Objects passed to member functions of a container as rvalue references shall not be elements -An object bound to an rvalue -reference parameter of a member function of a container shall not be -an element -of that container.; Nno -diagnostic required. -
    - - - - - - -
    -

    761. unordered_map needs an at() member function

    -

    Section: 23.4.1.2 [unord.map.elem] Status: WP - Submitter: Joe Gottman Date: 2007-11-15

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -The new member function at() was recently added to std::map(). It acts -like operator[](), except it throws an exception when the input key is -not found. It is useful when the map is const, the value_type of the -key doesn't have a default constructor, it is an error if the key is -not found, or the user wants to avoid accidentally adding an element to -the map. For exactly these same reasons, at() would be equally useful -in std::unordered_map. -

    - - -

    Proposed resolution:

    -

    -Add the following functions to the definition of unordered_map under "lookup" (23.4.1 [unord.map]): -

    - -
    mapped_type& at(const key_type& k);
-const mapped_type &at(const key_type &k) const;
-
    - -

    -Add the following definitions to 23.4.1.2 [unord.map.elem]: -

    - -
    -
    mapped_type& at(const key_type& k);
-const mapped_type &at(const key_type &k) const;
-
    -
    -

    -Returns: A reference to x.second, where x is the (unique) element -whose key is equivalent to k. -

    -

    -Throws: An exception object of type out_of_range if no such element -is present. -

    -
    -
    - -

    [ -Bellevue: Editorial note: the "(unique)" differs from map. -]

    - - - - - - - -
    -

    766. Inconsistent exception guarantees between ordered and unordered associative containers

    -

    Section: 23.1 [container.requirements], 23.1.5.1 [unord.req.except] Status: WP - Submitter: Ion Gaztañaga Date: 2007-12-22

    -

    View other active issues in [container.requirements].

    -

    View all other issues in [container.requirements].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -23.1 [container.requirements]p10 states: -

    - -
    -

    -Unless otherwise specified (see 23.2.2.3 and 23.2.5.4) all container types defined in this clause meet the following -additional requirements: -

    -
      - -
    • [...]
      • - -
    • no erase(), pop_back() or pop_front() function throws an exception.
      • - -
    -
    - -

    -23.2.2.3 [deque.modifiers] and 23.2.6.4 [vector.modifiers] offer -additional guarantees for deque/vector insert() and -erase() members. However, 23.1 [container.requirements]p10 -does not mention 23.1.5.1 [unord.req.except] that specifies exception -safety guarantees -for unordered containers. In addition, 23.1.5.1 [unord.req.except]p1 -offers the following guaratee for -erase(): -

    - -
    -No erase() function throws an exception unless that exception -is thrown by the container's Hash or Pred object (if any). -
    - -

    -Summary: -

    - -

    -According to 23.1 [container.requirements]p10 no -erase() function should throw an exception unless otherwise -specified. Although does not explicitly mention 23.1.5.1 [unord.req.except], this section offers additional guarantees -for unordered containers, allowing erase() to throw if -predicate or hash function throws. -

    - -

    -In contrast, associative containers have no exception safety guarantees -section so no erase() function should throw, including -erase(k) that needs to use the predicate function to -perform its work. This means that the predicate of an associative -container is not allowed to throw. -

    - -

    -So: -

    - -
      -
    1. -erase(k) for associative containers is not allowed to throw. On -the other hand, erase(k) for unordered associative containers -is allowed to throw. -
      2. -
    2. -erase(q) for associative containers is not allowed to throw. On -the other hand, erase(q) for unordered associative containers -is allowed to throw if it uses the hash or predicate. -
      3. -
    3. -To fulfill 1), predicates of associative containers are not allowed to throw. -Predicates of unordered associative containers are allowed to throw. -
      4. -
    4. -2) breaks a widely used programming pattern (flyweight pattern) for -unordered containers, where objects are registered in a global map in -their constructors and unregistered in their destructors. If erase(q) is -allowed to throw, the destructor of the object would need to rethrow the -exception or swallow it, leaving the object registered. -
      5. -
    - - -

    Proposed resolution:

    -

    -Create a new sub-section of 23.1.4 [associative.reqmts] (perhaps [associative.req.except]) titled "Exception -safety guarantees". -

    - -
    -

    -1 For associative containers, no clear() function throws an exception. -erase(k) does not throw an exception unless that exception is thrown by -the container's Pred object (if any). -

    - -

    -2 For associative containers, if an exception is thrown by any operation -from within an insert() function inserting a single element, the -insert() function has no effect. -

    - -

    -3 For associative containers, no swap function throws an exception -unless that exception is thrown by the copy constructor or copy -assignment operator of the container's Pred object (if any). -

    -
    - -

    -Change 23.1.5.1 [unord.req.except]p1: -

    - -
    -For unordered associative containers, no clear() function -throws an exception. No erase(k) -function does not throws an exception -unless that exception is thrown by the container's Hash or Pred object -(if any). -
    - -

    -Change 23.1 [container.requirements]p10 to add references to new sections: -

    - -
    -Unless otherwise specified (see [deque.modifiers], -and [vector.modifiers], [associative.req.except], -[unord.req.except]) all container types defined in this clause meet -the following additional requirements: -
    - -

    -Change 23.1 [container.requirements]p10 referring to swap: -

    - -
    -
      -
    • -no swap() function throws an exception unless that exception is thrown -by the copy constructor or assignment operator of the container's -Compare object (if any; see [associative.reqmts]). -
      • -
    -
    - - - - - - -
    -

    768. Typos in [atomics]?

    -

    Section: 29.3.3 [atomics.types.generic] Status: WP - Submitter: Alberto Ganesh Barbati Date: 2007-12-28

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -in the latest publicly available draft, paper -N2641, -in section 29.3.3 [atomics.types.generic], the following specialization of the template -atomic<> is provided for pointers: -

    - -
    template <class T> struct atomic<T*> : atomic_address { 
-  T* fetch_add(ptrdiff_t, memory_order = memory_order_seq_cst) volatile; 
-  T* fetch_sub(ptrdiff_t, memory_order = memory_order_seq_cst) volatile; 
-
-  atomic() = default; 
-  constexpr explicit atomic(T); 
-  atomic(const atomic&) = delete; 
-  atomic& operator=(const atomic&) = delete; 
-
-  T* operator=(T*) volatile; 
-  T* operator++(int) volatile; 
-  T* operator--(int) volatile; 
-  T* operator++() volatile; 
-  T* operator--() volatile; 
-  T* operator+=(ptrdiff_t) volatile;
-  T* operator-=(ptrdiff_t) volatile; 
-};
-
    - -

    -First of all, there is a typo in the non-default constructor which -should take a T* rather than a T. -

    - -

    -As you can see, the specialization redefine and therefore hide a few -methods from the base class atomic_address, namely fetch_add, fetch_sub, -operator=, operator+= and operator-=. That's good, but... what happened -to the other methods, in particular these ones: -

    - -
    void store(T*, memory_order = memory_order_seq_cst) volatile;
-T* load( memory_order = memory_order_seq_cst ) volatile;
-T* swap( T*, memory_order = memory_order_seq_cst ) volatile;
-bool compare_swap( T*&, T*, memory_order, memory_order ) volatile;
-bool compare_swap( T*&, T*, memory_order = memory_order_seq_cst ) volatile;
-
    - -

    -By reading paper -N2427 "C++ Atomic Types and Operations", -I see that the -definition of the specialization atomic<T*> matches the one in the -draft, but in the example implementation the methods load(), swap() -and compare_swap() are indeed present. -

    - -

    -Strangely, the example implementation does not redefine the method -store(). It's true that a T* is always convertible to void*, but not -hiding the void* signature from the base class makes the class -error-prone to say the least: it lets you assign pointers of any type to -a T*, without any hint from the compiler. -

    - -

    -Is there a true intent to remove them from the specialization or are -they just missing from the definition because of a mistake? -

    - -

    [ -Bellevue: -]

    - - -
    -

    -The proposed revisions are accepted. -

    -

    -Further discussion: why is the ctor labeled "constexpr"? Lawrence said -this permits the object to be statically initialized, and that's -important because otherwise there would be a race condition on -initialization. -

    -
    - - -

    Proposed resolution:

    -

    -Change the synopsis in 29.3.3 [atomics.types.generic]: -

    - -
    template <class T> struct atomic<T*> : atomic_address { 
-  void store(T*, memory_order = memory_order_seq_cst) volatile;
-  T* load( memory_order = memory_order_seq_cst ) volatile;
-  T* swap( T*, memory_order = memory_order_seq_cst ) volatile;
-  bool compare_swap( T*&, T*, memory_order, memory_order ) volatile;
-  bool compare_swap( T*&, T*, memory_order = memory_order_seq_cst ) volatile;
-
-  T* fetch_add(ptrdiff_t, memory_order = memory_order_seq_cst) volatile; 
-  T* fetch_sub(ptrdiff_t, memory_order = memory_order_seq_cst) volatile; 
-
-  atomic() = default; 
-  constexpr explicit atomic(T*); 
-  atomic(const atomic&) = delete; 
-  atomic& operator=(const atomic&) = delete; 
-
-  T* operator=(T*) volatile; 
-  T* operator++(int) volatile; 
-  T* operator--(int) volatile; 
-  T* operator++() volatile; 
-  T* operator--() volatile; 
-  T* operator+=(ptrdiff_t) volatile;
-  T* operator-=(ptrdiff_t) volatile; 
-};
-
    - - - - - - -
    -

    770. std::function should use rvalue swap

    -

    Section: 20.6.15 [func.wrap] Status: WP - Submitter: Daniel Krügler Date: 2008-01-10

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -It is expected that typical implementations of std::function will -use dynamic memory allocations at least under given conditions, -so it seems appropriate to change the current lvalue swappabilty of -this class to rvalue swappability. -

    - - -

    Proposed resolution:

    -

    -In 20.6 [function.objects], header <functional> synopsis, just below of -

    - -
    template<class R, class... ArgTypes>
-  void swap(function<R(ArgTypes...)>&, function<R(ArgTypes...)>&);
-template<class R, class... ArgTypes>
-  void swap(function<R(ArgTypes...)>&&, function<R(ArgTypes...)>&);
-template<class R, class... ArgTypes>
-  void swap(function<R(ArgTypes...)>&, function<R(ArgTypes...)>&&);
-
    - -

    -In 20.6.15.2 [func.wrap.func] class function definition, change -

    - -
    void swap(function&&);
-
    - -

    -In 20.6.15.2 [func.wrap.func], just below of -

    - -
    template <class R, class... ArgTypes>
-  void swap(function<R(ArgTypes...)>&, function<R(ArgTypes...)>&);
-template <class R, class... ArgTypes>
-  void swap(function<R(ArgTypes...)>&&, function<R(ArgTypes...)>&);
-template <class R, class... ArgTypes>
-  void swap(function<R(ArgTypes...)>&, function<R(ArgTypes...)>&&);
-
    - -

    -In 20.6.15.2.2 [func.wrap.func.mod] change -

    - -
    void swap(function&& other);
-
    - -

    -In 20.6.15.2.7 [func.wrap.func.alg] add the two overloads -

    - -
    template<class R, class... ArgTypes>
-  void swap(function<R(ArgTypes...)>&& f1, function<R(ArgTypes...)>& f2);
-template<class R, class... ArgTypes>
-  void swap(function<R(ArgTypes...)>& f1, function<R(ArgTypes...)>&& f2);
-
    - - - - - - -
    -

    775. Tuple indexing should be unsigned?

    -

    Section: 20.4.1.4 [tuple.helper] Status: WP - Submitter: Alisdair Meredith Date: 2008-01-16

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -The tuple element access API identifies the element in the sequence -using signed integers, and then goes on to enforce the requirement that -I be >= 0. There is a much easier way to do this - declare I as -unsigned. -

    -

    -In fact the proposal is to use std::size_t, matching the type used in the tuple_size API. -

    -

    -A second suggestion is that it is hard to imagine an API that deduces -and index at compile time and returns a reference throwing an exception. -Add a specific Throws: Nothing paragraph to each element -access API. -

    -

    -In addition to tuple, update the API applies to -pair and array, and should be updated -accordingly. -

    - -

    -A third observation is that the return type of the get -functions for std::pair is pseudo-code, but it is not -clearly marked as such. There is actually no need for pseudo-code as -the return type can be specified precisely with a call to -tuple_element. This is already done for -std::tuple, and std::array does not have a -problem as all elements are of type T. -

    - - -

    Proposed resolution:

    -

    -Update header <utility> synopsis in 20.2 [utility] -

    -
    // 20.2.3, tuple-like access to pair:
-template <class T> class tuple_size;
-template <intsize_t I, class T> class tuple_element;
-
-template <class T1, class T2> struct tuple_size<std::pair<T1, T2> >;
-template <class T1, class T2> struct tuple_element<0, std::pair<T1, T2> >;
-template <class T1, class T2> struct tuple_element<1, std::pair<T1, T2> >;
-
-template<intsize_t I, class T1, class T2>
-  Ptypename tuple_element<I, std::pair<T1, T2> >::type & get(std::pair<T1, T2>&);
-template<intsize_t I, class T1, class T2>
-  const Ptypename tuple_element<I, std::pair<T1, T2> >::type & get(const std::pair<T1, T2>&);
-
    -

    -Update 20.2.3 [pairs] Pairs -

    -
    template<intsize_t I, class T1, class T2>
-  Ptypename tuple_element<I, std::pair<T1, T2> >::type & get(pair<T1, T2>&);
-template<intsize_t I, class T1, class T2>
-  const Ptypename tuple_element<I, std::pair<T1, T2> >::type & get(const pair<T1, T2>&);
-
    -

    -24 Return type: If I == 0 then P is T1, if I == 1 then P is T2, and otherwise the program is ill-formed. -

    -

    -25 Returns: If I == 0 returns p.first, otherwise if I == 1 returns p.second, and otherwise the program is ill-formed. -

    -

    -Throws: Nothing. -

    - - -

    -Update header <tuple> synopsis in 20.4 [tuple] with a APIs as below: -

    -
    template <intsize_t I, class T> class tuple_element; // undefined
-template <intsize_t I, class... Types> class tuple_element<I, tuple<Types...> >;
-
-// 20.3.1.4, element access:
-template <intsize_t I, class... Types>
-  typename tuple_element<I, tuple<Types...> >::type& get(tuple<Types...>&);
-template <intsize_t I, class ... types>
-  typename tuple_element<I, tuple<Types...> >::type const& get(const tuple<Types...>&);
-
    - -

    -Update 20.4.1.4 [tuple.helper] Tuple helper classes -

    -
    template <intsize_t I, class... Types>
-class tuple_element<I, tuple<Types...> > {
-public:
-  typedef TI type;
-};
    -

    -1 Requires: 0 <= I and I < sizeof...(Types). The program is ill-formed if I is out of bounds. -

    -

    -2 Type: TI is the type of the Ith element of Types, where indexing is zero-based. -

    -

    -Update 20.4.1.5 [tuple.elem] Element access -

    -
    template <intsize_t I, class... types >
-typename tuple_element<I, tuple<Types...> >::type& get(tuple<Types...>& t);
-
    -1 Requires: 0 <= I and I < sizeof...(Types). The program is ill-formed if I is out of bounds. -

    -2 Returns: A reference to the Ith element of t, where indexing is zero-based. -

    -Throws: Nothing. -
    template <intsize_t I, class... types>
-typename tuple_element<I, tuple<Types...> >::type const& get(const tuple<Types...>& t);
-
    -

    -3 Requires: 0 <= I and I < sizeof...(Types). The program is ill-formed if I is out of bounds. -

    -

    -4 Returns: A const reference to the Ith element of t, where indexing is zero-based. -

    -

    -Throws: Nothing. -

    - - -

    -Update header <array> synopsis in 20.2 [utility] -

    -
    template <class T> class tuple_size; // forward declaration
-template <intsize_t I, class T> class tuple_element; // forward declaration
-template <class T, size_t N>
-  struct tuple_size<array<T, N> >;
-template <intsize_t I, class T, size_t N>
-  struct tuple_element<I, array<T, N> >;
-template <intsize_t I, class T, size_t N>
-  T& get(array<T, N>&);
-template <intsize_t I, class T, size_t N>
-  const T& get(const array<T, N>&);
-
    - -

    -Update 23.2.1.6 [array.tuple] Tuple interface to class template array -

    -
    tuple_element<size_t I, array<T, N> >::type
-
    -

    -3 Requires: 0 <= I < N. The program is ill-formed if I is out of bounds. -

    -

    -4 Value: The type T. -

    -
    template <intsize_t I, class T, size_t N> T& get(array<T, N>& a);
-
    -

    -5 Requires: 0 <= I < N. The program is ill-formed if I is out of bounds. -

    -

    -Returns: A reference to the Ith element of a, where indexing is zero-based. -

    -

    -Throws: Nothing. -

    -
    template <intsize_t I, class T, size_t N> const T& get(const array<T, N>& a);
-
    -

    -6 Requires: 0 <= I < N. The program is ill-formed if I is out of bounds. -

    -

    -7 Returns: A const reference to the Ith element of a, where indexing is zero-based. -

    -

    -Throws: Nothing. -

    - - -

    [ -Bellevue: Note also that the phrase "The program is ill-formed if I is -out of bounds" in the requires clauses are probably unnecessary, and -could be removed at the editor's discretion. Also std:: qualification -for pair is also unnecessary. -]

    - - - - -
    -

    777. Atomics Library Issue

    -

    Section: 29.4 [atomics.types.operations] Status: WP - Submitter: Lawrence Crowl Date: 2008-01-21

    -

    View all other issues in [atomics.types.operations].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -The load functions are defined as -

    - -
    C atomic_load(volatile A* object);
-C atomic_load_explicit(volatile A* object, memory_order);
-C A::load(memory_order order = memory_order_seq_cst) volatile;
-
    - -

    -which prevents their use in const contexts. -

    - -

    [ -post Bellevue Peter adds: -]

    - - -
    -

    -Issue 777 suggests making atomic_load operate on const objects. There is a -subtle point here. Atomic loads do not generally write to the object, except -potentially for the memory_order_seq_cst constraint. Depending on the -architecture, a dummy write with the same value may be required to be issued -by the atomic load to maintain sequential consistency. This, in turn, may -make the following code: -

    - -
    const atomic_int x{};
-
-int main()
-{
-  x.load();
-}
-
    - -

    -dump core under a straightforward implementation that puts const objects in -a read-only section. -

    -

    -There are ways to sidestep the problem, but it needs to be considered. -

    -

    -The tradeoff is between making the data member of the atomic types -mutable and requiring the user to explicitly mark atomic members as -mutable, as is already the case with mutexes. -

    -
    - - - -

    Proposed resolution:

    -

    -Add the const qualifier to *object and *this. -

    - -
    C atomic_load(const volatile A* object);
-C atomic_load_explicit(const volatile A* object, memory_order);
-C A::load(memory_order order = memory_order_seq_cst) const volatile;
-
    - - - - - - -
    -

    778. std::bitset does not have any constructor taking a string literal

    -

    Section: 23.3.5.1 [bitset.cons] Status: WP - Submitter: Thorsten Ottosen Date: 2008-01-24

    -

    View all other issues in [bitset.cons].

    -

    View all issues with WP status.

    -

    Duplicate of: 116

    -

    Discussion:

    -

    -A small issue with std::bitset: it does not have any constructor -taking a string literal, which is clumsy and looks like an oversigt when -we tried to enable uniform use of string and const char* in the library. -

    - -

    -Suggestion: Add -

    - -
    explicit bitset( const char* str );
-
    - -

    -to std::bitset. -

    - - -

    Proposed resolution:

    -

    -Add to synopsis in 23.3.5 [template.bitset] -

    - -
    explicit bitset( const char* str );
-
    - -

    -Add to synopsis in 23.3.5.1 [bitset.cons] -

    - -
    explicit bitset( const char* str );
-
    -

    -Effects: Constructs a bitset as if bitset(string(str)). -

    -
    - - - - - - -
    -

    781. std::complex should add missing C99 functions

    -

    Section: 26.3.7 [complex.value.ops] Status: WP - Submitter: Daniel Krügler Date: 2008-01-26

    -

    View all other issues in [complex.value.ops].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -A comparision of the N2461 header <complex> synopsis ([complex.synopsis]) -with the C99 standard (ISO 9899, 2nd edition and the two corrigenda) show -some complex functions that are missing in C++. These are: -

    - -
      -
    1. -7.3.9.4: (required elements of the C99 library)
      -The cproj functions -
      2. -
    2. -7.26.1: (optional elements of the C99 library)
      -
      cerf    cerfc    cexp2
-cexpm1  clog10   clog1p
-clog2   clgamma  ctgamma
-
      -
      3. -
    - -

    -I propose that at least the required cproj overloads are provided as equivalent -C++ functions. This addition is easy to do in one sentence (delegation to C99 -function). -

    - -

    -Please note also that the current entry polar -in 26.3.9 [cmplx.over]/1 -should be removed from the mentioned overload list. It does not make sense to require that a -function already expecting scalar arguments -should cast these arguments into corresponding -complex<T> arguments, which are not accepted by -this function. -

    - - -

    Proposed resolution:

    -

    -In 26.3.1 [complex.synopsis] add just between the declaration of conj and fabs: -

    - -
    template<class T> complex<T> conj(const complex<T>&);
-template<class T> complex<T> proj(const complex<T>&);
-template<class T> complex<T> fabs(const complex<T>&);
-
    - -

    -In 26.3.7 [complex.value.ops] just after p.6 (return clause of conj) add: -

    - -
    -
    template<class T> complex<T> proj(const complex<T>& x);
-
    -
    - -Effects: Behaves the same as C99 function cproj, defined in -subclause 7.3.9.4." -
    -
    - -

    -In 26.3.9 [cmplx.over]/1, add one further entry proj to -the overload list. -

    - -
    -

    -The following function templates shall have additional overloads: -

    -
    arg           norm 
-conj          polar proj
-imag          real
-
    -
    - - - - - - -
    -

    782. Extended seed_seq constructor is useless

    -

    Section: 26.4.7.1 [rand.util.seedseq] Status: WP - Submitter: Daniel Krügler Date: 2008-01-27

    -

    View other active issues in [rand.util.seedseq].

    -

    View all other issues in [rand.util.seedseq].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -Part of the resolution of n2423, issue 8 was the proposal to -extend the seed_seq constructor accepting an input range -as follows (which is now part of N2461): -

    - -
    template<class InputIterator,
-size_t u = numeric_limits<iterator_traits<InputIterator>::value_type>::digits>
-seed_seq(InputIterator begin, InputIterator end);
-
    - -

    -First, the expression iterator_traits<InputIterator>::value_type -is invalid due to missing typename keyword, which is easy to -fix. -

    - -

    -Second (and worse), while the language now supports default -template arguments of function templates, this customization -point via the second size_t template parameter is of no advantage, -because u can never be deduced, and worse - because it is a -constructor function template - it can also never be explicitly -provided (14.8.1 [temp.arg.explicit]/7). -

    - -

    -The question arises, which advantages result from a compile-time -knowledge of u versus a run time knowledge? If run time knowledge -suffices, this parameter should be provided as normal function -default argument [Resolution marked (A)], if compile-time knowledge -is important, this could be done via a tagging template or more -user-friendly via a standardized helper generator function -(make_seed_seq), which allows this [Resolution marked (B)]. -

    - -

    [ -Bellevue: -]

    - - -
    -

    -Fermilab does not have a strong opinion. Would prefer to go with -solution A. Bill agrees that solution A is a lot simpler and does the -job. -

    -

    -Proposed Resolution: Accept Solution A. -

    -
    - -

    -Issue 803 claims to make this issue moot. -

    - - - -

    Proposed resolution:

    -
      -
    1. -

      -In 26.4.7.1 [rand.util.seedseq]/2, class seed_seq synopsis replace: -

      - -
      class seed_seq 
-{ 
-public:
-   ...
-   template<class InputIterator,
-      size_t u = numeric_limits<iterator_traits<InputIterator>::value_type>::digits>
-          seed_seq(InputIterator begin, InputIterator end,
-          size_t u = numeric_limits<typename iterator_traits<InputIterator>::value_type>::digits);
-   ...
-};
-
      - -

      -and do a similar replacement in the member description between -p.3 and p.4. -

      -
      2. - -
    2. -

      -In 26.4.7.1 [rand.util.seedseq]/2, class seed_seq synopsis and in the -member description between p.3 and p.4 replace: -

      - -
      template<class InputIterator,
-  size_t u = numeric_limits<iterator_traits<InputIterator>::value_type>::digits>
-	  seed_seq(InputIterator begin, InputIterator end);
-template<class InputIterator, size_t u>
-seed_seq(InputIterator begin, InputIterator end, implementation-defined s);
-
      - -

      -In 26.4.2 [rand.synopsis], header <random> synopsis, immediately after the -class seed_seq declaration and in 26.4.7.1 [rand.util.seedseq]/2, immediately -after the class seed_seq definition add: -

      - -
      template<size_t u, class InputIterator>
-  seed_seq make_seed_seq(InputIterator begin, InputIterator end);
-
      - -

      -In 26.4.7.1 [rand.util.seedseq], just before p.5 insert two paragraphs: -

      - -
      -

      -The first constructor behaves as if it would provide an -integral constant expression u of type size_t of value -numeric_limits<typename iterator_traits<InputIterator>::value_type>::digits. -

      -

      -The second constructor uses an implementation-defined mechanism -to provide an integral constant expression u of type size_t and -is called by the function make_seed_seq. -

      -
      - -

      -In 26.4.7.1 [rand.util.seedseq], just after the last paragraph add: -

      - -
      -
      template<size_t u, class InputIterator>
-   seed_seq make_seed_seq(InputIterator begin, InputIterator end);
-
      -
      -

      -where u is used to construct an object s of implementation-defined type. -

      -

      -Returns: seed_seq(begin, end, s); -

      -
      -
      - -
      3. -
    - - - - - - -
    -

    783. thread::id reuse

    -

    Section: 30.2.1.1 [thread.thread.id] Status: WP - Submitter: Hans Boehm Date: 2008-02-01

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -The current working paper -(N2497, -integrated just before Bellevue) is -not completely clear whether a given thread::id value may be reused once -a thread has exited and has been joined or detached. Posix allows -thread ids (pthread_t values) to be reused in this case. Although it is -not completely clear whether this originally was the right decision, it -is clearly the established practice, and we believe it was always the -intent of the C++ threads API to follow Posix and allow this. Howard -Hinnant's example implementation implicitly relies on allowing reuse -of ids, since it uses Posix thread ids directly. -

    - -

    -It is important to be clear on this point, since it the reuse of thread -ids often requires extra care in client code, which would not be -necessary if thread ids were unique across all time. For example, a -hash table indexed by thread id may have to be careful not to associate -data values from an old thread with a new one that happens to reuse the -id. Simply removing the old entry after joining a thread may not be -sufficient, if it creates a visible window between the join and removal -during which a new thread with the same id could have been created and -added to the table. -

    - -

    [ -post Bellevue Peter adds: -]

    - - -
    -

    -There is a real issue with thread::id reuse, but I urge the LWG to -reconsider fixing this by disallowing reuse, rather than explicitly allowing -it. Dealing with thread id reuse is an incredibly painful exercise that -would just force the world to reimplement a non-conflicting thread::id over -and over. -

    -

    -In addition, it would be nice if a thread::id could be manipulated -atomically in a lock-free manner, as motivated by the recursive lock -example: -

    - -

    -http://www.decadentplace.org.uk/pipermail/cpp-threads/2006-August/001091.html -

    -
    - - - -

    Proposed resolution:

    -

    -Add a sentence to 30.2.1.1 [thread.thread.id]/p1: -

    - -
    -

    -An object of type thread::id provides -a unique identifier for each thread of execution -and a single distinct value for all thread objects -that do not represent a thread of execution ([thread.threads.class]). -Each thread of execution has a thread::id -that is not equal to the thread::id -of other threads of execution -and that is not equal to -the thread::id of std::thread objects -that do not represent threads of execution. -The library may reuse the value of a thread::id of a -terminated thread that can no longer be joined. -

    -
    - - - - - -
    -

    789. xor_combine_engine(result_type) should be explicit

    -

    Section: 26.4.4.4 [rand.adapt.xor] Status: WP - Submitter: P.J. Plauger Date: 2008-02-09

    -

    View all other issues in [rand.adapt.xor].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -xor_combine_engine(result_type) should be explicit. (Obvious oversight.) -

    - -

    [ -Bellevue: -]

    - - -
    -Non-controversial. Bill is right, but Fermilab believes that this is -easy to use badly and hard to use right, and so it should be removed -entirely. Got into TR1 by well defined route, do we have permission to -remove stuff? Should probably check with Jens, as it is believed he is -the originator. Broad consensus that this is not a robust engine -adapter. -
    - - -

    Proposed resolution:

    -

    -Remove xor_combine_engine from synopsis of 26.4.2 [rand.synopsis]. -

    -

    -Remove 26.4.4.4 [rand.adapt.xor] xor_combine_engine. -

    - - - - - -
    -

    792. piecewise_constant_distribution is undefined for a range with just one endpoint

    -

    Section: 26.4.8.5.2 [rand.dist.samp.pconst] Status: WP - Submitter: P.J. Plauger Date: 2008-02-09

    -

    View other active issues in [rand.dist.samp.pconst].

    -

    View all other issues in [rand.dist.samp.pconst].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -piecewise_constant_distribution is undefined for a range with just one -endpoint. (Probably should be the same as an empty range.) -

    - - -

    Proposed resolution:

    -

    -Change 26.4.8.5.2 [rand.dist.samp.pconst] paragraph 3b: -

    - -
    -b) If firstB == lastB or the sequence w has the length zero, -
    - - - - - -
    -

    798. Refactoring of binders lead to interface breakage

    -

    Section: D.8 [depr.lib.binders] Status: WP - Submitter: Daniel Krügler Date: 2008-02-14

    -

    View all other issues in [depr.lib.binders].

    -

    View all issues with WP status.

    -

    Discussion:

    -

    -N2521 -and its earlier predecessors have moved the old binders from -[lib.binders] to D.8 [depr.lib.binders] thereby introducing some renaming -of the template parameter names (Operation -> Fn). During this -renaming process the protected data member op was also renamed to -fn, which seems as an unnecessary interface breakage to me - even if -this user access point is probably rarely used. -

    - - -

    Proposed resolution:

    -

    -Change D.8.1 [depr.lib.binder.1st]: -

    - -
    -
    template <class Fn> 
-class binder1st 
-  : public unary_function<typename Fn::second_argument_type, 
-                          typename Fn::result_type> { 
-protected: 
-  Fn fn op; 
-  typename Fn::first_argument_type value; 
-public: 
-  binder1st(const Fn& x, 
-            const typename Fn::first_argument_type& y); 
-  typename Fn::result_type 
-    operator()(const typename Fn::second_argument_type& x) const; 
-  typename Fn::result_type 
-    operator()(typename Fn::second_argument_type& x) const; 
-};
-
    - -
    -

    --1- The constructor initializes fn op with x and value with y. -

    -

    --2- operator() returns fnop(value,x). -

    -
    -
    - -

    -Change D.8.3 [depr.lib.binder.2nd]: -

    - -
    -
    template <class Fn> 
-class binder2nd
-  : public unary_function<typename Fn::first_argument_type, 
-                          typename Fn::result_type> { 
-protected: 
-  Fn fn op; 
-  typename Fn::second_argument_type value; 
-public: 
-  binder2nd(const Fn& x, 
-            const typename Fn::second_argument_type& y); 
-  typename Fn::result_type 
-    operator()(const typename Fn::first_argument_type& x) const; 
-  typename Fn::result_type 
-    operator()(typename Fn::first_argument_type& x) const; 
-};
-
    - -
    -

    --1- The constructor initializes fn op with x and value with y. -

    -

    --2- operator() returns fnop(value,x). -

    -
    -
    - - - - - - - \ No newline at end of file diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/PythonPoweredSmall.gif b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/PythonPoweredSmall.gif deleted file mode 100644 index 268980706ab40af54e7de6d03af2e0fd467b9bd6..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 361 zcmV-v0hazpNk%w1VK)F40J8u9|NsBz=jYzu-qzOEy}iAJgoHvuLOD4(F)=YIDJd8j z7!VK;2nY!O-T(k&r2qf`A^8LW000dDEC2ui05<>@000F4u*pd)bvWydt^eS}jU*SI z&2y~Bqdv~du5a9`bp4{0a{xd<;n(^Vg1}=Da5yH3DkjW<${3qMDG@t_8iib8w50)Q zuE+F4IgSp~+ALVQv2cFD!aA#OIY@Z$FR)=n3>eyXUtK#`@$9APGNrR>a z)e2GrJs}}uM%JuiMJx%s;YygV8z?Mk5ZFs#42~`qHhKifL!PdatxASK$x@|DlPzC1 HhyVaP_=1?P diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/acks.html b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/acks.html deleted file mode 100644 index 6612a4a81..000000000 --- a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/acks.html +++ /dev/null @@ -1,65 +0,0 @@ - - - - - - - Acknowledgments - - - - -
    -

    Acknowledgments

    - -
      -
    1. This library was partially written at IBM's Haifa Research - Labs.
      2. - -
    2. The library is based heavily on policy-based design and - uses many useful techniques from [alexandrescu01modern].
      3. - -
    3. Two ideas are borrowed from the SGI-STL implementation - [sgi_stl]: - -
        -
      1. The prime-based resize policies use a list of primes - taken from the SGI-STL implementation.
        2. - -
      2. The red-black trees contain both a root node and a - header node (containing metadata), connected in a way - that forward and reverse iteration can be performed - efficiently.
        3. -
      -
      4. - -
    4. Some test utilities borrow ideas from [boost_timer].
      5. - -
    5. We would like to thank Scott Meyers for useful comments - (without attributing to him any flaws in the design or - implementation of the library).
      6. - -
    6. Much of the documentation is [Python Powered] (especially through PyChart, Beautiful - Soup, and kjbuckets) - and uses [HTML tidy]. The CSS-driven menus are - slightly modified from Brothercake - (hopefully without introducing errors).
      7. -
    -
    - - diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/assoc_container_tag_cd.png b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/assoc_container_tag_cd.png deleted file mode 100644 index 16cc6da870df0ad2a7899bfa366d4a8720e53114..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 21668 zcmd_S2T)a87bbWWMa6(9iYS5so=OyuoQxnKphU@n0s@jHM{@=xN>)jdMRGPFNK~R^ zl$<3?o^QW@dZxRpr>CZBs-~*vR=x58_nv$9-fOS*g|*M4i;6N^Y4*}kD3q@~@#-OEQ%XvYJM;+P~_uVd|G+WMrJn(cM7FNq*kC zo(C8e}Lb((mH<~ zrA+8=0GSVpj`VRV@^27bCHd!r(K>$euQlVxEfni--^$7^YH77-R{4d6x!p?0eW$Ff z+{V3z@_fTaV~Ur2^+OHm(X`$V*D+yZUv@eo42#8FkmL zT^m>!PA$G7uryt#)RJyevwoO`@<$3^^x>ReNJzrK!1Z9wz}dTZ*PT0e?wEwca)yQP z&A)$s-I$WE{di}CM3hW>zGKrqtAbz7oRX4yGTuzz_?COV`K7N*f3{DkZ%Bkm^yYa? zh)Ec?goN&fZA@j#=F-w%k9}6ZaN()4ii*UXN#)DeXC7=b(w?2@E|r)oEGVF7VhXd! zmGNP&YV_36(Ft@`idaza8Q)l1$p_CxhQjzqe>F|CV@$I#{EOQ9I zg!{tHdw1^+eB8iNZ{MUFH`wxT$HZJ-;E#LR%qB z_>zEG{Y5jg1hdAZ_^MDL^VTd2m+2oeYROsx_wL^}o9y|PppmNQU1PuWcVgl96CUv> z&AM2Hx=;5u&tU9{xQoXRAAYY4=2weXW)ryn{baIMrn0K4zu=9ZuhwtgJ@EbY8LfPW zWa+1SUeoMizg`+>}vHqh+j~+jIbSX|Td>Teo*F`FA}H~abS^;aJj9$A;cn4szYNY8`| z!F+NTE~rLIy4R=b7jMo#z2-yA*UB85?yt}GWl!bF4ynGq`1)qWz3x(<)~Ag8Bd;GY z^YN$8j<#xBTU!U3wq%-{gbG@e*E%%mIyR>kub3GdCu*c-Wm&X_1ZxgACR>cQWNOBS zi`d0V%+#xBwisT$I{NDYOO|H3ad2?6f>8UlA3uIXlyYdK+%Puw`$yqDgPzmJ%1V#F zzcwg^Cu?VC?H6-+8QhG!!4H-qlEo6PvzKvAE;cqcdDr$ldyD?+aARXZ=gDiXShcFk zB#-5VtZUzP@bhopvLz!(-=n#*GS6|`63bdqE92slw_n1g-mD?P=)t!A@2974CTe9S z#MLlMxV#M3G&Fn@z@^<-w}Pp4UAW$m5PTkWb>vJ5y=NTskiL8QW3;cQyci= zg+ZzJ{`B2kT9+?heu*2Z2oba}!!;-->f$J+p(a1d-l8y<~LzKaNr~z9UYeX zm+A0GdwzC^fO)J?htnBshRg`3- zM!a&&`wNb5Sfr$+0=RXxzJ2>f!oD#{GYXUIw9t}m70DVtYhUs0`N1<8_QUFG397P4 zOqZ}#yji4Du)-BKOtQhNLKLrb8Dv-;dKUNT7kVD^M(rMpqgwB-+>-p;MI~EXCDfUO z`!ijf9UW@RO&7Hvigp-nA={s3>(-eJwYL{fd9E&J%LQ>K7rM?R+-QF98?788cZ{7~ zPD9__-n+tmuH7-ybDdus@2J!FXpV7nE0#QA&^UYcZc5$|drh~VUNi0dEM8&9 zY?l{i$e4HY=y4w7_X>AnUe&3VT1~l}_9j6sv2WAMBTF+)`s}I$)B043DF?;Hb+8Af znd%x-bj5;$*)>v$|lE4Jj z_%|DvolcfK-lcNwT695Sp`9)Z<$#}G9gii261KI}Msydu>UBjkv!P=(v*yMN_ z1G%)>`S_GENV3TqQ}t7^+=GGImOlbC^x`obb1d)V%uEAUcH0|YHhDSUEUV6xt@{K? z-PS-_l5l_U;DI^v0=srrQcIRa;$a!@qX-v7u9}-$L0?T|s$2j&_KX}Kzgp7eOUAMI z@KF&FO)jmB@8tm;4eyQQm6AP|CLZiPas3rXYC&y!7*gQ?Rz^9^u;gZ)f>8YBG{ZPI zg+Lztl!p&DlFEZM4`fB2RK(1ooCRa_hh)hv+$&(lYGq}$U&Qw816me!42w+`Xy03F&iZ&tAvx%-V9&eEs~?a&3)vacQX{%_u+F&6VM~>YLWjM@ z#>yI&5Rw^!Rvk%(C65QOmNjZesVLXZAs=-y>9RKsVOpD=!xhr5|9E4D%Q363qXe;d z)UG86@P7md@oSy0-=ruM=R;gvRhUw(N0v>uZeLwpS(f~2?@BqjqluS_(zB-2hFyMW z&|&}4=clV~M6{lxc(npA;?>3HjW={1vSx}4Y89YRCV8Zh1#&(xl^)|XO^v2D&T1NU zp-|>&5994RPP%LXFQ&a(@8OL{ZZjfX=yiH7ZKj;uJyO1r@?m|Cu%d|3*w=xn&RApP zti}>wd~*B0pS(Ob%5xrGLu!1wPY?P6q4fxq$MKK#GxpE-IQ)=<1Icy|l? zhV68;`zs`ssXJC7)fz&xIybKF-R*B{Fh4&bkgH>E>pDN57CSZg`Nj0z;NVHO^{vZ5#mu)_!%g~0Y zRNL35)xPJdo-d7vcXz+T!TF0J!7;hI>%1y#no)q2t$42M`G7GpT0M&mJ!GAt)dDKLP2?GRQYo93a>9)TvXJL6^4I z`<}=})sVGh@MQ@OeiId?mUnZ|#LeBEzb)lR@xy1&W@P2%wb>tCaiEU$Scu;%WI5u% zIA0y&XSQvTh9Gy*pCnt5XUlqOr2Ly*cIgesRY5GlYwF_vGnJ2e?uvN==29F+OP(3VCbfWnc*7q+_-du z&(vJnStGY+XnVebPJm|F#KgpyqRyu@(6O+jc6D883ZxC=1l&OZ6i=0W^XARXsVbq! z262@*#fDI;B4@pdWu)pEz=vM57LY$uB}Kb$f{4|kCcMw=bR93u4OzVg4p6tc+_@Uw zApYUoM&px`SB#q#EnI)+$*eMMl~+(`0EqGT_jk^H`;S7%^~s*3rYi99cc_Uo#mK*=$_u!_xHY^MiDSP+#9SckkY=IU@UkWR;A$BxOy$OY79nAZ8feEBv-H$MTi$l22jC77D20>d91Gn(Qq!$g#mCs#&ZVWLLDh)> zONqs{(o8Lwd^}Vi9|hW{Yg4joVX}gUr%~Rg;_Qn<=cYmC<;#~oUIjt{o~b3G12~B} zenil#1@jrzN6YTq#iJ*#%|ej64i8}z@$vCA8#jJOEbrRB{Z(&85XXT72PzgVz(zz7 zIRJ9~rt%jq)W0{Xpx?PO3b1mBz+yyY1~@8V=!7~UF4<&3n;SblSCjWy=A6R7MI^HY z%p0%c>$Tordz6wtCQ671hkDX?1Zn--ONSfYUi!>GiYsPZE!~!BS|?3FUrWZ|d~wdv z=iBy+M!SyX%8=lA@}!QZc=zf|BQf`u$OMXtjqeOTD~cS-2HFN(loxXtxtOX~IQ?~> z)pd|zmyxtm)z}M+>o;r|_EVDlL7*{<$KO*{Mf0%${E3hxl)5z24DTUcVjykIjJ0d0 z7S3vA^)i8SLR0bc@$uQst@HLrl*}*|umSmke&0S09v+@$tkmSh#0!6Ci9#q5=3uKK zqV@?x4T(W9#f}}$GIssdYR&JB*kt)ls{OOG9kY5ppax)Hs5?33M0hNiS~R~u2OUiv zLd!NL;a9nK{Rv30S~=FQBitrsYixaeeNUJ-CfTjhmc)F9{*ljV>ARo-^7Lc!1z|zZ zfGjbYVE0inwAxsa{t177`qoVIpoS#Py2{E9=l=cs_>C_FN&?~;5mpr(jOni0&3W1S zYj4q9hpV7zEo;qkt7U#w(ZUc1KYwe!V=7j-Ql-v3wb0n_h*DPZ%0k6hPWQGNae(3s z#DYZWO5BBDL#yIthpgG3KQHg&HN5LSQNmzste$SHAO`U(IJj_mwpH-T2QU6ck2L$S zHj#6+4p2v?%CUElBuD&=8D`XGhX&TJF$FUMHls@bB*@fni}c zaDS;-k5-T}E8u65SwaG8I6UF`O?7H80-6*3{!G( zgnzg`-jB#t_=?EYrP2=9aS2x>x@5(0(JXA}Cl4RKgIw~{u13Nn(tS2KICv|IWE-=` zUxU!&2Db%FYrlN@^vO1fD z(W5j_(^em;mFvdF5Mr~i1SOS~(CZ8(T&9onr;Cjj5COovHQOp15}HdN3t4eYq6oL$ z>`3!0bSV>apC?b!p=30yrJ{n|h4JjBqr*}V3_-SSoEvjLL=5M?-rfMi`76u4fs6YN z8+%ot!XM>Htt@=3opmD~Br(CVJueUIZe%<;H`j!jV3VEe^ekp}pT0y?THSnyhRr+$ z&tp)4yV5(xSMQ=Gp7#~BYHnM0_a_qt1_i~t+evyS5u`w&BUMIETJDDs4bJzYaIS*`%7tt#xL`C2>sCg- zp0EWsY+@qQ+7Em`<-RceLt?Hi3bS{4xG7a*;&+MK`)jf_slOoes6*j(7;B5iy_jR7 zh`gy<=weUi1358%8?*S^dz%@CFu)*IXIEEqqQWkYW~X!IL*z!Ha}I2wTDz7W)RkK| z?>Z_H%7mZf(w{R#Achb|h;V(jRi~XxO3sP;1U30{Pj*8gyZ+-e5zi16V})~i00RTa z?w4$B-*01)OhRTguMQI-nyaY8$XhI#fV}?4k01B)8lFuFbTvGiivk!ymj&{^l}Y#_ zuGpZap&Rq|?NQlU6hVO-Kaa1crcO|blq8vzRTi>!5Gw*a9(-3$R`x||>NsN%;^ul) zgoO5*HERH#f>7Upz)k1&M+0Do}IPcn&qD!X2xF#YQX?qazh{oyDw~0I} zTPx6{6Gh4@B!xz=HB_YN8Z|28oAr{_{3nk??Qg%$(ExTeUw_7jic6PY1P1msvrV>`r_NkhtXEMw z25k*DgX*G`byc2iaJ+a`{l<+OfmchlGR*=KTmHH5^3{0Jq9P(bAUiudZWZzEG$cO3 z!>#W+Hx>~5&4vjdmxoUD9Z0{YyE_U?b?orrGf*&J1jk?d=DUD7rDtG>qdP2p9kVsm zQJ5c>3bWzfy?gN(v58Jfx3K1lAiq1Z!%$tE57}enZ^$0L(U?|K#4=nSAD7vYc%UYE z-~I=c{KufY2abM!$$OQaj_x4##`0q4YBk?zgoJAkW)gQhIFy)LJ^8Y@xEO`7zj<4v zH!5FXy14gV0lBIE8V$1b_Uswh6z<{S@h=+jKNbb-rz63l!@Ln00mXd=vfEq4lUBO% zGvL!iJiMBC(gPAWol?DcWL_xT^7+4CWI5jaPPwo!&R%OT^^t*S*dhZt-%4)S#xpL(d zks%x6Rb=)FS=N8JMWqH`szF3Tf+0jIhp@GaMJ(ZIuz51%dhnxQt{rR++ zNWWOV7=XT_G!EXmWw~lbdH>bYJ;HV~jPhF_RKVYehnOZ?dL*0Lcl`$L_k|r2yv5P53epv4`SQ+VKuXEH2-E45jFVokj~}ruLrxBnNz-e zIV)h*p@XztZO=vgD;Q{ppy;h%zuvh8DmoDo<1fBG4X~#I$XGKZB4}2B{`38%PD4YPX$MnbEfXQ&SrhNEtGSjM4k9b)-mBe4fL?U+%BMsL9WXW-_2;d=(HeTr=SbBc0zJU_;A4&y z;l%#?@3hcFZhJfXHk7n0bnRDmnb9E~=fs_#45X8}8alUxT}~0E4U{!&GJTXWE&D zL=6p~dU2l(>(?K{Td}h0$l*P`y)jRpZsF2=e-^IiMTCoZzGu(1@s2_oT3QVZQx)+7 z7f=aMUIPmr08RxEFJI2IU)WRucD(9Mq&mRBK3(~H!njH5^&%;T8Ot9;_2U!KiuUL3kU9&qNL=rjBhk4}gJY#ywZH z;oA^JokRc%B?lyZz~87thYu4jM`U4Q-y#oYAhA7}=(N@XJqSbU$Y3MtfzBV?b{Ik(vDeCmiqu{qBw9_*%{U>UqV_}ceGc!lTBm+NaI<$+1Gx8f> zhc*v}^zVYBbAYhSZ+rNYSr7CV?9R4^S>jSGQr6>EsBbYa$6cEbaVzrbrcb+AgkV- z7Lt;Z34quseXH~Rkw8(02ptbW-X+;Y*RkE+S?ln}q$`FR(p@`tW0^6)Yo>5&%_8>y z^&I(`c4JxJzCmrFsdyzIab79xwg?xO0*olLKsvFm(<1XZm7W;Rr7XYi8OU%*1yZ9a zsz;>rl=`~6{kk98BU{?4#i6{gtG?~Zm9qK$*)Hzzc-+7)g*cnc+{jx)rJ6zMAe^QKSxufJyVn^lQH9#DsS;anri2$Zks$;onudEj=zzRA7XW|T!SVNlanv}{d;;wvv5^yC*Cu$BGbd^JvoQW(Hk&KjQ@3bW+7{E;k;d#vrl#s^R88GPB2Qz_z| zu3GzuqbVes-FPJ^ctl9npX%uuM(~re;QK8VfGz==W5tIc%J> zomyUt^_Z4O@g=1hM~}aMY+P5CF4vuNR{WZJHWy}^r|e-}ZmOJm9ge|+vYo@zkw$Js z{i`9|Elb9M2YViO3rpqco;h{$_~(0*_k+1?h*4uZm=oMS>_A81)(=|v&PR5AkL!Qc zr}qEVYHJ?M-h8x-sdOT+2ZqMHe`>d|hb6-cpO|3HkpI{%PO_8sFk{MOd_OM^XVg}4 zHjEyc)?=lC9$2MUq2@Kze^0 z_aP}erZ}JILHMm}2RZnM$N%H@2+3=W;7v~G1z?DciLtlN_a?yY+QjD#)mV-Gc&Ikt z(DQecyi0gxdE7HD1+aURkLE7Qc^voUcV3rFds@(3_ZliY&I-eQGQ5ux9{Kd>6vyfr!smfIC&myf;h=)Gf7KU(R%-Xm&5|pxq)4k>vPsjrb;i5B1L-I;WphnB~>Qgz7u29P=J2^Rd?+Y!kg-itXZwaOk zJw2#u6VR4xd8sS?K#1rvAM{L5r5?jEsyYjWV4@?lr;+z|WuzFOnso z@I%ZJ8D6+g%aQ`;By7g*q@Hlo%&gAh&s@7WRN72_#W@hRVIachmZ+#GFrK3H1Rh@A ziGt7lC1;P{VKoJu(8{%q0sV@?dcxn=ByEJGrG*e0$n#Ag#Bae_6ZDHcAd$adCHw*y zC5WgxrOd7u0GUN*SAWQ`n1Wamejlq8nF6osE#!l|`MywlG#r@&a{BUlDmViu*_ZBj z9DtHi({O*s(W8J$0v=0F?vSI%XHTC#eF72(>3<0qwXYTGbc+(P>pKd6#W%xg!jSYr z>*y$#)nfzf|%HhTLwMKPs4M z*{(%+q)7{=RUdp*9VXHVNZU$_L{)W%lz*bM*A0Uq%^ze^F#;7pN+LBjygsvm^zmqV z*g)!UI_x9<266}K>#S(hK*&b8j){3jbe}j&*B~fSS4nEULAs* zZJ9Ut4_vSh{G*`TDY%092d_0Q5GXPbfptZeIpSevg*o`X8E8Q9FbSc!eKGY6I}fi2 z#zZ`EVM-YEr!)F9xWAT`4&U0qe31+kcW2R2&|FvgknS)X8+l?l#pyK4u((IVRCFpb zPth;d!@XUCUz6^Z?awFUht^g_GGijTivmzb=GyFhNK`;*9|UTLYK!P1%o6>TCydJJ z&q+%snAAj=K{bZ#)7yN94VvgGaO_P?m^nDtnEUDpe#?F*zY_(3fTg25-r00Z52J~% ze`N!U+ZD9&MWOLg6I8~2w50)N34~+}FcX?uTV*9cufaaS8xWGgmzp8L*o{cRH?%C8 zH?CO*@YaNM7aU9+1VMCE@$*F1`LubTbdd0-WX~Py8K@uxV zs{t+g5#c_oS+k6&($>-nfw|j^wy=>3p5hby>BJA2lJxlf=tvSKhGEDwFBaSEAJfOZ zckG3wI$7Jp=67{{(nJpv^p7?}L&M5Sl5~h?0X;JVB+9u(F$TkhFfCkx8-fPs)FA{7 zA1*<3G;2P1vBh9*%bBJ=W+U-L@?Yx;Hvd;ov2~1p^zgfcB3p!QcAc=n1%GDe0iXT=s`MjzFfu*P_ok z|JVI}in)~#Ew#|!*uR2ll2}!bS1thsx&aHL5xi7hPVPOV#>-#=O7oi5uO${o();@R zvwu#06b*~C($mvBhIfkfH;D*A5i*1-kqx?A^ zq~84Bk2!82J_DaWzXE2G4f6c5d9|?w#;|i^33l#R5OHH;V;GmaSy-%qyVb#zHgDaU ziDq)-{RlK&_v921=LK%hXs+kL_k%TamB`Pnq!p9DLZ=2@42D4VS?-GtiMsh&!NJd1 zq&lWVzC)+ih9issgK95`6wegI$iQHNC7NmTdG;(bCr6l{KUC5^uO0oFFp1FQ+%i=o zWo2wk7-Rsa=43t3%6jx*8v0$+xw1E|KGR%d7q`x3tdCaS&G@C|WdR5s2!E1hN#{5G zq7ztk+2GP#IOP2a<8b68rYiYcko(akfd;h$$LxZV;JwKCj^zz=lfNZ)rs#b0BOQLQml8pk^MD!bMy^6L$W2*=k==+JQpEy6D5$9Gh*j7Zz@x9H z+?P^X5y+*2&R+?iRpfg}mtp-mp@=&OE{RYDOmzA@SEg91g85~j{SsFl273m^3Ur_V zBSbydw)bWQS9Z^WNLTGHdirP-h;KDDN_ewo2qGqt{s2&3QEV+@_M+qPye|=Gp$Nu<>YKQ2+q7wu z%jCBsnHV_)7Gfz!ltS@72GK?>RZkZp(M7UX(*FK+N=BlEc?6fn54O4Aur>3T2y`J|jtHEAWnRT^|1T<2IluZVUzLOTa-}^D5nCNIUcF+0e z-(2I|3nla-9EYr|wuq-^%G(;xE5AN{PrUUxTGa<@q*hg-Z2xBjlcO!xobe$YpfU==LdY7+Xe`~_*Eqlj5SK=pnjr&)= zMGhjtm6w%04+;tbq7?7!x3&Gfd~kW(Jqwy2=dd9(esUZEVwfo;I;{eyv<|l^1vXaJ z0dxXX)|L)-n5?#~z^k(xs*QPqZ7#VCnP&kV2jV`Y3QdkGe&-C7)8WHAsy%FmsKV@B|Ntn(l3CW0_ji1dl~Vfh30tDb^=M0Oa+u?b8Kqj z21?Xz-E;gTv5`GimmUAD{_at0)?Y#aoW{bKqXxuDbn74ukOmb9jmOYKgT9F%bi#*r zXTX9Zc?wc4E$N|$@`Z-<2Bcf@(wXzYrTe$+6TGl_H|KXq_r6AVx0RVgZmuPF2w}|( z{S!o4gz3^F>`jieVBeU+#qFOBQKM^iv3uJU0t15L-G!W2WSsZ zFx4dWd3J}3JdPAZ3=(-0=vq+aXxa5?=2 zOW)#H3t0}dW%O&#j6!iU(rqhp&u2A76E<<|NKZB(L*&fj2n;NBYwLIY`LVe1PoF6;% zFDwkfnBt2oyvBRCk#d|g}wOSpvTBW^65V&bX!u@-`G z6Qd3JCEP}cugeWN@)EjB5@J<)SZ9r4v#IFu_?DzqrT1jLT2u>pE8`7Q% zJYP0hqWXI*3?4z4oBsath_sU>JJ?L;qvtKB<%&jfYT$kZD1cYSy`T| zE1C|81uw%q$CU51*)f?oVV}zYDR3=%oEJVq=qTEOV&O>*13;@nAP_J8sl!gl)_e4% z(^ig%WSf7h!O=$*?6XvFCXr9?Oqub;&&Y8d1eF=eg3D-T6QO>2y6O=_*c)g_N=&Ux zD*lgq)5dAa+qs73K8Uy+avE7`97Kx8M3z?!|6a{nX|t;#tXUohPFi)R?=c*}>6v5X zD9U{Qbu+yR(?V+|8N^X{OQ6Xh1cU{28>nTPsS$$J&~1~@9`tu`|C9${GD4? zp-KqIw}RTg?2SGcXNNWfb0{!q^?3?bH6VBN%t|*j`EHj9aAuQG2OQ%Qg^e1Rg+8Pn ze^R8$11)=j^PKrlAvjY&>?*{P|xkPk)h#xn+Z};(`=GcG#uTB!Wi$xWmzMSyeOr)Ow+fMkp-pDwd7+e6aVEZ;IdeM5M zv$(T#bT7?gaJ~6IE1#N$Zw_o9Pfh=@xY?u|bnqS@UTrCdi~0G%4R~VCzc^H&UKRkF z#3Nf2#=R;IHC?Ip84=7(3xktw^B)pr%*{~E_C9p%L*cbTc=^n;Xn*z3Fu5bFvdC}&TH;VJs z)&%V?wQ*xRC(FLv8N0Cu;bjpenD3~I_+=p;jK4HI%OIvW9p`)+ih?h*3zSbO^ULP5 zvB~Y7?kvuYWqkgil2hbCma32$j2q_%SMG}&7`L*a5vAC#Wmf)o4-3NM1EclR|DT+g z`0tK_ygzNpaPc`zkfZ#SqN_Q*^$xj;!;76kiBa9c4KybUbHfFtnjDJiBn^!#)?uca zdWNs`30I$&b@!Jl`k+@n60QAJYAjNr^-(D6)&T!78TZ|H=lLfM6mo-CugaE?k7)D` zU->8gHqJ`y3@9#c%i~>jo-;Le*uBaCLH^%^61r74jP&Mw3VMZCJ39(DoO2HMq^xpR z=x)EbR?qs;y0s5~TtBoYzU4m6mLKZA%C|xUojz_aFc65}^hoZuf{Y!Vf-+YYFDsw) z+7qwN?h{>MKXu8FZdYL9+BI~$cW=LT>)zDj9RrSEhYq|mEQ$;cH|TV)v5Ro8DH2<> z?s(F3#-jh^S-faH45%sRPCq=;qImlud0mhG^P7eIsyZ&FkSS-hj^UMtn zJC={HKfdQ-;2ecQ&rF^RFt(^kAFkFp z?7#r7-dlIF6ul3_nc?TH5)u=iiHVA`Ha0dYv{c9Nz~Qa^`t|D)xKo@=zLkVTVJujD zrnf^e?UTkv^>7%NwfOIdbOP;}GiQ2nivHk>^U?`V7IDJU-p<^7_@Ap+y9F)!YeQ#e z9Uh&2ef_$bneQ{>VnCMs%qt(!rAbA_8?wAjT2aya(wQ@NZo=q))>7SDT5p!g%EgtO znU?lLt~GZ%9o@5CdHAB_l9G}>+`o{Bh{$zw^Uru-087~t)kMN~sWLkIl6nPrA=priY7`Ay>Jx&?kb zlE5PFfrl#@4h?GU`kIsWzLxL`%mO}*#1ug?6dOA%&f`Bqh}AtL`6}V zWoosWey1AX@tl8>rE=iVp*IG6ocEf6Ospa6tVwq5`f%&lzIotue0@U8mJJ29b3ralt?#oaWPD^`1`G`Ecd(~hP?JWDC zxGblnL-|1G&&<4wynMy0#jP|npMc^ww0qUd&G%6++*p)^Zf-Til+u8gyYy}7&nZG1eV zaw{B@X)O#k>rG0E;?Cl{yu4D;(b3V1N9mWprlzEfT_S(`4Sp~26)SP3uK#jfef?c@ zkiID_ENq<&4BQQh6<6bcM$`Ms@l48*wz&mOpDx5GV-#yn_6v?$JgqmIk&xmyGBT2& zNe>JRv|MxyLfF+eNj;y-V)4CwdoAmcBZt}9Y2b^TQdHdLRXtY>aE#L^U7&m=0K{u3 zHa0dnP7{aFF8gR?WQ2JlMX!)1SH~ML^t$m^(tZ>sVn+=b*-JV83q)*z;YcyZZRC0| zZ&DYTDfGK`9YipqO&li65lR=%$N$W+ISj4yJ{lTL8@af-zhaCNApVC01a<}S=rae7 zk~C7duhzY?prGK2g~hY4U!`xf<KGc$Yl^%>*r$9kwPAA#(equOz98ONE{03QpB ziW&j{|Cyb=kIF_(!IxzY1UCw8$vHS%Fg}?Ud_9k zgSE^PO5vjSmX_SW;i$8+vi?GV_>-u=Oan!r6lnGjkh~#cZu@DR*`O#WC_I;o!BYLq zcjN)9mGZCR?Q?^3bGg_~}U8|(Q= zqrZ!bhgn(IL0K)Uu9lXO*#Mt`T1-srMrYCfZQHhyI|Gj16nx=6;Mp(0mIvYC`^zgT zCeYsgxvikT(1u)S;`cdRsN1o4asLGc1tRG_-6yooHkSzs!JYJUep_4H?R)k-MBC1% z`g(e3<|XKFk#Sqx`T)pu9lAA-g@uKEM_55_#hiBmrapM_f)0IiX)ZHnNgzPl`Jm<- zuq=qNyRTm#1dO*CtYt%+{62^V6wz#b3yb8w2XpN>%yaS5rCW&VE+5aO!w}yu>gjnS z-2Tqbf5ex={Ma@!I*PMRw;>*1*3>*GD!LcV!1piwb4Ed7D^!~+*RIu@FF|w1kgh_6 zxNd3r6`kgI8ab&$@ezt1cAL)y?O_Sg?;C+Fti4us=7$dG5xo%>i;wh@PdzJN&!SRkofU$E^718MyJxRnjoN4(+sADf#sp+sqKJa`uEw?CoTV7veRb|jJ>MQP)~FX)H-0<#Yhi;g!sdiwgS&MGQ? ze?b6C;7YUK-EIih8Zx)qprOCX(Q!_%yS>0!M?-e^XC%1bdv%j|w7i5YszhpMWr zxFD5xcTdk<7^rI~eEj^Ew6zn1GkK36KdGj+i~Nl2M|zd(Qj(Lmy12M3e^rks&we_2 z<_uM=V)$c}uKN1=142R!u&k&k=VO!=#-w&(Eu7%&Q7CAm-mZ!{q~SewKlS1y^}_`8zb7Q^LEa%MSaXOPNA*Z!H3v;)M!<2ke-fOk16b zT>3~RvEMlLPw_$r`B@p6&vkV>;oW@3X-DcXd5uVzLT?iiK0#kt zbCdaYKR%DzcIx%TE;vP$@6H>iFb1(#KY>iJ-Mun11?tTN;3H5dM>#p`-5xy6OdIyW z>BBxN+{+0ep~JkqbZ9vK0GH%AeBdvorL-bNj~;D`RyOtN1#D|KZioDdQ#=kePWbW9 z^z;|xNdqe@9~^Z#6Qg`8S^W$S@TGUOd+r1}E8Amh5S!RqXsW5nc#V${PnKB&AS&59 zI52RNBVlai1+V=O@kQ3+yx>5iF%%JK`}^A3+c)@YG|iiuREOOvDw0I!0gCt?i;q?j@H02oKPxJr-+@$9cPYcA(lA4JY0b#t~^k3C>kc*DEl zsVm0D)BvAMVh&rVsi{Mn5)%@xn3_I9j$nSEF|&JhjKh7bHJcU&`zJ_t){{N5Zg7Dp zqO>#RRaN(}bUn87U4pj*p+j%%uZfg7b!rXi18{P6r5b4S$wRxzhw^f{DYWbChfaS6 zBc7g_p<`m&a!|A;ck{-LUZJ7;&`9pWwBnSVKj*`(yZ9;~U{_^T)dcpbeJjuA&6^F7 zUPV;jOG&NVzyom@fGu9)Szq4F5|7~+Qo zn`xEKSDbMkpiJkh^`b0h6~7~q}MR30D+14F~x zm6aFpaIcNz1T;X{1DNC|550Kx_U%R(b$XE#LRKAHXlZEy<+{+#^mic2$GW$CSJgdP zGUp^i{DimC_nWG4nPI_zbYB2heX6OUMW8%<`g9%T!pq}p&>ZyvxpF~5qvG4QO$36F zx|e=bH(L1^H2bH}>p#PwPyDo77u_7hIT z;Tb@8AwnT|_0nU9?S6H4-@$I>6}XQX#ABvT%FAzN-SMc;Eg7v2AIr;W@Guc;N5=;c zU1OiAvX?-J-pQAH&kZNkoQx&H!14#}#xjTyI ztE@=%R#jE~P+h$Z&wsPFu{m||;&zDgci+4@1ZK4zCY!`>F=62YhYwTXu&Wnl8C@Co za4NzOGyl-Xrxa{(4Fx4>H)!6k-rjq#q5AND(s2 z+^ean30RCnNYu7=cKNzT&&I3%1|tRBxP$cD_dE%E6XyFFz+Iq{0YN`&p@Zw*zkh#X zbZTk}AY-eBh6c)zu$UO~7Yi;3ujAf@f9_!Xz?}m8GIw4C1guw5s^L&mQ%k3A|0~J3 zcduZgD*NZx8HH~1e3MgCym;0^)xGtUR|N%3!2BU+)-5XQ>OLzd5dYcQirfhB^|tlG zAWRkOnISb2peTrUUmKW&;EXBK@fR%8ud%U?{tLI1%YCY-gy3$NrKpsYZM%2xekpA8rf()Gi4z!~XvbHv!$pCYQ8nvA}At9lwr)S+OyWN@Z-|xuG%oKL}dmI4X zrK+L1IafJeRgw9xda-A0Z0uuri;wQiD+=5EUWdK}>7~E}Q8DIQkj1;O4RI{l5GNO? z%(MZmgDKx-kxp^59vQ2&|A%VTVvC%=>*utXS z;{IzX9J!~#ke~bcQDOfvi91=JcYfM{Pu|@wG4?t-D(Vhem)w3Xl-1OX+dNq>BU9?i zJht(sZfL2{3nr?9JGA89lTACW}<%xk6 z9CDjLlZJ!#EY8GzsHw5~o|YFTYEQHJw^S;RYif4(t2|HPiC448gy+wn_ex9SMaSJ{ zMDCioDx$Pq|0A7r97t{0MmQ`ok_C@QywBz#Cr1Ox9Uq^V$nC$N6x7n91tH=iHY6C~ znd)u>?n*6f?KHRpmK9sJYCw%OY8aF?;vE?PT-*>|qrY50d8-E02&{_tuwQe|UHM^Yg4xMay@$&*PL - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - image/svg+xml - - - - Benjamin Kosnik - - - - - - - - - - - - basic_hash_table_tag - basic_tree_tag - - - tree_tag - trie_tag - - associative_container_tag - - - - - cc_hash_table_tag - gp_hash_table_tag - - - - - list_update_tag - - rb_tree_tag - splay_tree_tag - - - - pat_trie_tag - - ov_tree_tag - - diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/assoc_container_traits.html b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/assoc_container_traits.html deleted file mode 100644 index 7814712c3..000000000 --- a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/assoc_container_traits.html +++ /dev/null @@ -1,170 +0,0 @@ - - - - - - - container_traits Interface - - - - -
    -

    container_traits Interface

    - -

    Traits of an associative-container based on its underlying - data structure.

    - -

    Defined in: tag_and_trait.hpp

    - -

    Template Parameters

    - - - - - - - - - - - - - - - - - -
    ParameterDescriptionDefault Value
    - 
    -class Cntnr
-
    -     		-

    Container type.

    -     		-
    - -

    Public Types and - Constants

    - -

    Container Attributes

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    TypeDefinitionDescription
    - 
    -invalidation_guarantee
-
    -     		- 
    -Invalidation guarantee.
-
    -     		-

    Invalidation-guarantee type.

    - -

    This is either basic_invalidation_guarantee, - point_invalidation_guarantee, or - range_invalidation_guarantee

    -
    - 
    -order_preserving
-
    -     		- 
    -True only if Cntnr objects guarantee storing  keys by order.
-
    -     		-

    Order-preserving indicator.

    -
    - 
    -erase_can_throw
-
    -     		- 
    -True only if erasing a key can throw.
-
    -     		-

    Erase-throw indicator.

    -
    - 
    -reverse_iteration
-
    -     		- 
    -True only reverse iterators are supported.
-
    -     		-

    Reverse iteration indicator.

    -
    - 
    -split_join_can_throw
-
    -     		- 
    -True only if split or join operations can throw.
-
    -     		-

    Split-join throw indicator.

    -
    -
    - - diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/assoc_design.html b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/assoc_design.html deleted file mode 100644 index 6c501e26b..000000000 --- a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/assoc_design.html +++ /dev/null @@ -1,46 +0,0 @@ - - - - - - - Associative Containers - - - - -
    -

    Associative-Container Design

    - -
      -
    1. Data-Structure Genericity
      2. - -
    2. Genericity discusses generic manipulation of - containers based on different underlying - data structures.
      3. - -
    3. Genericity discusses generic manipulation of - containers with different mapping semantics.
      4. - -
    4. Tree-Based - Containers describes the design and policies of - tree-based containers.
      5. - -
    5. Trie-Based - Containers describes the design and policies of - trie-based containers.
      6. - -
    6. Hash-Based - Containers describes the design and policies of - hash-based containers.
      7. - -
    7. List-Based - Containers describes the design and policies of - list-based containers with update policies.
      8. -
    -
    - - diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/assoc_examples.html b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/assoc_examples.html deleted file mode 100644 index b64c74745..000000000 --- a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/assoc_examples.html +++ /dev/null @@ -1,151 +0,0 @@ - - - - - - - Examples - - - - -
    -

    Associative-Container Examples

    - -

    Basic Use

    - -
      -
    1. - basic_map.cc - Basic use of "maps".
      2. - -
    2. basic_set.cc - Basic use of "sets".
      3. - -
    3. erase_if.cc - Conditionally erasing values from a container object.
      4. -
    - -

    Generics

    - -
      -
    1. assoc_container_traits.cc - Using container_traits to query - about underlying data structure behavior.
      2. - -
    2. hash_find_neg.cc - A non-compiling example showing wrong use of finding keys in - hash-based containers.
      3. -
    - -

    Hash-Based - Containers

    - - -

    Resize - Related

    - - -
      -
    1. hash_initial_size.cc - Setting the initial size of a hash-based container - object.
      2. - -
    2. hash_resize_neg.cc - A non-compiling example showing how not to resize a - hash-based container object.
      3. - -
    3. hash_resize.cc - Resizing the size of a hash-based container object.
      4. - -
    4. hash_illegal_resize.cc - Showing an illegal resize of a hash-based container - object.
      5. - -
    5. hash_load_set_change.cc - Changing the load factors of a hash-based container - object.
      6. -
    - -

    Hash-Function - Related

    - - -
      -
    1. hash_mod.cc - Using a modulo range-hashing function for the case of an - unknown skewed key distribution.
      2. - -
    2. shift_mask.cc - Writing a range-hashing functor for the case of a known - skewed key distribution.
      3. - -
    3. store_hash.cc - Storing the hash value along with each key.
      4. - -
    4. ranged_hash.cc - Writing a ranged-hash functor.
      5. -
    - -

    Tree-Like Containers (Trees and - Tries)

    - - -

    Node-Invariants

    - - -
      -
    1. tree_order_statistics.cc - Using trees for order statistics.
      2. - -
    2. tree_intervals.cc - Augmenting trees to support operations on line - intervals.
      3. -
    - -

    Split and - Join

    - - -
      -
    1. tree_join.cc - Joining two tree-based container objects.
      2. - -
    2. trie_split.cc - Splitting a PATRICIA trie container object.
      3. - -
    3. tree_order_statistics_join.cc - Order statistics while joining two tree-based container - objects.
      4. -
    - -

    Trie-Based - Containers

    - - -
      -
    1. trie_dna.cc - Using a PATRICIA trie for DNA strings.
      2. - -
    2. trie_prefix_search.cc - Using a PATRICIA trie for finding all entries whose key - matches a given prefix.
      3. -
    - -

    "Multimaps" and - "Multisets".

    -
      -
    1. basic_multimap.cc - Basic use of "multimaps".
      2. - -
    2. basic_multiset.cc - Basic use of "multisets".
      3. -
    -
    - - diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/assoc_performance_tests.html b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/assoc_performance_tests.html deleted file mode 100644 index 642f84809..000000000 --- a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/assoc_performance_tests.html +++ /dev/null @@ -1,345 +0,0 @@ - - - - - -Associative-Container Performance Tests - - - -
    -

    Associative-Container - Performance Tests

    -

    Settings

    -

    This section describes performance tests and their results. - In the following, g++, msvc++, and local (the build used for generating this - documentation) stand for three different builds:

    -
    -
    -

    g++

    -
      -
    • CPU speed - cpu MHz : 2660.644
      • -
    • Memory - MemTotal: 484412 kB
      • -
    • Platform - - Linux-2.6.12-9-386-i686-with-debian-testing-unstable
      • -
    • Compiler - g++ (GCC) 4.0.2 20050808 (prerelease) - (Ubuntu 4.0.1-4ubuntu9) Copyright (C) 2005 Free Software - Foundation, Inc. This is free software; see the source - for copying conditions. There is NO warranty; not even - for MERCHANTABILITY or FITNESS FOR A PARTICULAR - PURPOSE.
      • -
    -
    -
    -
    -
    -
    -

    msvc++

    -
      -
    • CPU speed - cpu MHz : 2660.554
      • -
    • Memory - MemTotal: 484412 kB
      • -
    • Platform - Windows XP Pro
      • -
    • Compiler - Microsoft (R) 32-bit C/C++ Optimizing - Compiler Version 13.10.3077 for 80x86 Copyright (C) - Microsoft Corporation 1984-2002. All rights - reserved.
      • -
    -
    -
    -
    -

    local

      -
    • CPU speed - cpu MHz : 2250.000
      • -
    • Memory - MemTotal: 2076248 kB
      • -
    • Platform - Linux-2.6.16-1.2133_FC5-i686-with-redhat-5-Bordeaux
      • -
    • Compiler - g++ (GCC) 4.1.1 20060525 (Red Hat 4.1.1-1) -Copyright (C) 2006 Free Software Foundation, Inc. -This is free software; see the source for copying conditions. There is NO -warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -
      • -
    -
    -

    Tests

    -

    Hash-Based - Containers

    -
      -
    1. Hash-Based - Text find Find Timing Test
      2. -
    2. Hash-Based - Random-Integer find Find Timing Test
      3. -
    3. Hash-Based - Random-Integer Subscript Find Timing Test
      4. -
    4. Hash-Based - Random-Integer Subscript Insert Timing Test
      5. -
    5. Hash-Based - Skewed-Distribution Random-Integer find Find Timing - Test
      6. -
    6. Hash-Based Erase - Memory Use Test
      7. -
    -

    Tree-Like-Based Containers

    -
      -
    1. Tree-Based - and Trie-Based Text Insert Timing Test
      2. -
    2. Tree-Based - and Trie-Based Text find Find Timing Test
      3. -
    3. Tree-Based - Locality-of-Reference Text find Find Timing - Test
      4. -
    4. Tree-Based - Random-Integer find Find Timing Test
      5. -
    5. Tree Split and - Join Timing Test
      6. -
    6. Tree - Order-Statistics Timing Test
      7. -
    -

    Multimaps

    -
      -
    1. "Multimap" - Text Find Timing Test with Small Average Secondary-Key - to Primary-Key Ratio
      2. -
    2. "Multimap" - Text Find Timing Test with Large Average Secondary-Key - to Primary-Key Ratio
      3. -
    3. "Multimap" - Text Insert Timing Test with Small Average - Secondary-Key to Primary-Key Ratio
      4. -
    4. "Multimap" - Text Insert Timing Test with Large Average - Secondary-Key to Primary-Key Ratio
      5. -
    5. "Multimap" - Text Insert Memory-Use Test with Small Average - Secondary-Key to Primary-Key Ratio
      6. -
    6. "Multimap" - Text Insert Memory-Use Test with Large Average - Secondary-Key to Primary-Key Ratio
      7. -
    -

    Observations

    -

    Underlying Data-Structure Families

    -

    In general, hash-based containers (see Design::Associative - Containers::Hash-Based Containers) have better timing - performance than containers based on different underlying-data - structures. The main reason to choose a tree-based (see - Design::Associative - Containers::Tree-Based Containers) or trie-based container - (see Design::Associative - Containers::Trie-Based Containers) is if a byproduct of the - tree-like structure is required: either order-preservation, or - the ability to utilize node invariants (see Design::Associative - Containers::Tree-Based Containers::Node Invariants and - Design::Associative - Containers::Trie-Based Containers::Node Invariants). If - memory-use is the major factor, an ordered-vector tree (see - Design::Associative - Containers::Tree-Based Containers) gives optimal results - (albeit with high modificiation costs), and a list-based - container (see Design::Associative - Containers::List-Based Containers) gives reasonable - results.

    -

    Hash-Based - Container Types

    -

    Hash-based containers are typically either collision - chaining or probing (see Design::Associative - Containers::Hash-Based Containers). Collision-chaining - containers are more flexible internally, and so offer better - timing performance. Probing containers, if used for simple - value-types, manage memory more efficiently (they perform far - fewer allocation-related calls). In general, therefore, a - collision-chaining table should be used. A probing container, - conversely, might be used efficiently for operations such as - eliminating duplicates in a sequence, or counting the number of - occurrences within a sequence. Probing containers might be more - useful also in multithreaded applications where each thread - manipulates a hash-based container: in the STL, allocators have - class-wise semantics (see [meyers96more] - Item 10); a - probing container might incur less contention in this case.

    -

    Hash-Based Containers' Policies

    -

    In hash-based containers, the range-hashing scheme (see - Design::Associative - Containers::Hash-Based Containers::Hash Policies) seems to - affect performance more than other considerations. In most - settings, a mask-based scheme works well (or can be made to - work well). If the key-distribution can be estimated a-priori, - a simple hash function can produce nearly uniform hash-value - distribution. In many other cases (e.g., text hashing, - floating-point hashing), the hash function is powerful enough - to generate hash values with good uniformity properties - [knuth98sorting]; - a modulo-based scheme, taking into account all bits of the hash - value, appears to overlap the hash function in its effort.

    -

    The range-hashing scheme determines many of the other - policies (see Design::Hash-Based - Containers::Policy Interaction). A mask-based scheme works - well with an exponential-size policy (see Design::Associative - Containers::Hash-Based Containers::Resize Policies) ; for - probing-based containers, it goes well with a linear-probe - function (see Design::Associative - Containers::Hash-Based Containers::Hash Policies).

    -

    An orthogonal consideration is the trigger policy (see - Design::Associative - Containers::Hash-Based Containers::Resize Policies). This - presents difficult tradeoffs. E.g., different load - factors in a load-check trigger policy yield a - space/amortized-cost tradeoff.

    -

    Tree-Like-Based Container - Types

    -

    In general, there are several families of tree-based - underlying data structures: balanced node-based trees - (e.g., red-black or AVL trees), high-probability - balanced node-based trees (e.g., random treaps or - skip-lists), competitive node-based trees (e.g., splay - trees), vector-based "trees", and tries. (Additionally, there - are disk-residing or network-residing trees, such as B-Trees - and their numerous variants. An interface for this would have - to deal with the execution model and ACID guarantees; this is - out of the scope of this library.) Following are some - observations on their application to different settings.

    -

    Of the balanced node-based trees, this library includes a - red-black tree (see Design::Associative - Containers::Tree-Based Containers), as does STL (in - practice). This type of tree is the "workhorse" of tree-based - containers: it offers both reasonable modification and - reasonable lookup time. Unfortunately, this data structure - stores a huge amount of metadata. Each node must contain, - besides a value, three pointers and a boolean. This type might - be avoided if space is at a premium [austern00noset].

    -

    High-probability balanced node-based trees suffer the - drawbacks of deterministic balanced trees. Although they are - fascinating data structures, preliminary tests with them showed - their performance was worse than red-black trees. The library - does not contain any such trees, therefore.

    -

    Competitive node-based trees have two drawbacks. They are - usually somewhat unbalanced, and they perform a large number of - comparisons. Balanced trees perform one comparison per each - node they encounter on a search path; a splay tree performs two - comparisons. If the keys are complex objects, e.g., - std::string, this can increase the running time. - Conversely, such trees do well when there is much locality of - reference. It is difficult to determine in which case to prefer - such trees over balanced trees. This library includes a splay - tree (see Design::Associative - Containers::Tree-Based Containers).

    -

    Ordered-vector trees (see Design::Associative - Containers::Tree-Based Containers) use very little space - [austern00noset]. - They do not have any other advantages (at least in this - implementation).

    -

    Large-fan-out PATRICIA tries (see Design::Associative - Containers::Trie-Based Containers) have excellent lookup - performance, but they do so through maintaining, for each node, - a miniature "hash-table". Their space efficiency is low, and - their modification performance is bad. These tries might be - used for semi-static settings, where order preservation is - important. Alternatively, red-black trees cross-referenced with - hash tables can be used. [okasaki98mereable] - discusses small-fan-out PATRICIA tries for integers, but the - cited results seem to indicate that the amortized cost of - maintaining such trees is higher than that of balanced trees. - Moderate-fan-out trees might be useful for sequences where each - element has a limited number of choices, e.g., DNA - strings (see Examples::Associative - Containers::Trie-Based Containers).

    -

    Mapping-Semantics - Considerations

    -

    Different mapping semantics were discussed in Motivation::Associative - Containers::Alternative to Multiple Equivalent Keys and - Tutorial::Associative - Containers::Associative Containers Others than Maps. We - will focus here on the case where a keys can be composed into - primary keys and secondary keys. (In the case where some keys - are completely identical, it is trivial that one should use an - associative container mapping values to size types.) In this - case there are (at least) five possibilities:

    -
      -
    1. Use an associative container that allows equivalent-key - values (such as std::multimap)
      2. -
    2. Use a unique-key value associative container that maps - each primary key to some complex associative container of - secondary keys, say a tree-based or hash-based container (see - Design::Associative - Containers::Tree-Based Containers and Design::Associative - Containers::Hash-Based Containers)
      3. -
    3. Use a unique-key value associative container that maps - each primary key to some simple associative container of - secondary keys, say a list-based container (see Design::Associative - Containers::List-Based Containers)
      4. -
    4. Use a unique-key value associative container that maps - each primary key to some non-associative container - (e.g., std::vector)
      5. -
    5. Use a unique-key value associative container that takes - into account both primary and secondary keys.
      6. -
    -

    We do not think there is a simple answer for this (excluding - option 1, which we think should be avoided in all cases).

    -

    If the expected ratio of secondary keys to primary keys is - small, then 3 and 4 seem reasonable. Both types of secondary - containers are relatively lightweight (in terms of memory use - and construction time), and so creating an entire container - object for each primary key is not too expensive. Option 4 - might be preferable to option 3 if changing the secondary key - of some primary key is frequent - one cannot modify an - associative container's key, and the only possibility, - therefore, is erasing the secondary key and inserting another - one instead; a non-associative container, conversely, can - support in-place modification. The actual cost of erasing a - secondary key and inserting another one depends also on the - allocator used for secondary associative-containers (The tests - above used the standard allocator, but in practice one might - choose to use, e.g., [boost_pool]). Option 2 is - definitely an overkill in this case. Option 1 loses out either - immediately (when there is one secondary key per primary key) - or almost immediately after that. Option 5 has the same - drawbacks as option 2, but it has the additional drawback that - finding all values whose primary key is equivalent to some key, - might be linear in the total number of values stored (for - example, if using a hash-based container).

    -

    If the expected ratio of secondary keys to primary keys is - large, then the answer is more complicated. It depends on the - distribution of secondary keys to primary keys, the - distribution of accesses according to primary keys, and the - types of operations most frequent.

    -

    To be more precise, assume there are m primary keys, - primary key i is mapped to ni - secondary keys, and each primary key is mapped, on average, to - n secondary keys (i.e., - E(ni) = n).

    -

    Suppose one wants to find a specific pair of primary and - secondary keys. Using 1 with a tree based container - (std::multimap), the expected cost is - E(Θ(log(m) + ni)) = Θ(log(m) + - n); using 1 with a hash-based container - (std::tr1::unordered_multimap), the expected cost is - Θ(n). Using 2 with a primary hash-based container - and secondary hash-based containers, the expected cost is - O(1); using 2 with a primary tree-based container and - secondary tree-based containers, the expected cost is (using - the Jensen inequality [motwani95random]) - E(O(log(m) + log(ni)) = O(log(m)) + - E(O(log(ni)) = O(log(m)) + O(log(n)), - assuming that primary keys are accessed equiprobably. 3 and 4 - are similar to 1, but with lower constants. Using 5 with a - hash-based container, the expected cost is O(1); using 5 - with a tree based container, the cost is - E(Θ(log(mn))) = Θ(log(m) + - log(n)).

    -

    Suppose one needs the values whose primary key matches some - given key. Using 1 with a hash-based container, the expected - cost is Θ(n), but the values will not be ordered - by secondary keys (which may or may not be required); using 1 - with a tree-based container, the expected cost is - Θ(log(m) + n), but with high constants; again the - values will not be ordered by secondary keys. 2, 3, and 4 are - similar to 1, but typically with lower constants (and, - additionally, if one uses a tree-based container for secondary - keys, they will be ordered). Using 5 with a hash-based - container, the cost is Θ(mn).

    -

    Suppose one wants to assign to a primary key all secondary - keys assigned to a different primary key. Using 1 with a - hash-based container, the expected cost is Θ(n), - but with very high constants; using 1 with a tree-based - container, the cost is Θ(nlog(mn)). Using 2, 3, - and 4, the expected cost is Θ(n), but typically - with far lower costs than 1. 5 is similar to 1.

    -
    - - diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/assoc_regression_tests.html b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/assoc_regression_tests.html deleted file mode 100644 index 9b6b6b839..000000000 --- a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/assoc_regression_tests.html +++ /dev/null @@ -1,93 +0,0 @@ - - - - - - - Associative-Container Regression Tests - - - - - -
    -

    Associative-Container Regression Tests

    - -

    Description

    - -

    The library contains a single comprehensive regression test. - For a given container type in pb_ds, the test creates - an object of the container type and an object of the - corresponding STL type (e.g., std::set). It - then performs a random sequence of methods with random - arguments (e.g., inserts, erases, and so forth) on both - objects. At each operation, the test checks the return value of - the method, and optionally both compares pb_ds's - object with the STL's object as well as performing other - consistency checks on pb_ds's object (e.g., - order preservation, when applicable, or node invariants, when - applicable).

    - -

    Additionally, the test integrally checks exception safety - and resource leaks. This is done as follows. A special - allocator type, written for the purpose of the test, both - randomly throws an exceptions when allocations are performed, - and tracks allocations and de-allocations. The exceptions thrown - at allocations simulate memory-allocation failures; the - tracking mechanism checks for memory-related bugs (e.g., - resource leaks and multiple de-allocations). Both - pb_ds's containers and the containers' value-types are - configured to use this allocator.

    - -

    Due to compiler constraints, the test is split into the - several sources, each checking only some containers.

    - -

    Tests

    - -

    "Set" - Tests

    - -

    The following check all "set" types:

    - -
      -
    1. hash_no_data_map_rand.cc - checks all hash-based "set" types.
      2. - -
    2. list_update_no_data_map_rand.cc - checks all list-based "set" types.
      3. - -
    3. tree_no_data_map_rand.cc - checks all tree-based "set" types.
      4. - -
    4. trie_no_data_map_rand.cc - checks all PATRICIA-trie-based "set" types.
      5. -
    - -

    "Map" - Tests

    - -

    The following check all "map" types:

    - -
      -
    1. hash_data_map_rand.cc - checks all hash-based "map" types.
      2. - -
    2. list_update_data_map_rand.cc - checks all list-based "map" types.
      3. - -
    3. tree_data_map_rand.cc - checks all tree-based "map" types.
      4. - -
    4. trie_data_map_rand.cc - checks all PATRICIA-trie-based "map" types.
      5. -
    -
    - - diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/assoc_tests.html b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/assoc_tests.html deleted file mode 100644 index 6e4474945..000000000 --- a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/assoc_tests.html +++ /dev/null @@ -1,24 +0,0 @@ - - - - - - - Associative-Container Tests - - - - -
    -

    Associative-Container Tests

    - -

    Associative-Container - Regression Tests describes the regression tests; Associative-Container - Performance Tests describes the performance tests.

    -
    - - diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/associative_container_tag.html b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/associative_container_tag.html deleted file mode 100644 index ceb91cdc7..000000000 --- a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/associative_container_tag.html +++ /dev/null @@ -1,47 +0,0 @@ - - - - - - - associative_container_tag Interface - - - - -
    -

    associative_container_tag Interface

    - -

    Basic associative-container data structure tag.

    - -

    Defined in: tag_and_trait.hpp

    - -

    Base Classes

    - - - - - - - - - - - - - -
    ClassDerivation Type
    - 
    -container_tag
-
    -     		-

    public

    -
    -
    - - diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/balls_and_bins.png b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/balls_and_bins.png deleted file mode 100644 index 529c3ae41bc45cabbeeecd17a3a88d6a82b59e5b..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 10139 zcmZ8n2RzjO|2K;4WYZb-rKoI&bCDU@GetNTGR_FuByyRV8E0lwBC=

    @9nSvo~k^ ze@@@}{vQ8(czE1>?sKotdpuvy*Yo-Md;&Gp9#W7plj7mwQ79?OY2o1!-UHspT_FJe zn1qhlj^tpIE60#lySBq$DS;<7%{)q~2omaHRQ^J(uI>i9pspu&Rp4 z(;)x8yn(CQy~Fghs#d|$mgGb#^>r_LUe6+fr$4@Riimvs?h*Yn%iA|H*~?uSE|Vzg zsXAzmm)u#p5zM=X6<_eo#&ko4u#U;%LOX`tH>%yHDpKMdJ4LXDj#G~2XBgx2qoJx@ zY66)DSFYf5uwU|jeO2*29z=!h_xr0CU-<4`slMYClc)Lj9N_r$`O8Qd>Hj@qLVqa( zZSMOlhVyeg4zG@lDpK!zm3sNUz}icZdrYh(I!H6#gS@ zgi_dT+LzdL`Ot2pY|?$jkL@J&bMr$sFWRwg&jq2n!%jPh6!iRLXKkv4Wxwst7n_l< zO?tnYf*B~fUH6uC4V+7&ellB~G*Ee)OqvZG6Ngw~YiB0v{(Mmvo;4-=1fP5$sy6$A2?{=Yp?DK}Hv;DG$ zx*MZvNf5J~UYmou^Fv0fj3gZ^{!2`o0*nbBQ#NsQ2k8JR=Y51=Y!ZG+v4O zp&*$|eOUn>ZrTScniIg*j_|XM9ux_-a~IEq&@AVFsXf|6Q>94xoUN5jvHD*&3y`y> zCs~*jWeEZUzvxn(2NCqaF7u}mbPvz95XqV@xb@nI{qkp47IWM{QHZ21fYYum%E0fb zyo;)nbeO#)AT(;X?p2)jB8mlJ`m9s1L|}k3iU@zHkf24Q(!!~MAIn4@7(X99q5V#tp_qeYhz{IrMV?ecEyDTooZ+sF*3xp4TWb{sz?tE z3wm1Fd?C=A{pev2A9G?0upx1`J~0A{?jJukNAH%1znp7XpQwTx$IYMiORSg6LTtjJ zxJAgyRy`_vvz?;gXq&bjDUR*(8OtJZ{uDLGbbpr)!IRqA;79zP^*-}T#;{U=dlY39 zWw2S;h-IT*#x?=~BI&fBo6YmcSf{JS3PTliM5VYr1vd95l(p37+`DW;a=+MZXMsi3 zw(+T^QAzHD+B>Y~CTAhQl!e}~J#_{pYr3^IN`RMBL!IK*sv)y578aH?-Yi|Uk_bwn z9tEy;c6LxHxqG0^JkvZAg$@lcB#JHmrNRd9-4y1Uh3#is{C?=fUO9-3!lrC~0bEAc zNNbBUKA!7!!N>G-HuTz|p{->&$@gT%lY3PKR z@IFH2r0UgLByLgWQEml+pB3lFt|%hu>WO!TTb7$d=Q(k^XgWbbk|ku(Wgl%_&aoY= z9PSjh!f3is_+dn2tI&SGz(NVQ#8C}!iRz5smvCV55@Yk3nUCxgm7po^=VvkhwyeE- zzo;ybv$X9Fs~#iq9Mdi1(E>E7Zb@zccopjokidaU8s^4Jh3R-x+`c|Sy7e`RCBF3< z;;Z-4D=jnoratw0KZGj?*?GnL#h|mR!aOI<7mbzFPy&`Pa3eb0G+F4Grlo&p0(llL z-}+#Eur%$2wi+57vKcjz7CJ^+5EZvpeV2Ypn?eJ&_@>D(!3=z0LsQY=!TiT0iK%^~ z70S55K0+!XoB9m?%`55TqJ&FPz6ji)tYkXfWKR22&UORUJx#ll?>o_?0I2p^lx2f> z9XVlm?Qtn5k4m(pS#;~DVLLeG0l&ksO(XyN&`;3x?Z_Y`H!J;$EiDy`tO};wy*%R- zRz!%H-0p+z%(CftfPfJyEdlUI#h>CCP{|o(`{}C&Q31AJ*bLbIyJH21=K+IhXy^kJ z)dFsdmDF9H(<#s)u3mRH{;E!h`zZm}Mj_WDs*La+@EVII(Y-{ixShSwp*`d~zj3nD-ahV#_XzcDUT9O$JTZ`7UVW+w-IGnE?YN|JEy#WsLlhHwSG~49|fAFLZ$|)&y|$j zIn~c+>8wB{Pj>19oQ4_koowG)yii2GRV#3dj-qT&XRH34bCGVpQIQUS7nu5OK9D&c z;=eGU(gokp-DJ&@T=oX1&FO~phwlU2gAC@yJX5MO_Lrz;%_lodzyp$}|K(a3iLRSc z6PlJP*jY5u!1v?w_)N{FGNZN2xC0W%k71cSC(<}f!f=pIZ72>Lo;Yyu=4j&Z3Ay`o z;;O=ZpRTDK`LY+Av| zf?eI|{z$P!V9Gt3;T-hXi^168vBql#^K?{qLI{87nnyF_MLNk~Z-C8BUtVE)Q|qfV zI?PKg3q6l0>_E;^(=eCz<%KpIBK*mv<`zeeE)DY+ zg5D;yiDC`}G0k=f55YjW(*S1u>Ggje87kYwxLlBzKLnR)I07hI&-#qkcv>yi zYIo)JH(iEm(+JtbPc^YqxYfBhVOI}WPE#@VZhhl7+=-t5Cb_+gyiHmO)J64cY|0Q1 zwUsSl{6!5{4JaYO3Ke8jVBvSP4#5OL|59a}5D#CjE3n2z>&;E*cbvt6`I`zXVV!Xk5g-Hayk=Y|iin}q#ud0GTvdUm_!+=I-&O}Z z!r^EWePr1dv|POA1z3e|DiclKk@B}HqJgPj6g~w}SsP5iZl#0CcPTPR{Fq5?Qa>pcGfCJMH}BmVv8}tz01U z2R7FL>QOQ=T#MC7MFYI&ved`vra-6(C?s&SC)-NalWQtc=ZD?uiDJ}UiI0uk-tJ&K zf$wM$Uq7nO>Kcnl>3)5Wqk~U5^+J&bZfoC$02;Ot!et1Jl`Rbq((K!WF^klO}tV(q3-9SP**JeUuO0mZGY*OB9qu(fx7AOkM(N73i0w3ql^)yR8 z!d)&g7(B^XA!OC+Nszb0%r>k%p=c~hmKPU?79p6S`UwrFTpM|wDFqyJ zOS(1_kzA34cZUaBRKJ{WTk6k_Fy*T~m^IPveAxyh@4}21SIHAG!He-FflIF2y=Ja* z-{Vnc#-{1YwQE?et(`283<48YMBckz%)|e?rY^cFl)eskuiu$H(8u3#keUvYur_;d zF{d+F6k90v>K!vhIX|a;nB!DWApic-jvqkpg*b7XLn4A9*&C`m6Y)!0xhb9-^O)OZ zb-2iSsNhzL=U1V`-@EcMOEncI)~B)gfNaXW{^C7_QGkr^Uia(`o&ZX;beU*`EA&?p z{KrA0v>ewEtdr~1JXSy3$kFq=jhKhY&BS2y?ib(z{{)QxvR2e8-pW5%rovc0W7}Jt zmUX|`B)NpdMWnrlE03OTojui6A3yp9^w;4I#_i@r)H|o-qt%h(_1tFY%?AFn60`OX z4dKIckWUfDjp!E5eQHr0qMhQ9*aQusL=89Nuf=W4!jbx7hmQj4$bwKf{a(@<4le3P z{b4Hr_nQr&6d$S&M#2|v2x{1{f)x14vs*3r{{dG}8Vs8kCkkGOpL-c*b@hfN4ov4o zprf@{H->QDB)LmOf}(iFutb305YmA+x(!I+c6j-=orw+bDr7dd&^H16L5m4xfyOib z4llro^ubueBfgh<#Ku1aXpg-RK1Rx*HG#vDMZAVFKzGgF2WAmrA8~t|gQHKfAD>9c zZ{XyCz-9=N5)_os)cUM4^yKu%uTc|W>7Au~Qb6JGqjRnz^yFC7JUHlCCvW<9_8_q1 zj_T!3);<+Lp&u}7#pWD-bbIc&f!xvNJie$2K~?LO!PX0=ENx$hi)G|I$i`%@QGI>MwSK6r?n9SW23(^ zkl19Ot4U@$q^HI>JHKD_iiVCwBH2UUmts2&&SKa>*@eS2M~RcZBqXHeXTQ1>XvK^1 zdx%#Px?~w}A8uRp1`%y#7nDe~$S-^QGN0%1S{VzgojjzY|Jt8jUtEw$VletO*QY;A75+X}l5a$6=aVH0XTti` zbC&L>a}5Y=Gsv+32Bqezn%n$5tDg(bhp4*S!A%lWGSH7^@i1ml1HlLZrFxgT;|aK4 zoAQk&Q;y8)$=K_JsxTd@qz=H&u*m9u8F4=V$Zm5@DB(6M_~t>H?vxuQ3GPt=HI{C) z2C8$Kb4i<}%(Eu{gh?TuLQQECKedv3j4ju!e1_TaJ9;&WXCQJ@6f~hKv{ZKj2^-N} ziQ+V4rZpqfV3B|HGO(Pt9?t;f9IA8p;1Vqr z*(Iwk)9aT@Ts9^*WeuMh{OF=`^Z|Sm#3rPF)c$@z$6a3v-kq>e8wX;}W3=h#aqT-H zkc!u+x8Q)sRUej4#c#E2uY91qlS;J}!oX|z!ZwuLQa~^`KU6r)TqKQaKO{k8B@Rfb zNE54;92c`;bp4AG#ZWjHaLjBg*#= z*hQD0_+3tBU!?5Ey!)G0bo?mu5xJ$pyH)c^p)Zpos90ak1b7w1%)L~?dT0K?X^84M z#=Q&2{x!=~L&*GeGUzg6Q~9z-{G})-eGqJ*F~62zp*I9|8}z{eGj8?t7t@o4NC%Vr zgXxA{G3%ERVy5FoLWBMZWByhqC^sWvphv*emnBsx5h|BSec6I(!TVq9&w(%nh5auv zqzQpt5f(qfK)~P4kLb}@Dyc%DSmRfE9c{`5#TLR4kIICh`_GSIOaD=<=)q z*K`s{C1oEbr=HtMchDc!a`bU!^==jM@jnbCIq#KzW z1kVO)FU!+dmC{&=tz{)>psi^U+Zmx_XKyK2t}FVA;Yti?E{HP4AG{4la4nt`+OvI( z)CBlKzClENra5zal$LBNjKI2#M5OszP;_Ry#%;cMj6bt{x)Rqw4s#}2FoQywuhhqF zUDO&JUeTG}-fu2rm+q>+XLniNjS(Pq9F=hbkPvoLzXlHKHA` z=RJF_%{VEsu2@*VPzgsia}6lR@=jE{Ij-jGWuT$={;dt!5*g^PeK4PsUu+W*Ccf|~ z5V$mi67_TJ0CmsqSHr_&G=aFWy8s|X-LJ+T^~h3%)?^9O_kVYJubM+ld0nwiW>CB! zP<>aRyRi@UWT}wPdn3zIb>N;F9X%1`8L_@D~^HqdPIn!zweSPiy+|oMkyMz6~?Afm* zNw1@}m^(|(fEx}_%RqGi5+tX3Zg^2K#bh>|->6DJjGL0K%KNmk!Tu@Gs=~*~NiroZ zFPvnrbOr2KY3ACr|0AvKP|-<~6iH11VJ0aTcKwKp27`@#AvfRBmNY=?cN6)>Ydo;c z%>fNnsw)V3u!;PnLNB%v7~jME*TlGRi@wUCqZu2lf#a8~fuU8X9^K|YGy5|9mW-iq zk>9PkFm znguwszzxcB)nC0`i=FiF*^WwSe7e;(m!*obk=`Y#QB^E{JclS*R$fKO96dE_zKYZ5 zEVz28o(yFg)7bwy9W0@@o@L~{^xY(bD<(FCpfok9I0&hGmC9qYffzvW`-hs*-xC*t z62C4LUIfepEHBxN(u5h1@QYI(>lMhMtY*q|HcveIMniebhC4hs=8gEGUMl4b|uhC5EVNDlmYOFje#@^lV8wduG4}Wl)@}oKAk@&vafZ;XJy2L z11g{QT_hvZ`0(@_@jeQUPBRO}FjTm{9zS-Z~r z;Fq!E#?TBx4%Ilx<)6qS6o3=xh#>;g|-$f+-!w+^{vOE9s zMD=%iXc=LUZcync6PX}tI@wT)b-I;vXC;tARM0;7=^p1kxS=?nl=5OK_aMA6d+X0! zCiYrxzAqoFIEL;I!^cer0zbGpF;04Fbm0F8dez0e9a+*?Gu=wO`FC5^aJB_$5wapV zp>d3sn#zFKj?gEeL2U87vxM7(wX;01560xu^*PJAndleNt9<-P;|8i5Q8v-6tOZ({ zj@Q^4g;#X~r1ViQrzDh|O#LCW-s^yGIV${t0YoJSjpx4{Hhm;r*}=!&NSJLi@hEEfF`9(vv%B zmU*gGX%PhXxBW|CA=nxUu~a9ZffNQlP@m21+{DzKKlW~$Pz|S}GT=oc`Kl+mT483F?RS_i_DGi2qn(#kV#Fb*`VTE|R7|@#~r;p&pz?7G>d* zPg|C#uZ7IaR@I?WlR@p5v*y=0*+qqbizc%Fbi5sNXEq9|2>nkWchS}Vj26Yq)9(jK zG{IX*zKKu6Va_EK+yU;l)sU*nsH-4)?^o0uTCQSBCU6*4DH-iU)Fx5!M|+E(cXQEw z{aks(v4Ho%XXDtTUq)#4aa~e~VUoqUKHF)n^G&3bT+;kIO4-mDfI%X~$~FC|9~vrv z?8cnHOh}-On*9J$e(DoW(;^xBUEkHICDpAQvJ}TBl$Mp<3Ebq-eC+E-TJd`OY+}Qk zSj?9zswH>xFt zVJBSBl?^WZKga{8u0vf5*+CzY!GIefh1QSwu2Qlb*Aq*cR2d82M}&uH5>C+>DIjM= z4V&3dv=hseR8aQ+{4w&=dF6awOUgwQoOd;Qjw1mc{xVaK!q#GIjE_f$Oe4~uq^tKg z+|*q|8g!*M$#XS>C=D(nP9P!JgLlZLS3hRZNKLyUy=YP7w~l}%OTUk^-+$=ayFS>t zKec2TWrWn-Kma@N;o~2lJ*`FIDD^dfVU*&1*+<7a&<*8Cqd7)OS?#*By)Qz+EaY`t zp>}ffZYUntk>hxaWPyP=Nxt}GFwo@@Z8QnDH8exK9=My0yVlMOmCu34)UnZBvAg_Y z5sf_zI?>7CK<8nID{8kSFcV-aBwaJUUQU2MwbAfRTR;Hs0qe=s$}Rh)oS~f}!1!!C z7U5f>?!6s#J$qN=hj9Viq?>BH&Js(kJxKhOvz7 zP+van#&Hqmr|lD8yJfc7;5^=8m}6QAq>;MQ|upZBbE? z2iBHQ@RPv)>Ij@)7_i7N_fh^dX49G1O2$1miF9cC&E>0T=h?uOEmnSllsZXEYu?4>we5I$ zk=u?rq2T2vTo!nl+!R3Q%^{#rLt?wAWN?5lAJ7eo6sr%T=xTe95J0s(84Y`478C2a zUV)he5YQyaJ`XspjZp$i!`2@hv;oXgN4@XQW*O@E8MB6PK*Th}Ym7wE9xoFbD^7ln zK7}n=qQhRwvL-&}5=D$YpJW49lx_8MIT*bJRjay>G8%sT?c~0sB|+T;OPl5>^LGM06`S3+_tc|}ke}ax&qxMKn~oQI(@Q6O z7j{36@ZU%1n_m~RXa6vh7-Hs)1N*fVe)l?e-0X^Ib%EyRC>zkl-({e|!^;5LfW zDhFAHp448hddx?3R%YjS2LgmxF%NKa-0*|!qt<=ilQVC8oFDFzVUe?1y>_{`JGiFQ zRo{IyV+dCLd~JPz^qdxhxYo~gT`6Yu;=aP2P3^kVHM{if7p_bL-Kmu5w9VrMA=ier zl4Rshr$1;9L;1l%1_A21|%+PyE$(J1j^&b`cmtbB`Z@SDcI@ z@5&6g^SW6!w1#gfY!oBp>VG=7#s9|fQ`fUlzt~AJ5WVv+lq@{Hp6DgVcuWy=4= ztPE0L)4L8))!`4hhd7aK>TL!su(}%1wmPf}kZ-(IBg8e=oOpz)8?<|y@#$vs7BA~D zv`_Idb?v+bvkFDOuRkm$%sbd=lv5;~`R06Ho%Tg(ibod}8b5RbQ%(w6kTHdeJ}AS; zn>%1>{YKvrw6ZgZp97Y5$U~kPl!)eJ5uEF`vA% zRn-&CyHaV*VKXw8vc(+B(`y5~noY%^BqZ%!_iXw`w;I^IR%yIVcy8u*&*xvM~etT)x8=j8o=uzG}SU|P0un);;L5u;{q zjg`a6W@_28iB~MKLt2{sV*Rl}}#cpgR`UlpP`bZNk+yY4)vNSB9APN%`@8_SMmE!RanI z{EKoA(`Vi@ zhWAork_#U}{_8Op1r9dh_?-h-)pvAiLNfQZW{A(mcz-!D(hSB?uG}f!w~OPVfRMW= zIKv^IzH}r^U6qvf{^lI#K`+O6%cAdE@@4TB**%9V<3R&U=5pxNs%-k@j|$8}Tn{K7 zJ{K7#>JnHpE#h+qt6Qap<`1Q4?UFMljQTt%-;Md=*+fle)*Ri#2QM!THt(S(f+i{T zmcT~v#6cP4*RjkmG1?G>jQgvnqdFT1y+^438X`HCf1h-DFbIe%-H94^vA++Vu)~2) zgy8yh5!JuXwd61ZE-bI=G1V>HvoROX!#ocGBz|*JdKSsw=UjAg#Nv!yp80dm72gn` z0n}dZI3WBtda4x=y={Hc5z_?{vw!Uu24VCI({_?VCTY z;B$)ruK1p6Xr4T7DB&aoffi9J$?lWpipb93bFFVTzbCTJ8t=AgP0`t?WG0p+E2Og@ zBx;wt?Qo6WE)U&*Q@j_lkmz?;4xBG0?s zIh{t&;EP&dqW2>6p7}Opj?8{cJW6JC>~RZj+~a`87lgoAWi9j^>@_Ua3E@iWnSq#LAl)%Q&jY(_~}s`dsI zZ~Rmt;jzlA5Bz8HYrW9y_iO%BTHkXjff?nn;{U{i`q*A$IOyJ2yXO5WMUt5#qIg+A z<@|LYY)K#`t9f5xTUcCT$X171&@92?$^ktC57likhluFDSF>3wD?kwa$Coxg@TLx` zMV7ckmirT>NY^Du4iy!E_QEhg|1XAUk%Ph0d?1sYA#=dfHeL2BtCclh6DF#mAPD$% z9H}o?>Y!`!=H~)ip%I;Xy;y$$3G`vQMw}Civr(>d|BPjHSB6$5s5471useUbIX5_E z6^etA2{pl~;qwETXG*W-7Ymj*`e6Ao;7%;BCmENjkX4?1_|E~9JN?DNF90|-o0PUn z{tZ6>4jT7>oW37?1@Epp1q8q7UNw@`$13 z24H0_GUbYI2QCY${RW_aqo+OvqUWtWy&v~?I^p8LbmCpY6aLFFo#6U9{M!6-Iu>`C Remvl%B(Ek{AY=08{{TMDT&Vy6 diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/basic_hash_table.html b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/basic_hash_table.html deleted file mode 100644 index 668e681d8..000000000 --- a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/basic_hash_table.html +++ /dev/null @@ -1,436 +0,0 @@ - - - - - - - basic_hash_table Interface - - - - -

    -

    basic_hash_table Interface

    - -

    An abstract basic hash-based associative container.

    - -

    Defined in: assoc_container.hpp

    - -

    Template Parameters

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    ParameterDescriptionDefault Value
    - 
    -typename Key
-
    -     		-

    Key type.

    -     		-
    - 
    -typename Mapped
-
    -     		-

    Mapped type.

    -     		-
    - 
    -class Hash_Fn
-
    -     		-

    Hash functor.

    -     		-
    - 
    -class Eq_Fn
-
    -     		-

    Equivalence functor.

    -     		-
    - 
    -class Resize_Policy
-
    -     		-

    Resize policy.

    -     		-
    - 
    -bool Store_Hash
-
    -     		-

    Indicates whether the hash value will be stored along - with each key.

    -     		-
    - 
    -class Tag
-
    -     		-

    Mapped-structure tag.

    -     		-
    - 
    -class Allocator
-
    -     		-

    Allocator type.

    -     		-
    - -

    Base Classes

    - - - - - - - - - - - - - - - - - - - -
    ClassDerivation Type
    - 
    -Resize_Policy
-
    -     		-

    public

    -
    - 
    -container_base
-
    -     		-

    public

    -
    - -

    Public Types and - Constants

    - -

    Policy Definitions

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    TypeDefinitionDescription
    - 
    -hash_fn
-
    -     		- 
    -Hash_Fn
-
    -     		-

    Hash functor type.

    -
    - 
    -eq_fn
-
    -     		- 
    -Eq_Fn
-
    -     		-

    Equivalence functor type.

    -
    - 
    -resize_policy
-
    -     		- 
    -Resize_Policy
-
    -     		-

    Resize policy type.

    -
    - 
    -store_hash
-
    -     		- 
    -Store_Hash
-
    -     		-

    Indicates whether a hash value is stored with each - entry.

    -
    - -

    Public Methods

    - -

    Constructors, Destructor, and - Related

    - - - - - - - - - - - - - -
    MethodDescription
    - 
    -virtual 
-  ~basic_hash_table
-  ()
-
    -     		-

    Destructor.

    -
    - -

    Policy Access Methods

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    MethodDescription
    - 
    -hash_fn &
-  get_hash_fn
-  ()
-
    -     		-

    Access to the hash_fn object.

    -
    - 
    -const hash_fn &
-  get_hash_fn
-  () const
-
    -     		-

    Const access to the hash_fn object.

    -
    - 
    -eq_fn &
-  get_eq_fn
-  ()
-
    -     		-

    Access to the eq_fn - object.

    -
    - 
    -const eq_fn &
-  get_eq_fn
-  () const
-
    -     		-

    Const access to the eq_fn object.

    -
    - 
    -resize_policy &
-  get_resize_policy
-  ()
-
    -     		-

    Access to the resize_policy - object.

    -
    - 
    -const resize_policy &
-  get_resize_policy
-  () const
-
    -     		-

    Const access to the resize_policy - object.

    -
    - -

    Private Methods

    - -

    Resize Methods

    - - - - - - - - - - - - - -
    MethodDescription
    - 
    -virtual void 
-  do_resize
-  (size_type new_size)
-
    -     		-

    Resizes the container object to new_size.

    -
    -
    - - diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/basic_hash_tag.html b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/basic_hash_tag.html deleted file mode 100644 index 9dc5e6d86..000000000 --- a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/basic_hash_tag.html +++ /dev/null @@ -1,47 +0,0 @@ - - - - - - - basic_hash_tag Interface - - - - -
    -

    basic_hash_tag Interface

    - -

    Basic hash data structure tag.

    - -

    Defined in: tag_and_trait.hpp

    - -

    Base Classes

    - - - - - - - - - - - - - -
    ClassDerivation Type
    - 
    -associative_container_tag
-
    -     		-

    public

    -
    -
    - - diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/basic_invalidation_guarantee.html b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/basic_invalidation_guarantee.html deleted file mode 100644 index d4a0df23f..000000000 --- a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/basic_invalidation_guarantee.html +++ /dev/null @@ -1,26 +0,0 @@ - - - - - - - basic_invalidation_guarantee Interface - - - - -
    -

    basic_invalidation_guarantee Interface

    - -

    Signifies a basic invalidation guarantee that any iterator, - pointer, or reference to a container object's mapped value type - is valid as long as the container is not modified.

    - -

    Defined in: tag_and_trait.hpp

    -
    - - diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/basic_tree.html b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/basic_tree.html deleted file mode 100644 index 3811707fa..000000000 --- a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/basic_tree.html +++ /dev/null @@ -1,660 +0,0 @@ - - - - - - - basic_tree Interface - - - - -
    -

    basic_tree Interface

    - -

    An abstract basic tree-like-based associative container.

    - -

    Defined in: assoc_container.hpp

    - -

    Template Parameters

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    ParameterDescriptionDefault Value
    - 
    -typename Key
-
    -     		-

    Key type.

    -     		-
    - 
    -typename Mapped
-
    -     		-

    Mapped type.

    -     		-
    - 
    -class Tag
-
    -     		-

    Mapped-structure tag.

    -     		-
    - 
    -class Node_Update
-
    -     		-

    Node updater.

    - -

    Restores node-invariants when invalidated.

    -     		-
    - 
    -class Policy_Tl
-
    -     		-

    Policy typelist.

    - -

    Contains subclasses' policies.

    -     		-
    - 
    -class Allocator
-
    -     		-

    Allocator type.

    -     		-
    - -

    Base Classes

    - - - - - - - - - - - - - - - - - - - -
    ClassDerivation Type
    - 
    -Node_Update
-
    -     		-

    public

    -
    - 
    -container_base
-
    -     		-

    public

    -
    - -

    Public Types and - Constants

    - -

    Key-Type Definitions

    - - - - - - - - - - - - - - - - - -
    TypeDefinitionDescription
    - 
    -const_key_reference
-
    -     		- 
    -typename container_base::const_key_reference
-
    -     		-

    Const key reference type.

    -
    - -

    Policy Definitions

    - - - - - - - - - - - - - - - - - -
    TypeDefinitionDescription
    - 
    -node_update
-
    -     		- 
    -Node_Update
-
    -     		-

    Node updater type.

    -
    - -

    Iterator Definitions

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    TypeDefinitionDescription
    - 
    -const_iterator
-
    -     		- 
    -typename container_base::const_iterator
-
    -     		-

    Const range-type iterator.

    -
    - 
    -iterator
-
    -     		- 
    -typename container_base::iterator
-
    -     		-

    Range-type iterator.

    -
    - 
    -const_reverse_iterator
-
    -     		- 
    -Const reverse range-type iterator.
-
    -     		-

    Const reverse range-type iterator.

    -
    - 
    -reverse_iterator
-
    -     		- 
    -Reverse range-type iterator.
    
-If Mapped is null_mapped_type, then this is synonymous to const_reverse_iterator
-
    -     		-

    Reverse range-type iterator.

    -
    - -

    Public Methods

    - -

    Constructors, Destructor, and - Related

    - - - - - - - - - - - - - -
    MethodDescription
    - 
    -virtual 
-  ~basic_tree
-  ()
-
    -     		-

    Destructor.

    -
    - -

    Policy Access Methods

    - - - - - - - - - - - - - - - - - - - -
    MethodDescription
    - 
    -node_update &
-  get_node_update
-  ()
-
    -     		-

    Access to the node_update - object.

    -
    - 
    -const node_update &
-  get_node_update
-  () const
-
    -     		-

    Const access to the node_update - object.

    -
    - -

    Find Methods

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    MethodDescription
    - 
    -iterator
-  lower_bound
-  (const_key_reference r_key)
-
    -     		-

    Returns an iterator corresponding - to the entry whose key is the smallest one at least as - large as r_key.

    -
    - 
    -const_iterator
-  lower_bound
-  (const_key_reference r_key) const
-
    -     		-

    Returns a const iterator corresponding - to the entry whose key is the smallest one at least as - large as r_key.

    -
    - 
    -iterator
-  upper_bound
-  (const_key_reference r_key)
-
    -     		-

    Returns an iterator corresponding - to the entry whose key is the smallest one larger than - r_key.

    -
    - 
    -const_iterator
-  upper_bound
-  (const_key_reference r_key) const
-
    -     		-

    Returns a const_iterator - corresponding to the entry whose key is the smallest one - larger than r_key.

    -
    - -

    Erase Methods

    - - - - - - - - - - - - - - - - - - - -
    MethodDescription
    - 
    -iterator
-  erase
-  (iterator it)
-
    -     		-

    Erases the value_type corresponding to the iterator it. Returns the iterator corresponding - to the next value_type.

    -
    - 
    -reverse_iterator
-  erase
-  (reverse_iterator it)
-
    -     		-

    Erases the value_type corresponding to the reverse_iterator - it. Returns the reverse_iterator - corresponding to the previous value_type.

    -
    - -

    Iteration Methods

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    MethodDescription
    - 
    -reverse_iterator
-  rbegin
-  ()
-
    -     		-

    Returns a reverse_iterator - corresponding to the last value_type in the - container.

    -
    - 
    -const_reverse_iterator
-  rbegin
-  () const
-
    -     		-

    Returns a const_reverse_iterator - corresponding to the last value_type in the - container.

    -
    - 
    -reverse_iterator
-  rend
-  ()
-
    -     		-

    Returns a reverse_iterator - corresponding to the just-before-first value_type in the - container.

    -
    - 
    -const_reverse_iterator
-  rend
-  () const
-
    -     		-

    Returns a const_reverse_iterator - corresponding to the just-before-first value_type in the - container.

    -
    - -

    Split and join - Methods

    - - - - - - - - - - - - - - - - - - - -
    MethodDescription
    - 
    -void 
-  join
-  (basic_tree &other)
-
    -     		-

    Joins two trees. When this function returns, - other will be - empty.

    - -

    When calling this method, other's keys must be all larger or - all smaller than this object's keys, and other's policies must be - equivalent to this object's policies.

    -
    - 
    -void
-  split
-  (const_key_reference r_key, 
-    basic_tree &other)
-
    -     		-

    Splits into two trees. When this function returns, - other will contain - only keys larger than r_key.

    - -

    When calling this method, other's policies must be - equivalent to this object's policies.

    -
    -
    - - diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/basic_tree_assoc_container_const_node_iterator.html b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/basic_tree_assoc_container_const_node_iterator.html deleted file mode 100644 index 5647f551e..000000000 --- a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/basic_tree_assoc_container_const_node_iterator.html +++ /dev/null @@ -1,383 +0,0 @@ - - - - - - - tree::const_node_iterator - Interface - - - - -
    -

    tree::const_node_iterator - Interface

    - -

    Const node iterator.

    - -

    This is an &qout;iterator to an iterator&qout; - it - iterates over nodes, and de-referencing it returns one of the - tree's iterators

    - -

    Public Types and - Constants

    - -

    Iterator Definitions

    - - - - - - - - - - - - - - - - - - - - - - - - - -
    TypeDefinitionDescription
    - 
    -iterator_category
-
    -     		- 
    -trivial_iterator_tag
-
    -     		-

    Category.

    - -

    This tag identifies that the iterator has none of the - STL's iterators' movement abilities.

    -
    - 
    -difference_type
-
    -     		- 
    -void
-
    -     		-

    Difference type.

    -
    - -

    Value-Type Definitions

    - -

    Note that a node iterator's value type is actually a tree - iterator.

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    TypeDefinitionDescription
    - 
    -value_type
-
    -     		- 
    -container_base::const_iterator
-
    -     		-

    Iterator's value type.

    -
    - 
    -reference
-
    -     		- 
    -container_base::const_iterator
-
    -     		-

    Iterator's reference type.

    -
    - 
    -const_reference
-
    -     		- 
    -container_base::const_iterator
-
    -     		-

    Iterator's const reference type.

    -
    - -

    Metadata Definitions

    - -

    These are only defined if - basic_tree::Node_Update - is not null_tree_node_update

    - - - - - - - - - - - - - - - - - - - - - - - - - -
    TypeDefinitionDescription
    - 
    -metadata_type
-
    -     		- 
    -typename basic_tree::Node_Update::metadata_type
-
    -     		-

    Metadata type.

    -
    - 
    -const_metadata_reference
-
    -     		- 
    -typename Allocator::template rebind<
-    metadata_type>::other::const_reference
-
    -     		-

    Const metadata reference type.

    -
    - -

    Public Methods

    - -

    Constructors, Destructor, and - Related

    - - - - - - - - - - - - - -
    MethodDescription
    - 
    -inline 
-  const_node_iterator
-  ()
-
    -     		-

    Default constructor.

    -
    - -

    Access Methods

    - - - - - - - - - - - - - -
    MethodDescription
    - 
    -inline const_reference
-  operator*
-  () const
-
    -     		-

    Access.

    -
    - -

    Metadata Access Methods

    - -

    These are only defined if - basic_tree::Node_Update - is not null_tree_node_update

    - - - - - - - - - - - - - -
    MethodDescription
    - 
    -inline const_metadata_reference
-  get_metadata
-  () const
-
    -     		-

    Metadata access.

    -
    - -

    Movement Methods

    - - - - - - - - - - - - - - - - - - - -
    MethodDescription
    - 
    -inline const_node_iterator
-  get_l_child
-  () const
-
    -     		-

    Returns the const node iterator associated with the - left node.

    -
    - 
    -inline const_node_iterator
-  get_r_child
-  () const
-
    -     		-

    Returns the const node iterator associated with the - right node.

    -
    - -

    Comparison Methods

    - - - - - - - - - - - - - - - - - - - -
    MethodDescription
    - 
    -inline bool
-  operator==
-  (const const_node_iterator &other) const
-
    -     		-

    Compares to a different iterator object.

    -
    - 
    -inline bool
-  operator!=
-  (const const_node_iterator &other) const
-
    -     		-

    Compares (negatively) to a different iterator - object.

    -
    -
    - - diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/basic_tree_tag.html b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/basic_tree_tag.html deleted file mode 100644 index 8eca2a818..000000000 --- a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/basic_tree_tag.html +++ /dev/null @@ -1,47 +0,0 @@ - - - - - - - basic_tree_tag Interface - - - - -
    -

    basic_tree_tag Interface

    - -

    Basic tree-like data structure tag.

    - -

    Defined in: tag_and_trait.hpp

    - -

    Base Classes

    - - - - - - - - - - - - - -
    ClassDerivation Type
    - 
    -associative_container_tag
-
    -     		-

    public

    -
    -
    - - diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/binary_heap_tag.html b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/binary_heap_tag.html deleted file mode 100644 index 47873b1cf..000000000 --- a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/binary_heap_tag.html +++ /dev/null @@ -1,47 +0,0 @@ - - - - - - - binary_heap_tag Interface - - - - -
    -

    binary_heap_tag Interface

    - -

    Binary-heap (array-based) data structure tag.

    - -

    Defined in: tag_and_trait.hpp

    - -

    Base Classes

    - - - - - - - - - - - - - -
    ClassDerivation Type
    - 
    -priority_queue_tag
-
    -     		-

    public

    -
    -
    - - diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/binary_priority_queue_random_int_push_timing_test_gcc.png b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/binary_priority_queue_random_int_push_timing_test_gcc.png deleted file mode 100644 index 07f0953a661467d0953c8cf555161522bdc26b89..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 5357 zcmcgwc{r49-@YXklWdigEtN_!m?XQbNp>QcL1l#OhD=!^TORQw#vuDnB(e`7R0czY zY}uEwWDObjdyVh;j`#Tf``+)5?>>&1Ykt>nJJ0iXFUQx?+K}0M>Btk?oM1<+7WE4ckLS!ODCPQQxRDxg>1Y;qX2*G3s1_r1N zN`qP;8AQYMKJ){NLJ?6YG71IL+X4%VMPZ33EE$D`=_r7ch(!^JC?Xj}gz2C_EE$U; z6H#O`iVOpcAQc5;Q7{n&lTk3}3Q&V$05m`eU;!U!3~GbYpcY7m>4fMuIEYv*8HbIRGX=7%&8=K`{UtWCB*h~uG_+I8c{i3@M2sp*33LAei3r3m~f z7TDI3JEhOg&g#yWl(f|1ly)sAvGqRh`7uUi#k6&1|5Ser#5BXC{~s+uEO?H$7yZJP zQiCyHO*?TkBL))0LP4ZJU`d~yWNS|0)=1%2X23HX1xsozMxHI+ER)@EOOCKKy#D99 zR^<&I-YQ=&qUd%`6Y`9Of@iM|?I$zqn%g6evHX~(k)raPBCFSS>mQ}6~_8TkC&R+ zG|zBxpXWCh-rE~#62I*w$G3YquiaBDup{-c7Lx5uu{8f%&iF6gmms>`I7X0R89;llGfKYM zqP9CMO;4rnaZf!+%4rnfqN)cK#w!s+FehfOBl%kwdJ|QXdf0p^L=3jTPXtQ|uNh$_ ziAx4ze2pQJ_&%UtY+T<|Q84BD z(Vj7L?KVxl`I7TY(BH0OmZbs5m71I6{f(;`Dg`!W z!t{FJQ#>WSMPSU*jCxRM#;R6Z98~PyAC+jigSf#6NINDAh`QY=h;CzQ zd{kJ~F;yeifEiqtRcn?v=qW%a-zDv)u2BPPNk6!-3X=$3=sGMm#hXyS4EiXOO&5Y*^*{ zE3u3gzH*h9E&97UOL7PJW2= zI%8q`VZvJtyo5l_6u~;+h-o`h1MfjAc@dqvq?sel2j24H4LrB)%Px1mYKd`wCf>pj zw-lT87PFIbEIY91z(g8jR+*?l_iLpNS8uC%hD+bS1%}b$Ujl-4HGQVWtEPVCcrjB=N8tw5fQ&um+U24;l)J76l zX`6%bPQr@j(ZV6U0z?!u%qw>yvc{V#^gH>UiMeq2O%k?3({brf7>-0p#2)!tI#cE@ zf*9sT6_r+(`%Nszr%F;&XBJXEC8!GOv|kh2;g(AnY)`y7F5ux=B!6CPC91Pue$DNR z;?n0sG<$hga_*pCrmZXWj9f9RpV6+FKtHXtYPh-6WMb`v&GdVj2gU-2H4W#}$@j7< zTW6&wBjBbHy*#Saj_WPE+GcXjh|Tgyuf~&j$LTtHeskTxw)p@@Ax6Vfv|E1J+PO=C zCjz1jJjgCYtjysWHDnYE7m|V~ZTOsl?>`oBIy6CMT}UuSg`7{Yk0HI_S>I=AA(Qnj zyf1LUp?h6rstb{IIg@w;$*#?`bGKlv1G}g+X;CHSIl!)c>}7Qg3$28>-Dr3LXW#En0ZFz#cw(6+BzD^b;_4n#XJSfrsmszlS7S^oBbAjyK!l%F@bgP!szmlv)^qNiHu*d0LuDe6YOKDsk+^#G-%ucj4b-{E4;aiyOd4nnCXstO#c+mvyCwKQk zri68%)9%nagHI>*)Lt*D-8%g?1i$5#8oQAp>wg28^^IA$Mz$$c`_tV^uvm8&BM<(L z-T*nHS9ok_TG(cF>0Wym^L12Qi-t)2FDHc%(d>rw2L%B_TVAJQokG8BuJE>71q&tI z@WM&Dggp+Q9tkp+9rL;ymm9|Q_q$zgLTI_mE;=XkQrdU@^9K{Bi+gNhsLw2fhF{Sk zw1;8^MmFx~)*aW+DokWdi5(98t}v2%_N3a)p7rW0-Cd`bpBsOQ?l#2HL=eRuS}I7s zPbg(k66Y1Nm)18`c;AOL?TMm4_BJ}|AAa@5h&{{hc(XcSX_{9U&Z)26yLPM&L0Z$b z#n(UVmKohqSK{WRZBmuJo>T2|&y~b-9$u4FEQW1l)Gr*(LmbvB;I33g{*0$sme2hR zV!|_+?sv@b*x%4au{?;M9t_T9k2AzQ>vVBEffE^@@MDm2b*#8iWXW9ntCuNw@}cUv z@~02%Yo0zxIq7@KY3s;jz?N7=TG6y-ir2rN*8ki;PLKQafm#f++dgI#KJTT*D)xgP zY!90Mm^5M%{elxRIqsv1RrTIAQgbT>hKS z9&S(ACOmRCA9e2AEsD}RmNxq`xviM@(hTdYLyC%`NodyjwBOc6Q<=kAK6oQ!a-Pf; z-rQZML-J=HQChE&)8qJF+D{s-M~?W4ARHEhA9zBeuVzYoa-#I4T!jZ-hczBeX_T^x zqT=sO#@VP|iwR2-=*g!p-B$VgEROMXjF87*EG=Hc!uW-6~O>Tx4`M-!!Pu)Zw#D^H|QxxpN=oK_LLQkUXa+?{B2mU?sT zy3)c?QfG+WtS-ye&nJ_E44Ew-(rjIpGhNU>*(M?#n%Y0YhTlmDl5y(TPNq1ebrU>< z_pR-_0G5VCeD18YH+QGwo3jE$jM45Nx4Q@8w;4x8PbmoW*YQyUH@#GKEMfWm1Uxaa zKp9ziSLW4czR(nW*g8`_}nXv|pYwM})0bK1}A-QRug3hxVTXhU`vq5sO*vy-EjN)ziPeKGa^4jII##CQSj4+X+Pl|IY%E75!wfQQb zJfA78wHVzrxuYrqyb2s!)WMx59jjiW#-(wCo}KCxuC85K_}E#FEz1qnlOSY4t2|Xn z$E1Cls^hHKwz3qEmGOgpNjl(?p=00T)|HtzF17jS>i46ob`-f(Kd+vV-sLfg>!M>! zMHs&OyZZ`5*VAa{DToRo-pJ#8-_ugKUDPSTKRU}o-Pw)9sy;?N$LE@HpLi9|_Be&G ztR#?^y$md)_>&!{>J^q()9(cu zSb#q7SbK!jDs>Owd6JDz`DWLIjxd=fuD=&dVz6-Ik9?POp!d`2&_qcyg}H`XWp_xL zvoQM`T03g8Yr^YJjav2T&vkOrxmW*kyMKToK3peyj#Dd05MCV2_^z29C+8fPtjV(F zHPW)RWzfJde!i%rKf}UYZeqlT3v+5N#$(&Y%o17Uzt(&TY#l3PZF9rwl-p72=1(Px zNBRBMskk~gEvU4fw!vzUhDNL`wMRIpCTOjfQIgC|wy0<5b#`~uwWkOevRYGxzhfGj zzBRpW&|r7I22O;pZu;+3BS*V~5yQy`de8pQAN7%PVH)#d_>ccO{Vx+XJAu_= zq%{*;m67A_BfvKPy&y!GE0P44?qIof+?5`m>d%?m`SeG`Z^skDVX|(SS#G&sJ$M*| z#|W5xI(!$8EF4rKhYQYk}?4GNFEa^`j*v%x62mzR^Qq^)k;ZEF$ zZl!UL7%%Zc^j+>=nMPeX(vG>nR;6*1I&rY7qMgU{$83|0W<+hKTkeZ+$$p&c8`Qjb z|5l*mbjGpza$_+Q4nBkSI)of&taKMLxK9 z$5}NT3lS8dHYrR$bqbmFD03eZ|K73FSk=ICC@T*$$RuCOUhjr_-q$2au-ZT3qc|{i zHO{pEKIu@fQu4y)cyf!2REMhEREHJ(+2v}gqf?+4Zh3BUb**{i-rpRBOihs_vN$^V?J}WPM``Z0T9h`bSHSbAwg{))NYLdRlfdSW-bxGLt zNTQ9kyIs!&8Tw^>w0~y2sy)`b%_N{Tx^ar*-pXTM{OrWuR!=}%bfaB} z!|>&#KZwn#5xd65`lo{O1`OZDV+H;uk8F+K4F;m zZpn|Zf|dAu4cjBtb_>)b{NE@ZNxFW|AZSs0zOlML`K!NmeN^oE52ZW_`T{UbL!H|>I8Ft+TxcoTLZ3{NoKwo9T~9vO3Dy z?v**1C3RD`pQ?=P(674GiGINsUwU)x@@D=yoY&73uxnu0cdGKl--o2dbq=nr?3bG` zBNZfQ2-oIvS(-CVDCWitL=4JHc*@7SH6Tdx)>8Q?CLNF4wjUNJNQ^LDe4Vrqzo<6z pCEU6*pdNn`nqi{+^M+)T%|&_0ETVYj2>nHomb$K5p^8<&zW_MnMG61_ diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/binary_priority_queue_random_int_push_timing_test_local.png b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/binary_priority_queue_random_int_push_timing_test_local.png deleted file mode 100644 index 76e02f134f01c94919c0abf6d8912bd380b6e01e..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 6710 zcmcgxc{G%9+a3y`vSi=M5=J8vLe?VtlJFp^k+EeTOWC5xt`Zu1*%`}NvloM8kUe{m zeJ3=w`JVB<=RNQH{r7$6JKu8-kNbDu_jO;_bwB6uj0i*hI~Qm;Xdn>C1uf0ncOejR z00JS)I(G&<>7Ym{fI!Yb40Z3RgCPV0hd_`J2pR&xLm)&_1cyW5NC+Gaf#V@?A}NW4 zLy$-a5)DD(AxI*r77d4>kq|T*g2qG8L{cjr4#6WKcr*l$hv11I5`+kc5Rnif8bZWF zh+qI>gU}!r*bG(^NpnaS5)Mbh;dnTlNE!=9NF*GIh9mKCB$31dOrnu+G#ZY^!_h<% zDXCh=$_9*@KmLG>Uhuog)~BZ+t<5tIk|0n!A! zK|4VGAPG<*$QlF#NrNoGQjiBY7{mslK`bK4IZ_&o!3&Q@6G=vb`oOVZgvX=tM9^1I zF318*qKSAk5%dvs8Z-dp1(t(GgK9x5K|es6U^i$7$O#k-Dg;@BU?6F*6Ql+500)EE zAT*J*B2qP&24nCdf*S*k1oeSq!3a+zk`{QneiDn*jgt0xx+D^*Q{PGJJ++d=@zfpC zwoe6S%|G^fNYK6;JOxI=g4^@l7oy;D)+Xh`Jqo8NFVb3VQ3B|$3&ff}-i=RY71RR((? zY?s0*fakz-ivQc&uF}g81qL;|nD_8(s8+a^qB%aRD`n#S9C|fmnxTho{@xY5u<3Hi zyNtFw@3mfHu!#9%y45bqT~mMwmGsUG+;tENOe*R~GF zC7q}sNQU+P6KYVcG3G%QoKKU{9wL@FKu{X1+x0iMVkj{+SdQ)sfcp6IAl4=vf8T8s z5y6nzqk(8v`5h0uU3bfRuz*j^!Kv8O^)Ce zZWGnY!rdn>L>WB9kGMMlF5ItT=A{~2{j4b6Bnwq;) zBr@A-?V-=8vr3ndKQb}uG1u)W=Uu@&4Ywj}H!e};EH&($>}i>6ExKkv=@QdF!G8_YuY?}g=uzRLspkbC`vAu9VJdHufps+eP;QDxs37N$bd zy?0QZjVME_syJhrcozHZn&-wTiMqo|a>!|jQ=(mMBP!E`D*XGU=C6a1V=WePqhmR4 zuxSs!rOdiz^0&ajOb?L7!(~a%#d;LF*B@+}_A@ePMUW`4`L}q>r8@mt4U6PP&Y99@ zUqt!6MDt4LxGG(9ujgd~>y`ki{P<^rPuaxqWKEW6s>sR`j}-#OZ9l|dE!sU2xR+bX zvbN^-`0Ex5W_Lm&=|xfeKHJrl!ZyxaZWi$OTT&_Naii7NE+b5@Y>DWEzcNev71Pl5 z(elTJZ?iZ{1H`hf{E`*sLyR&yNo3slOt&iM|B zCeXw{S>~rv+J}fO z;#8Oe0| z{M^Ho$?*Lt6;uWKnH)#{Z#T6H#3PMI)7R_A&aXe+NI{yV1OoxL9ylYFZn64RJlE_b z)+JrUEpu)=!gof;(Q95)wR`H;5x)-0u@M2JD z6m4G7Z>(!!{9&iiVmuQIq8f z6FMT+?y8vKO-jv6K}2tOjkWbvY*Nn~KHM_IhfBOF@Qo;Lh+4clDK>@m0kkqK#+{un z<_=F|Zkyh)c3&R>`2R+&8|pdicR>?`4WI)o%@2|;omP6dIEOKDt$f+ifI}jOPQ~qSHx1e z-jAyUMazgT$n;HUY6)M+28NDB_PaFhOxF z)5;5Um(jwzbh95)+w3hc+vvlp0|lK8SJ>R0@|;3;i=IGC6K|F+)={O4t@a=)E_qVT z6h0?T$aoG+8>&KQ-lQM3{-u@;4NIKm3I44@ys&6p^}@JCLZU;FJcy2ZYtUVL=Hlzz z#MyZr@B4-}YX*#6?r>p+tG#S}S!N^koVR`DTzVdNP#_#;y4)*-6(r+sfQi5b#cD2D zr}8s9F99o4Advb_;;i+=Bw6aDyFlzwT~ZI53P!MJUT!K8a^G+1e9MOEpC#rk&gY&x zT)QgoiG;m=_Lp~X2P;-kc-xfI#o}(y9;!Nd#JG+flc9}soh-_2$zGzJGS40El&;v2 z)N|!%Sv}ACDWbsT-9$J7eZ)`YHv;kVNwvas?Dw-%gjX%S+1CronWcN1p0eOuKg;FQ zy}h0@a7{V6ufS~N&HikjSwh-r<~^_9bc8c3&6=Qxu@=X;#mog2&pt`7AZUy#pTFt1 z^yeIItmE800|)ekv)*b+L%l+ei!S&(rEZp0wr=;E_#;pCMc9cFG#m&=MHZpG_h<_X%0OnI{!AlUF%E zxoS;Y69O=IQ`Bxj!+fr*`zGp-K7R1U+2CN029colY`cSPn&Xogw5^*Xejt^T- z8e2HBh4@#bl7T*H&D!_?>U$3;H)+mf3q36cj&`VDbT(0ayw(_GaK*ip2G)gS)!I}1 zj^p^yvc1tECUxQ9?W&V+F_1yqTB}*Ldlzfpb6#{fx3HL_vxz(s-i*l`x|qahEsPg` z{8Dfj!klQ<^1<0PB)HriT9aUNiDWZ=f;W`$P#`C=`9TWUV~O5)U!xQCHFg?_te5mg-6 zeWbIld?V7#j#|7ZSIG2tA`s=c>5nZ-x|onHKO5l{Ej`yJKWuu!HtW-8P?n_sE?XhX zcQ*zYrbTvet>)Yk5gL|c9yV`T(RHR-W7REs)reXYTxB=J=*2yom*1Fb|NhT9m);xJ zZ(ecw#s{#vGC2*nm}u_l-9Bcwz!c*eH#S&SU^51*yF6c@X&krDa^$y!04CvVXR*)p zs+n6TV}3K^3U7Vq4TLELL8>n%_T;a)$-ga<>{n0O@N=s+gX5=kwvx+T}6sf3Ihn(HDu;8_^f- zKeoKZsXpCNcA3vq&l^jLDdRJ>I$?KQ`0c=FY7(|fgBZe@XZn{JlVcqPLg-%c9X@S{ zA?wN8az>pC&Pr={Wk{mRdVQ=iGUT!ufZc zt`o8OR5*|7zF@#7>nv`prRm1_q6((oh+sOqCFsYnVsF}=#g3SaSU!5}FT(O+XFc`( ztX5ePQ8%$U%5nc8uGBNRo9Kf`tDo~VxIDhdg$O0*{kH96w8rxUe`GhE!prAX-RI8H z{eVg{MKS4Xkc=47y23IxvGwK!*DOyCrgQ$nUDN7Ser4Bo4DeqEG9MNSQ)AOf&^GhD z2ovQW?+LGfAvzi4NmQhC*ChSqnpATvnEl$Eoe31}PVSe2qs|jXn3$Xxqnff%wb4ow z|H$WN0s?+`+o!j2ZEk0iU(yM$?Thrh@(6^)KHcjjh;KR%&JSu2$pC9EkD*<5^& zNT~e~Q8sSyHQL?~dR@qiPR8Ciyk~=r;HnS3UoxTyylTC0UGg)q|B(CQ>wc9lgNi@O z5FbPf{K_7ssG$Noz6N649|nw1T+a17?-Hc-~W-;1KXZX1qQP9-yIcc z&p8V-N8jvS?)62#9qDl_7&Mqjrnziga+xT<5+Q4*YHQ!8W0*UG)b?`b7E&0?JNYqU zN6GevsL^(C zdeqycbgu(FpDG=jRK=#O#>^u`-pId^SF@(<-g&oiq+hEDazjMO87GVo`J`nQ2S|G>ZS0@(N`eyA#jRgK*^ zPou4ckL4j5f{f*VaiiOjTU$@d`#LHy8D%Kx#zB*j4e8;TR{*!_iOOD9k zeu7I59sk9VG2;LIBUjoLf^l6XSJ9WnNGDZZTK~}X0+@DI9AM{a1%CVxQZ1%7q5|bf z-Jpr%ju{T%TA{F3g?>KsA8#iA`JVDWi~hh&Ju18mqfT@v5Yk%29CB=OwqwD~@@*QN z}f*ocp!I$<{ie_f>;Z{h)#A$iA(AS@;WiPT7XSs1e=RdIk4?mA(k^^1uL2r1RNT3Pua|aUTt^fDfTz*_B=6iaWXY~E<^&2cWF}-n-qjAf4 zRnQ61Q-=mGRiIS7#x8YHN}JYXWKOVZfSE zvF6Lxy?Ac=BE@Cqh)o_f%!hnHuq7a~xdgqJ@@JJGcleG|aR_PDw|=*3!E%itzc&v4 zmEs^4vAfYKn&^*QZ?urDnBT&%f4*EhSX`727Q^r2Y1$^5P}eUYG7Z*^Jy zCIj{*I=teJKV~~wTH&vMw;v}?Ona`vIbm;#6Ju1@?$aw(FIcPy2 z4Li75$?X{_hJ-ff@x~~CW7W}za zoN3#!kpr;+%4OX$uC9<$G5ybywJSAZD6=`fsbmHSkCCyWI*kJT3dF-r&ZMIL+Xopf aLFJ}~Z(p-ykp3S8(NfpHU843d?=h(jp>N1f@t< zAVvj5A@rtTi1ZRjq=X=l?7PC5b7t<`nQ!j*{rL6_%)I+u>v^B&dDq@+?fhwGqPuVJ ziM=owY@fc~C36_;H#iKo!(-1*aL0M#+!GjVC(O*qQU`=E7y<@E!C*KTj0l54>b>J3s`_84kF?p;3IGv7yx*I;lOC17FY@V05rjDUrxZs2zN*(|m@%I@cOlh~xTeP_3K+e$XaZFkt+ z-WJTJysd%V{B2rn1>2PXG*}LxOTav!X}i?+O8kHS=ZX$L1&VU|>e=|iU|fgUe>-|f zkz3%VV1UlG01F>fK(LdaD@@12Oi0(=$3MW|+0Vl_K-DmrScIcuyv4l>cy(Nr|r#ZkquWe_g-n*G|3-61~D@i3`=^YfYT=eJYrpmE^YG(VGmykTv!VxAmt*8tlMnp^HHOBY z6HrtNFbK>KtHflV8s&E$qTA2dt2CP8gg0J}8s~dmXfKZ18sk1Y>#CmDe_a|Mh7{x@ z-{Uhb4lDci;i)JJTzlKA1T$^R`ZX_^CsZgoSQGg+=`EC#8<*{wpls*z21OyV3Ie+IH~v9hoS9 zDS6C6i%ewlNIvUWwQm03@idE?!=HJ3ggkHpr>r8LNL}CGc0M&j<9@L*JnEDwVRsiY z%;i(x^!?FUlA`DMl%*|8s89hz3R;L5RYQN-gWkcZH0x@|l+Q(8CR?qfhOQ<*I~Y-&vZJ^|TY4u{-XLK1D)FeaR+jE9-2iVJ4-R=vo#7VqL3%wU4xR9fNTz?{h0lI8ZX{u z7yeGP%4%|}U8kMUeqa})Q;=>?hMOoi@S^+%@M1Hh`h^x`dHUy!w|A8G6a79^qNgP= z=bG>(}+6|av@pv%(qWw-7J>zQYbdpaLS zvu^N)U5fv(d3v~TB?@n3)$jS_>R)Rlk}qo~#ih49xJ|$&4Zmx;znyb!-2Qc_2-~_% z_!ayrN$!cyCE}yo$hE^6{?_&DJUQvf-&HR>LBG0-B*t27WeMgq6;^RM4RX0-4gAZI z0UT9lY;EWYvLtK&f&;N?%31b%s*swPIz`5Oi+%Ntz@LMfLlh2+zDJG&DI;AKw;j{C ze*e@LQ|$Fl9v!h<;;bePY9C)sZcN#MKl&mFpU{^_s}7W#eSU6$qEl%uHR_w2p3q;G zzIzgqDC=$~rC^%LchfolhX*%#bzH1B+iP_+wySZMD^7^G%%Nzh{Q&v>wPS<^# za#gc8?)1rMr(-`yhdO7*`S1$dSFiiXp3TnQ7oSiYPr5MLAxuwR4eoBvHu$KXbj$L1 z-}^HTsm4lJM&|O(4GH&Q`FKy!BbYXQI6C3tWIZ;85aorD)^W(Hh7{1#l9zDnoD{sCQQibc`u zn-uJ_4LICPHD;)#i=^nxGAX>*X2UxU>HHtBW+ofWZ(TMcED-D%@2y2oxm)cxH)#=UHn!g%2ULmzYkYHdBh1^n;|UGB&`UcPZIi}ndFg9Q?PfzfV`jrx!ier~`ft6)X#%^i zM}7L)_IhYQi>Forxn)l&wAr~R&`Kt?b3JL6ZYrjq;}$`wiYkvfb*?v<(-u@eKCGm(s=;10c zP#X~ZLmw`>d{2yX8e7I*5)4`zy$LKO{drp2XRasFtnKr}2O6Q99OJyT5yO%_*~HlK z_W{F;Zyw3TD_LVEqhv=`03DNu65L(HQM`x#i->g7qph22uGk4@nfRhRFf^zXh0O#x`SUu zY1C;CGfT~_zz~w9s)RDc_(%os3Yjr-N9$Ftku>S&9UC&nEdr@Deh11y^3njp z<%0bD)9iOqJ7sn;bMl|jA1h8Vg2{E?1L>Wn4kiYC)B?_dDr?hFkG-R&V&M?g@no%4 zX>0f{ecSb%Vs%yWEH&)oj`CkE)zZrwl79VMVf216(sOhV>&U9PG=mYfwN`}LXaA!a zp2`#cff;cF9=7OC83;OL`6qa;!|`?*Jc?gZkEnq+;^~#Xp-DO~m1be5FQ;K|Dc2QV zN~n?jSnd!MyDGYj=GG`l-#rz041=+SV=%$wR;yjE*DSWuH-7c0;G`xAf{%<|KdG!- zhg%(yniM}ek?NGVhw$IuAYXDie2TN3{PtjJ zhM$%M^}heAsI}kpR@y}j3BTk}SW%qYt^QQ_*E=aZw9-rve|x$->!@L##(}dP-ri|? zyJ`$rB7wgsK{Y@0W(t+G9a5kp$0o2Zu4niJ443Tjd~yaS6K=EGWnpvIBW@1a+^q682)=0_W?~4yfzFiH2rvkzPW zw@I_^nJZf5nS3W0x``(gIr{FDDd`Cr(rmoY(d<@~=(X4rh@Nw{ink&E=(3?agsZj- zw6%g)ge;ZN$ah+D3+=w=x#M5kgYt#F8;Y3$Sq>9+C&6~%qKY}{|32ZCp;C)@6)FA1 zIPIg=IoBfH-X5$IJ?G1LH7haYgFfm@!MSR++#SBCuhJGTf+?{Yiu<}QvF{4ia?f1& zTx-8aCUcSHCS!2a}FvgsM^g;Ta3Us8Da?_vElkvund|JUD8 z|FH-B^9A*9ndk$q?u2Iy##Ymkbgc(?J)TU@O-!1n{fe8gzSIl0tMjtj{LEJJ%7NDM z`vu?>;BOZj`LIao>Pz*7X7j~ykE3e$P0>q=u8f6PenYFp0{sD$%GbA_lD@Br(T+KU+9M82i+sWRrK`qn=uK7Se1TQHqU zc~;?{jr0oWcl7z@>sJR8^jTd`Seool+KrhLs@5a2sXRet z75+7g=AlmicEdYFfPE@TpD`bg6OtW_&ze#55${`UTxP<2l$h9-V^=lh(&t+)yr0{B z#ReH`UUlu6C~qoF-N$=IIV0_x2fm0KbD@t;(RlI2N=lP*Uh z-5k73@Gf5NT_ZN0#JJh#NemUrRCrj5t`y&5s-V+iIwA}|j1*1mAmqH&EQqM04c)B^CeN{s#B04dyscr^k z<|)UKEEc`?xzz;m)tp~=cGJ!C96R6Z#L!e#4I0T;h$A^KMx*@sqjjU$=hQE{-p^_e z3#hIp#}BJ{yQ&4vit^Ni4!4Ckb{mS_T&X^`{53b-sDIi+da^u%xV{~*~8@?1LPy<^T zp-}Ph(pqr0*?zgsOoJgr?Ctr%)w)p|$?kT(go|6OTSLaAClz5XrQo|$e*WbpYe~bt z0;{~R4?Z%9x;)Bz(dWCq7EkG{T^4CmHp1@2KXvl(JC5gmd|6=2TyV>sr@JF-_!j!n zV{w!RR^Z#14&05GDB<3%jznCTPj6Zc{^L_oSVN)8mHL$%vo(&qraQrj - - - - - - binomial_heap_tag Interface - - - - -
    -

    binomial_heap_tag Interface

    - -

    Binomial-heap data structure tag.

    - -

    Defined in: tag_and_trait.hpp

    - -

    Base Classes

    - - - - - - - - - - - - - -
    ClassDerivation Type
    - 
    -priority_queue_tag
-
    -     		-

    public

    -
    -
    - - diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/cc_hash_max_collision_check_resize_trigger.html b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/cc_hash_max_collision_check_resize_trigger.html deleted file mode 100644 index a6b512b0d..000000000 --- a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/cc_hash_max_collision_check_resize_trigger.html +++ /dev/null @@ -1,532 +0,0 @@ - - - - - - - cc_hash_max_collision_check_resize_trigger - Interface - - - - -
    -

    cc_hash_max_collision_check_resize_trigger - Interface

    - -

    A resize trigger policy based on collision checks. It keeps - the simulated load factor lower than some given load - factor.

    - -

    Defined in: hash_policy.hpp

    - -

    Template Parameters

    - - - - - - - - - - - - - - - - - - - - - - - - - -
    ParameterDescriptionDefault Value
    - 
    -bool External_Load_Access 
-
    -     		-

    Specifies whether the load factor can be accessed - externally. The two options have different trade-offs in - terms of flexibility, genericity, and encapsulation.

    -     		false
    - 
    -typename Size_Type 
-
    -     		-

    Size type.

    -     		size_t
    - -

    Public Types and - Constants

    - -

    General Definitions

    - - - - - - - - - - - - - - - - - - - - - - - - - -
    TypeDefinitionDescription
    - 
    -size_type
-
    -     		- 
    -Size_Type
-
    -     		-

    Size type.

    -
    - 
    -external_load_access
-
    -     		- 
    -External_Load_Access
-
    -     		-

    Indicates whether loads can be accessed externally

    -
    - -

    Public Methods

    - -

    Constructors, Destructor, and - Related

    - - - - - - - - - - - - - - - - - - - -
    MethodDescription
    - 
    -  cc_hash_max_collision_check_resize_trigger
-  (float load = 0.5)
-
    -     		-

    Default constructor, or constructor taking - load, a load factor - which it will attempt to maintain.

    -
    - 
    -void
-  swap
-  (cc_hash_max_collision_check_resize_trigger &other)
-
    -     		-

    Swaps content.

    -
    - -

    Load Access Methods

    - -

    These methods are only available if the external access - parameter is set.

    - - - - - - - - - - - - - - - - - - - -
    MethodDescription
    - 
    -inline float
-  get_load
-  () const
-
    -     		-

    Returns the current load.

    - -

    Calling this method will not compile when External_Load_Access - == false.

    -
    - 
    -void 
-  set_load
-  (float load)
-
    -     		-

    Sets the load; does - not resize the container.

    - -

    It is the responsibility of the user to pass an - appropriate load to this - function. Calling this method will not compile when - External_Load_Access - == false.

    -
    - -

    Protected Methods

    - -

    Insert Search - Notifications.

    - -

    Notifications called during an insert operation.

    - - - - - - - - - - - - - - - - - - - - - - - - - -
    MethodDescription
    - 
    -inline void
-  notify_insert_search_start
-  ()
-
    -     		-

    Notifies a search started.

    -
    - 
    -inline void
-  notify_insert_search_collision
-  ()
-
    -     		-

    Notifies a search encountered a collision.

    -
    - 
    -inline void
-  notify_insert_search_end
-  ()
-
    -     		-

    Notifies a search ended.

    -
    - -

    Find Search - Notifications.

    - -

    Notifications called during a find operation.

    - - - - - - - - - - - - - - - - - - - - - - - - - -
    MethodDescription
    - 
    -inline void
-  notify_find_search_start
-  ()
-
    -     		-

    Notifies a search started.

    -
    - 
    -inline void
-  notify_find_search_collision
-  ()
-
    -     		-

    Notifies a search encountered a collision.

    -
    - 
    -inline void
-  notify_find_search_end
-  ()
-
    -     		-

    Notifies a search ended.

    -
    - -

    Erase Search - Notifications.

    - -

    Notifications called during an insert operation.

    - - - - - - - - - - - - - - - - - - - - - - - - - -
    MethodDescription
    - 
    -inline void
-  notify_erase_search_start
-  ()
-
    -     		-

    Notifies a search started.

    -
    - 
    -inline void
-  notify_erase_search_collision
-  ()
-
    -     		-

    Notifies a search encountered a collision.

    -
    - 
    -inline void
-  notify_erase_search_end
-  ()
-
    -     		-

    Notifies a search ended.

    -
    - -

    Content Change - Notifications

    - -

    Notifications called when the content of the table changes - in a way that can affect the resize policy.

    - - - - - - - - - - - - - - - - - - - - - - - - - -
    MethodDescription
    - 
    -inline void
-  notify_inserted
-  (size_type num_entries)
-
    -     		-

    Notifies an element was inserted.

    -
    - 
    -inline void
-  notify_erased
-  (size_type num_entries)
-
    -     		-

    Notifies an element was erased.

    -
    - 
    -void 
-  notify_cleared
-  ()
-
    -     		-

    Notifies the table was cleared.

    -
    - -

    Size Change - Notifications

    - -

    Notifications called when the table changes size.

    - - - - - - - - - - - - - - - - - - - -
    MethodDescription
    - 
    -void
-  notify_resized
-  (size_type new_size)
-
    -     		-

    Notifies the table was resized as a result of this - object's signifying that a resize is needed.

    -
    - 
    -void
-  notify_externally_resized
-  (size_type new_size)
-
    -     		-

    Notifies the table was resized externally.

    -
    - -

    Queries

    - -

    Called to query whether/how to resize.

    - - - - - - - - - - - - - - - - - - - -
    MethodDescription
    - 
    -inline bool 
-  is_resize_needed
-  () const
-
    -     		-

    Queries whether a resize is needed.

    -
    - 
    -inline bool
-  is_grow_needed
-  (size_type size, size_type num_entries) const
-
    -     		-

    Queries whether a grow is needed.

    - -

    This method is called only if this object indicated is - needed.

    -
    -
    - - diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/cc_hash_random_int_find_timing_test_gcc.png b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/cc_hash_random_int_find_timing_test_gcc.png deleted file mode 100644 index 85b9eca4ff621bae92b74d47a17dfff387c69101..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 7074 zcmch6c{r5+`|q?!h(2X4Ny5jP@iC#SMRrk^>@yO>ShF)>LMXzAXiVAH$dW=a#zeBs zWZz2)V`s82Gv+zZ_@3)r*E!ekT-W*ibKcj?JlDOvU-#?2@Avb5mU(u^M30mGJUave z;WW^{Wd?y9g+d@l;!hp}H5;(Ibr8rg$Q@$~9Z-ZoU=Ror0>MEbWC#RcN-!7%hJ?Uy z5EvN(1DHl641z>LkT?jE3_$`+UmOgALqc#k2#yTF0nDjn7=(<3kZ}+)8A1j?BnSY5 z07wXcg8*a*016;B2n}L^lR;Q%Hn(3gyak#R6G8Ab*`j^I=nfP?`!7(j*rU{sJb2nLb{S%S1c8yFbG2BASL za5BJ5h$({uheVQ*NPw9i7#5UpI3$jY!~x87K^CBqj6;&iNHPFs50V0XkpK<}kdXkG z9#{{MCO8``2be!d0?ZI(4T6EBL6)E^$O8-vVuR2i7Qn0=(+tYsAmeZVvyfnZU|3Kh zlW}AKtSgu<$O1It05T2$>j+jFEC9$0bO#F!W($@QtOrOFoDG%(a~11oH#Kf)W`3m<>E^Ka<5_N16RRY!Z{yVcnVS zJuD@Y<6(7}-9Aj1N%=4bX7dkeF*7)f1VV$$0qhc3JTRxjP=_n=|ND;%I!p)*%Jxv- z#vcOVILrJV>7R(8gG%859qRydA7nuAeLok7j`^KSdTu`c0sasCP!9txUHeB-PF?{U zl*I>u2nZS6x@i%TxsrvdE4cJm%-+EF5W$CT zFI;rOj_B*DIY4@OdpUkV2oSFS_JMcv@(tEPCFI@G!LFk}SkOl<VYwjm1 zXFFy$Xl_9RXA69a90=C0wYBK4-1%m{96a?LPNv^dIuMIONrXC%C%@v3VB^0m5WYBv zwT`&eZwC775azRP5lTOO(#h3(qA?YbkKpjLVDq$$^$A#dr#9Vd^cvmg!?M>p@Ogg+ zX6m82xpZ?@JbRdaSK@-e5bHE*((ntqx=oboAMTv3K?+_Gdx`koJ%{d-5Syo5TCqb} zL4QiD6{im*j%hs1E9>n_-PxH4Hq)xj&odk9t5J_RM?1bRRui>gzWNltl$x~Oh+92D9Uy7t^qdUh+isrT>@KM` zYrF}?YsNDWIcEc-uWv>7;RBa+a~>vE{v9EFrA2i^X2Q8+m9*#&G`LELvH`*>l@K~ba&5`p>-P{ zj(-Cdb(?M9wy67S2JWAT&jS&wtGZ>Hn%o>tRudQmo9*J9fyWM(^V zcJzpJ9Yg=4m!`?SW@IyPYr?Uc?)Z1$N8d*``%9CbtS4V`^$r&0$BQIRpW5pfO0Wvc z(&g7u%i)3|{q%Md?lSG0fH(GC@X5EkQ7gR0z?NTc=d$hf(hTmB9KNmh#J~eY z(&kisbK0O$;Y{6SGl(G6Ke$cAUp67>mgkq59{mcK0n5n!-v#ZNCQz{%9&)Af~kO*4*pf%uo3FEo3H- zes>V)mYQ0^H)mRMWKsLKQnIOK+-@=6uE&KcHuc8++f1f;5jkZX)to24J1SS{1Sl_yGy9_m)Q%@gxl~%QHP7E zZ5yBZSS(^juXxP~EmKbnw6}{o$Y>^JS&}28|IN`(bKNpazt^>PwHf^wu4XIMKJYxB z|7E+OyOWHA({(f1xc-Mi-t0xDL4O%u3lW{*wB3V$`3EU#eHz?R{^#ONDCrLT%@%YV zrtG~x6XkqO5M6K3n)IPkyz~>pEN_$R54P*U;nM9`fGT$4-r|XK*rVu9$CY!0nJw)2 z_Ha^_vl}7f*dMH+zUHIaU1>~d)t+24LR$Qw>w@gaD8nop;Gh?o^Q~c;gR*;WdX8DSmoU zhtw1YM#@!Jhs1)B@{4~=9E|8V^}ELY4^~=Vh7$71QT+z=Vny0CO1BRT=T{ggJwp6aQai%n=d>0FxJfU^rV~}2vV&Q}xGv!zy+H*bUIr$Zd%wBJ_&l69 zX>_KYUpF)NLK1YFBKGGooSbr$0cB7<4`g3F5+BF9@R1twB6g42=|wz&5PQS@Rjz+x>Jn`}L-WQ^#@2?TYJ`2ob8T zs8rkak5dm%P;@+g*OM|wr#c)e>49-Tv z%_4-#?-QP;u0_!&$80aeLHrjl*OWLILl^aXsp6JU`$O_P1hE4ZYdpGI@)t0bb?Jvx ztgkc(h+@Tkh>BPq&m%Tw;O zLacT>zteuE-j>;CK%A~>=X`6NznP{o}KN+$-4&H&gaGnXfvIc>lRfaNfcg zJfp2E5IzGG@T0a$lA$BI+A!xx0Ojf`X`J|c1z3M{8o(B8W`2Use)CNX8?t&sq$Nhx zdA$1zS%|3xNTEOY&0n*k7sde>k0bjA_E4W~CTMCt|1R;uU{Y|@{4gLczG@T?4;Z6e zNS6HtoHg!wN=q#S?X4cJ7XWPGC+Htcsp%4h)YccH1?{YXH+h~a2F*VVxd5yoNQ{F3 zxp-xPCE$kp1HN>20Z#Dp^B4|c{jUyj{shkmf&HJ+lrLx0tZ3GSYFVu4X?y6*v)Gl1 zSy8^{8U%Ia>LM9Z6`%@V|pEC1`K82 zmew%7ZoB7feQEe!pXUnE`Ey@m{_CtER&YLA4z;NAta!m3M&k(?X={65KJo9c(J#>M zGQIyR(+|##?ps*S7Qb3Fq`(%o3nz>|Fj+gN-*?Kyi|Ww&^KMvJQEyI+@{%ZUzlncI z#}xHQ;(n7%j@(eS>60;xNb>ALr0WD`?}YHIU~Yrf6PG)_CU;*vA@%0@)x}Yae_dGW zQ!7Y_KA5;!Ms9W!Y2v$B;FB`g`21$s^GoI7FG@&e$L1;LopaAEw3s}Gha8W69ULI5 z+Dkg4d#)MP$q`xwKWhuP_`l$Rmt!{wTi9>6%|dYSj7OK}ZS30y6DGQ=9nQG@W{+O{ znrcvMjA(v}K8FGbin;>{y@Hjz3XeoY7g(gFdgRfO_sZm-zpxlzuk43bD{Cgb@~Lg7z|<3;m&P;^t&Ps+`PUXE2krRa%M>v~6G zXsV=`bwf=yGZfnZpRfpq->fNv<7>=RooYk+cJIo~i#l|kg$LKXPM6jg*lqCFemq)H zWB34lE?^7Rt(>b)u#nUbY^$&AbxCWeX#$dD!CnWQ#SjIR!Y*}}I^|YrqewA^r zjzOU=v^a~D+G-YWOPpiXuPk!2hJU+DpJ?b|wIIooE7KA!i5OAI*n4l61?WYamyLnT z7GfFtl1M1SduAc$y;>Po^D^(g!ODB*IE$smpo=ZM&$%A#S`rOpmJeP{@8YW)4cB)p z0Ab5`gF9~}V{$ngR;Vf~D!0AON!9wMi17p>&8ildROt>Wnd+@~(h_%+E7=JSSoJ9E? z3B+f}60pk|@R!lfS}Ti{2$cz5-lxPzMbf8x>W7tzcGh6*ZEg*-A)5m?Jg1c&!Q0;n z?#il9{-Qqbr$wA=$S@-yjyE8b4`R={{w0+@A~iPh=0db((_1^;%)vsnz?gi)UyWy0 z#cD0!Y+_cr?kzO|>2{GX#(qw!=kqumt-4k*FJ2!BJ0F%W)KBE6(eZAmBoVJ&yZ)L% zqJFnboJ}}ur!cMmBK%8EULA{PyTWw|h#Au|nmA2PrHXz+<7QuO zUO0J&FHJWqv1?or=j7-%;F36odz`|r}2wzdnx3C<8`ooFo2AwnA33hM|31DyH{{T0duc-iqBLz$fiKewV2x2V0e z4*6^_z1Jif178)^`Sf!zS^a@fUL+`UZRPvOOfK>4?`nM1%|Um{hXt&MdnaaZnuUHl zdNd%9|B-Hd#P7S{6;IHJKi7Bs-H&e&%__&U>BT8Jau0L8c6T@4p#g%$xzFnQg0VSq zfx?-SrhTV}&AruqlIuN}z#BcrhPwym0m>~nIR*Y&_%|nFXR1^STEX3$FyI_jXg4_J zoE|T1F_chpo+M)}P#$g@w?7h-9p~WI;8LCTu1O=QWM7}|aEEPuhefFpRGmay9v%|1Rt*i7~Z-oW9xM)M5sv2g48B24!jK4$%>L)6}X9;pKuQG0UN zVz;3g)TjsNF&dDoCpM2>y8(S1?X4{$k2zA3i#c*Ziw2!X+&DE5yEvO7xqa+tuMyyg z;eVJ*!}D%1q2&ILr}JMmzX#SjZcJY@{h%R~eCle_hMIxoMH^h>4eaqLqbr{<$DK0U zMP<_X=TkRAoSAe|`I5_TfHcoerRYpi_t*H9xS#gOE6jOa>+H~spgZjR=_c&ra|64- z-x;k&l<(qa-nAtV6GF!i?mSE5M|f~+;*UuUcV z+CpqVr_dyN6Y_-#bo0SwM6nH{eDf$l-DW`WTsyqp_pwwx;cz|n zBxQ=~6miDR!`gOt&PjZ!fT|y9-zGRkoPS9kidAl}rSqg0{rk;MXK`lUqH;HhH{~q>-c>t@q$)=tD$|s`1k9iCIu=>3 z9e8DWiRBNP-q#bN%2n3vXQ~2qO{6B2&WXyorsv0;XiKs0eQS*r=?YXpp{3ICe^Uki z`Ipb^PvxdECA=G>Yyb`3k-8RogcSkZh-RE(Lkty$vn!N5b=}I35aDNp46dTlSS@}U zPr+1oaP-dkm0K!|mf$je%*djo%2P8XQ?~i zy5-PX0a6n#y=T8XTh%@pV|HGwM#C@Z$~LFI5YqFq>r6b+!`@va{qHrZFpHAo6PnrL z&6xDA^O#_}5&5pui%zw9_6Bjnv7C!K2N5^Ack$LEHA&vtf!8jZ_Wu_~$k=TlG1%0Ptp&I1e$0z6L}zr^0_E`E2{-5y!S{O*h0fsHf$616*h|GG z7A0Sgg^}?6xlf#^eKud1o9XUzR=Wmi$QMPz_ujtaFftj+QNSOQ9DNy8xyXo3qF}!~nTN36uK81^1HgY*x zo!}zd{4{K9`FppQ{FM*i(Pz#zX?)+C?eX$c?76MFG~$TCN@{ZOEr3{gFyuZ#4 z8ns1kHwg_q;L67;Ee4K|4%Q@-EfmK0RNKy`62yCzNwLGNCSG+7p)jLo6fWH^s*mG`JLTS`{IR{p5#DMoJ&FC()yJ-MXP7_s@KPYo+zw@ z2oSFNIW$okXWdi0BqU0*>^G3U7~-W#x~k_V)%RXw6x+n*w)Z@9-l(R%#r6-cC#GaN zM-&o0f492f19BDjhm1S~?Fz65EuPV{50!zPVRiO!OM%^pNoWC}aEmo#0TC z&$YL;?lpDymCJ-CAKvrWa`XG*eM9vO{-AF(cH&)-{fBzasJuw#Q>nOc#Y#>3XmvE) zuW#JM4kx5KFV4?YjYUSn6_~0#rivR>@s9s*UV@;iIp>HP*MBa($Nrm#kGsZN#Q7cmVI!>l6$=`vQV zxKSW3!?NiYXDJfUq~2XBWxmxU62AJuSj%#z zG5*$kBWv^a$$jDY- zIoE?G4lP-~I((3XmI?eGQc9q_}Q{I?>RSbjSaQwX}M`ZAP~K- zj;09+Lu&K11*Vs)S(~{ImlSwObakUATS7o0D({-5FP{~om*fq2#f%MQ6MlL z1SXw#BETR70)#+;5O@%Rbnc4+gHQ+%3I#&pK`7GsP&^ofM}Y7s5FQW0lK>xpL>-fDK%D6pC~%B#<8v z7O?Pm6rKd=3Zx6L06I}5Jc+Y?hSMUHgJ)EiUC3b`2k@83r`}Q7w~WS&sqGf=y^T=7U`VS zU)|5k`&Y_yj(^oTulC=B&nf@S;k@{NX`N^AHxd91Ob4J!fOtSoe?$G9iT~gKIRw1q z1%lE%*MWJ0Ky)nUp9_Q2!GD0pt6o}AFH?7fmoMDI0iLj_3ke%_TSF%2KD}%?a-3N$Jg5LK+!_THvf(dxd(Ji7HQ*z zCneF>hsmVJ3S$qV=p@HGcnM_EW)P@xaq>4FK4~cjT`Tu~J%kd04M{P8kBls3@YJCj zt+bT@1xkAgGZ6&-tcF{BUs%0da@^zavYp0^948nbum8C^3%%6Jrg0JHu_Z})*Cr90 z!1wUGHEo1LwvAESy^W5nYK91hG3gbuwB2XY&L?-E$PZzRCP-F^LP2+Ci^r4>iKcQG zP-rqW5w9`Tt+f{8OC7x&Q1F{=op)D8>fPQoDMrO7-ZVCJg-=u>dwElv3zyBIZxt9i zOr?)mEh^DMszi$9?U!(vx$#6WOJ)51IXTRAtbu|!-AutftI&Jh7+De@v99cgFj!a6?*N;2uy*W6>bJ|rs3hL`u9&|JQRebiXo>W4Vu!_?D|+wbeU!%73FI+Pz@0LHdy4^AgYFH-|0zthy3 zO#`7XtZ|9A(Ve$EP2DSm6Eamu6cHoJ3(B`sms)-m_ezw!bc+m-L=QiJafbSSM_GqpOn*;Zdnjn<9yX~O zV{8A}bzgTJYNA^BT;%t)E@#j~^4Xd#0ql$bjh?w~aIE|~uc}j?p0cD}lrA}G$gs|b z3!q+HYNn@f!qM>OcDcX@?;N*07|a+Gy2 zS@)l4n-s#@ZqH5kS8EIshSZYR^|niF$5)vS%OXeuA=N5BVMe4g7Siyjol0YVj{ZfA zFEd2vYsETqkKgg6MBd>e@7|FUo}NIZXQqlpSM{enoBp^ex0Pc|yhkkTi<0k-Z7R2b zXF9+8jTJgfvQGF7_S`s)e%#4qn_~4YNQIdyf77$z!@8#qq$j-YDJ!AL&h6Tt!+J+! z8hsMv%@!lNV7VWHBn*X0bj5{u=gW^^1l6HbWsyl$7z;__oYO>EiFB2~A$)7;H#`WN z{1V!gEbVDKdZuF#B7;yFABk0bk@}~@LfA3n#!V%;sRZT8cPN|q&5a@JFo;BgEboRT zkpZ6HLftc*c9mG}*brASwXYqN>?)PqJCoHZLFfrF^i4Y9IK+Kqqzz=X2)IGIP=AJ* zTWk4>xz7DIPv^m8KV$zZNvtk?^ol<8^GBHB#B~h4_mmV#M6V!rdALXX#OUGIDbYE4 z1El?zl+g~_a)`q_5pl97s5T~(>_v2!0H^gy&Eb#0Oz^`Y?;t|W}@|4JM1 zra>sVERD@E{q#0;kxQEA*JWb;3Ga581GB(kL(dbQ{Crn4n;hb-S1D!WUNc(U12GW# zWMAw=CmG=^L0%;^`mUJoS^ebcR&xQQ%TmKlb;6uJAC$nj*^!&BhIP*>jkW|UmYt*xD=HS^It zq#(qj6t=#*%kz8p>b)yVIUfsqmwP?2H69c?ga)sffrHITao;ErQH!+geb5*OFS_<% z&_A>^QM9;oi0zDr8Rph8$)NpK^U_-2%I(uI(e6!XYyh=+ZWz6%`SN>xc>TGm$-i%*+I4eMuk+7O zQoZH9rW%a*XCkKS$`Uld3ToLh1(CB*h2!LYD(Ph7$`$$_yr_&l8*K2>gt7_;1oogz z4RV%5*otNoo8BNsN7yW!PX#Od`?_7j8r)=fdjh(7jL!VZ6O>Rl!|TNEeaBXip|5i# zHLG*CdvPpQXquL&ILh$aF)DLQn8;|l3f`)rd+8G_tx+UwDs;CVj1`kQYrm5#!El)_>0>~_%`KHK*Rhh_$_kw~pIc=Yb3N-1U)9bR?G zv{FCVUrsoBm(%YP*XGoCx#`Vl*At;exo@8>Ozkv!$}Ma(TdT^BSqTUmR|A^-rbKFX zWc`Hhm6B))wgO;X)7onbjeEe?7<;TxrABMrU9d;pGKcgBB}D~qbn-d^hdoWpGuCX` zJ&)p^M zw>TxIU7wE}e`lt)Q76^>B9+5Jz-(e~H|Ro3atg!HkMygOFKJn~ue%lZH_u+&$c4k( z`If1EMaK|n*v(CEPO;sG$G==$?yQRP)V{arp6lwVzSDoO;rEIa*p5q$7e zr52OgUMDXrgGvJ;Vza8ixZQokoF4pF?kf80qruC?9a}Dwm(w3esU@lAruDqhs zNQah$j)7;ejcQMJEbD~!Caiyin4Ajpf zg?qm^+1Lke(Tn-3DVh*%a2Di~U;f1k9#W-6Czq*HQ=EEeKhnM5xcN-hL z?!-ThT~s5WaG&wV$3Z}7xed0H-VSb6xAe)aqtAb?C;M*Xl6U*Df1eTZ^12b#w>Leo zRo>tQLUjqD?`ZA+qh#B&pAO*IWchMs^EB6JrrnL{B%A$td9zoFmW(fs`0UW@XUCz2 zLmwc|A%n@vjaRW0jqRL-nD1Dfy)sBK8W7PRmHs*QBuO$4}ODEijnf zrohy@=N4X`oyPoYcY$-gJ^i4C`2Lr46h_<}cEP2Nr<77W{x~`{2ff(DT=>$Iuvz?t zzo?sG(7+5DUfEprUQLT#{xJBO|KwB2;0d?-K|n9 zh0yq$Oc&oH`sjE+tE05qnz_{;t!4u6obC2n{RBIc}2NqwCgew~-0}$=69?gqfwPB4= zn?z7s$&6mDwCwUREe|>-iqDS{V%`K_UGBEXzj|g__$RNMnnUf>A8X=PB_@^ma4Y< zDRsj~w+E|d1h7ti6ZN>l>mO||NLg{Z9cVqRO1ZdJt;gwXGpAb6FRi!9|KNs066fw* z>SFFrM%_KHsa^ZY8BOvH_oc@PXtZR_fGUsmOghAX0ZIh-sh(5xT%Xf6DU@{YA0ZwvWh13pLimBSx}` zR;La2g^l&?>UFYIcQ4z7+cwE7|1(vY%rJ0RwfL|;1oi0KeXWOAFP@@DaVTSTn}D;A zL3%02Tn+2Nu|in2g25(x8Qw|nL!RH9{*eb}tcTG)Jd$aSIpS~gIG+lv_Lo+(Auje;|VTAr@V>k_0IsCmqe zJTD8C=rr!NU*$^zl3%6w@6qJ7wt1dCOPXbduoa5TG zANM=3QaF9Gz1rZlE2HYn3F}-qE}+lemo}cJuOI)1%_{8?vScc2gKs!NC6+sd zHzlQ39PjvUmI2!?MHW88Z@3-C=Ip2D(7E|L&{q`y{mB1ckCO8P;{R#qJKwQMuI73J z_iPPnYWN<5Q(cU_X$Op1=~kr3RVLgjdXRVDr$^R(XmZ(@>@Kvyw62x#Olf1XO#$*N z<&s!)AU}5escmxU3%cro7o077WP^JzgTDB%5-a|2QumDCqrwH;MfNixD`J5gWQ5dJ zL2LtTL|Z6g#0N=F9sRgoIdyziv*?e@yO-C^zP;UpotaoySj8PEl*RU4$3mN<|Et|@ zsyuvn{9dQi%_i>;3W3rO&g{N;ST|V3u|x&)%--u16Jyy*70jR;d1e=c%z%CE9U zuSZR+GhP=VI35XLC(k)C5!TOx6yUf=r+P75jx8JzG7K(GO-ghq-|0-EV zr4ZRWQE0&3WF(_DMV~DCdZ%P+fuEv*9C#zc&Bl@XF_4v5DIT#sseP2j%27u=5ZS-u zOHQxIwP~;x%3#7>D|;Y9C@TGtIF$yiF%XEERqdWlFa2TDq+Dh=P5+4zcr~$WnbiMj za;HWV>%=s<6OvfYj?=#@oC1^bcCfBU?`{!`z1VFOXU*=w-VN^Y@s%FT6!C6&=#gwq zd0DR|j;l#5#1qF&>7Pk>WM1qlw9Tx8yPRI`7Fn5)IvhbJ>ySV|EMC@gR^^)dq>`}x#b2s_c@;7U(R(ThVgD&XaDJ?aT!b2 zNY!&l>k)0bPNDk!VyB0x$#FYt8cX6M;ScYvGu}5yjJ~ic8Za4CU$~w_Tjmqq@j{HJ zN#pyy%*#z;O<79tB8%l?$L@?KJF(ZOYAe(3-@l2HK8;VOy%Qe|VoGm%u4Lk(@}IXe zF5XJ~bBAgu(EEsogTqgbi4gedX!tGWz~lxsQU1rvRn7iDS+0mZ?x(8WSxXIEmvDj_ zf%V#S-gF4Q&-z-hPv0qUmaxXn%bV@?#5}*-_5#Mqwk?iOnN%fN=&yU>7^p?bl zv&xi3UM_ZPfJ#QOorh_1?XfiWK`rG&QvE-gh2=aCh_mK;Lyg=q1+^k$&^fkllZ>1g zRh%554tP@%RxN?c4lVV2j$z+W=I#Yf^%Qksr65LNC;NYM`}xm3aHboay?U%s+Qm3$ zy@v{}f~=Og8nFj`*6^|&*1|-v|N47}W~u*%R11q5k#A+v@mFbo-p8w7A348P?=9i} z11%da>c_d-<h(exA-R@?ilY1d?Zp#7K;d$*{e)=&g9{0{Mto-(fXHLbmFEFL}= z6ch=Qo}AaDHlgyeWFb@@N`E+Vogoa5Y2ft)!_KBQ&lGtC1zX8F~xx(=L zThDF~EBxK&o@_ZWG*$|=*-NWGmszMO{u(QJmx=r=&oN3(10d6Z3b-i%&x}{$us-Fc@25fvsK{Rueb~4YG?k}XNceH z((<4>R^CQgp2eSh*JQswNbfo_%i$$p9(8=DBiaov^1O^yjB#G5-0bYt-XUM;9?mOWOOK9RHi3qpgwuAj1zoaz zw?NgEly3@0VTqMhU|Ermc*O(@+O{H4oG|9JDv}*M`4P-Iz^Ox!}K(1(&i{rH|$;2lps*1<& z);&LRGE~}NA#@{aKDh7dUj{pLY%RK?A243!wNH~v8^{$AcYplQHQ_ny*h}U9vW4U^ zrIqIvsD%(1U5Sjw?gM`T6EkQZOu9m~LFSxWS;ujn9A{4kwrT%kTQHkp;q#Z(acA+H z+QC7~!Mw~C*6#=0Ykn%tv#5FHEm#$b5YaG;P#1RDi)jdiP-Lzb-KurPPGm)2r}Z^% zUjnqCn`Khg0Gfv&Uc_;?HdDa00!qr<4Yt#tv%#H`hqbQ`M)UK`lx}~&_s;eXaaCzF zh9CRqX5JNGT`X*@I4My1C=&TFDMg;@u}S9NjtJry8cyZBcF7~#qppqCl*WW{okcE! zyb!gdTCaF#1FpO~-?2MI92|T@TT2^3yi!`0uGu>|CNf{<&g$?Moxre!(sNPIF{|d5 zd>-*jx!GP^F;#Do`Sx&{Z=jUi?AOoobwnLkF2$=KxTob-^bRqv*52TwtMGane@*?u zjJ)2Gdxm}}46?5jq@w4@9;P-URga)s#Hn~8`;axwQs@T#f{%wD$i5GJB1dsB2*d?& z?s2H_5)t^RL2Pxo$3zfvT%lfiObSXNSN`J7D61#RD*lu*oa?lIkavLo$jm?#P06hY+G>|Vi@RU4LmHYd ztF>}^?h4MQ-i2N}X68Vw48MzjLG=Ikf~5g(iCmt9qlv@Yz7%hjycCqR9Zdw@yKdx= z?TSd9r1kCp7*I0r63S4@y@;kMTvGA!GGyNoTQF$g%WJGxB(N*(Hblks<=^GY#nzA$ zV32rdkLo|V6-L#l8fMV;S8;>BJ|_etZ_vKBkag?kdu2YCpngR?QEtf}NhsHfzJPe} zBRfx1OEj95nur`%g0y5a7tb$^suX2B>VrYHp`pdte8mjqve-S^PJ?QQvZx@I2eGt# zk@0oYo7t-em8zQujCN`adESbudZK(TTiT}+t;iaOA#ZtRX??2-PeI%uMbRx~ZBf4) zf3*JmsWX_*qs*ou4oji^uyB^M55|Fth0>{srCt#yj!RD>&0qM$8E!p3q+{-DIa8LU z@-ZgbVp4Jw-Ys5MvtY?^ZZ(t_m->Bq|HrnR8rRwVh|?%fq@f(rMG0#9Vpx#D&o-lzntV{HLE~9EoLhFyQD=DUiZ8WPaxk^pqyr z7s((y7z~qDUJ_fUEu=BFSBHKQ|IbJF{AFCXk3rv_)!|8C+m#!7OZNg;k*5ZZfy>M3 z5)1KN{%UGCsaJgwBft3|kUU!dobs6re`L>(q|)OV4ecc}f%i{lCQD=1r4cJqJ--ir z3^<0|#L53T!;*$QCA_V<-bcb9M>-!lfGI=67yF!E?H+8Ey21-GuJJGRU7amUJ`u)j zvvlIq2^T87ECJNNW#O_}?-ry5R##U1#J`=B6gy7N^*8J~W&iK(k+mC?_`wx>Mqcz> z%hu?;vW~1?UNkT(!?cCAfHkJFmibppn=7Q;{f=?Ttz)`mD%`3OG$pr{m!`sNgIt~? if+CgdKaXE$+aF>uMQl7TypVYh0JRQvL&9KK7>ode0o1afg+#)TSQwH3LjqJ5pc9LPVX-hQ0fq&r zq`+7L5=Own2m}}b06BuGFaQYyurPoC1Hh^vYY+@14YCAjfj+P>hz&x6SYR?h6-2ec z4U0q)kVt^44=f8>SS%7tKw<%^T#yCmBw&#Q0+IlL>OoRqEE2#X0Rj>L<$?VGX@c2c zJ3##)2~Z)(8UzDLgDk;NkOx>8#0H^3EP&cMsvESyjex}h)JB5(z_Or4AYcgq*jG?4 z$O3d?0Rk2P`v`U#Yyij$3Z$ zASE=Y6P)Q>swe)hZyB!;C;d+3MPiMwWtT&AgAfq91v)*yuLvET4D*QGxo;aM6@wFa zWCNe8akqye_&CZguXLE?Z_42=F)p5EQdEUX^le!q@Yz zFOIN#ATwZ|V4a$qcGjehzpJ&9O!!DtkEm+po3plJ!2>$2yK35V8J9Ov&fMf_BE@>& zmc3ZtWy;t2{1~=XMt=H@89v58PyL%xUvF)b^_=-7F8L>swcZ?fuN!%zj>$Ql!6jDw!Yj}Z#-aO_3_Ejxc=b5L1&Dg8J@fPX|8o- zn`@Oe-mBuc;?ubHGUK+%wPnI_k1ZpoI)C@9bV<8-LxZ!`sj@)Iu^^tk`?=kL-nsmx zuBzwe()Wz>Q5)O%oGb+8%5t__8l^gQ+V{^PI@++%g5!W^{R5?t5|h(MKcZr`*dyq2 zr^ZQg>#IT%OWt-lTPFC(mOq{!?~Q78tWxTNXU*gYMQw4raO`Zk9xZ;x z1uu4R@Kim|=CUGT7MoNl-7kqWJJ$1@#*E7(8zXCLBY3x;!(cb?1Rvl!R7B~0Yvf-j zgV@~3>)R_oJuNWo!!r`!LxN{{gjk82qPjHDgMJRB=TSrRbsuHNje!$@-d5&Vn$#kYPGcdowwQ6*87ub!`DaQ#2y<}^ zN?!xr_M+eEIoFRqu>ze?TkhQPOV*MyMe06wnZ1!al|=lPoyrHUX^YT^==vT(D?aha zM@N~j^4aUMSL;6>kJ=pU`DMAz=9U$NcWH11O*PzwYPe)ys$%S;B~5ibPT}ZhC%|C2w!P+gfy416u2md)ivqjBUNI^^cg0>t>H7SE`LByJu#OuH>o4 z!Om87A)jRL@K51O0LO!M2*AbXx(|gW)8+!LrR{e|jxXXlJDFcs-9k<7pa*v!w3p0W zMg;-zI|p3_O}hJdiRPz_6sXvuuzjgz;357CeurxVt)+$kr$Nw68C>wA82o%_n;Ev zYF%?xg?5x5UR+&j8YoaYiXr{@lG#J+E6}*=GHhN&WOZ2{Y;ZAyHp`vhO8b|`^GSKP z$lbSxkn2kt0C*!X?+S2F89})_5t!n_W!$taB<-bIE#kz$*)P zb;8#Vhp^PlgX4aU29few$`XbfjuUe!2(ZxknWtNWxt za1f@a-ONp%R|k3DEk%($##I+KIGo=H-ZTjeW<=!)b(Ad&XWUk5A=^UJ3zO*E zh!5*>6)R_OG65_6wG8ztuTV=;o)<;0!qWwQ29(Rw&|xtjRq1e-#vR^q%^bEJNj&O^ zUmm!fnJ_yVYWNmgA+P37Ll-mlQP_1`KV6`JyFad{_4XfB$Z#(D!W5mq=(|5*PoMpw zT=>OatA;%UO)UgZ^znsMKrY_pbT7&^2_5;f!tqH}oHJQrYW)>qs*J z+n&7J(d?}n$>}z;jECbzSDA(N*k_f^HQiDdgqwzQZE-ae11FSVGxOFl5-Iws#bZgr z%b`30(IfXmUM&xmLC+*qFDkA9)f!U)_Y48`dV%$mlRDB-rK*kcIr4wvvJ~jdItgJsSHd^^PJhmh{W`rtuhavj86ECB208-J1JHep?BwbjJtG# zh-Z2_PfU!E*exRby2`Yar%%S;qu0o_R#K{|SOBT}Fb%-KI#F!RU*aXI3E5x4#_vvgS2?45lUPzki|fI}Hl>S`@Gwyr*3 z8vSc$%MrlDksY!Z=qOOps_7H~#4->I?l+vcg>t;7(v4RDTuOOT*<6eIeNpdou!+_} z>7GBbZXu%f2juJY7KE{VtDx)=8i2f69R~8*_RY!cC7eWSp$8qIHzvY`dlz78J{;gH} z-u%*W>($Z8xYIA5UJo209~?-1PD;FA`+lcO>3EQ2K4zKH3wyQeu_HAe8DNpJNhXuU zaHo-{Ar->|m(q7Y*XH-e7b!;Ox6rYUJkc|6`#ncPGtGohgQ!oPuvbERQsWrX=eVgC zrr8q7merFEO2jHN)L>f4Ky#vh{IX!6(uUNy9BGRyw#B2=*?h0|Nn;m6p6A9uv%qk$ z3SYwdZXTDtolj1jM(!W0^ujCEw$6c-(5R?+x}xczxBItxTMzI=ouFIS zc(IA&kMbX*3v5drj)n^lp)cWvJow2!>a?V6%zeXLxB$j%tke5S*GGipt~5t`hZplk zv?FEoB=6$vP{pc*25Z?u)#jvOQ>v!zw=TGW;V%n`MmIs2__RynSJ#}gIQEM_T&2d& zYY(^wcxnrgA*HE8on$0R+HcygFW{z|{?C1c)iSJL0Q%H%Yt z>saITz4*d{aQo~0mjmsn#l}sCy}6NCn>%c&DvcXBg5OKOE0gAL7$|5oEtZVTN>e>ZDXAW!$oLu2M2JnKA>Vu4r-B20! za~kvR%Hi^ki}vy*l^-k~)YvzKliRFg?eaE`n8^DyZ}Sj-83=>Z%H0vtxIz_c=g6;% z!frUfWd&Z~4gDN*(V6^6OW9v#@R(9opF=v|hxrkgR~p&iWEPI0PS(n2N3tiUmyzKe zA4bwK0nT#`=N<0Meq-tH|IS~KYa2;>1&9qoDE&xo8pjo3W=yhWZqJGMmKHo&8z%8jViZZ2$0y3-gnCZYtR5uQvd$fj%wD?pCG51*k=6A6 zE(xyMZ}5Q=CvlkN3)JjfLJ!(u(z<4#Wg)v_aAoVYoCK|H&~1{OFoU+l%Pm@ zw9%AtHk>9I#BrtS^*Jw<#y4~)O&nV!!M0~1BP6G zB>C9%IjWAVU^k2#!qzAxoST0*eUJf1C zn>sC2yA^)LWF+6fD1z5?%;@WgM&%+9<{ z__f?mf6$ArQT5-&Ye!0225;br(%T;g(N~ z1uNT2K~i@3DAgfZ1tG=<^SpPMl$a;#zB{xouPQyA{2FQg?VV0;H|hu@VuKTik+1I6 z;Cd>}e~$@=!p_NZ%1rDH(; zkK@cooVYl3*_~cu9>Tpz1zFXu!{hozWhb^$6J4jelSmjN7Z?SzZnxBGT6^Bz@ZEc` zez@}mBXj+ovS9CCk&t67FqsNmG>ttV-3e2;8GCe(id{{IdE18{Xo~>hyS)VZ0;R$Srg^Z8! z-PE_ELSG)-leJl7OWrin67Kl+MCN^_r}X{2h|LAjoa^!Vn?bUvj}5~5t0kV19XjYA zm(>)r@Tz$`j`T_|v8}PTXZq!fy?c(|qhDkA8mf$DY=hHwG&60}Iw|$O**fp0zR=X< z-ua4uPU7g%$#{hPbROcI$-9xmQAB8GM3W!F^F`f9DebM}Sg zL(SQ(2e+9mTuud`<;GPCF{VQo*x~k;?Y^F~pFUi&aEZP*4_z?3n0+1h1^37~+jwOk zzPj)J1NZ0|a~(QQdA#Z6Koz zU-CnGqe>iu2muJLKCOD!S8aLVu#Rqye5K1g{PBAoKpQ zdP?O={z0ZwYwJud7fsyQ^exZ}B>r>3D<2~|5bD>U zufIip;wpGcIZyk`t!HQpeIsa}WwlYU(aQeXw<^U63h6h#e7p6)bC7f8c+}-MAo%uN zIq-`tEi}zWF}u*8)|xXR={FnY7FItbTo|R9xH*>>bo`MTZ;2~B6y@)0t-a>%`g_=^ z&h#67X>+Crmfq>?ZBxW*Okb3oMcszVqdxbRa-4f*q|ioi;c0(ax=p#XguMmr@b-sH zOTzZ|+!4L{+aUpsjf3VF=0#4xfJ-goX_B#~-n-IMKLpCiycW!KBBJ<0%RoP|a-C#a za&GI4F>mU4Mrx8nua=^#`#in~G&P6b*FpR1PM^1`=+S^1cNh>WTyl4G(9Rjre%;5 zB`j#eF%+fldFsX6gxU^z_sM0)!i5fYVzBgvjl01)v{HU;YE)C>A0q+P-zn?#YqH;h z&Q}|X>?@K#F7KWGC>J175}h75SK3d^C~jiOs%x%)U!%ORS4S)j2@RV)Cl>Y0efw4Q zsVdtqrh1EBGGo#!J2uUj17RWXA|YWtcPffmhp z^o;v=zaTF%tL8&%p-tae2D^G>VPImjbBebxuOD|Gb5;Ne+IrBgW zZ}#fiN(s|5R@phif2xw{l7ke{9it@lmxHC!ciRJvcfE2 z?e<|kP0cEx9M76|<~}X>MY?^nrwhG;UnyyHI@zrXU7xRKSsgIYEHpZ zefvwryp_DVz{AG~OUKX@6sp#OA6sUmaphkNU0wPq_#OsWeEz#Et@ellLTRJJe5e~v zOS}+Y$d>7t_njiS5?5w8PSJ5Ct~x~=Iv{4BTj|!x-^rW~!I9um zTxy(s5e*&tBdmrV@!#Ry>lXH9KW#MKLLAw(^>GW#elG-rvv0f^XzIq;oU~RxtgdCr zaojb722ajcq@a(sxr^ugoi!<^ccV{dm$`ZJD78kILR*R9vpvkys)r-(UG_eoF*ldI z`&+j+-)UZZ?-PF6^ncSaetpJuM4l(=#6&5j82J8x?=BDKeMZ}y487cy%+Av^9VQOQMi>T ze$SrAXLM+DrQAYX^Y6#7;lOi6ZUZ}yo8<_Pi@5*uS8*XEqR(e&Yh^$UYFSxLjCW$7N7;U^N~zXX^yy?iTeMo~I8^o; zQRD2Ed%Yuym-O?VtD@V66QuV)o}mA?H{bvB;_Mlsz^`ZZ>2+w8=U8k)sDGgJ;kATl zqZv&}*x5&`ZT$Ja*sLDY?+)=S#ecri*?N{mpVar>7#`2OFw1BlxckDF zyV|8q$!l;Ke0G=6U+l1I(9>C&?~p=~qE<_WL$&M7>IIi)P+%|O~ZDLZo& zr=4`~R&h@hvZmtVl zAP|UKPglzX1Y(7PKrE3b*Z|Ka%(wysVgniJn`#3l2m}LxP#_Qv1R{Vy45kHxfnX>Q z3#rT1HcBL0W2UHh-NVBFfSAghJ(QfFc^bb7O+q#7zzhN5nw0=lLfGd zL&0!37>)qLF_@%)SON-0z`+Ov7=ZzB1X5uP6pVp`F$gdQP!(VefB~cdmH;ha4JZs? z1JD2#kj!8TV%orkL!k&L6oaV`C<|CP912H3;TTN001IG|fI|@oC;|ge50C<4Q4Ac4 zK|nD8c|bn^nm{(t4nRLZ0#FFB2EYK)081bg-~ki{umNZQi^1$1a~ZIKi-5y1n2iMV z0c8P;K)?|gKwkm501IFd#~|PsKp%ll0}TLp0pUQS0kuFYfqnoqfoz~104G2&pb%gU zfB~d|On?@^11Jn&1JDfSh?vp9GGGH21DF`lNI)M@7O)5m26KQ%<7cusnkaLgM?+$g zI_f)fyhp8May;q|bJ|COnUs$-Fo%Cci>ctK5&#Ws2VhD-^8igprH*#u|Mx!*n3sY; zQO*~-7M>sw_zd&S(o1}G05~ssX`6dJa6@_dJn?VuxI)x7eg7E2Sshj#HFQ*WLz6k#j;#cYVjBVRa4R}>}a`1{D=$$*Y^^&JlDUxOK z58;+8e4yUbh7gb!`xfi1JJ8o`|F<_ycKnHMmb@4XQ|a<=AfF%vh+~fZ#hfX0vP_$c zOG+jk>pv2}Jx4*Hk!+YsEOBT~18RHW4L{1W{Yr&w={QVwOwIP%_C+U3>XUKwC5{v2 z&F?$5#uP@KB6^B@ixAPxA|kKuD{y`DB#9<@$NSs&@iZi%-wK2VEV};#ozy>;$&>Ob zf+83H;liP`?1FZ&_=0xxh#V_Xbc@eFj*fg=c+aNb+T%>CFbaPdVzfVsF5N1m!?rkk z{iKW9)}ngL?c{Bm5r2^NM2{CA3OD|vcErJBx2}X!I)!nPc zxNpBnGBdb&*Hcpqx&R{iW~mP0map|>>SpCm-Qv8TKJJ}deQ_;$SW_zLE7 zuHls>5Z?Z)8GY;EcC=`+{lx(t%e@4pzlW-_%u{dn5r6w*aPynzCpsI(`3>Ecxf7?r zn2|%{Eo6XhH}_0G&)wp|LU2ICjjB(yFdtRn{J!qqeO`8FkTqHQ|2B(sD4$z0PYr~Lk5b(T7DziC}*nW@!^%; z8mxLyr{q=zb>^(|l~EUvf?Ru*DGd`MU#2!Ius08^VJx9{+Vo`>_0^aiR@C{UN;9 zSL@k)+_H~h4sqeZstHBJDS2v9vyJxc4{}Mx@{J#|dGpviWG+jYr`9?CJ_h0-BmX1~_2yY+zE?IaYwzLWcU zQR+j0(~pxkLwY5ZPDnhfdAD-B@StdtzjU(j=t1zWo!gM-nc^EPSWk#aQmqs|9~+8z zex}6EdMMuXaiA0u1E#?#|Jt|HTi6TJgaHJ}6V8ISFWHVpZ0x~ZU0l{-e&vW*?ltT^ zT{XpWnp9vOg(h2%l$JRBH77e%eVBcb0inUOvyg+e^;RmY+gQa~t}4l^wuNdK8oUsq zTY7Vy;~=}@Q?7plCaA7oQDFO|(4s00E*SRt9_>e6LP^!%nUB}7qG93ebd$m8$PZw; z$@D3fz`TGy`8RzY^~ikT!UVEY4HbmHRb~>K>lcOi4NVkNImq?^f?^RYP)bMZ{>W22Z_8<~Y2lcx2M(~?)h$WeZZ zoXY7~J2(pivZG?9);^7h*mgMITqE~c2U)_q=`Tg5HAJ2*8=R5-2{DQGbY7s4B9$AL z>jK#ikjZRK_QYbPmlnt6k0Bi6XLd|l*F(-q&e6^kztcW^lPnOE#XqY&S~nb6s5zK+ zwU5yp(8cHd>#_b#$dmp&rMOe=5u~W^8^;dEBfq`4h`i+<96K64CqY@Z;a=2Eh=xqp zK6Ry~W0KSNW1;lqVC4erWk>wWk?@o&Tk-mf zl=hbPEt4jOgh-|C_qqEIhSw>H#7W(&t2EODW>$G7Gs z+EB+ZmAb7(-YFXK@`uPXQ?>svC`)f!sPR1v35k{VX1O*ONf%(Ux=@Qlq{&q6OMU2C zU<9o$`DeiH8wPxY23_3+T*19)ERf9seDuX z^J>cs51}2(=ZBK9xPHe~L+YUq0i}`EWd_pZ2^DCOo$f|af2oyypqYiYPiAdUw?9liF%Eic(nGh1rj@HxplJK-~bIAU6+RMEDL&rx z&BS~8#*iMQu)1RF@8iF@LiDEUPk%MO&1=H)?M|;7Jg22)2 z^}kMN|L3=>V@9>-jD}Y& zy}wi;GOCEI!>%E(wC)q4UZnBYPhr5wT6I~70G*a zVEFH<7;Qu3LJNt#Yibdcj8>Q_wB-2~XhH59h^hmpN@_zAYVSGwWwNZ46!yP`l)C85#%H-KRKRb!Y3OYm1_XYS7va zKyF3J=!;aM_|NKR(_x6Z0c+#0K&r}@k+4%4A!AE^K|&de-i>Zoa764TW>`*iLt4V`-U}!@5-GB z+SmCv$9-{S9xG{Rw}`J0--}y;LW5k%`Ij<>cm|;c9?EVE%g(g0?8A|fuC0>yse>cXzSfn`cG7!L@=lZ#~V@q_@&ysW9 zloUf%{-Oj`Va~OxRNP-E=Dfl{-4cyCiI0H@6 zRTVN+aLD+r62+;&5sfv)h3MY;ns7b9hNza09ddbVNmH84#+?6E)L5JKOaDx{uncvz z_-@cWPgRm^!Vs8dCGnQdw(lQge>JeOwY+5&A>ZB3`+VzMicDxH@+wJXc6Ftsms+B= z4y=|O(38%~73Rm; zpJDNjLg*42iQX?`ZR1y5`D9Do4k_frcK5N|-hc+L=Fc0-KE(@H3!e)`*g{Wz&V|&* z1sPB3E8R9PKi}Fu*f2sfcUQ)A>^;wq3wk8pwFX&GB4~B(_jFTG{GBWySLqh z=Gj3D-=3F4H0_){{sh@><1B0N`i7T${h}e%KuPV^>M*R7YbsWvn(yzwkQLV;D%6uy z+qlgMErrggPIWP27(U-Spf|w-(H*5es-RJ!n2D~z|BP{Ox;8CO#(Adbx93|MVkMt+ z&Mv+$yrEdglZ${td|frW)@&iWMT$4c*P(8)UHc!baxTT{pkg-Zictz(a#EwAEOte> zUv&@fX&|IV|Gdcgm*p!(A&Xz$TH$3yO-8Z%{^-aD@?3h7rww&E@$0Qz6yAI8*}vps z6ayaDRfOVeWs-f>LpC;YZ5T~*hDM6JD&IqOp!jjO8YL_{Bz=eNB{RpnF}n4)7k82R zXtzMz7b65@q&N{~&iW|bbuLQhE}QJd9$z92tf)?>{gF(C7`@%hM-~@T72em5<|HZj zkykNAUh;+k30W?W#Zt^b#4qkst6YD*nMx*IU^Ubzjw=gGk-yv_p0Z*b+p$io&ZyDI zuB<_DINvFb%QDCz{j|Sti#j}Mq!Q4R=M9?$Z2TOSaIb9kCOpy)xHb(pR~gNQcKV=#*jA>iI#s=Aj+&tJVSWkzL`?{BG3O-?lk@ zJ-(6!V(JG(x8KNO*d_Hd_8HnbsK3@Pn6kH&1Zhm()v9{sv6UsbJA+iIUD{bRcK5_rP9x#BMH*m{Ow4OQD_L1J#QR_9njx!Bl&O?*SJ2evt_BCj0xGN}J5SXi0-;<#4X5 z^q!N=eqcWr(!88jS{R~hCUpo`!Ec>rWGl!mQ07jfVYrr0kz`|zb>u?4(M}aox74oS zO(GVV)D@#cr$IwD7J}YaA(M0pUxa#y%#6Uu9AYxXa^qOHXErsL^Ha&&{h{2-mS8sY&19AMsO(HKtD168n_V-+a%mpw6#G zoH&<#dd`oKd5WTlQ^vG;$Jj)R&Et^IbUJ^an_sCUJ0ITn8`~zS2sS>LImeKDtn=87 zkma7Wq^tlbLbRX{&sU)7r+FJpY=|`nJas{pdR!~M{o~X!m1%qd_)=#%bK$_Fg{D7zAJaF zaJy4fpLN_rtB6+pbw+Pq+q4u8>(P_ni*@<26Q>NmYW6p^!01V~M+=F&QNVN1eOa7y zFII+M;c{`-Ax~qkGg0xqLbg|PJAdHK6Q04Wvgb617BIJAyJHE8DogQ3BFn#ilA3w% zDb3v&pB0|PjD)2YYPw%$*(I-P$jWAn8EKouT(+!xhBYjBMEjEqh&8dW`?v{_!acw* zHTK-Fvmh&Bflu! z_*3`i-S#fQKIEUs(i=c2mOS`*lC+IO5X|$t+sBsHT+`+qRK;RF}brP&dAt{Pz=P|iN$Ws5;2V>~G8k^kMl+g+}g?VOr~9!#sJyM^`|ja72DZ2T&~Ql2-@^ut?%wrf)|f4+=B zjD8-nhVJ~#R5odId^%z{FGw~H4H7qO=5k%C$jiCni|}@lew3S%Hx5ns6}fP0zb>`& zt^lmPVW!BWgx@v!H~XhgHmJwzj*B&qOL5B&MTfXFFDs3hDSHWgcSi^{`gIJ54kh{> zxwd$%1ZH_*<7X?)JiZm4aIjpz`mD?yQADYkk$&eQAvqRll*1dR35`j{y4)_Vw6wQs zYjctus<9YHLR)V#wgpyVpTW_UMR(D57LlIcufuEi+?P<_X?h#w`eN`~BBOGGjxn#O zy`v3-R?FsQo1Y5q+JVu<<>cWG=R%D@JV0wo&DWbCqCN?s9jsM)Wx$iPF znTS8RCrmiPuY)_iXok<890yZ-a!(z!W`>ZY)%c5H#}8=;Q~jx7%kh3PAJ{iM5y z$9YiIa;`u2v(UrR9##>?d@EwQeU*CAb7}aI0|I{vMSulUr*V8u8D$=kC{twWtL<0Z- diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/cc_hash_random_int_subscript_timing_test_find_local.png b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/cc_hash_random_int_subscript_timing_test_find_local.png deleted file mode 100644 index ca4db96f457f3d6db6712a03f84434af3ad3e584..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 8445 zcmch6cT`hfw{1X?CW1mh=>pPw=pYEvtF#cRh7v$}N2(~Hh=Pa&LzUhkh=dLrDFUGg z5~?5_1VpJ)a}WN$d&m9m{p-E)#yexAth3jeYp%KWIeVWZ{+^*04HYvL2n3?h(N;GB zfk5DAvz0&wOvJ4F--bOCfv-%JBAK_CbSgaCoiAP^n|BA#0i2nd1zLC_!w9t0tt z40a<3VWRc_1vAb2zckB8ui07oDcLPS7_Xb2GxAp%(e)&Lkl8ej>~0>*&E05$*(U;)9z z^McN8;6Nh~cm#rYULTMau+V4(8jnB|&&vf^0E2im0*^=Fi9q!LDZm#&L?eiJ1Q93? z&;y_eL<4dF^#de;3IWyt7(g0e3Ah40fW!bc01aRf&y_nL25jKKqtV23A%XgUw19=j zqwz#QSD;*g1u%#v;?YDvM?h&n0Du?Z4hRiY3rGp*0nh}Z0XYCpK*2zT0BZmYAPqzU zv;ZDJVgMU}CZ4zG+#47MY~UaQ9Rq{}>I2dO7M@5vZ{XkdpR@Se(er-(ZPGcZzq+5d z_pg-a9RI3w-tE5ypHu!@!+G=n(mJo;Zzcd5m<~Xf0P%pD{-*jn6aT-zIfaC=0ZA#n zwJrTXAnI%9FOuPJ5huV&4u1`pzo{3(KM3yY1ky0Q$EoGw<>&9`;Opw`&nYJ%Eh;XV z7MR5d0U@fyJO-DGU6PiYg7t{VwYsh}$-eW^IL|P!T?2sZ( z&p5@$#3+io>9zfxxq!KM_}bL{C2j zILv2&%Ug;T7{gaF0U!0EQs-ja_ ze@6XKx(~~U;4H%iH(~Z;18m_GmXx6-!YdK?Bu zP5Q=V>{0jKoTMUK_!r)=Cz_3}WxX|WjKS;Z3%S1MwwMbi z5bRD!aX;9$!R!X@Qo15NDm#K%e?TT;fw`4NPSotrf{?|V#K%3?PoX zwdyr)dZWwl{HBzd2_HW2+$v3VniTLyR;zc+TuckU-a4RvxRJ7513lE9(_c1xIZC2S zK6~)%X2r}+O1C&AgW}ARfDiRYYvnoM-=Co5#1W&Wi0jd#id7ghBbj6N)1$^Mrbe#e zwvh@Y{=tt2Y_b&PL774=Sha`3D-kWZ{<5WKhI*a8UuY&Djadg4)RM8y+iu}s_Fo%* zzv27pn$1!PbCJ$5EQLx|zp2yrsVz`jutl)G=5VEqGn-PC-N+x~7u(}wSLfUxnS@3* z9K(K^mI6LQ)fnl4lxjk<*`#wM>RZ>?6K^8{DtkRXXL5a~OT(SzBwRln~dp@q}|*6bBLr!ft7(+exgz z%9H(@aXJy=K7*&*wc!$6!B=Z?U873gSiLA%X-P_n$5{037oLO<(YFz$a&xs?lpQoi zw#n2<3nK8PYFM#_t(-HjoW=buvF%xep}S-6X<4en&C0FDHL3&A3bXdztwE>e0bI*L zl3tvZI3lufH`=-XLUgCvxLBtZ&*7}X16|e;k+g_x0XMDMqo7#KqDSjuzgnBSV#klP zGfDowemM`u5c@A3`w`M!Sm{@zf)9*?(zugCeVwPcpO5&{?FEm}ZuG;nE=7{8>h=DV&myXKadrDw?|B?8U=Dl*l%5O2Brx*eYk`9{w zl}==iN&d``OGDR*uI`R>c^Go3Qf+#;XMwVOwMU&rKuk5=v8uK#$}~~>S!((uK5esB ze1`txfA$KpLqQ2qOM0ww_D>R_3>o%_JBRz8Ikr7G}T+ftk{`_+*ZfjE1q!Y>p4*6I< zHOA>dU7eaNWUOw@Bxd#cxqV}D@h!qxmY{RjqXVm+ha|%j!oOxZ%6gcV_cpn;qd1(1 z^C=Moc2DgictYr`+(YL`>fxY(kXiM%I_|A}^V5Usoq?2zxiD^@^-7_e8Xr$<9I%c( z+Kmd?V$GfjR6$f;jTYm>0}M)yPTMq7b*~*5{=jamtT|}mB_lr#J>=0tGwLF~xz8_x z2bwo~7GHFn(atgDxPs%X46hY5u(~8{M|>lN+s5osnEVQRWx-q1JbmmlJHz~W;x~W0 z{s-A7!gd)^BNxXGbm_ zauBgGn!z%vncZ$oc@n)3ZR4|?cby)Xw?B|?qKB5%38)miDzIX4S@|{CxESl9*h-lN zSq_Obehrr?RFZu|e)0)>@!KS8kFK9Qk`Z4*rrXAn*-ULMT4Wc@;J$S?S|26u1=^Cl zauZ|wk@S@+T;a?F?_2lc&;5)&?kQxTPnme#a|LSptn=HkcEUa zd(q1ez89?yMv-BLKkO;w+&o=Jz!=7KLNHKB#i%k^ThbzV=Io< zI+5kQUc)3l1+{RgfBtrQCM+>S7Qp*yu-f4}jh}dOg)-ZdE_tZ|eZHgwBIEz{O@0f# z)NuIje3_X897n!KRtz{y>5(h34TA|8D=viF7p@-+lNiNf6}sCV4Rm2{JN5z-F<9=m zz`k9(Y(wap@WN^d(m{;vmv>7cSAQxkYh@4gDYr1H)&E1S53;VwIK{>x^cNdn&={zY zh0y8`;;1X`bEipcDO@1eA-7<$?vVo$xW`d3amrT@x%EbuU)I{z4_yQCMxTAkijSzR zgPnO~32gLMe6k5$drVI!2z@CcCiJ=C5ca7!$xl&vHg$Fh*OYbzlS>wpZpqo}roDeP zH~*>p<*KcyOEazhkE1wm4Cf1Q9c_nj)%%lzCo)!oZ%@&LuD!o=D#yC!$_qcO`*SEw z)ChlgCC_zXEk;RN(_A%?x>4d<6)KbHd5w{gEZ6&Y$+LUkaK~e6Ze5laB?`-DLz{3{ z6Q0mD1e(I% ze|#F(=}bvDoa(`T76l8;3~7FAD!lHr+w!D}`EdJYvL-L2On2>pqWf9b2-VT3wjjDA zuTw0+%d7HDzOJn8oF;PV{+klt_w895&5r9!Qj!<9ba;+N)O+lC?T_J$VD5c#Bf%J! znYK%%-$Z$K^JwN58s6|_jd0u!RP`R;-Nd#m?ZZs_y+8FK3t7+w)wLx;dFhvuU8lGl zh`}MdZ?ARUV$!pd6kHJuvQXkECln1?M2J|ivE9f!?De(DHn(i6k_ik|*=4|nG_6KQ z#BVT`=26PF?H$v%RQrq#c+_MESHEO@E%1lG3>##9b6#O6wss6wR5u8@1$(Gey2tOhUI&|7xM>6+`VvEJHiWyhbd zcI@2`TKh!c+{>;tu%nkyB$q{tCCdL}_`pD*xMENga)rAYm% z$#fN_P+B`{$h3&h(ge)D>my*hdE?qvUGiJquE?vh)OPQaR$A(7FO^npzb?Xly01Yo z&04){Jn0+k`QdmnURt}cw*Q9X?%S!nys8s9x{)!`bj=F|hN}XF0t-GV{)HRCZM469 zs>F$5I2UZ;C$2&P--NpTr$)ZvIZ29wmr?yyuRJyyma3Vj8n(=!c>36NqwdNdtLdC4 z6J3{Eu440x?ps^v8A~LwR;jSH7p>Ij)@sn9JRMC=Gin|#ieAFRneB~t?7$}86iIB~ zf2>I%`dLa!vReG=h@%*D!^H!tZft8j^G~mp2Ps)uTL;6G{u*-R@1MvD>Nov-8rNoi zYA!W*`gx7!;)WdQM^-5$u*y8ze7erIUXSQz%>e=??9-j@4sq28DUqw)u#L5AmsVW1 zX-m7Zc9myHcn-;uZ!zNK6TO%8?3QhF+7a8bk&%y@EzI7Z4N3Pk_S|=XJ)VvrFt#~u1p`q+N>S-U2Y7h35zw-mg;h#QxNjsxb z?{&M2xw6F;D!(IlwyXY&1l6)L2cRqaFB8s$D(__u6W z&QdJK)2L!_+X77B54!7L->2jOfb+K(D2KH%{avAC~wwmaT>>5OdtK- z!&|as+N$SWL|#H7s}^TE6gH{mPWFw@mZOn#N3HR<#i#FFAn6LF4}I|X^(9e!YkYu^ zu>Y+CUV?`O#Y%nBwk)6U<*_ZpiV^P%t51umg<7FYkX7u-CZ!v52lj-c(48zpr{p3e zp-@*7y<{en?|+S7<#4f#zuNm0F)>%AG5OGBPo&5E@S!9MpD5SPAL)lIrs1T{L)~l%0Cg>q|}3?c?yQTp^}c^Z_i~QS9mj1-ZzWEd`OAH%v=yDGJM{W zhUcspyOU5#&%LDqp;(t5vj5TXIrPhA9M|3ER;}8mTM~!G*G>5}XA%%}j9F3ssjg62 z9?k#q2laTU7{Nx3o-_W-hd`q1)5{IrqtEaB8lQZScO!a_-9;k6ezDc@61_4Q+2(UMGv05%17p2hX0@`hd?ow>+y@gB zDdthhL&r#tdstTR8SgmU*n$n@0G#;8!gEGSm8~tHHXS@;Bf(McIE5L%s)gz5V%zJg zq%&tN%IP_UMT?9D^fvlfKew-M3s=Y8Y56WR^MNq>qPP8(SpBH0fKb@(N9wkDnmCU@ z3?qTxCbm4%Zbzg1oucvf{nA3$`!t%;HuPb_-c(DaM&-|yagsAf3S60F9_G4Nu}4z5vcvi;3Vw-zRmqVR7GtHC+J=iZcTWrJvB-Wzm39{)8aye>!J63pyJVc zu%8vmb0?6?dYF!+Y3}f2ch>zwvvsYXs{P_6hvrWsp~3;{wc;7DACCtNaPOwdHupkq zYt`q%!0#husOt9fGWC^8!TosE<7i_mq;n-R`tCw_IMPyNYA%zm;L7TIo(k9Bp`1Gt zEtRD;)_A@7i>JwvC@F&Jw{KtTQ^7F;awIqfJw2R>mkngS)-uq${7{OVe3O3OStP0s z>!%!G_!u*=%>eHop0f-sdNhtGr;m0T;G*hNIge8u2(^O^{0Lr?>7+-=Cva8BEB!q^ z7xM~(wb-ExTg;)87n*bMh?M16-;oUzl)I}4PGdqbQ&(ApOl2_;Ygd7InSc7{i~L|vMT~@2^wbwNPmM$>-+lCyux$$q?AL&4eek|DWbFA z-8$fAMux{e(aTwmIq?}v&D~(msFxY^Ue`?IQ+gc3<`$rDvB()%sN~3y;o)_GGt!B31&Io z=%8vEMGG#Djb!>x^Hj7)MiQT678Q5&Uq`_I1Y#2(UDsPBugd&d|0!o=`IJ(GFKQe> ze9sjQAYv0DiZv26$7!Ps*6+sVYX>3^Q&4xF1*%pmSZjmRa+Y5&h{AQSEuBZ2gRdn_ z5tr`|5N_-(VB6j>sb$UZFLRg&!2^p;wdDO|ZW5dY-!I2~4B+&A^yU<5-1tpkF zuR8qEdboVQK=%s~LQb!ZFp;qDCZ@BYHMdLE?YzFqad_72Mf>g3Re0y#_1jJ0!5Y1j zp{!S4t&@{K@ox0|8F4qqr68duFx~pMhFPgX14qh5uUw`l>`Qs|+^b!23ewhmbcE~7 zOwr&QtzC)f^YVcV@U@p;wK&`u;G4mp2KYiv-jh~N`u%v$S#cs&%qmOSxA=3-RYuHR zah*B)O{Je|LaKSQ{11k~@y@o9`P4A4Fv8rYH*K#bQhJ?X0h)Bsh;-A$P^43;>0c4T zAX*w)h;`OqHJR%DQ-GK?`SI^M+ETDP)3+>NnhRPdfTLCX_>hfaYYN+_3I1zQlEhHwV)-Q(ZCJf3@kZO5{M2X#Bu0CeTR3|{L1N)TfM!28 zJm_H}-LXz=k-V|11#It5f(8gjYVbccUW0VdKy6?9d$E=Z*9c$4qruy&mJ07##0Xg| zypxTT;gcJ_a9jPRu*WR8VjOoco+={dsTBClO+SrV+TE*Cu5gxo;9RBG z-V;j&oN5H{K1F^XKaAcU;6$vMAwJT$Svnx%tOde@jjHI#wb;Lh62&G##Nsio|vOQ}E) z9SmJv%@kZT{+waOQGCTNi~yG3ZH-MFC{<%Gtf*(IsP*S^7CD9(rH8-kZ@EoEmyv%yq>DDY{U^qS-yxOaeO|G>gpv7t$1u6#yD5C@Vfb8GD&{xf^ zjGbDkv}e}(&pVSfy(^jztLoUVu=q3WSYGSLg=>NbCK~>Fd#Z7A)^LA)CxXbizu+Ab zyKwGKb7tDU@6b2(ZmkI&$5>Q3A%7LV_Joj;l~1qa5_wgn-P7Wa>qi&hvee^?Ac#{E zlkXk-K&_<&;A`|hbFxyv(9Q{Yg^y47nYc2Uj<-5mFb0)wkAU|45FR|NdG$w%C9q5f zjvmCsCZ-*#9t&OFR{?0ga&F9iDh<{WndhvuS0tbEQ3TBS_m+935F7}m*NdQW}qm=Vq(cD&^6 z`7G5P^6!3Qz9(t-(g=OsgA>fb;hjrSm?L_|En&8KozOb_zyae)FqHmn=M&5w(|>;k z!9k)^+0rvv>VG92#K{A5>BTOu@Ugb@KV41!{D>G4Z3)VvEMK|p?{5g+)^=*0-4Ra9 z6@u^mtIItt_1%)#`ZtBO!h^GSwIYx6`D{LIC7l?3D>nJ(5-~h0NM!^XPRV|IjydA_ zyRSm{;WbBEwyf`}#|h(KdED-~xr-SWXd7-lwp0+=%KfJ=nikFP;&3?OtW}-OjepMF zO5AB98se$DeTfN{3SUwtC+=$T1rMF6O?zKJtnJps{+$B>e@IM#1or0%zR>^qAe_bi zujIC@#KQfq|0WP(%{wRBQsE$qks7#lko@~I8SUAP^zaML@b#BT|9{r9_Gp=|lt(R6vTL5JL^UNUt9y zM5IILRay|FH|ZsW^G>+${(0lRG2XjB?imSZ?7h~WYtFgO8Jv9*VxXtN#K6G-fk2qF zG*#gc2n`ehITiX3EjY6UdsG2|&_WD!4AsCP1OkIVP!I?f0wF>m0Cfa|L0~8d3=4q~ zAuxa%M8O~^6agaF_G#0H^3EO0TH4N&V)4-^cBg~5n07(guxj!-BV3JXIKVJLvg0t{kNFf0~^ zCBm=(l@ypuM8Swy7?B7g0w70lDGWft04xk3!T_);$QlF#NrNmwT3`$;3}S=OAQre7 zpbDan!2^pz5m6|Bst+s+j<8r1mWaXvRJkAvFi6Crh(r_-0M&z}z+4o7MFB(<0LlaX z0BM4&K|4VGAPG<*$QlF#NrNoGRFDT)7{mslK`emk95oD%!Gnm!0#qYGePCH|L?mK~ z0O%_y7i0kju>cVZfIfmwg9d=Sz;w`PP%UUB=m$s>Tn*X*asmZ|3PIK&7)Tmi3DN?2 zfQ3P95E`Jih?)(C!7+FMV8=isL49CZa6|+EY6DN&Pi1k^QEER=nnWda;ybmyCstB9 zp14Ep_K9FBFT6KRPcEtm%-LJ{sk{!!?Ee^CA~Kw@O3?Pb%rLw%CDy|@1;Im@9hYaPE+myx2H=88&oso{ zW-|4~f`9b(bm)4n+&YX)U-IwoNQ%0jQpCN@YbgpWHn}Yf`bF1C`}g&|CauNLpf48f zh9T9f?}vL{S^L72 z`t=HtvZXf2_J;LQ{XIT2L2-(`KG?#SKCQnFnv$CzISP)5hF7^?BDl*5tx7QWJCo>V z5e_!TuMy%E3l-On`ZZH(kqMnCDe?Xafs|n_nAl}0<6&Ie6O6(h$7EjndDJbGgHi1CweR>&$e7iTYe_5YLZAD=e%Sqgd>Q;5OsONEOD*%ejIHk-B265 z9p}g3TGTd}S)i(s#P4@?-Rd&C;P><*LNLx;cwkiOo;SjJmchKTVE!|GC44Hkq%X#jeK@(Ek{? z?d&egCK)m&uJ`RkC9cQO+P)XlaIdp*9Q6H9tkDM|v_Bm zgwU|9iO=;Gr@yG665Y**&l6yMr8QjWc?9cHtNOGAs*jH9NdQZcCm@QAFCA=>Rr2HLVobE0VW{KDZ| zm=P_ENd#+0@!h=Xd2Ros6;X6sxT4Lza4*`{40`6{-@MhVSh5_ciko zekH3DZlL)Kf*Ui|4U14c|e)4QV+5nRmPs^&^FVhUWnzEgh znj918nBYaWWOI!i&NZcovHs~1)xMjmAIT8Or6%M*DP|8he{tCc$%x*;=vq`n782H__;wOTH|Qqdy)k=|In{DFq-S%s<}O zT1NLmpK9d5@ZV@HXQB=qxZ*3y1nG{LJC~chzRC@D)X9HV7?6>2w9{wU=SB=`Pu=p! z#L#;2ynvVamS-pkO?lZqfI7FX2`E9|s%WEsdov5v(7u|8y052=j-qpVWPH+Tm;70| zde)jytb+6#v{qx75|r&%>2m&*ro?VwNf)EPyn%tMUahI-nm=`G{?hQ8uNa6HodgaPd~F zLgMLbJsrDRAH0=QNW^Z5s><=^|#)Mj1;(_bTa2IbOCPs_iJ~-H&tWSLg4I67~V~ z$A#oOFr>kPv`XNJu9FGR?0}t2q(Q${0?u|;=+H~3z40t-qmSN@QT!RS*2XT_&pN_D z6msN5K`$e&gj-IS6Z=vhI`_pk0cVJJp`|K_NyYFxC!=?!Ki@zaxV+uWx@u;ED_DQb zh4P#^JE)pTzxGHDvd4AT%Ctw1s}|3-9pyc6=g414W#xE&qL9)J`p zc`*#$yVg1YCTQNe9++ME+`hxR07P#lqn5}th z$8sMWCX-?jdj&^YS)T1Ufqh851DWjwWt1eBPYSc*M@lMXugU%Z1mco567u-*KL8to z=j03!y`3PkPxzYke<-IrhE_&502vql`eSiyKhkdE-_mP367%4voN3XgxWK7X|JCV+ zF0{BN*K@6|^!^ngulax>&AyH)C$_@T-h!~-6J8x}Sgejvb=^NlTnZDu_Fo+wB8CP{%_I^jYrD@! z9Ky9q#E0O|^c=u-i{lTFaGP_-s7#xC2xNJe59h9Z=yHa|+GzL$ZFZ{k)|-b=b>Zz& zjZoe;J5J^<1@rnFhp}PrUkxnZ_>O7q^tI^K))5{vw&~#QwBy|Ueyt)VLfSv&N}dky z*2MXRStVh!XbH786-!QfO2?E3zq;Po;jLQidLmk!<=}Kq-k(+LO)-&zC7Y_O+~vgA zkYVQ*HGwFQR4#_(-v$@AHq@Cczp4RkSFrwsQwf~oT3N4yLyd>qHxr4Z2ba-yVuid5 zPP1sB+gOLcP_e_0Lm7v0Nbfe%%PZ;|tK&1!62h_FPwi|J-+3|juv@ek$99dKTGlp_PhmVdG!^5n z2bUJZ8ZQbIvzWpi6%WirWh`*0rF@&VT21I;{xgbdLFIU-gPg1&%yifi{D(mRuQ%9g zQ~}9UKonbU{TCxQ|FBbV@OuprJ>BPCdvEvIJ1rV~f=fPoclCR+mC>bhTmJDtN1Z2( zq%~TH6q9~o^1Z&hoOpjM&WvA>K-L53-xh!OS;@CvF*$q zR|lUovS;t~c-o)xzsvtR$|$lL9CVv@eZ@d9!d~Rx_eqtH?QiQR9 zFXb~AApQ*1`()?elOMShZFcda$eXaQ4sRz7boG*72pm0GiX)^SHAc^Ica4kZzr@<% z<~7qK@IfI*<~iwEHyIR# zUAq0D`r8ct+{=68k1urv&?Ac0J+GmBZ{KggKg>r}luU(s`fSj&B_uO4tSvEln9VrOPT%);OupuVFqeO2!E0@sQG|A8I1@fd z;cf{~f`;i z^8V#-dX8JOO{w>bgZJojLmq{!4SNt$tj}F9!SF%pB|`<~rylhOFVE;}#wcoa#u)Qn z7EL(&i?a;gsk*(1Qw-F|Kwuws>fBzj)qLfr9fv-|pqt=BH6>!5-eeEO{Bz=kR}N~K zb39lPw@AL3X+B8#EV9S1%}~KdPrO9pvJg6hMH-LGUg&DV2a*0^8vavD8?w6Q=!;~E z_4mFP{*&srv6SwJhf{UfLgt;NDvDe&qIJ+&QQ`I9*44_Z9nrOmsJ3%erysA?N=Y;J zw&!V!a{kfTVrV7#FVdcWuj4b@&>zCvW3AHw7a#^HG`&MF9#-r`Prb}97<90)>J_8g z>0>Ijup#9ly%p%)@_U03p%EH0D*-*mMHXI7GOyiV4Rg$g6vixh1npdS70?!o`8Hd# z>ch*C-So`i=d$5aIB+R0=5S-(p5C>1BzGavOnrg#pqAf}A(AyJg5D~s!HCVOvXPH- zELbCx31$DVDQ?V{p;9W=`=dFj*;m?2dydp$8&zF!UBFc6-?Pm4{kz$icki2B{?LM3 zzWl}6V#Wid{#YdLYnGiB)SzR_Tle$2rP4RHJ=^RI8e2ZY*NP$o@U!Xc(|Zl{(p^yI z^S>$EaUy$TDx&36WbK?OzjD1Z%I*lio_w|tjNBK#B;f)0`HOh()m-{GCqqi?E!#Gp zq$MPBQ6LB*{O)kLY3<`G-reDIwJ37w)xE)gw_c(TaIv{OoyGo&D^h3Ij6S+>LM30^ zdy<_YWgECMeqP?Q;`geF^-RXxr!0o@0gZ=Ww#^j97mT-*&3K4(8{WAF+TjV(?F;um zq+1OB{-?oA_iWSS_lTvSE(^=8zE(;xT1SFqjBCR%B^Hsw#PQ4j)4fvl>mXix3pH)F zjMn9lORX>J%nRze$_K0eyv#Q5aDdVcz$GVl(p-I3!3X=?4{Pgl9vOO^krFn{sxpb| zbM1_GwamBJ4CKMxv(h|NzuQZBwdZ(t@jxs)F?Q`dq?_t57%MVofqx^secVHUFc(wU zwxQ1=^O-uE_+nO1(e!AOpZT-7;K(&}TQs`w4#ZCO;s1L(4xXmUpEqr^DlvI`l^StI zo*M}8Qq&T;W|~y1^ktu1^Sl(r^O=X=vp z2hyEgEYr`!IsbeSI2O|sTvu4I+h`r9o!b|qtl^hDaY>TPcIkp z>XHzPZo8g^Ycq+Cb<8VBLdckAKHO=t%4>uvD3{oOdJfnza;e*|`Joai8QI!c;^qHi zQt3hR%{xxgq9HA${D9~$1tv(~*5yXh=(2_9jzskNcPyVn31(*m#x&+<85{Mt_EYP} z3QM;z`1eJ}4=iGyPR@mZ;SNNaD#>|BvO64>)3~=>YxX%o6`g7s9fq)&-tbCpIjXKC z`F8nUS?-RM6l(k=qt3GEzjB;E!EhyvK)&bBHFD^0+S%9~Ki?9^YN>X#Knc&HwC+SS z+y2gZQp8m(b=16LH@`=;Yt-&^9I9WT{T|rmHJ?AR#y6amxbx3mPh(((hhA@$*3k3t zwRPq#@^8-LZ(hTEo=Hoc@|NF!Te^MuIUE@~xIvzW!U+eRUB^jUehVLTP4Pss;QCMp zlHd|!CMs%-xJ6#-|zJS&85I^Tli^7qe&zOQYGmlVtki-*~kRZBzs<4S4@KbjQ|i&ZYZ* zpm~BcfeyAePMarp34eQst|~>nGP*XTsD<=SX<}PEeCUJju(G{Hh;1~Z|h=wBB@0C84s7||KF@CdlGhX`4KV>P> zsMRYOQFVND-SH&>`%owH--vV7JW*1<`lKit*}*H*gr`emh5GmOd>)aa-VuP*+=%Ww z(rEbBQ&-1R^QznM?*!JYiTIHY+ly#?@hFJU?{BXF=REc^58tr(sSx#Lr?q7cCy+8& z%>oE$BSQ?-(kEv2ie+uJawiMP^Pgs~m;Jrtu3+B3qwbttKVHsow5;)qo=>sRiYNAA zilfZ#!`WqPc!loJ`y%pk;lzT<3U_syQNu&-uROjML10&TvU{_^F6Y zIAN@CIn4x#GaWzZ5WyDdYVnxM>&t>P%{aUo_TQPof4LR;f1muF&SYmW5NMJkWQW7-$~viV za>vxAU2lmDP7gqi&i~8gxPARF!jDUlH<})8mpmi2ZK?gsBxl!3FxH+;KkdgSnSRDz z*6^6zhBLCohJ$)>hK`xE@-{1f9g`QE!ZR4~wVlkQT`Y14$$<9B;I4Dz;2x|ig%W#b zgcHP~Z%RUQBpSNh(6VONt4@{=)TXzelkZ+^QrFm-#IiYwJSqQjQ;IKCvoqB{UL1Wj9^3su~&y12iE3Rz`pmWlY#`y8; zk=E(Fwl5I+i`+9&Ka_YM7q@fNIOYmVBpLsTi(V>w-%fduW2@8h>llp)lS9Q~JIw{G z#Fu3184V@tS;sfBmunxC{@i7_QQp8~t?{y@q2d+y{AFCjW5Mo(A%Rn5-$K?;SY>cDH< z#Vy$JmsY;Ikri)Km06rtfgerH^cBUBryYhR?@Ki%GHABk1qk-MM*HmWCD2 z_Ym>{=8qg^vtKr>m3!{4N~t+=dODZ0a9k-j3LBMLnY0(YD`KC|^~7le-_sQ_vHKs1 zzNLNi_1^=iFVEE?MmD ziS|c;@4eL=<~IAuYNpkli&5 z`9X~jS}?$tj5t;80Ur~+T(#2pZDS#Z1-UTG9EhZ2+6pr+j6`pV&(-iW%XE8sc%{y@ reacLx3*5O20iR1w{l}xt-|G(=mqRyZu6(2Z@}i}tr&{pf*}MM*#|2Jz diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/cc_hash_random_int_subscript_timing_test_insert_gcc.png b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/cc_hash_random_int_subscript_timing_test_insert_gcc.png deleted file mode 100644 index 6e494038125307760faed5281441a5c85c4c3036..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 7636 zcmch6cT`j1(`IN&k*XL3rHV)m5Jj3qsUj*!Zy_KMDFV`@g(}jE6%4(IR6&Y#f`CX1 zU5eCDLhn5UlD)XQXZNq)`M&*Q?>R}%yfgF6Gtb=Io4hwt=ZOX*JtsW~1Y*>DpsEW3 zQ9?is=ffUpjMP8f&&K;t z$}^7t)H$2>zlP5!|Lfsw`2T2~b?~ne01ccDz?1;-fS&%9`gbP&e}A*}MO_1m(!G3O z;tm2au${dq1||befJGh;HDeDw7o>-mm76U{O;3kc!_LLs!`<4={-p=6tki7@N$JE_ zsh2?@PHj!q`}*D~>+td5BHj!5#mZ8~(fHFxumkA&1O>Yf{kx!yMbui4ET5|EPJ~nx z1T?QQ;RKSr^b;IJxkZx!LQ&iVAwcy1Et7Lg4MfFT1ufLgF<`$Z{J(N7Utm%$W!gt; zxu<%Eao;bB6-jrZRk7d7VPU=7OnRZ&-H6AV-`upML>N~L!5UsNmPbTmcS%Cp0c>5H zy>eE?jGEi>(RlhTC5+es=?^RGR8#1QkYT*RJR^$mLSVh^itC%JA-U7GKOQxb%Npj- z54}9jRWT;r>K@-rUvE5?q%+Fb-6qRT*R(L>Ih|%P89w*HiTD&w zd`DGI801szpc?eu+jT5elj&L%sv1rFCcpEJCSgdVaNf}4_#CzmX77hB-^GpyeT!vT zU7QAc-n-e2-l2EzE6z4}&uD!MKgASqYF{zmmEOErXAC?2CeXI|v5Ktmu2t;j9_yyi zsSi0@zk|sfHfn@F_@K)-@gCvnB!Sdesa;Dq$9OL|UUB+0WmUF#Sra3NAQk=&v)sM< z?fr|-b8nr`HkPkpfU zgU}~JsB@;O%(PLcCK7#TA>#nsB^fipe#!7DW)&G@Q zhUdy#^}x#gjW*NGjliKxyf(W%<8n8WS}iumhyo2$lMJJbwF#fiyC1HS2A$&t=g=k5 z4g$k;R;h+a+pIb5$S%mnz$h;IuZSjQ?JINn)c&^XohC!pjt}-p3%#54dR&iJh0I2m zJgs5tF%V*aZ{iQFq*;B* z{qNV#;kC>wqcR(G2mwJ5+o1+VoR*2F3)PXX;pDg^H6rea&Hp;*kuJ-WRcL8ZnzY%g z&hd0buG5{?ErWB)GFib8nwe|r99^7w&pPBYwIFJ3D7iT5|LxG=h`y4?kKxO4QHw|Q z-%+m6>VP&?ThCErzBtFHgnBIr9OLY7wu|-)ASz3KqvlVG&_QkEu*8Femz5&J%_nYU}N6wQ#-u(NkzsA=O-zTs6PvR z(yS1p)_*+6mn^w;mm>tCowvbvb{$clWe{Y$u2BD)(_+Uh<`>w47mKH#>H_2Fe=l@t zvKCaD3VqHtVkyk+Tr_L`N{yO z;a@Vi4QnXtBOpbQA#OX=4Iz*=3KHsmK+2F;oo@WYkqOvJS}+Q2&9`o@ViO#oRL8 z!Ka5Pw(Ji!(i1}JDQD;A@5s85A3ckj=V1; z8Gl5=t|K-occ*pl{*1rLm7TVdG`Nd5BEeM{2L$f~-#`r#%jWX|U&Wzq4QhMVQnkz~ zPUUq&`Y#T|1o;W8XaAhP38Lhj_(8~_ErAfya|C>*G60L}?;2PwNSGp*FYenIvD}EG zS$~tJ8-Gwu#4;>DTpK z&3k}YHlUU_=8$R`XK}wMO(flgE}3l$&;QIfl`%?Coe8DM6@LPWZP|r_}c2(mgYu!t`beLs&k$`whZcVRyRA-SuR+DY? zR=@gff8_+yPtzB@)2JU8=%YhQgqq9;-Y0?Ykh?}4YbPcC84$8o#_}y7nTCLvIDu@~ zC%xh$cf~GED#@gz-aL9AJGE}z(sC4X0#Tc7ClAn;L`M5KlfW6beP5P_3_+cHQq(*L+?F%96+2z>0@8ZTzvEsYVZ;E>#uZ2@lp7M^L zpQ3H}dr@^vT>+&9^Qcni@NH=;YQ`V5l-dI_}<0GxSeP!yUoP%-f zgGKxZ&BKan8);s7vwBTG(uNFwWc>}Z1s%!C-3uAS?2EjqatZ4-DcP2@U7ff9dAo9r zG|S$0d*a^!MK5vb!u@Dk7*+KtV_36LktV%VEJNUMBhi&(;P!Lr%^_OyHjP|8bnh2lW3>4c!@>t?)xTs@;RHEpCc$vU2j-Fo;gBP@_!ip%_<~b zxzmVh3|@}#QqUcU%Z#qM2bb${*o=l=*?srqlRy#wE-4~4^_E7R|EY~>{rJdgEQgrS z^W5u&8{yL8a2Bj5+^N~PX1w-#;cWM(msNT$mKgIjoOgb*#O#SFdE-zj4x6YIDktuK z-ukA2^F}n+^W02=Td-t4TX$WEYGU`{^$mgUQB)?|joetSLn>EqDa?c$(efpxkM@J` zL>aThpzYl<*RQEf*}HEBaG`JTG%6CAF%qj*kCQGNGWRB)^al;3#1K~O5>YmG+H6=LW9_|M7De}TL}Qm0V^eXGgCP?O zeew-6y1ZhQitIcQs2atD8?F{f#RA~E;hqsIR-+|rO=PilWbEk3?I$&Sbhtc2o+wo z@hWLjLt8Bm2q5TbFD`}i*X9u(eAh#o*Lrj$QfAku-Mk7v(7ycqp)gbuemu{>W97Y6 z7J$#fwtFmpgwO<(H7$v4f_yoVH0q>RQzYv)>t{tDPvU6T)0%J| zaxrC7qDT4Czje4WVk8AECdK$l$wCuQj#P=$VuS?y=(f@Ozk-3|jSY>yqHjw<+-Va2 zyZACsK`E6AgPM!!9zE#omKtoj_EVI>4-CpJ;Kc^7^nGW0{ixy6V#ziR@(q3iksZi8 zet)9MPwGZYXJ+&MypVL)|0TP7p;q>52fU*0(`DpFqQG2ny06#WwT0;%yx!yF&t_jH zpLL8_r>-tg1vJm%S4U+EGk7>T2W?O`q(`bUY?m$iE_2CBF|VKRzMQmv^cyWM@*bXdY;W=u>x1tG*|UVU^G%r{wfdb}DmZnc>!q>0uRZw`XYwd^-y zr?^5yhiER)B|>(Ppd-p(mc&&hY2T*CQuAyH%Lm5()$Kn+Yup2`fxq|GQZ{y+uzdFQ zoTNK)ExvaL4b9toOV0UHP}J@q5zZ2wB$d(YnHJ;PdfbdKLMO!dTn}f^4HG0vUqt-= z%)@*!(Y{-wa^iEmSa$dO%{9{DX8LS1j4<;kUdKN3y-d#ckxzLLE$vdNA*-b71%;Fa z;&9zc60FUnZo~hpi7G2L_8AwR68LM?C=XEmCTag$XCa;e93h_a?@-?Kh^~y?!SSE*#~KQ2M#+(Pa~O*=bfETJ*fJk^5se zV1sdn&ywy|>G?M#Qv|^8vs%3nH@6cH=O1ISrYmubdaG~#e7SG7Fq`rHYFhFjwaA)M zJ<(@0X0^>Rh0oy$4V)@|ObF~k&70fKzy-nQHk4QWoTIae?rT@+6N3I=yF*1q zj0z`SYl@glZ}Ot0n@Il@R@y7<@;$%q2GdsS@TU+g0 z`Rea)5-#53CL&u|yBDcDlks@+cIh<)7{&ccia9TSB}fUCrftB1yA!Ap!u;o{pHQqR z!thzwC-BCX(|{j`IteSIyWb@cmFNd+ZyXl&x|`^%C7$fKb&1CoS3Im%P7IxPVRvXt z1cJi)iiROKL`~=Qx|L%O$2VW|D?I1;^TtS4d;}t=yt96hCz@S!WdZPhXMQOEJ55ba zu0;bw>*x@S1;6Q#UGskFfCrqo9;g?MSc+Bpbke)u7LBUIISZ(Y&3McKN*|W)!2Oxu z>`CFxfJT48Tule&Rti7ZwaAuRp*J!=Y^@kLWuppwBo(sLpoO8(Pw*FvBXy;|q1&5P z0i}n^>pS^K+Fh!(*-24_9L_cORxz_;B8k1czSyd!RV)Lz*;(t7P24%xCZ+ zZghO;-RylX{}|g)6EqTIojO1LEoA0gtIHt44(`<6Z-vfMZk(<(=#Ve)_z(!T3(`3$ zUMw$n;f#po^1D3cyt7HU&&q{(hBDb3e{nDr>E5<8d{TGMNtPtv5P%j?{@rqe%k{Xk zk>QWpC_?BNS8~gbtlZ=tAkBbvqebxM^`Z;7vFH&q5Rb)) zoRj@{n!CUpEP4F}=GNH>wN32%v`QJKiX(X>*9P&;C}|HA0XG-wIWMz6G#4Th{An>U z%(=`OJ!HyTK^Gs(*#ZAg*w=J6D0Uk`k7te%^~Rf~o)jwlKf%AWD4vcUa%}>UdrTt; zFBc%vD>Plm{wY|JA6G(k^ZVgo^)zitOGBW(le8O9H1tD(_2sN7UMiqO33H&9#jj0D zsUsAcwHKs1)2lJ6P32m>I@#Bt4o$amCc(uy3IW0g0rIjHc`*|5Ja5e>=I5tVbFf#n z6sRvm>F|sdnJ5G#LU*s6(|vG_kn^g^YIl>8FZ4j;$%Rk*PEuN__-Xdb-OZj9ElrJq z^YWIz+Tamlcxdb+u#=b)23n z1uOlS=J?)OyxaFX_9Y1}P+DLFmK5{gadv+a1c~;UFm6m)oMtD*17F%c|LW(u``7>I zSF}y|U*H7Re^@Ba0FpAepYjXO9p;-R+2xk>krGu&lP2P?X99gVPEOw~Rt$2R3D+&r z)_aiPM_%dYOPHT4!We(CF166~7E(y@27v$Hwu1l5`^FFUG6Q_4NJt*0#4TGu5!b13 zd4+=0Zl$XdtZyk0zuSCxR@Pt#cZe^mRqvfcUEx{uw-bt#cgtC6QI{AJ783|M&({i$ z);mrnSuW_Zv!czN7pQ#4mNHkLY`0=_=rM|qnc-ehknx)|7)4!XcvY&ZQK0+#uiP%8 zXiDiCPuIT}?jCLn{(wol=SM|6a)z7BsPy`y`u{#nbs?UICKg1r+l;i@LiZ$>Ycj?= zb2zsqIcxOa=w+n^f`Kyj-|7tEeS_-Sj*~xDLegY>O;?KzzXPkSVGpOd%~)f^z$E)DkiYi_(^udV9CdXEbWXVRcbA3+R}G;lTcRF`r7J(;b$Wg zDFk&3zB~a&y7aoxkA6R|%aYh`8T&2SY{mp$k0K<iBF+5n4Ik`>c(3NMAT?boO%wGL!;gRpCBDZhbaGOu6 zFgKlf+Etl&mJe+$ef@1dge0FKAWJB`Tj1CHw(QYB$G@c?l*vNjddwrWCLf6mN5j)r ztu4XbwrxMS{(da|tmn|3SmLkPu*Qj?!=x?$dUH`_dYGcY${e$|FzQ>ttsz=ci(JB5 z9U9+FvoLg8??bn2l={y4hAX=;)#a{ivzI$KhD}|4r9Ct!iX0kdg3GUQ=LuzbDS9k? z_bcKy60cIm_5aUD7)pB!_JuR0REX-ncWtX%{d2WuaH*^g?V(_ALuxL_t;NVAng9mRLx>yM4499&>{s`BYGw_H**>tCeF>Ikexo`ESys30EJ>|q pOBf>v$8eA8h*AfH0bM#d-woF0>UMtE3p|AaX{tR@EmpP+`5(mc;@toM diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/cc_hash_random_int_subscript_timing_test_insert_local.png b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/cc_hash_random_int_subscript_timing_test_insert_local.png deleted file mode 100644 index 48fcf76c048c88b3e69f9021057c2391b237ac79..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 9396 zcmch7cT`hfw{1{5(xeDT6RFaaNDB%IBGQo>IuQs+@4ZMDX#!G0l@8JZNN*Aa1VWJ# zic~>bsM2fh!TbBhyWbo4zi+&E#(=@vYwfk>oNH%u&d!O{P*Wf$Wg-QEK;()qo@s(W z*PtK}ULWywVB~HteHI9G9i*Y6Ef1I=5Eul4gFpxn2n_<^t}HMZ1crma2oM+z0^_cn za4-lC2f+~_I2r`UUBx26AOswQK!6Zv5CV5K6%7WV;UF{ughqqVI3N=U2L|EbARGdO zLxXUD0ptc!1G#|7Ks4^E&ea76gArgb8Vtr=l?5y~91KT*;b<@%cZC9QBH&;I0*pX| z5x6T*Kr9*#MkByzG#HHoFalG-I5-%G0OQbL98eWN4I~3V11JGlfDb4PZf0)e{{65t1v1uQfg zfyM#40(1csfD?g3BXEF@fYN{f04^XL5E@_$ND1fxzyxLkasZeB!T>`6HINJd4a@{! z0XTrdKyDy4?y5ys(SRGUfeQz83=k6F2b2XYG!A#wz`yOkLh-kwSN;6kq$^N=b-!xw zUn#FJ{#ECy+kXjPLH^6(s`-CmT`~Au2}lhr2cS!UcmSurrT(tO|L?ynef(H}q9jf) z^j$$9vYS^wc*8RR=fEJFn>^G_%MtG833IUo$!lq_D_A?ay1AOWymoS9mv|s5bYCRJ zBa;ml9LJ6L|LB1iTqNl?951c+XZ5ABv z-mr(OglK+!fy-EXiEar1m(q#RO3=`qx1@9PKNqc#!N?Si+d>15^B%%1FPkN#?68YB z{cjw)xI53J+1*cu_{N|{saQL$dsNk;X!zS~3TL!8*n)0hlqkDs5$@pS8!Xe=m)}MG z#iED%KPF}9!d{eGQt3)XBDZLvzJ+akqbdU?uKN`U%U|MilZ=L`Ff}?q95v)D!|1SB z(yChcju;najDa;KPny}!3pXN$NUsh<)-4nyjwFqw@G-siO_PhwNq;C|T&}RJ9C()s zR*)qX>Mo+#sjZnz!frPd{!wV7Il(|@IX2@*&4Wy0{u1O=n0sQx&TEU-l8P`<1fh`I zr>7pTTt8k{NOi$iYHC~iRreFCY8J7JznE6M7 zy$c^`FuZhBFXn)W-m<}YXtLJs^7}sV$`^7n!WSdSPRiLia+U{{KQOkV@yOX21WUfp zPnkwABG`3!5xT&;`lntxHMK}`)5^W7I!$4sLRWVH$x?4()rxAaZq?Sek*k-T_`s!zmc$9f%k1zfujr)TaCw@w&ZNtL;Xgu9Gmwtvg|5U8Ga*8A@uPFlu7US*W$ zWsS4xw74iPKN?W`FxHAx>dj4g^fRR<(xNwIGzh)YCRWO5TwBG5cg@@|m0{7j?E<+u znW0{UQnCp=QYZ|~Xn&~`+gD2~yl-At!od?TaH`pBd-?FU1o?_%n8O;qE!V0JbkgPf z>{)wb8V_&NLz4o>Bro@V3x(zccsaWuSW|Djuxj-8q+DE;7Az@u`2*eYGexguiRhd8 z%36BgQYK+`@&>})*s1Bf-_{S6AeB6=4h#LcJZ&`n_8kpw#s4A8+h!Jh zXSZZ2@AB@Z6Q+bWUM1kNIHamVEiB1-c3j=4g!A;QU;F99+>`Go>Ii|5?^}nsTE%S$ z_FH%cPod1-iTu~9#t$K1zs#n8s!*p*cBB|l>XMOD>3bLOezyPKIZMjpMqFH+T2dI@ z#4Uq5=?LDU)r9`oOJkAfsZyj%TzA<|YW_YR27;HpYu_$0_m8Ru6IdEaU1YYKEdBjl z==UEy>qv<%U#^(JqHoFC@OX&!qkd(@65wdbTbWO!UvfsXza^8y=GPu4I0}f()Pb#E zCHdx-Ih~`kihfl-bs^zcOkkK36bMXQ&Y}@&&!fKQQa@sK2mf~VC{7P{GCX%L?bebM`BRT){EEs8be?W`)oW-ywRQh=rHHp>;b!2;O ze&O)6*H5~$=v~@i3uD%IpG{AccS(&NaKE0K&vNj7A8$6LP*X1bsXm}Q*ZuvaklqSs z_J}wm`ia-Cey2kI%d@Ychmxl6;r6h{YL_f^-~1M;xAmcdAvc#z=N*rQGjY^i$c0?W zfF730>095jqwI4pO-C3-sWKFHm}`tW$`<_Q9&D%R-bN>~m#8m(OzwRCJB93VO?`!S z#bI&aO&{9;jUEE^Q!PXlvPGc|!Cuf`A|n0jRG7j3amTd4(_dOnonpcp4KhEqhF_k8 zTX$#>M-Ls?fVvf|rn1*qI1RODL16VR0O6`^-@Puy$+8JuTYL?PQrn-DX!Bk27cOZxFJ+WTvZ`06J>^xo87W+|_Q=?W=fu`~ z%ZJ!stF9>iaO6dlciAngY`W#sko=?C=uo@QK1H6jB*eDDhgmqTi`L@q&r-IcrJ513dPnHkNZ(wYG9c)cppprb=b} zg)?bRj`p^#;>XU8+z~>(r?A-#C7;0knP}_{+Hlgo&lawl8v%P6>_~(9yi|LsJpZDa z!(quNd7bURD4pfiPtmo>s#%RkdAULFSG4sii$nVfO|^1EBDeUgmR8s%T>2=P=ag6Q z11>M{o2q+H8#%DG$@}!@=lq8(?&a=bFg+T4%z!Ga#=nV#VrbQHRLxxy^Idlk%7u8Q?D=Az+zzfDU)UT23^A|pbwx`M_V%^y< zbhfsgLN{SUGzO!)zp^hB;l3Qs{ZCxAoQbQ>L!1RL73>)=FGoJm#k2?)F~|f^4C>-JH4J7MGBj=#LI!cQdT_cj^-3>#FjD-;?EJ5Y!>N`;S5=Z!sF_-Dd8eMhpSWZ}(oV*UA@i#A;Tb zI6O+f&YJH3Xdo+{l9p{>eW@kR$2unwF(lYT+Wolnq^hy2cdD%P?tzNL^n1znFZpR- z8QG>uz)v9Gu{KsQoiRj{8mg1KlU}4FYFKZOto@qBVA38jSlfvK`jgoT*RGa|LAX zy=>@P_i407W*0il&YPREC!v$cknYT-qLs2=He44q#C!H~WbNHsR;@F2e&}>u4$1yB zm9R6Sp5ix}Q%TWFMt}E}Gx;T@2#+K^-Nw34 zF;2)6df8&V5Odm|N~22SDcXu{eUi$UB#U%Px2289;17LnCuclGA-M5gEJDTlQ`~Wa zgSCI3=lLgiMc1p#AD)JL`eI>IOuurO_?cRoe94DB*tod2GjGXOOxalblX*TWO%*e4 z4Y8C9J20JrHJ22=aPmM01RYW6s_G&Z@7-?YsmMq-_^Jtc27Y&zTr&Qr_ucbQB~R5- zL!S=wb@qst-VP=!nR_n{66`C>QzbUbg*U%frS+V=&5zAb=oy2?BY$m|7z-}fyFH_n z6Ir#gBGojP=Ss$}4e~6$_jY{tl+gI08VL+3s}x^NDhM|$4(u0yZm6)&-U``%%6DdK z)t&w8O&@OljOB3WQY^)ENZx#wGU{4gHoSC?^>_DppsL)Rlvs1)u5c6B76o}o$xN+I zSMIr1qaB~#h=66YeM64jc$7)pL{q76*myOt;xI}L{NAyOC-f1Ht%oa96GFQ=BAdTU zN4uwoIv+i2M=AM#7}gQ#h4d7P1zMGlQ~W-$ImqwJSr?^u#Hl43u0o+LaS6>z+qT}x zFNO3AE$~ST%eUutiXjp)~1Y*jBfR##^^G3tW{CeqiF8!yFuLtQRinr8Aye`2@Y#JC!5yU7ObQcY84I zC8IaZ5Q!^o7=wrJu*4sbYqbWy<#pQ6g$dhnN&X zekz}X?5ckoon29HF?L4haWy?1a|{36u1T*UDREo=uqK6K6>o}mHc`-v zJwLRl?*jqsai;Eyv54W$lj1l6SWx0eRMY&-OK!lPZ@Esr`u&W6zXd!QOmuC9IIzh1lN9KIagVNE6io;cmfH0OtN3w*X0p9=nd~ zin9(H(=OB102H!;^+)XfKd7V1{Lrsh%e#!N3WHR^B}FLT%c)nNjGUu-_D ze7f#2rbtuBKl^U8;QDEPd1#Lb1e=!Ys4g&}!?WDf>h>gMM{8qo`Ta)09@7Q|q@w~N zzEyDDhtuHRaEjlOHJ4^;3(^f72?P?;B|9LKbz+O|xMaM7sYZ>kZhQ)9bpzdD^bSNQ zKz7+*bCz|u5nfb4CX|V&s`p5hQ3iy~+@~x6B>cLrSFG6gGwrJrV|I^RnOJ?-{3PAp zU96i6{uGu^y20q+B;E8=2UvF?rH2l$eM2MZufh7;+Ws`Jn+dZ#F=Jgr##slqx)quU z^hR`>K-fbCVJ$PDSd>_p7aJKfm&Wcq$<^6Wgph#PxZ5e?=0b-e4x(0Se} zBwVEsWc9=}9dYn+1RoZZ_iW&-Oe)-(wBw~UNnGFR2|-gZl9iI40FT3rT=Val$y>j& zQn9dbWEO>t^2!v@gCO7#WtHyQ-!m0KSlLrjH4cL=V%zt@u5U9u0dwFELhtQ3{0k!| zI0w=5Y4~riWdFti=m_~Fh~TJu?Sv)Pb@R?F;#8j0oIIlrH1i?^(+fA)))KI z7_O0ziFO@(Z!DnY?8z19oM*N;Cyx1>Q(|f8fln~^@J-f{SAl1GKa%lke)P?YyY+4r zgcR=ZM=C)bM?QRh+v}jwATmMkK%Eq?1ryE;()YiK@`1oe()-&PWNeLlWNvoS(jJ(3$owA}uB`?-J z)f@-12x~T<%@j(X44BYHfw{i`1VRaW%<`)xj&bENL%xe@nk2)_yMoD9x8)%38AbrD z>R0k#lfm8b$ve5_w}DS?gg9o&fvJsM5rCB+Uh*e|%gwVJI?7tvvK1OX5d%$1RwlcG5Sw1U-{b?WMO=VPFGMuE)Kr)jBM6!RGV!nZCnoC7R z*~r4D<$bu?30)E}U!obTYBbEb$K?}|?Q2f6K-VSZ2PQevHLpCy+1YGF#(i_#dfeYv z(c4AskpUSo_gBekr**h~b`=KeSJbq{6y;2KVw4NozV;WG#mu-*II0LgYa_59vPk|Y z5O&+}6P7(`-8#E%a>bR90Tx(<@|iO>@2^ud?NRDL-zF`jx9j^Zy0NVW4Kb#8T`?&( zt{$LI>NiXhdr+9~(Jd~}A_I_A0H;ORe-bP^U~&U8A=ZW=lKR%PRjFX1am0DcsyOF)TK`X&9j0 z{V%^qc%h~PnY-L8d-L^}yW3-CR2ahQp8;FM?*9LC$Y$|_p{#K>^k=Hi;&)$BhR}n@ zpJPhIV_U|9pF&Mv^riaP78~9F4-USS!+)qZpA9IVXIcsN+a)iI*t*e<|MC^0O2!Xq zEOT{sjj*~7Q#4C&7cMWSXBQyR*3c2;*h^GgIh~ps1fdeXG;DdO6`iP5mK|%3RA+VF z;w3}f>=5{7l}~$W=u^J%r_F#850&tWDW>{^@v_-TNs86UJL5}mi9=}kY5_4*c? zAohKvY=iS;YP*D^5UB|gTkX*WA8Aw9+>}?D#lMeo3wkOD&F@u^NYhV*?T+#Y=G7xx z>MMLhYitbZ7V?6S7VLwho3YRLAh8Em|I*&v_>YeLa~xqhbrWrZwi*T7eMB&S0e@3z zVyt=N!5(o&yWI#un2LU@Y8VX}9JXs1 zeJUkR!e3U3F*nY-Th9AAc;6~d#8y}+F_Nby7l9LrzAuzB3^lmx$}~|?c|YA!>P0B0 z`;eMCD$T^1Y)K}4TvXKV?MYJPy!1PB!Jrv!&$QE~YSeu$YWA|$eNKTrB64~^F=6ry z3hDly6d1lVhM!~;6|b&{4;=AibCh{Id%5*Jq{P}C5W-HNF{pQUpFn-ry1j+TqRL`Z zDz!L(Q9)GN2r(7LHZ^dt_Yc z6Q)qQZz5PCOUvd%(yzp?*FRLi(rD9i|5Z{$dfeRbMA>v1CWQzDb5gVfe_-Hh#mM450DdMgA={(s#hh7MBcR;kzL zeHEwA%a{(aQ*qFia+#&;;h542M{26gI@Oz*9{0bZ>G%HSS!MlJ+dl{5wa@jfA7%5X z-Zso##QQ89dN=e(izG|jB8Ed1o44PjN`(Q3i4HL;MXGL?@7QqG1ge)0_%|W7t>0wx zC91?pN*i`RM*V>G7_*@<`myLJa_4Jk?u8CcHe9*5@cpdEMdK3TgNV?SF}H06Qfh|- zYe{U!?J}Q1&6yfF1mKBI054XOaSj1-&I3#YtNakT_5m{(2*-$iYybiLEG zBGW_VtGSONWQaouEgQ`121rD8Uv6F+zRIHP&K%*dp4OFaI=jEDT+P7unlO=}<6qOx zLJL-N()kvP(D-<{BHBOUSi7C77rB?}fCO7VqXnlW8=c~tKQrVORAZpK-=97h=3h6{ zkjt~ha0&$OQ%lqLPnss!RSsQFiyH!WjokK0F0Ha`A)H_AZw~ll`|}poTV+L*J*eLt zR2|z0-Hzlto-YG1H#q%%t;Xd*lguHI-B86Xv$}M>Ir|KbZQwlMjalm=2--xd>O!Zv z7dGk#T6m3o)Mnw1i6>_669*)P*A+TnXiYM@joWD>f~t>OqOMknp80{?nf-C6UF(a6 zLMmOFLF#0*9gEOTxGg44fqS|_QubH8n5wHyfho+G$fk^tU0{gd-#4@!M$|nIMGv?2 z`^r{NKa1ah75ME7Wa?=l2-O`zS6B664|ZmSy_-^1?uaP!P-s-IAy7)Q4!q(1xyWbm zwQqPzVvn_YRq{5u>PKI zY5`5w$bvp38rf!>9GiX_rVqhzYbi2k6nrJ_%N`R4;#by+4;oaVsRdfm-%P&Dulsij zuq68C^Pq<%#gvPf7Efy2R1Sp#(Zf}ZtZ4;_OP9T-HQcb1ytthzqr-a=-vn6Fm$vjF zYe^r+7s%ji`DV!jryW681MK0ik_QSt&xM7fBK65Mw6n%H1Y=^^lDUU`ioZTFsFg$Naq{rSFRH(0r_iHjh? z_V}(gWC(q~n^NnK(XU^4iSjx8CuX^|Ew<{C5273qc~HImNOHp>-P`~Ao9y)A-y0bY zheOU*?V>2j^E3TR#ERB(!yjo(l|IC-?3rFbb-xH!e$a1Wxo{sMRTTHw%_!LLZpPO* zy=2K#9!cehxTMv4sqglLA`gr!_gi~RtXB4`B4U-D%#RbHW1o$l7Co?~Hoy6rrEYL| z!JNEG;bvQ1OWXUkPb8SsHu(RE-2u*qZD=tS`VhY|*gMj}HmPdnk(5POlneD%cIHSQ zz@sB(VK7u;`%rq9h%^79(KcC4NO$QRU$Lb$=Kfe2^4w}dj;Ghp{Fo-^D|teVTXmH+ z3}4F`%|W5eJJ4M%BbAmp(*IAIyR7U<83l<^@)05D7PnWLc;ODDukS+;nInT&5#`iN z?*Vs={5pZuWY^)Z6c0&%?VFrG`!_NI0If(IVs?z}+O@K~X8CsxZdKd}J$MA`85n*Y zZ6VALU$Fxgd~@h=Bk+>V-K%#2-0^G#h{@at{{5@`X@RmXX@v(9Z2?h!ft3%4(8KXP ztvzpwNchi}VgKF7ybSLs0!kW8;?a<^r15(Nu5Apq3fq@xo*DnO=ASV^?0gjoe9iBa z6|%Ka|6C%%Qdi9yAHMd;l9DB59z(pcvlo{||1Z01hi7*?;>u>uzFP8(r}8y!)>?1% zA(asuIg2-^87`mEN+ORU|L$p#`Vf_TpJ?H<0=bCW_mx)|0a*Cr;WBh|25 diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/cc_hash_random_int_subscript_timing_test_insert_msvc.png b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/cc_hash_random_int_subscript_timing_test_insert_msvc.png deleted file mode 100644 index 39c96ad8daf3900880a53f2b5ec4dba63c5169da..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 6840 zcmcgwXHZjrn++%yiUcW&R(gTZJK zFc{6t6Gwn&6?vBcgB^kCYU-;369z-VU>Fz-4}(!)FoP%4-68CMc$51F33Ix~#P#_lr;V}>e0|9zK4*(NX133VH00J-s zs6jIT8lVKJ00$ThdV|)W7erN#8U{8vD0n41W^}wxPB^%!;Mn+dAKAhs6*YU>phf`it$h#>b4IFQz0L6pf3Lq7L~!_ zB+we14q!__JizI2)Zv-<|Ndf&4d4btPrBVU_JqM0SgB8%-r>i4z{%^Sdf)4wE5^&$ z(!&;}dQbPfy1lEXm#4LdgPYfRsjJt;#INCelG$M}IP%UdC4Ikl^U2d?>E};}ZX+FP zj#63zz(dn+h%WtGx(&K|N4z>?V{rG zMoG-woc?y&blQKl=*~g!IYgX2tCy&VaQGg`G{rAkT|`4nx81y6)gAHX*oEiDknP!B z#A=nT$p*7kFX5fTplCydtAg+86}Y-&pKG6eCchdxTN8|RYJDkImP>=4`Ep`*p z6M-5suAY4tlo2ICwIWcVPo{TmUN8FWlI&U`&Y$DC`;OUuKCUjdPY5hC|e1e?6f?4aA{N!YRuprIQQ)|JB29L z_TJ8;>S%2i4zKXu@=`H8P^?#{HlS6^yqo+d=Hr1;wcoIX*uF)-<1nFHKr=1r#Ym>{ z{YPSXNsQ7_*IV$`uY{SUWlFZlauKVrFyhrsu`%33lt!{($h3MMyFq2Ni7}KZbwX5Y zc3cjZe)Hv?IqI+H)5?{n_{Y~Ji@siSDW|(F{CKZxWT!`RnTPS!3&&G4&Jb@0o&AgZ%)eaq#dP}%EzU!UevZjubD)R|W7#{)<0VT;j)j`YL90yGgqjxVY;t zE7(1f?sJ9TE|=0c=WhQ(jE7Zl$1Cc2MUY1ZMcr?5UYnDn|f;tA>Ouww$lfgYU$U^$w9e5&bV zf`?qk18OnX^dCe5!xn13rrTWj6T_fM&XLGskvHEx`&w|9l31q3FDq0x)6w5)_6m3r ze&+SU)?Y!jXs?q28i;e;=2m}?4$sBE^ZA^K`mKU(o7rMLBQRx+ZCiw_NOn%ro&CtZ zVVv!Qzou~gr-*O#JH)f@0hWy?+y88RbCQl(Q2ut`%>p(M(ikq zfOhvbzbRjYTxdRL6t!Z}{HTkO-G$D$lvyg62pLm5UHg*JO)S2Q{q)8RzG|8V{kSUxDE2UxkQu z5ZwVH6N>PEgRT4xt(-5wAvjZygrYw>5CgvZ;nBaL_}5$qhy*Yf+=Y2Wr|G;Dovqmu z=>0hVrKa2 zCl7Ip!u@qhLWj45ZIG@s^FsAV3HE+WEjxPA=W>JJYJ&Tb3mdQN7!na6td%Vdt@q6Pa+Pb%OFE;F zEUUxo)4j-z7hJYrWV6$s@^!fU1%aXo|Lpl^Z-wOxlEdc=vfqgoUtEuMGt zZ64BC#NI0HL;{)Tr}bv7ptScQxyGiL{-Kc|_&e}9G15SL_eScc& zjC^3L*|e&Oe^sxB#d}!LWrj5mGNsSkkk;4ND)am9hn0-wzEt$D+v&$PYQM^w7{IU& z!S^fetp`*-2BZJ^?NdDnXIfj4$`M5yAiK$ZHV(6n+`u7z?!oryj<5xtpy<8idfq+r zU#J%sj$-{qRmb!;)b4~~+YC5kiq71u(tY%*d5yL2IezGS6=~A3HsmeV#|#p~2IeE^ z&Q3f^WEdaUvMf#2lH`>mM<*L85xsKQiS3t*YvCUI;_NT!6Ph4*-uHdDijU3PDkKMd zB}%sr!=xV-Cyuxmr!cW|H+-woL_1{B9o}nWN=ZwaHWurYypoZ6u`93Xh6Q2aLPxCYh{9gn=*#RDlh_`n z?PXuSqO3HH^fO-r{3jX9`A0{Jm`P*V7qxfN{#iZ1u3Iv3*tB#qHjPBpr1)%0&pL2T z{;{2vW=&7&DzC!V@i@*4rD~3+8W7N`KXAP_1G8fYJ?3bh6i)LSajyIhVsWd1;u}zT1E^|_CE8nK^_vl#r;8q zn8nCw>G#v}k&4Qslr+1!tD80L8%p)dp_uY0)hu+W1G%Qlk|%;Rn~fNSmp`fRXpnm! z6*n*voByi|XWS@X^zr~9Mx486SP*nqNUhj)$Y1cFa9Co}7x(tQicb5gWhukb&*i_T zLW}pg$$~{kcX0EB9!-H7KBD-qU6x`qaUDXa`rpO3Wwj$lgvT{KOOJ*HwB2bv*LKzR z^|@jQIeDvwd_>X8PPIR&cF(f(Zj<4^2rM1?;<6 zlUU!uvy?o+>w`*N*GtLi^31o6pCZalb;XKiz1%d8Jk5FF{nx}QXH#x&v3HAmAEgyA zBr#|zk~41pb-n7nVWt(rJ1_%H*x0tSxSZQJGH-0u9}z?>R79)hAi4a1wDfir$t8w+ z;B2~JT@An5bG^{H!5`mSf4nHH8!ud=iy+O&HivthThf%381Fu1KI)zE+45%u8fVLE zT7;U_=$g4XH+B=xZE|PvU{g8QUw2Qz;rp);v<`EgO{QMRi*7PeyY+SG_Q4a)D)*$; z>m+?2N?T0IBvxPNjxFNJvMpD86sJ43GWXPe03mndy?dda^~rrwiLMWtG2&RTf2_Od z=4$Jc9Naoa@d);$MV9+Fmcj+qOu4y6=?~Rib{$;BqeA+HsKmFk1HV|`G4{=5T8!Km zi^IvPdX2aj9mRS!+xNM1&%MgNnHS_f&*h0X*f5bk7Qb5~b2+lBV6e$736pcJSEp&5 zE$_7(TEVv2K{#fC^^?}FsfEUvcgyWUPtCkXdGq?{q43w&Tq_<jf%FqinxjRx^e{d&X?HVQlxB@uaeMyW4Xdjt4Y6VV*NTB}!{m9s?^(!w z9`Fmme&@n^&n=${W7*6Kj)DKWNlO=uh8>@xb9?gdZ)r^AVa89ZwA{)+me{%)LPBCC zy>2o)(P^7;^O!E{-H8926EbjhKjYbY&CtNe)IYr+^LqVqL>!j&m1d>ZtV;95d#8I0 zT#U|%q~szH-TeKe&ULvt=k&ghc?)+#>X-FH)i!#c4#i5YDKN{v-#lM7mHX&u&d{>{ zmsj1?NxMl)!a*GJRWrZxAXAh2Fvtr@Qw zy77c((a$JNBBK4LFU@(i=gy(MR$douS3jyF?$&^+=_CLR>gMn7(_F!Z!g>di5D zlL$D}o6ctFqCcP_ch%QdXw8%deaVFl%7}eW`4Q3A@F`Y``Jpl&R^b$1C5|DIMJ+@9 z?`>Ee4VH!re1rc}BXCJPhz9o|h=$8_7BOZ1B&LLEyo2xV935>p3bF`GF zf8%<#s)uga?eZNgvzg`Eo8EEZ~;b5tEB0-Ef<=6jew>X>ZuqI)5-{ zn=Ji0wgq+hflxSUm;dLi_ggiL4EuDC-*`UzvM=drHPiJM_E$;edG;=J_umPf4%+0a z7&_f`gO;~YvT@(x_tQ?_!Hi)Va7x0fYGn&X1h%Ycc_*;LSntSfh9%1xTeF+N=qJoF zJW*r`j?HL|ak{E!rGKirF~e7csf)_Rz4Q+jQwk8O`{Eu{r40n5Oy0=_S&h@A2Yi5a zI7BOT{(#~4lPv_0odi4eUmPsU=Jexq*rT)FPmT~%n)lUCH`fH|JBwcf>r?*W#uF+y z*rtfsw=VnR+Rgx({cac_p9nhkyNM^pO`d7*&8pcXQSHy3q|`m?f>HfLNOc7*lV=nt@2Jn& zemnQet)cP`kpOn!5MA3Q3*+sH&d5a3S|oMRyF0DL_5!9*j$$>4Uznr2A$OB$Pin}m zdDXG*_?|D#f4UU>#|y*%!K$!VSznXeR}1o4w9E=d?+E;SE+Lb_dK?eR zz^}J)A|a3RY4shtb1Hi+Y41ae9$Sh;kN>zZa?a+nX9K|`ooy^hBr#WfL$JJ-LDqY& zpI|18_?BaxMVQy~|Dw$;TjqjmXYiT%mgB-%!+acT%1xaYocZCrey zb5BJql>bg3}?*hs)e=%@TMKF?CoTk zqGQf!sJKi@al$LOXtwk>jHYmnt zS%qFpbj}r`=P??7+y2$TPI!|cn zzJ&}s&2P>7s5&wDxRzOSb~+aPQy}^cq`FAum0=|+EjE>9d8+sSmG}nZ$$7Ns81=%8 z3n(S@8d^1-!nUb8iMZGr&V9g{Qe7CjW7xJ^z!ge$X;NMG{~^m6xQ+!KTax;pej)z% zu}fE(lo=-(sz$ohPnDeR6E8ww%;{F+UhcJ8vRf4qw^b6hQdLCj?mlWL$;dvr7GHlp zb9+m0;4#MfSJw5>G=32};LAKMGs68m&;-d`H0S*RCoxebVqASzTB1PM*zU_s(T-GZ zSvu?;JDz9xt?p-D=pN~teS+4DRf+B=mpY9#CG7lF$*XhIbPOY2+)Ut*<{^62GZ53o zU5u3aWJZSzW7M{h6V-K1HJv`?3%BxL;iBBx7z?v#z|H?(=P)b`68dEoVPz@dLjBMG Nj;i*pLS>7Pe*?z$bt(V= diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/cc_hash_table.html b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/cc_hash_table.html deleted file mode 100644 index 0557732a5..000000000 --- a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/cc_hash_table.html +++ /dev/null @@ -1,724 +0,0 @@ - - - - - - - cc_hash_table Interface - - - - -
    -

    cc_hash_table Interface

    - -

    A concrete collision-chaining hash-based associative - container.

    - -

    Defined in: assoc_container.hpp

    - -

    Template Parameters

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    ParameterDescriptionDefault Value
    - 
    -typename Key
-
    -     		-

    Key type.

    -     		-
    - 
    -typename Mapped
-
    -     		-

    Mapped type.

    -     		-
    - 
    -class Hash_Fn 
-
    -     		-

    Hash functor.

    -     		- 
    -__gnu_cxx::hash<Key>
-
    if using gcc; - 
    -stdext::hash_value<Key>
-
    if using Visual C++ .net -
    - 
    -class Eq_Fn 
-
    -     		-

    Equivalence functor.

    -     		- 
    -std::equal_to<Key>
-
    -
    - 
    -class Comb_Hash_Fn 
-
    -     		-

    Combining hash functor.

    - -

    If Hash_Fn is - not null_hash_fn, then this is the - ranged-hash functor; otherwise, this is the range-hashing - functor.

    - -

    (See Design::Hash-Based - Containers::Hash Policies.)

    -     		- 
    -direct_mask_range_hashing
-
    -
    - 
    -class Resize_Policy 
-
    -     		-

    Resize policy.

    -     		- If Comb_Hash_Fn - is direct_mask_range_hashing, - then - 
    -hash_standard_resize_policy<
-  hash_exponential_size_policy<
-    typename Comb_Hash_Fn::size_type>,
-  hash_load_check_resize_trigger<
-    typename Comb_Hash_Fn::size_type>,
-  false,
-  typename Comb_Hash_Fn::size_type>
-
    otherwise, - 
    -hash_standard_resize_policy<
-  hash_exponential_size_policy<
-    typename Comb_Hash_Fn::size_type>,
-  hash_load_check_resize_trigger<
-    typename Comb_Hash_Fn::size_type>,
-  false,
-  typename Comb_Hash_Fn::size_type>
-
    -
    - 
    -bool Store_Hash 
-
    -     		-

    Indicates whether the hash value will be stored along - with each key.

    - -

    If hash_fn is null_hash_fn, then the container - will not compile if this value is - true

    -     		- 
    -false
-
    -
    - 
    -class Allocator 
-
    -     		-

    Allocator type.

    -     		- 
    -std::allocator<char>
-
    -
    - -

    Base Classes

    - - - - - - - - - - - - - -
    ClassDerivation Type
    - 
    -basic_hash_table
-
    -     		-

    public

    -
    - -

    Public Types and - Constants

    - -

    Policy Definitions

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    TypeDefinitionDescription
    - 
    -hash_fn
-
    -     		- 
    -Hash_Fn
-
    -     		-

    Hash functor type.

    -
    - 
    -eq_fn
-
    -     		- 
    -Eq_Fn
-
    -     		-

    Equivalence functor type.

    -
    - 
    -resize_policy
-
    -     		- 
    -Resize_Policy
-
    -     		-

    Resize policy type.

    -
    - 
    -comb_hash_fn
-
    -     		- 
    -Comb_Hash_Fn
-
    -     		-

    Combining hash functor type.

    -
    - -

    Public Methods

    - -

    Constructors, Destructor, and - Related

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    MethodDescription
    - 
    -  cc_hash_table
-  ()
-
    -     		-

    Default constructor.

    -
    - 
    -  cc_hash_table
-  (const hash_fn &r_hash_fn)
-
    -     		-

    Constructor taking some policy objects. r_hash_fn will be copied by the - Hash_Fn object of - the container object.

    -
    - 
    -  cc_hash_table
-  (const hash_fn &r_hash_fn, 
-    const eq_fn &r_eq_fn)
-
    -     		-

    Constructor taking some policy objects. r_hash_fn will be copied by the - hash_fn object of - the container object, and r_eq_fn will be copied by the - eq_fn object of the - container object.

    -
    - 
    -  cc_hash_table
-  (const hash_fn &r_hash_fn, 
-    const eq_fn &r_eq_fn, 
-    const comb_hash_fn &r_comb_hash_fn)
-
    -     		-

    Constructor taking some policy objects. r_hash_fn will be copied by the - hash_fn object of - the container object, r_eq_fn will be copied by the - eq_fn object of the - container object, and r_comb_hash_fn will be copied by the - comb_hash_fn - object of the container object.

    -
    - 
    -  cc_hash_table
-  (const hash_fn &r_hash_fn, 
-    const eq_fn &r_eq_fn, 
-    const comb_hash_fn &r_comb_hash_fn, 
-    const resize_policy &r_resize_policy)
-
    -     		-

    Constructor taking some policy objects. r_hash_fn will be copied by the - hash_fn object of - the container object, r_eq_fn will be copied by the - eq_fn object of the - container object, r_comb_hash_fn will be copied by the - comb_hash_fn - object of the container object, and r_resize_policy will be copied by - the resize_policy - object of the container object.

    -
    - 
    -template<
-    class It>
-  cc_hash_table
-  (It first_it, 
-    It last_it)
-
    -     		-

    Constructor taking iterators to a range of - value_types. The value_types between first_it and last_it will be inserted into the - container object.

    -
    - 
    -template<
-    class It>
-  cc_hash_table
-  (It first_it, 
-    It last_it,
-    const hash_fn &r_hash_fn)
-
    -     		-

    Constructor taking iterators to a range of value_types - and some policy objects. The value_types between - first_it and - last_it will be inserted - into the container object.

    -
    - 
    -template<
-    class It>
-  cc_hash_table
-  (It first_it, 
-    It last_it,
-    const hash_fn &r_hash_fn, 
-    const eq_fn &r_eq_fn)
-
    -     		-

    Constructor taking iterators to a range of value_types - and some policy objects The value_types between - first_it and - last_it will be inserted - into the container object. r_hash_fn will be copied by the - hash_fn object of - the container object, and r_eq_fn will be copied by the - eq_fn object of the - container object.

    -
    - 
    -template<
-    class It>
-  cc_hash_table
-  (It first_it, 
-    It last_it,
-    const hash_fn &r_hash_fn, 
-    const eq_fn &r_eq_fn, 
-    const comb_hash_fn &r_comb_hash_fn)
-
    -     		-

    Constructor taking iterators to a range of value_types - and some policy objects The value_types between - first_it and - last_it will be inserted - into the container object. r_hash_fn will be copied by the - hash_fn object of - the container object, r_eq_fn will be copied by the - eq_fn object of the - container object, and r_comb_hash_fn will be copied by the - comb_hash_fn - object of the container object.

    -
    - 
    -template<
-    class It>
-  cc_hash_table
-  (It first_it, 
-    It last_it,
-    const hash_fn &r_hash_fn, 
-    const eq_fn &r_eq_fn, 
-    const comb_hash_fn &r_comb_hash_fn, 
-    const resize_policy &r_resize_policy)
-
    -     		-

    Constructor taking iterators to a range of value_types - and some policy objects The value_types between - first_it and - last_it will be inserted - into the container object. r_hash_fn will be copied by the - hash_fn object of - the container object, r_eq_fn will be copied by the - eq_fn object of the - container object, r_comb_hash_fn will be copied by the - comb_hash_fn - object of the container object, and r_resize_policy will be copied by - the resize_policy - object of the container object.

    -
    - 
    -  cc_hash_table
-  (const cc_hash_table &other)
-
    -     		-

    Copy constructor.

    -
    - 
    -virtual 
-  ~cc_hash_table
-  ()
-
    -     		-

    Destructor.

    -
    - 
    -cc_hash_table &
-  operator=
-  (const cc_hash_table &other)
-
    -     		-

    Assignment operator.

    -
    - 
    -void
-  swap
-  (cc_hash_table &other)
-
    -     		-

    Swaps content.

    -
    - -

    Policy Access Methods

    - - - - - - - - - - - - - - - - - - - -
    MethodDescription
    - 
    -comb_hash_fn &
-  get_comb_hash_fn
-  ()
-
    -     		-

    Access to the comb_hash_fn - object.

    -
    - 
    -const comb_hash_fn &
-  get_comb_hash_fn
-  () const
-
    -     		-

    Const access to the comb_hash_fn - object.

    -
    -
    - - diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/cc_hash_tag.html b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/cc_hash_tag.html deleted file mode 100644 index 1923e20fb..000000000 --- a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/cc_hash_tag.html +++ /dev/null @@ -1,47 +0,0 @@ - - - - - - - cc_hash_tag Interface - - - - -
    -

    cc_hash_tag Interface

    - -

    Collision-chaining hash data structure tag.

    - -

    Defined in: tag_and_trait.hpp

    - -

    Base Classes

    - - - - - - - - - - - - - -
    ClassDerivation Type
    - 
    -basic_hash_tag
-
    -     		-

    public

    -
    -
    - - diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/ccgp_hash_random_int_subscript_timing_test_insert_gcc.png b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/ccgp_hash_random_int_subscript_timing_test_insert_gcc.png deleted file mode 100644 index fde6b41bf94f13ea35145fb7a5fba18fabca9dee..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 7355 zcmch6c{G&&+y6+DEnCgl$`XATgcu4j8d*~zX6%$@?Ag~CHTqb_z8k{W*CBfdpAuPy z>_VatBD-Xr=bpab=l7i7Iln)C&-2G~pTm8w>wR6X>-BnFH|IVxk$Mj_nHhN)K_C#b zwwBsM5a52M1_QznKo~LzL!s6Z;2;79L?D0&WDtQuZ6(7&WDJN*0FlWcG6g^aQQ#m7 z21Fr%C}a=?2movV8o&aYfockM4)wyo;RHCG42M&wV}S^Rfnx}83>l80P+0(n1Pq)& zfD_1Y0)!N4g5IE4(S08;_h02n|TUM;-l7nwkyP>lri0b_xP zOeT;ifUkgDfCX?!ppXd^z(>GozyN?3P!1Rks0FM9`~YYI-GChcCqOWu5MT{}0i=OW zfEK_57z|(o&=l&5sMWwR5Cazl*cf0Wpbr=eL}Utuy1+l{r?U97QR+VbEQw0$kMGp= z{;`tE@sB&yZT}HWrTj+&b@_j2Q5F1|1V96i1F$8)JV4W*QGcGq|Mg#XfkC{$PzHA` z6E6^m=>qkKW_SjB3?%uz)s4Lk+%VpLk3H=`>IQlOnhtJW-d;AIj_%$9^3rmW*JaXt zvp7H??i<=_NJIaZKeMKvhYGN%A57jDes=OH?&Op1)MNxs34Gb|n==1ogaO zEe|gh=4Y`%l3%`lg-buR(78bouJj5DH1bShVC;2n{qk(JS{5FX5x~K(zar9bia2wj zdBW9^`!@2$8wPm^()3vMP3GDgmPPha6S2PCwa~ibvPV+`)~g1=IGb%~WQsjJvATewIzjI3;!?8 z2KrrH_8K-Z^Ticw3L_7u!&W{u+c&#tx)Q_~jJ}+^hl(d#2>WvW?e=w#d@r=6wFl+f zq?0iuW=CiX6Vrtq!HO~{<7o#6tngpTygEGYWyTq*=rzz^1d$n72 zzQMLSE{3ZZbbZ9yRerX?=Vi)=bYN!P`2_qJ;HErAGw>5Hm96}VxxhNp!Fy7PJ5kkR z1hnDe7()&}8oCmI-Uy9t5$(-h#bg%Sovh!d+)5%85L;E##r<$NC6S7CMP1eV7fXpb ze5p|!b;JBUM$W^YMapF|cagr-cBA;-vB4{dgEZH7Y)`v}@;{X=@ZH2ST+Dde>Z~X7 zzUGBznrwdI*A|ghgU1@3n-mOIe_%X+@cFJ_(~w!#Vj_wgl~c3E8*R;D1b5u(`2h00 z7ixFQ@?|w530>96(N$b&Rutr0vVawC%g|;5U{AD)4;LjJHFRpT`oHC9_eFKt@yB4W z)?H`fgif-9?7E`0_2Wx=<-w6P`|u?69Oswga5oFpsE<}m_jbmA9pm;cA#6^ZES(!q z-X%L)#eS~B3pTul+FB*$`~_)w0C?7ytR!WU5j>Bb>&&Q2%@(mrSF{@J`>QO`uP^s7 z*{;#~`?Mv}I^^$%4!;tAp(V^e$gk#-aOmJLeJ0p4AFtT*%_ya!Ynq9uz%~<`*XrJ; z;*XPY$@$;PU`0v;vZ5lvLcuQE?#+DAx|p?N89{F*1@VclwN@0yI0x z#7!&FSV~R&o#ff}YYU>jv#5%QV&jZ*E++K7e+e)hd{`Uj-$yusdV(F)Lu_iCj`ksvZ?Z56yO<514yjA>sY&sObs#71_#`&bb7xc#!*T%{KJtRZ1EI7 zQ@9sg-O<_WSwHOja8HT}WjG2eTKr4pNedpj4bky{M(M?0JDk^)27k4-YckDZlsV~B zg;LoD;Ai}x;tQgw-^4ibi8{K~Ep?Wxreq!WpKRYZrI^tFB{;s=7+20U38*DO4O1+8 zhcYVmK;YJR4`}j&qECm1Sj}ZWi%!O;_|BsC6;a=`N{AtkKmMmJDcln3?V;uLr0~IY zVXIUJgj{ftHl7AN)0I}`Azkp-s`Lv8J8bzzb`U?ODxMzVeaXI!_52m}f_mKc5#1zB zdE1Ao1KH-I!%e$MSN2crUO&{Y6huTX@!Qf>94=PO&?dGa;ARJ|&!aYtr09XZO5CaZ zw8F;hDdTTC6S`NOui*iQhxc4OXB~qK=tTu%jziO{KZw0ou+iFMt)WG)R90GzF-M5j zyL{CAw9ov1uuYlwBX$N;wB6KmaPLz+?r5=de^lvKd`2)x8DVzFu>S}XMp&__;=BD% zkps_AQ?dq!hvX0E4+M|Lm{hgcSH3zSszTy#JxclIg^+w3=bXJL_OBC15>axwHE0s% zk*7DNO=Z=02B-MnvG{annX9v)F{Z=q z96~KYcAr&jGpzYlc)VV`>|>K~R{d)d$Dud!%R=tV+9c{gNg>mGwO36Q$e!SyTO~tJdWT^;%E&G2mzWlaU{T<=3*m1@S zN8-ufnnB!&(a0Z>ZQIN~9D0L2wGhK4W}mOS?Bf?1e@pV`jprLD0YnSC6K&5w)UB(> z{WDUUFL3?(vH*x3MnCur2V(wz-D2p$D}3S~LcZ~3`S34pN^Pyvg|egB_P3KQy$(a7 zeB%5!-3QQ-NE!DD*3&g|^8b<29Qfi1*rf zyeDb?TK;22=Ve*Hu{YZ0xf1~%$Biv1efBp}j?-&Ydd78;IsCb@v^A8j%8ze!tW9mk z`I-=v>8E@X@XULYIo3MIEGnF~272~)KX+a{JlNH=m2ir~@Kbm#$kM7L@%HV95L;j5 zV>5jli-s?4QsAt20qJ4%J4Bm>VK2SxsVwr+cuk%0TC~_peXAW7)Qz}dy;m1FeaweX zZ%Nh-EZw@9>@2;idd)0!v1HEWE;-cWF6*$~`_F1-G>R0nf|60fZdw&xaCHhe+)Vk(z!O-8i(qc&mB1i*WiLuS_d<^&zn<|fBEIl(zB`6(o2oZnMNj>FI?%e$ zpdZ4hIL<6J;==Z0&nsC&lIG@qun`qIapfGdJ&v+-M3ePe$L+x9XuBO)!)>q1T6h z|6MXE@8$kk__jRwCmYWUBtFsXBC|z>%aj-nSF_dBQn1FRH~pmBM8K}GEHAjhqV1lj z5(??JargJs>W)6e@Tve&xj#40<}7QV9%`|Pu~{THZl5jp%H4$FNcO?(_&$wT>ywh@ zw~Wm~SK6PodD>P?$)tg6E;{cJ5r(_A;6fePsAZ$Qk)QU3cyk}a7bBMHacI3`E`db4 z@=TGE30RISO;5^s*RO3Pd^U+F%g`w|A)=oO89r;vk98`}!t+%MeEE`q;+!#8`pEM$ zK|U-%CP7j06m1C)Y{p&4xPpW*G#A`n!_`%=@QztEV%u=me94k(KF+oTZB-0E$6YHoiE8j_JLQ-CYxNATS%R)lf4yn(SibnD9(mflFyM0 zCteBN(9Sfo(fqc4Ni=eNUvT@18R}`{(!&CNF(vE6sjHec;2BENPG6dl%{c;{M^G#_ zK!$SG-i(0|1CL-XB#KW|UvApCY2mf&K+E884XnT;>}=!Mm_t7qeO17|Jk@E1(WyS$ zt^2caFKP2A;Jo*hUolRodFExo^`fQD1weVzt@U#B z5oxt3>gQjxvF<}gKv8sh1_pngv+RlY?BeT=_B-MZs|IAIfQFKl@AvPTIS5q7Oq$Bq zeA6ygr!C4aDH;vBv-)H+GH&R zg+-bSk(ZFy+>}eo*WSk6-2WYOh~9E8IH{c^`!cEauoMpna9W`=wCg;QU0%85w(Nl|u6O-NJZM z;wV~g@Ixwx56O8K+PQKQL^3G#%V&{ieK-+Xd4X3%h4`$ZJixaSmR2vvhh^7xn=D%_ zeQ^h=`)l3d-f}{M>0(Lbcv(A>*Dg{`l?mVRxB_-MS_^rK+!2R(53#r2Mh-wbA2w)o z@usz56`Zc8=6GvT?U5}#S(PJahfN6L_#Y(;(&b)H|+atP^Smwu0B))YyIr#*sJ0U&R z{ZwXGbrYwnoK~B{KZM^#7;d3YB2leNd;9wciJ0xt+V;s_xn)#aSn4^x6~XMl?BE1w zy7SLwr0g7hBt%c&CCu8e-=*!+J6+|~p=Wk=Rzg~v6Q4hd@-fR7hW3=^y{}j>7fm~f zrB~T=QKRKxFWT+DAkOpZBS+RPiNs=VgIf8eyR;7y|FeD8YsW`+?s%&p-Q&Q%1hXL@PS zq9@QndzsGYK%4%O_uj`_ig?HK59oZr>fe%k66e)x`2;v;3yyY>+F%02Xx4c&aRTq#6OQlJo8rc zxtBBwH&;sE{=$}3J(nyYK5XDa+WQGz_VdV04Y&EsS#H0|pfqPP@=I}eqM)xW>eWVr zzl?+r=%mD$S=iJpcZfqx4Fwcp6(&&;g0cl;q^G=zu!XQ zNzMJ(>#S#bh^%L1%~z4jp|_Rn%ki1k6`!Kyh(z|c8M4IODs7`W@HrZ|<84~TGqOa1 z|GafLjM;0xrDeXJZGv@yC=D{sJMtSr-pDlkBarSqOvc|vb#ri?4ad3LL$4BN$K2K5 zirX@s$MKzXUII(COI)W9EDy|^D~(j+TIpou47Sx*$@aEU45?|8mA0?y^7uM&I6aoJ zl-KU5|?mayx6C8t&hN>&DX3Ru#41KuV@p)8J zY2}ggqFeuK*l#Jlgs18W0aAJC#;j9q73LoO^V*tiBLem|UG@#-4s&us`vlT}+H?-8 z(zH*?bzWNpCX^ZW5I!XoX)p8TQYAWg0A60otCJlIQ)We2xbVMjq_0G~`nw@Y8{5Y& zFKE2+c+)IMd1F*{cF=x!+H-ew^UHBt>Sa{x3$#GJRZ#=KrsiSBZp}%1-HxX+2i@n5 z`h>{k^8QBqM#3eFTdm;(4gEg+ZJ*6MQsK`xPRomml;lqK)3S9-ALMIa-7-&SoErB! z%+_9N-pI!8*RK)1qUYi+P4DWvoJuBn=vE|?rU?t%7bjD=X087=Ln}z_&&`ONnr${d zgQI_xc2ovB)^?uh$&@XYC}h!8v_L{#_qyuwJbrY9rDrBhZ|JOs(Q&^O^PhAj@h#nr zeY)f0;uAG?`$RU)rgHSPn$?kGj#I;-hU^3T4U>8ga&u;z)p_OJe3(sXfr1pnD#ca@(89UNS=6|gfrhhs|X6*xokk#%R-^%3B~ZbeNHsy%tx zA+mz#@>AgvizDsOfmcx3juzUhkK(LfXV8hJ!yP9qP=5^>t ztY-Fsu+KZ8g{x3= zbEZrtJNY!HZ8G?U(7y`G=mc*Go%HtKy*k&E754nOmQj4F#;HhqNy0ON$o&eEf4pv1 zkf$+|s8-C`^Wd0NT^8pnVBX+M5LsJjvoy(ZF>x9L$<}ql07?lR7i_7(Q9Lp#^E+^AVoT!`;OX z5GN+9q_FspBNcn-JKal;zZiiPTe-{i+?39&@AwhTn;g7_#ETVWa7712WrM*FGEBX z%^qI9kpt0*%WM3rQ-3E?8YNFr-EAn4cS1-PF)mr*CDR~uWRa=ion;qok557G!g@17 zcW8lEC_Ozypczv|Z4o_qF|V=yA5&+%o}MH%RWEoJY)4HwQB%UyRKx#ObpuGf@T2oT z`|r20|K=^hSh%am?&#MPKImtp{bR!TEZy|g-G4__t$SlBzkei&c#VD;ZGgBw$HDHo zn8a1NtVYSNB9t>SQ!DuN*ua(C!NSV-k9HlhEQjGpr0h7UWwM!9n&{d*`F%pghh#*@ zLJLu|&q^=pCiI2%d|dU^`TAQfH{8d`?+9Np@26#>`>!uMj%lj{mGZ$nvUjLo`)I2_ KP^(mZg!>OyWTVjl diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/ccgp_hash_random_int_subscript_timing_test_insert_local.png b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/ccgp_hash_random_int_subscript_timing_test_insert_local.png deleted file mode 100644 index 2449e1de324c4d44bbc4f2d10433d3ab840c69a9..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 9557 zcmch7XH-)`*KQIBRk{?ZQUs)HqzR!&mo9=JT_6;t_Z|>XqzedRwdV?e2m--CAOr{mw4p&D?2QD2fnW#_3 z3a~{ZU}zK!jfSDI07jrI42ytaQ7|kTh6SPmr~zjHXaFSu3(x_90pEaYz!%UNdy~+O z3|uG#0*ydmZ}J1e0ul;^K%o&R>`l4=3P6cQA<$?98Vh6(fC6k0SQG+_Mqq*T06qYi zKyQE!Ab$V^kRgB?a0Y+|Py(g^4j?e#8*mNy!rm}`ejxmH!6Czlz?}^Iwr}K>g$Wro8{C zyutX7ottX^OZW!zzZ`Cg{}0wp2LB=fu7TkIR0$vt$mw6Gecge%V)26)pMdo5IoTYcUW>Ew#_XUFS_9NG8gj{=7VGAgfMM|OYxj(%ko9a&m% z3Z#1sh~r_cVq!4ea5#-tqqCmT+mXNmGW&_AxO6o#L?5fGhq|RLssgGBW zrYiI!A6QWTG=Ch~5Lw4*u)+hjTX4{0W~MMR19=kcSDwT7)*Yur5*Ae6GfY@lKf*pP ze}GL*^*8Mv_>NomQm3AyHNHUqyJD}+#otQ?PX^XFfn>jmXnS@kQ?}3FLcM;{^d_q? z2VIMTZ{g4``%fa)s4D-C^^_y#5eOY0bt@NKJu zh+bMyyY`u*7UBLg6Z7d)tNhpaxiF`Vqe|_c0W!6<(;+CfET?))g(Y|T9WrVtX^CpG z_-|`xRC{3bm1+{s4kh^|!WUl+PlC6tIc;*1W_v(+muG%5M_t^ozQq5KIQT(Ns`uNrD z`<7me63L~*NiT*!3mMisEVu1Zez^)&uRO;QrCKD_bjlc3zL*_a-*qoa8pov9*tEY74V2BZ1~6lRr^ z_XbUqqxZ&kA`I4ApD6N3GP|{QN#yyj?WH*e~^Rc`ui4SX#Yn@6-46b%p)lL-~I>&tr)gJW=PGXADB)>m`ZN&#O=fxdwN+ z(7zAtm71iT3Cj4UGtZD`W7(6ovwCsmKa8&V@<+ogaLbpsQ<6MNws=IEKPPHH^-tjZ z-0Bw03H39FQ|tP6oNq_v16Vvs&bf$}T#Fasxyvw)#v|W`6@1iW#m|#Z!P66GmT#Zu zY1S-sgy>bF3mW_(z!1%a%=P6^RecUa8&Pt7$YM_0Bi|KKGH>WQ8@V4)lGEl3+)g`z z#l^56RiW;NgBFmj@JwCn#3{EwI_B- zN)&f8=B?jHAV^NSjdAPjaa_}|7w5zShnW&%sutn;m^6={9_&}Krv zYZB`On}y-xJny+_Hj}}8nw9vw>}^qw{v|pO9Bc!&rX!-4v)}fNotsByo&QyX0m`vLYFl6#F$s%^DiQh`6ni z`Lf&ZiU~H9PcI1KT@BgJW-_XLk2TY`#l`Lki^pvAhBe^F7b}k)Q25}N!fB_;P7Ntc zkM_tJM1DD3Z+9u^Y>^x(uga#hcs~gF74XFVW3lStMN9A9udVhBork@ z*2k=V4Z~M@cJZJ@@h2YJw5$#DEKgY+C~<+R1$!Q!vo7eZ7<|pdl1`pgXZXmW` z@~plT6>VOyC>)NWXC*G*JKu6Vt6kr_m~H*i*1}X9R7#Q&ADNUrv*IaVv`1q0(T zr#;K4K@JoSE;2ap3M&bsmOlsZJcau)bQ({&9yPZMaK5^qDQ=t5>~X(NM5|D9TDn+9 z>20XqFC=Ysw#D&U?rRJ6D2mCG8Nb5WD2OAMjD^G;mtf%&r6573svpBMwm7DR*M3ku zo<}_dUeK}34ZEwMT_~Nn`D@z%!=Y;W^unGr+lL>g`taK0 z!tmIbqmx;>uov%|;!1q%sf|{iAWvH3Ox42B_Vx((bz1D3-l+XGEzRANk=JeRuU#%= zS1Oktey^21S&4X|=TF46L~Wbl@a1BBjMZqCW>8vpLDl!eQp|0Y@$!hdA7A2G>**3q zmNYQSw<*NwDbj3Mx3AF5LKvH z-FfBiLa^H@eJXX5gTk0rcA(YOqcw%T;epN9PYYOfkZ|3pa2rQ;7@3f$@VZ+bNSEX> z{+*OL!iPhI&RbR;^ZLz|OH$zhRU;9e$GL(-$ujU3RSTD0u0Dwx)~Nu)&AIIJl2Ff8 zTq2V>d>7SC8T9>;2*ay@RH~&^x#fZk>QfbXQZj^HGjJU5vB{^XeDu!cV8PNXa&v$29-q$>6rro+^)uF8_UFi!Yf9LTj)>43tH(sQM-2?i zi-D<0&gqv?(5FnZA?z%>nlX@ToJY)PRQ#Uth*9xf}_Z&&$xwS1g~3kD>pM# zdHRV)sFmUG&Ykp@SG^ki1OA*!-q5snRwa+gt%VAOP zLO(mhm9Ou(@&m>r4y~tMR*5#1MdR?`iB`-pDhCzqD96y-sN#TK#%5=E@7 zV<+JY*Ai#89C=6cIXr~iHw*$VI6&rC>$KE#81A)6_w_~wYHdx@*0JQkv59IcmMQBv z3;KxY5?<*}p!h_-h`qtSg5+SwxcfS8AtTC!;um_awC<3PLMeY%&#XO4BM@yXY(w1? znP1P|u*NYA4uwRs%sC( z?d2(y%Ic8ySn3#Lm*P;(QgHEfDoXK*jmz4-tt#Q)Ycx6u3qPd{uYOerCuzt2(qm`k z5XJ+4)CrAm&)5Vjvh)$+u&xnl$(yDpX2Yx5?eSj^=G5OMTYsNpCw5{Ik5N46?{gL^>Tz5KBejeJr#dby_Jg2{TLP9A%jA_~YQw zPJbNfddGs?$ z;|l%s7`+J6DL*z^P^1Xg&2r`Gya6T<{B+rTN=EQdguFH8k3KN-1p;Qc__%qW>eaeDY1$%PJ$<^W`RRwVUfN|z2o);P=dx3cWG{~qef1nB<#Zr>UMUm+L$ZXWUq z%-V>wJJzqH?i=izWgdaGp>Hdll6+F@-Y`ONKjeXKdum3Hz&_M^)-Hl5{VjxzV;ZDSTc+-+&f1 z8p-4_3;K@ACB%6@zI9g+<_=ZyFNu4|ifgQ<5vNk;S~?Zb(S2;d zH1ep~n87gggSE{3@!O%DCh@_ROSju`NE2#|}L`agpaYvlJVm{$hG{ zo+0SwqL&(QJp)Pq)}Az$ktLHSM2h)raSVP}O16H7-{;jiW7FnAk=WXFsnnOVi;#pD zEV10=$Ii$p=_13nAVjZ$v&DWvYvod}j;Q*WPQrffaqdgD()|oVo?u!{_J_A=F|_UC zyhG{aQ(Fek=i;sJf&W@+3Mi_t-9DNJL=uJaPv-In`79)*lTek5Sn6k%zd$_Np8Z|ZC5MOhF-%B0t48yQwGEPH#zOBulo}xl;7fy(cFS3z-1fF zbB4#x;pPTLK_Jyl&Ytm^uTlzEH5<`CC86mf4>ze>*NVIyPr?2zr4tN>QgN6Vu4hA1m9=dxTNwn;r24D5uN>&^8k{I-3-!p7-li}n z^$)(<7`BDda>q(k(w9;M!!v8kg^jtYOXZqageLTU^;r<4MTf#OkBZXu0zG5*Zo9*~ zOb+*k@jIDE4bEMbPRCzd+fqjY25ys4(E6V=Rw2f-yOrB1a8zU78BuDsgi zjv)v)sruJELzZmgpLZu1QR(YT$|xQg6ibK$hA5~JRyvO2{kqDJF>~rnl;j->p%Bn@ zgcv1h5n6D^lw#M;k$N5)$Dbv6Np*#Ow&?^*mI&pAL*X<(%Y9u~*D{NvDwouf-6|H# z>z-=8vr@d2$>&|$*5xnp&UdrUM=u*VYb488EcVgeQ$8lqc}~Ao|HG~Sv?4%5um0%q zcfB)@>l+LGip5`IoT|qYUD*$`z@PEL44_msAr|JZ`hwr-aI`t+`xU>n9ts+twEro_ zJ48sON+Zdb72>V-qP>EY*@o&x?}Tc9Yl`U52iJ~HfWdcl1sW{X5ydElGga+fGG54N#WXgtFw!^}CzP<(4KDo96vH#Iqz5o07ftHDjOfnYO zKT^u3w8R8J4fF`-NtZ40FV|U(6@azsOYi;m^t08g4gc5{0eW&^rAejSMmf%B4B_-<5GuW5o3e<=DITzyEUN zl+oGQdcltS)AJ)OrI{>yh>a?i!oGNW(5==g`f^Y6aB*T4EsE8=c*{tY3#B8jlNiT* z5%%2rdo=zV4*h_3s2>4tG6kUHvrO+yFPW!1mQo(zcZ#Y!dofvyfuy$dm*NcWII39 z|1UiltQURjYyrPuvHwOV!=CM8*^8ALA<=<9Tn;2tV;Ti<155eScMy5%Zieaag=S(0 zqWytj3?Vs&t|<;v$B=W&ZTV2q<9GD>!+nr9yKfUnJM=*DNBVo?KUgL_9yuxTyb2y@e;&|SqG~t z5>ZDe?{>G$wdZIW$SRDp`gl*Tt~~p*)2qIdf~UV9Ol|ZkTt{r^AQv3Bk_TovR3(o< zYfNN9v~Px$A%~_yfO99>&tKe4lM-uabW+TlWzT}CAL&t+>s?cAQrL4m6| ze!1==HPhk$jQ#V~;BffqQ`EfAwF%;kHoHb<8Y?PAcw!ciOh21upCDA z(U33V+`sdin?#qM5BfiNQU5b+R3Jrx!ZB#fw!NrEIMEksziUr)w~gjjf&LncCWQ}# z+>F?*ns_S-3V9Rcq_)7O*l6Q7lu^IW2N>mXzBg$so{yK93Fxfa-ok;>-)-Z}i&9Tq zHVV|*<;QM;<7*+1H(if-phV44{f9aZT%qZA@NX*+Px5#?zg{?W!B{m}=6mAyWlZGQw2TyM=<> zjG*^{3fqjp$2V6<+Blm&jK{}Ph;On zt`U_T=GZZuxk?)x%Il;r@vajI^g9G_9N~g#lG^JbMQV=&-sWJpOpH6p?dJ z+2I!#ZeDy~83?~YNiCM^IN#I#gsqxJ-1ISLlct2_P-SJBA=>~#4~2L#ZfWyc zOmk8}mxm3XQ2mzL?Hd=)Z23g-pan|Zj?H7GoppXfd>M=h}Ig)+rwZ-5eQ) zxcgqhwT%7yuPw(F9}X={rLRpyw)jJpam%Cbg%+^&<%;+^)UCt)BQ@TnFN-j%9*cjl zq;B$$??YGJ`8mEr|04j3Ae%SGkn587s%F?$|u@hk~h#6;)RGgR2ZB{jWTv z-2{akRdC8f^gRgZEg1d~9+gLZP$b9bkKxs13{l`%KHNVryv>su&vj<{@_41^F68y+ zR^`hS<#xTkup>BH^PI@{5mgGdAgyf-T9bi*l!sqo4=$Znetv zjaOo9ZFLS=870%~zbM1rF8dX$e`8Adredt7@iYBrlX5fd5m?F`wL&~p&tj$qPD0nc32XMmvo`Dvf~nw-A-44+@PG6&aQ5~J}Y{A4KeuV6LhmfPd< zCa+E{JG^)2K2qGzpMadhc~WToUrFre_7^E5PbP}}WIk8$H(2uOV;SH4b~GBu%41aF z70Y7}wS~^|{;Qz{FjhvL&h+-zb6N=$E|AWZs3vYU^0g9W6!q;?ow=G@g&mwSvikE6 z{M~EDhwwzCtpq3j^6wa&YEdU-MLj!l$ww4Y>3jO#gVN3FKRnOxOQ#iR;!3ej;X3Y~ z*^d>a^Jua+d1Nn9n1fb~TetbMH#--@pWU!;&=!z~t!`m0CL**V1JfKxf}?AK1zi0+ zjTiCewQIiFa&+vpoS&o3o`n}hib-2m;)YdF@qGvT54PqZ_e7>u^Q7&UUaQMf0`K^Jx6jf zt$oOX%%$eMk@jD@f%7pNBhg1(*4|K;2U34b&1aUKV38r^tj=^ZR#3;_W6h(2`G&go zQ!qY-(S^zy5MB9aZ`KEzIUkk%Ap9Gd?79+(`ow<;6 zS~+=^O`M-GX4v``2iHrkJK&R* z6G0CIpTxXeJ96R$&s)I_nZ%AV*G!57Mc}*wE)z<_pJD4OwnvZG*lTa?PH#y=k!$7PJ4}8e6f^EXV-*^w$*MQ&gogvQjl9b9gbN2 z7tRi>OI>8T#b{5oKk~WmukQC{xFx*M##=opIvdwUz-!5;=CKf=*0*M<&SSE(!af7% z{6fh!bodkd(OB9q{(Igxn7L(UNX8F~>Xvo?d=-zF`XM5yn)knv8V1pvakakMep zo({GW6{{{DK$}Q#{~Cd7jHzCD#R&uyS-)0jg=|CgWeCXU=>K!mzy1SAl)<9srCnTM z>geeax7vPA;o4mpY;nJJGgJS&vtDoi@d?)}HO1agsqwOB>l5g&&sokQw3U}w1 zNDsJyn>L-^@Pr|}hokLBL7kp;7j;QQC8TPrucOKA*r-ZBW-t{|jr7r-%P^*1a|?-; z;5t@sba(C;lzk|u52u~iEW&+iR*ftm;w)S`guH1KC{acZZCezjUpOB##)EWcw!Rx+ zg<4%SD|Z^|D8ZkT^x>ylo8pS#F^A+D>#lpHhs|HLkme?3J_3A`HiQXnTr#cf4Lb(T zR$EK2Ah(W!CtS;4!RvgYM0-n*coqd@4@fJiS=Lk&oi(3@0Ix)6E? z0Yy59(wmaIIxb5ilSE9z*~P z02_b?uz+MBnn0{WypS*$1_r~!U<6`Wz(OKnNDK^#ham|>7Qi9~3BzDu7(5I^Ad&)N z@kkgR1H;t9!UV?0sR1I0@*-2 z0Q~?7Kq0^y00T$^EP+sf2T&Nm2A}~f0#p`T@`cvVnF0oB+XqLVz^@29O3a0a^eLpfG?9 zKof`~B1QwtfDK#(U}8Wc0ewJOz`_##&wc%G0Y#}^su;V2K$ou) z-z1~+fqwue6ooKC>Apasyq>x}2O)H|*p=;GxTD-{-0WYX*d;{7gznu>^~_=hfmmo& z72$f`nLo3BCYQ2b2|KNERwp~Mc?i7525ESEi_oedks(R1ol;J?HwC>lqh;7Dc9Uzt zJ`$zumoD*#zxoWZwyH#5zyAMZGBI+cy?UR=?#rOgZv?+`#ek0Nogp}jRVT$%N^CO1 zcKJ4>EV*z=7~v8YcCWRk6VfL~{upl5DTwFHdX{~tY;mSq+7{8S>v-PXDGUC@^wh@U>$)gi+Uug)!@GW_+^6TJc!I%O51hR5T$IB$!gKAY z{Pr%Fxcc1Wis2hvY4J*`i$~C`Lq8|2(FYw#<()Sgiz*^`AzilfZS+z`;)B<8bH|HN zhY&4E+d@P9h}*3?H)9b4{Y~Fb*eZ1W!paFjrFxbEQgdhe`Nu8VGIK6)XK{9itVFaPZh-H&{;)EK=8?_E zrn_Gi^m^`Ts=2l;j;}5EC=v&hsYY9GOUluWJSsLq1VO!adjR$L@nv-WUn?G|C2&= zpqtTKLGQPL)JlTN);NQ5#%GZiDDX_N<&PKMxrAeykqOQ>H)wSNl?k< zH}Onzzib1vwRcozTd%=x+Xn=jcFoZz=G64*{~BF!9VPD)f0Hinl$!9#901$7u-bWr!nWs<35^j5LGGs$E8udOns@^T73kO-|)e{3|n%b6FZ5W zB;#Ly9gV|IoV0?kU7Sahp)f1GUnElsi%(D+6^Su8b_b!950+#OvMp-xD&x+@ zUyC*F@mOlxeH0A{RPD6_&vPeNcuD`{;ztSg{}ymuGpX-@G(F+8RGg}29jeZlXJ#wK z&MEFAJOul91^nKlW2sNrke^9L)3$C_`9-~t2xyF^^EF%XO-X1-Ve(F?LkW%*n(&5? zcL+#4Drb|#g?F1eG2={(AX5?dW&7>S`Xgof^`PUOb$G_MLi7dWUgn1vLF7b8>)pwE z+80%->brHD>O=QAr>d_GRsV?FXF1)3GR@|-eEARv<%)g6ncdDNlH{8PrtlsdwVX>( zH>zWeRqi})uMsfuY5)5*a!=4zkbhS|x*N^|;dB**6_)UaPZR0Tp#0xtXX#%Lno2?+ zq!im4m!s9p`yn#@Zj6dQOpxjmzd{5kW$TL_V?vV6;CIGPeZ+w{Z~q# z>f}2=dVb0z@!-&cp2llc=tn+e;U>OVKW#_wjf%8k1kVNsYK6xAYKTKtq0fC-*Bp8N z(Rm|ppXzeS+$)^YOJRo{X#U#Xn2=O%$IxqOb*W1eO@afnko%2L8mW=IOvUo1TMZ7B z$9dhmA+d*@wNbHO+Pyc-8anddc{wFNn1h@(DR)J=u{Cabek;v9`1Ub%56O?_YaZXBs0F9o4ow;7SadyvzUnIpL@l$j z)zR!YZ}I}plS=dV{YP(_hl@3^!Hj()vN!3%rNGg#kdLFH|VvF#8KptfuLEB;#O`M+Q2JR`?A5Xtd!pH3&uuT<0Gy+ z*{~V=kWga?U#!`o4#3i|$|vVu#b%zni@?`&7DDdjyu)D=xEBrIppe9)&Ida2Hu)$< z?-%1Lo=v6fIyy=%H=#VnaT=vc` zxjw$3Uy;>PqFamm_8En_GTkWTJ~!zWs|{}|^KMAKwsas}eUO%SFchxB-`mhnJ}KF) zB?Lr1SESpER&tYBos{Svz6&^35Ohsi@u%G)VT1OqCGhW1Mrrl~R#(QPhDg`wTt}q? z+NM}`MqXZ4Rrlyzb>D`Jo}+)BBl!3EmT%V;jB5?z7c6rb*T9cd?q4e4Ia4EGK?cL0 zYZ&!<9oO7u^*)V0#W>>ilE{ z7PZ3W{Cj!)SQl=cR-WXx;Z)v*bncZ zJR|y@^|J)P(agjo%9zkJ#h8Fkh}cs-z0=qnrg7%7 z#5A+M^W>jQ!KK)1yHp<=nqQb@IK1Jo0@p3eKU$P#u?Dw>Yc89n6{{;u7_vj{F5`L! zrqZg(4+L99a8GO@efIkKDTa>fhWy`?_|6sExJQq0xfhJf!m8(1=4-9~dG(Y`2Y2a* zKiE(o7GPODoB}8+d42EHgq3-dyba2y-OyDqzsp;se=LgK#LG@k%fD#8NqXke)FVWd zR?eu``4idd&R!iZ#}kyLeXb$1s);f?= zhLu;fs(omr_<6U0zxdw%x{Ns-L1S#kOd<(>lOmk6Ag=LwpDF1s^>XfSb0$QK1l^w9 z7fMK9JVlpT-!1y5l*KTrm|SesDpy97uEFK*`UJPHd?uP#SrG8WS`E83x5ox@mE_~e zp_g>D%=nibNsb^t?c3LP=4y1s<2r14!LQ2{+ftVCBbj9f%8%XJyysQy?ty(A7m6m- zHygj-Rpnwc=+0!e3pJ10>&k2ovXx2@l#kv&L)@B5n{VB_N>WBk7K>Pxs6q68sOuAk zX)jkf{LM1!_}CISVP>N?LmGh<2TMLhGrtWiUSNVL-15s0k?K+{vn4Uyc%*D2@>N2` zv`Mu7;l@<;jZcAYyak~9`RMA&N{>VFak^5k6Xf9$}{A|AL3}Z zqb^wou^nI`e#M*?>J#R z@?FK)eXV6S^!Aw?RQS3btJ<#DLUfGnPwQh^*g5CwwQFnqk=^oqcvR|czVIep$IY_* zuFSyAYRZB?0dE5=!9q;6)L~^$+A>67GAXGzp&zP?hFU3Mqp3JWd#7Y)sWWn)ubYzf zW+n^qjSdO#)+cVM4edCe@?}2Nc{$>IOVihpZA%>bn0&89NKdmb^vl+^npb3iFZG?} z`KTvUYq38poKm~!kxi-IqbXL~i~i~=Q-@i@bg{lmh+dWi(-mIXJAC&|^?9TVebv)8 zR(JE=OTMZm>Cfec-J`fkPvZ0A{Y%l01#0gbFrh65<_s^A7|wg#@Y`uS5LhN3nNSnzM^#||f)bi;PEVENpzK#rjw!Id5CYw|A z$IkRvAdBfcbCJ7j4A=4?uSVPDVW|;s-c`Qd`KzeaIo=yO(Q(fFc<98W54~Drnxx%r z4uXrt$qRH|HPe%L=?|oQ-9>n2L^EBT2Lly?ar}c9aEDcgP506?Itb%%++e=yHoN3y zvrtQ0(jH^dJxOP-ARZqt{_aF~Nd5@DD#VC_Enh;8(LHc?1Q*ycQaOn&9ocjrL?h=_Ir8G(^V@gxe=gyU!VI@&c3&m&+yB z;#4E;a^DVvAo9anF?OPz-2Q%pQ1@@~D$j6K5{9|uIr=U;?|4&1jo^keSLkZN)Lu%i z2@5yB=SjUT+?ACX@1?9vMqIOZ9DsM@1D7IvlBwP{GM#W21%NRgyf8Gcaa zRmNd39O48Xw`+~UY;u4PSilnwtz)Tr`g{uJM)38Nw=dq87=)HQlRH#@isRGI5H8O( zk}_QR9X(L@-s39Y#JY`rj&Rdb1?Ob zU0H`jUsBJRq1dP!xUy?ilXoXaubR|n`&e3Z+>d{IJihNxQSb7`i7YGmKFiC&trz?E z(Y7R27V9K?_W)KGF&O8dTywaN#J&j!%RM8NTYvsozQb}I30`=HQ_Y(2vs8{~yE@hy zYW=iraBvH-UXbYBLZWZnS+e_-qv`61V#h8l@S!7)$KAclAHN){doirAIy({!Eym`$ z{#vzJC~ME4ou$Q0fPBjVh9}2((!8!5T8Qz$x{1Vle5NQ;^qU#v(qt*SNja0^v&(Ar zz^z5C_m=gc)2oecF`sD>H@2Nj(VxwfRr>>e%_P+$!3n>{-5c0c8D`qCm)AVsW5X(r z9R_WB;E^<$bH^4p2?JD`-)A6AdXxdzP?T#0oNhgEO%~N(qJc8)OanI&%SZ4bq8T8? zsfFKC6m73zvCq=mK_7G*+S`$X?^HZzL#k3}e(SZgY;6xE<`{UE?_? zsp}ZyX9*B`>QRaS8(-jY?iarzV+O6SHS{2cGRz2$nbl%p@&36j0c+*u?zJd|n@24q zm(r31=qn#Uz^6fUbDZB3|Bz+n;Sx=x-|?y1e3jgYthcLd%8ezjEnB3O;%2esYOSGK z^O{&!fv?h}ew#QPxS;`8lU$aQ2HlG0&f8_oM~5=RNeBDTPB2jyvjv>#LF|+$2|(Bq1o^HW#!U#JNTteKg5usL+}yas1djW}Ouvz?Y@g&yeSZB$V;M^f z+7Om4nlvW$=7Y*l?f`Ujxv9t7s={{f(TmkvRx#fP(^Vm*-lKy^ z1vN@6O!=W389{TR*>|zcHvb~!JY+GDt?@=VoM`pte zQgW!lfEsq_G5S^ky;YDsQTbtrQ;K~-d@7PBKvny7iY5J-o$wnWRMKWh>`&Zp?(op& z8PkkAu{>FY4cz^V<4w7vqLT^Y@9etaJz!q%6Xk{s$DTwDEg>xD!|p(Et^0cMo}IMZ zJG=KtrjPycFU1Xk)Ne|(wWlJhx29WzJufyFE4s>z^QxA<&c)T5WSDj)(ljh~N^<%} z26HWI-UvM+Wjn$1y(~XfQ>4|=I`s1Hbdr7H%(l>86awtx#d13;CK}3`L#7!$dtX(; z!@;O9X`a^Jw$vVRxB`N!{u*&a`f~TPFNm1kmcu9 zi9X|OiS!5*9|{b~`W~164p-vI$&m3w+T*%r`ukWvapJ3iT( zc0!P5FWHmB=vE+ZqpaEzhu5U9R;uKGsY|9^)8&C)aWsTf-zKR+EA>-!%qF9cKE^PK zK9jpXSvvjk$WmG5TR>c3;t->1qT^*8K2uW@($sXV<~B)`V!D~B(eqV*U!7t4xv9U8 zgR1^Ho&GuF_uy4X?v&U2h5}bBf5&1o5?B2x3R_SiaYKUHDnfi6iAuM)8*Il1WPanRT^r?tjt3)~6T+T*S<=cdNte7u@h>aDP zDl})>^Up5HCEVxW(_(1%1yio5;pF-g*7}!B2d@pp3ej}JL%;oFEj*0ChuUM!=x>H1 zth?;1`}3OirMwm!KVo30sqcj-^Wy0e<=xWAh^{hB5sRX37s zHPLy)2lb#p!bxr_Z2ieSg^qux5Wm-*g(?R#Ir%B07FJ0e2kus*D~YbjXgYq%2*8CS zy5fnh+5Z+b47lQ3rPGu@{r{Y1{5$%f?7UAUBDgo_$iG*|6We~jtc{lA&cSS?|Idhb zl@kkRn`-`tUqWUaUpSaX)>oq0)vb+>E98$5ksdeM2A(`Npf#W)FSy~wCHrLVw_TRS zD69%?Ra)JgFdzF7t2*Did#Gu?HS?FS=Yow@})}6x&0BoD{;*YPbN}UQ1~Y3he^1EJcDtfo4L2Yz>gr zh`5E)uC=t66m>O6$!SGS3HF47OHvG*HVwnCWd@acb$*ic(9a7NR6hNt6P(y`(Wap?|;Iz)Ad;t=S;Ne9Or9CfhfVAa8jgJlOJ2TLAPb4=AS6~~kv6FR0l zksJd$O2}nfQJW-e;#OqixQ#U%t2S0_EZb(nHsiLb*`}JJ*rsf25sM@&Y*;vHVYi7} zShp~;%(!LhmI1A#Y$cJE5G^%AykLS|CNXtlK$4LDJ7X^$bSbPUAx#cw$gc@N7hyf7sgRn~gK^G5# zoG0K10k;C+2S5OT2Y~YeIN-)Tc>}La#s9RRa!>Qt*5+-+ds|v}7O&sgT)eWju70Wy zlz0!k-vn?Bq;Z8cr(+fGXG~cf8hJQzK+P(6MQ`M1gGqU%a|aub!fL>0*Ub6rp})3! zYF$UuNY$IQAI;l(DRa@Znv?BknW9f*l5_>+fO zdd}1A1H13M_vpb_-)-30alRqf*Cw?6wrb0Ute^6?Ul`h*=4)D#Y4H#HWmuF!&eSJba9o;7l#BKv$vZ+dld*Z9WeSyc@+bI+b$*Y5Mj{8uN9 zoa*UZ`1QoJH{|@lv17|de!i6T+_ll02YrdmkH-Rh%b~(>Rw3V(e~?=;oViks_4!)v z^^Z;JZ!hcKo*w+YyJy|K{Nda!6EkAIg(XMZeaG`Aa{Dq0>&uI!*yXnUP2(HwHu&r8 zo<-KaKd!`XbC0i-e$X|&EA&g5wEDyy?S(ZbI!I}6#pI#Cd%k#f|LFDV - - - - - - Concepts - - - - -
    -

    Concepts

    - -

    Point and Range Methods and - Iterators

    - -

    A point-type iterator is an iterator that refers to a - specific element, e.g. as returned through an - associative-container's find method; a range-type - iterator is an iterator that is used to go over a sequence of - elements, e.g., as returned by a container's - find method. A point-type method is a method that - returns a point-type iterator; a range-type method is a method - that returns a range-type iterator.

    - -

    For most containers, these types are synonymous; for - self-organizing containers, such as hash-based containers or - priority queues, these are inherently different (in any - implementation, including that of the STL), but in - pb_ds this is made explicit - they are distinct - types.

    - - -

    Invalidation Guarantees

    - -

    If one manipulates a container object, then iterators - previously obtained from it can be invalidated. In some cases a - previously-obtained iterator cannot be de-referenced; in other - cases, the iterator's next or previous element might have - changed unpredictably. This corresponds exactly to the question - whether a point-type or range-type iterator (see previous - concept) is valid or not. In pb_ds one can query a - container (in compile time) what are its invalidation - guarantees.

    - -

    Primary and Secondary Keys - and Associative Containers

    - -

    In pb_ds there are no associative containers which - allow multiple values with equivalent keys (such as the STL's - std::multimap, for example). Instead, one maps the - unique part of a key - the primary key, into an - associative-container of the (originally) non-unique parts of - the key - the secondary key. A primary associative-container is - an associative container of primary keys; a secondary - associative-container is an associative container of secondary - keys.

    - - -

    Null Policy Classes

    - -

    Associative containers are typically parametrized by - various policies. For example, a hash-based associative - container is parametrized by a hash-functor, transforming each - key into an non-negative numerical type. Each such value is - then further mapped into a position within the table. The - mapping of a key into a position within the table is therefore - a two-step process.

    - -

    In some cases, instantiations are redundant. For - example, when the keys are integers, it is possible to use a - redundant hash policy, which transforms each key into - its value.

    - -

    In some other cases, these policies are irrelevant. - For example, a hash-based associative container might transform - keys into positions within a table by a different method than - the two-step method described above. In such a case, the hash - functor is simply irrelevant.

    - -

    pb_ds uses special pre-defined "null policies" - classes for these cases. Some null policies in pb_ds - are:

    - -
      -
    1. null_mapped_type
      2. - -
    2. null_tree_node_update
      3. - -
    3. null_trie_node_update
      4. - -
    4. null_hash_fn
      5. - -
    5. null_probe_fn
      6. -
    - -

    A "set" in pb_ds, for example, is an associative - container with its Data_Parameter instantiated by - null_mapped_type. - Design::Tree-Based - Containers::Node Invariants explains another case where a - null policy is needed.

    -
    - - diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/contact.html b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/contact.html deleted file mode 100644 index 3d506c975..000000000 --- a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/contact.html +++ /dev/null @@ -1,22 +0,0 @@ - - - - - - - Contact - - - - -
    -

    Contact

    - -

    For anything relevant, please write to pbassoc@gmail.com

    -
    - - diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/container_base.html b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/container_base.html deleted file mode 100644 index 359e02459..000000000 --- a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/container_base.html +++ /dev/null @@ -1,1063 +0,0 @@ - - - - - - - container_base Interface - - - - -
    -

    container_base Interface

    - -

    An abstract basic associative container.

    - -

    Defined in: assoc_container.hpp

    - -

    Template Parameters

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    ParameterDescriptionDefault Value
    - 
    -typename Key
-
    -     		-

    Key type.

    -     		-
    - 
    -typename Mapped
-
    -     		-

    Mapped type.

    -     		-
    - 
    -class Tag
-
    -     		-

    Data structure tag.

    -     		-
    - 
    -class Policy_Tl
-
    -     		-

    Policy typelist.

    - -

    Contains subclasses' policies.

    -     		-
    - 
    -class Allocator
-
    -     		-

    Allocator type.

    -     		-
    - -

    Public Types and - Constants

    - -

    General Container - Definitions

    - - - - - - - - - - - - - - - - - - - - - - - - - -
    TypeDefinitionDescription
    - 
    -size_type
-
    -     		- 
    -typename Allocator::size_type
-
    -     		-

    Size type.

    -
    - 
    -difference_type
-
    -     		- 
    -typename Allocator::difference_type
-
    -     		-

    Difference type.

    -
    - -

    Categories

    - - - - - - - - - - - - - - - - - -
    TypeDefinitionDescription
    - 
    -container_category
-
    -     		- 
    -Tag
-
    -     		-

    The underlying mapped-structure tag of the - container.

    - -

    This is one of:

    - -
      -
    1. cc_hash_tag
      2. - -
    2. gp_hash_tag
      3. - -
    3. rb_tree_tag
      4. - -
    4. ov_tree_tag
      5. - -
    5. splay_tree_tag
      6. - -
    6. pat_trie_tag
      7. - -
    7. list_update_tag
      8. -
    -
    - -

    Policy Definitions

    - - - - - - - - - - - - - - - - - -
    TypeDefinitionDescription
    - 
    -allocator
-
    -     		- 
    -Allocator
-
    -     		-

    Allocator - type.

    -
    - -

    Key-Type Definitions

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    TypeDefinitionDescription
    - 
    -key_type
-
    -     		- 
    -typename allocator::template rebind<
-    Key>::other::value_type
-
    -     		-

    Key type.

    -
    - 
    -key_reference
-
    -     		- 
    -typename allocator::template rebind<
-    key_type>::other::reference
-
    -     		-

    Key reference - type.

    -
    - 
    -const_key_reference
-
    -     		- 
    -typename allocator::template rebind<
-    key_type>::other::const_reference
-
    -     		-

    Const key reference type.

    -
    - 
    -key_pointer
-
    -     		- 
    -typename allocator::template rebind<
-    key_type>::other::pointer
-
    -     		-

    Key pointer type.

    -
    - 
    -const_key_pointer
-
    -     		- 
    -typename allocator::template rebind<
-    key_type>::other::const_pointer
-
    -     		-

    Const key pointer type.

    -
    - -

    Mapped-Type Definitions

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    TypeDefinitionDescription
    - 
    -mapped_type
-
    -     		- 
    -Mapped
-
    -     		-

    Mapped type.

    -
    - 
    -mapped_reference
-
    -     		- 
    -typename allocator::template rebind<
-    mapped_type>::other::reference
-
    -     		-

    Mapped reference - type.

    -
    - 
    -const_mapped_reference
-
    -     		- 
    -typename allocator::template rebind<
-    mapped_type>::other::const_reference
-
    -     		-

    Const mapped reference type.

    -
    - 
    -mapped_pointer
-
    -     		- 
    -typename allocator::template rebind<
-    mapped_type>::other::pointer
-
    -     		-

    Mapped pointer - type.

    -
    - 
    -const_mapped_pointer
-
    -     		- 
    -typename allocator::template rebind<
-    mapped_type>::other::const_pointer
-
    -     		-

    Const mapped pointer type.

    -
    - -

    Value-Type Definitions

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    TypeDefinitionDescription
    - 
    -value_type
-
    -     		- 
    -
    
-If Mapped is null_mapped_type, then Key
    
-Otherwise, Mapped
-
    -     		-

    Value type.

    -
    - 
    -reference
-
    -     		- 
    -typename allocator::template rebind<
-    value_type>::other::reference
-
    -     		-

    Value reference type.

    -
    - 
    -const_reference
-
    -     		- 
    -typename allocator::template rebind<
-    value_type>::other::const_reference
-
    -     		-

    Const value reference type.

    -
    - 
    -pointer
-
    -     		- 
    -typename allocator::template rebind<
-    value_type>::other::pointer
-
    -     		-

    Value pointer type.

    -
    - 
    -const_pointer
-
    -     		- 
    -typename allocator::template rebind<
-    value_type>::other::const_pointer
-
    -     		-

    Const Value pointer type.

    -
    - -

    Iterator Definitions

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    TypeDefinitionDescription
    - 
    -const_point_iterator
-
    -     		- 
    -Const point-type iterator.
-
    -     		-

    Const point-type iterator.

    -
    - 
    -point_iterator
-
    -     		- 
    -
    
-Point-type iterator.
    
-If Mapped is null_mapped_type, then this is synonymous to const_point_iterator
-
    -     		-

    Point-type iterator.

    -
    - 
    -const_iterator
-
    -     		- 
    -Const range-type iterator.
-
    -     		-

    Const range-type iterator.

    -
    - 
    -iterator
-
    -     		- 
    -
    
-Range-type iterator.
    
-If Mapped is null_mapped_type, then this is synonymous to const_iterator
-
    -     		-

    Range-type iterator.

    -
    - -

    Public Methods

    - -

    Constructors, Destructor, and - Related

    - - - - - - - - - - - - - -
    MethodDescription
    - 
    -virtual 
-  ~container_base
-  ()
-
    -     		-

    Destructor.

    -
    - -

    Information Methods

    - - - - - - - - - - - - - - - - - - - - - - - - - -
    MethodDescription
    - 
    -inline size_type
-  size
-  () const
-
    -     		-

    Returns the number of distinct value_type objects - the container object is storing.

    -
    - 
    -inline size_type
-  max_size
-  () const
-
    -     		-

    Returns an upper bound on the number of distinct - value_type - objects this container can store.

    -
    - 
    -inline bool
-  empty
-  () const
-
    -     		-

    Returns whether the container object is not storing - any value_type - objects.

    -
    - -

    Insert Methods

    - - - - - - - - - - - - - - - - - - - -
    MethodDescription
    - 
    -std::pair<point_iterator, bool>
-  insert
-  (const_reference r_val)
-
    -     		-

    Inserts a value_type object. If - no value_type - with r_val's key was in - the container object, inserts and returns (point_iterator - object associated with r_val, true); - otherwise just returns (point_iterator - object associated with r_val's key, - false).

    -
    - 
    -mapped_reference
-  operator[]
-  (const_key_reference r_key)
-
    -     		-

    Subscript operator.

    -
    - -

    Find Methods

    - - - - - - - - - - - - - - - - - - - -
    MethodDescription
    - 
    -point_iterator 
-  find
-  (const_key_reference r_key)
-
    -     		-

    Returns the point_iterator - corresponding to the value_type with - r_key as its key, or the - point_iterator - corresponding to the just-after-last entry if no such - value_type.

    -
    - 
    -const_point_iterator 
-  find
-  (const_key_reference r_key) const
-
    -     		-

    Returns the const_point_iterator - corresponding to the value_type with - r_key as its key, or the - const_point_iterator - corresponding to the just-after-last entry if no such - value_type.

    -
    - -

    Erase Methods

    - - - - - - - - - - - - - - - - - - - - - - - - - -
    MethodDescription
    - 
    -bool
-  erase
-  (const_key_reference r_key)
-
    -     		-

    Erases the value_type associated - with r_key. returns - false iff r_key was not contained.

    -
    - 
    -template<
-  class Pred>
-size_type 
-  erase_if
-  (Pred prd)
-
    -     		-

    Erases any value_type satisfying - the predicate prd (this - is transactional, either all matching value_types are - erased, or, if an exception is thrown (for types whose - erase can throw an exception) none); returns the number - of value_types - erased.

    -
    - 
    -void 
-  clear
-  ()
-
    -     		-

    Clears the container object.

    -
    - -

    Iteration Methods

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    MethodDescription
    - 
    -iterator
-  begin
-  ()
-
    -     		-

    Returns an iterator corresponding - to the first value_type in the - container.

    -
    - 
    -const_iterator
-  begin
-  () const
-
    -     		-

    Returns a const_iterator - corresponding to the first value_type in the - container.

    -
    - 
    -iterator
-  end
-  ()
-
    -     		-

    Returns an iterator corresponding - to the just-after-last value_type in the - container.

    -
    - 
    -const_iterator
-  end
-  () const
-
    -     		-

    Returns a const_iterator - corresponding to the just-after-last value_type in the - container.

    -
    -
    - - diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/container_cd.png b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/container_cd.png deleted file mode 100644 index 52553278cac2614875adc035c8b109bcff3631b2..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 11884 zcmdU#WmuGLxA#X8xo;FqQVs;&q|E={_QC^yYoSqzoLQ!BIJy1rWNT}ie z?SGww@2doU2l(fN!##}ZU-0Gr*Rwb9Go7Q9rlX3Du_MmV9*e@^aGYk=77j*+wpdOZ zdy|+|F?tm03JUY!uIlsH6}*e%MQr`iy23|s_Pe+546&S`x|Z|q!JX4N8s}Iw1jsHv zV5GTNAuL2A-RIA2Klbp2!4Er5p_?~-zFnLAeE!^{vtLoi4gFrReDGk!n7DX)J+ynNgKJTH&*7S&geAihIwWKVRm$b*pM%RRq;& z9q&v7&+}{`SBsp2qO9h0-}$z1j^5?rlDd_A64cnSPsdU6b~Ay3Xmm5f`28tkWM4=M5m^G1qZRy~ZD3o{GU&u0{bRQO?P?@Qz53pD)O`45Sz&n3`E}01w zYWr>>ylChnvvjF>e|Cwypji(Khh8-?xvvo0Mjc4UJC{tPK-n^#IEAuxprfNh-^~0o z>M=Y#Y%jzRmd?S(rsC{ePFO!Y*xQ_qFi?+7&&+&u>((u*k@4p<6nKwqJk>~Xak1lW zP-b{o*e!AKy6++-#l@YjeaviZIiHP;0+f}N(RJa)#XO9n&bd7w-|z3c#|ha@2M|!G zA)kpN6iU#E_)95}o?qt0ix=pdH-E@-)urm#)TuE)46uFeIsKlzn`h9V4;R+1vQN`@nWZ8nBU}2jKC|29 zb(nHpE;wqV{_R;bg<6*S91k4Ja-N^t~iKrK+r)EV^2G zKk$;^z77+9%94osr~|l9HOMUdrc%y>F&9qGs2ebhkd( z-RywX&hcQ35wsD=)2R@E>(Cmt|DI~Y)o8;u_+k0CpqB9#c7q2lh2PPy;oSQkhben{P#0O6z&5ml6v%*)a+0?E- z^evz8-0RqBo0O1{fV0sLA;*e|6UBwIz+>FHdGpcE&Q93w{#=X=vEgX1!MrE+Ed)6g zEv=?mwCm<#7DPdC>ek9A8$Z9=-+%utqo6PdYtM@D_4PF$%#UNab>+&PL4CIsIs@6k ze7)J(Sys&Aa7l*q@=#KYbv4GQIY3EC>0`8@O@3)9ADxlo(ZTjo>x~4}?NvO#<1aXjcpe2v6bo@UWKI4Xl5uHGju<`l#`>7!6?XOX3@`!ntDx|o$g95M>Jb>oJ#$KF!r+_JbU)*D~*9_$aT3=&jZ)G zow=BiDu;}8xtR2C-yT^F7fZoD2d55~n6R<2$-?>XNxJXXmn?N^b7@ck;w}WMWj+ke!pC-MxPdMU#LH5Z+To*+!MHw`nNfgQ z{9IbfxnxtT1g}Syf|5Zf(c2rP=ds!U?(JJUPM@DYpHb1!h&IVuTINnqPxqx_E^Myi zb;ifXsnQE%tgZ85ubydzZ!Hg})O+lqA>@Kfjan#IMk^Fx^HlHMds&TJ%O?^Yt;Q;q zZpg>};HVgz7URf)t%T_N-rA~^As^QVE8$=D%ia{>nB5 zby-KexSQjyXBzCFfSSYlId;_KnOJgCROJ(DPTkC&o*r^5mGsA18@p#vjkCT_j=>-F zJ$JA*vXFIO6?{NSMr8o}8ii`aLh6Sv&i|+@6)~i!1G}1Gsbpkb6j(n22 zRyY{NA>5>9Dw$d2;$G{D5MQVq5V`d}ey@=yJRyzf$i`sklkNj-R*o`zJ5jUSqYq z!uUE?MZ8raC&=QqY^*FpQmcbqWfqsO^Xml+KEE}m=1f}K%r6Q~|1E(3hgKVuoVSCKmbylbg{{%uU@@(SYWB27&ck}IL?JZ=_kCRz z8H=q*9k4VCyGU;|z0CPJPAi-$dt;L<%tglhld~GX(c@e^f8rdwQ2?HQl0h^4s~2r& zR7Qr$Q#(65*_tI=lW^>g47#v}vQI)^U!RPTQu+HF>Y^y1-gqQ1Y8dB)UWW+su$WXkAqv>-^+H)}N`w z%x^jL1AhGen&J}Qvu|f>+8TwYI|`|@H3}}<+)*?&u#^8u%>JjtW!t(k zR;9AAu)w)lWHHE@mX@ZM_|AKTgPHk$!@*Vz%U(rbg6A$$>dQNrGQV>*>?ecHjMyEj zcFNh<*yvmkmfZjCBTJ}N^oT`ENa*{WVao4|kB-j9*We6(xJ-S&U)adH4QpeuG>`|^ z0NMEUYuxCX5~AX!aXPlbBlR9Nh`zz}1hdMPnsmjRXF!EqmdeBSq+&!sr@IEM}&XdA4tu{o4n^S;cFCD$<`kkbXMMp6gzbO?JVZQYvu&fu&swYIj7 zRNAF14&>!P?O6no+_`e)_H9MMG28oT^EX&nzBM)72iXy!T5kpWaEpUOPD@J*Yz$J( z_?|SP=JV8hdwNRYHf1V0#_HTE%55g{6BDm&F7&nxPi#+k6%-cU)^l4aGw)9J1=mn& zH}jC+W?Wa?l~@_+Po_}_$|+B~Oa{4cIYB%N1`7HhL}F+}L}^MYfMB`B&8-w8V5JNz(_dnuz;F8FP7l+lCP;_u1IDPKAx&^UxOeZ~Dd(u? zT?9!6n&=k@W6-W@P{h%Xk9rj(!4c_^kWq$an9K(GfDrD5BiWZG8-d==xuYiZ^q9`$ z1PQ$w+}eQT;rf|_gEg-RmOTBs5xTRhb=&%1zkGQVyjrs+fm{f*LHEXN8!Kk5Zady# zAJ!jaCVLt@Lx_Szmc1v$m33oM@%lF(}xB+XJWiwGPBQHMyQl=E# zBAAwMQ?@q+1l0W~8M8Nb2=iTo#n`skAn8DQ)`cLZ9PPp4lSS8RRhntR^4t^? z(}lA(5MxuH17T3{5GCO`QEr%HJ2A~y$V zVs~rQh82UjK6qkmKsWq(GvR1oIx8zHTGGq2jL_cE(T^C-%1WWlmC->L@*Zg>k5q^O z@Hp~QQ&VUT4mEf8+THE7f|-^eHcrk?muHfqqB>rCqZ1ctXfl5P{%syq`=zCY4NM?% z?=mtyopGXNmcu-0sj0ufH{=$2#R}TQgXc?8%TYILkK_*9-JSO5BK{0fK!ZiOaQ*QQ zNF|*vE;HoV0K-fvAC?kpyogE+60pYbHZW8WTe2a%oZ;swSsPUA0Hn$fl=W5Qd3!aYh4^vw6)Cx zxQ(a3yuHrD)5CJ(MhrY}Zr=req^lkr%k9o)!euYJ1`^L})RN!R5I)YQgXYZC^BBPtaY z*|l&6;abH#L<5h_u&Sl}n%EWC-Gm)DiX8!TyzNT`4b}nN>AAV>rIy1z3=-~$HwECJ zRbm{d1s2F`ytWD+;MXrxUh}@2CX$dP8nh~HlN?4Zz|uL?<`*QeSGS#Q1)ahU7|^U%=?w9yXpOBwA70BJZKg;FCeYEX$WCAx_Svh1mR@u$2Rs6+qX`sV$ zq8`5wA(yUEpg#w(Mzx!1&`^I1jpk{lB`lY8MSC6XO{jIUadUSQ0rlL|fink7W7AH? z^MTx`4FX}-R>*NFufn|1`xpWU_V@Qg zn8fbICMG7*8{DafQw~K~?%cU^8{69&>gwug z*sBLc90~uZic94zx5UJ19}-UdMP2w6iYPxwB~UD_Q?{AU z`J@|Q4%j&zO27M7BcIT7NsV^%9euX4juif4RbScSdes1n#xV3k0-uwW0K}AQG<#n)RfM#P8opE*F z?ANfE?~Dshg+*t(aic|ewJ(O#a=cdSjKrTr21-9T3JCdtv^L?Q;u~Uc{&5tK6zqxX za#0J*K@nqoA0!M2J2^;;xPcCV*Zxxx2A)b#L(AN@t)aNwQ{M4ggSg3pLLYtG@MY@8 zZG4`NAj0k-`z}Im@_o{sCQIW%?3U(fRvilJLj(e1#sP}t024#%Tk3|B*HED$y?|w8 z{h#Sm$ZOvP1mxN^WZ39HmitlCC6NP2a}n}KeknUk7Q79TFtUpv9Aak*8V+6MVuh4o z6+1_~qpxT-Qjb>H3<9bsb(oij)1wzmY$Q2j+Lx)cI8>Apzzy3N!2*Xy_S2_NGP1J0 zKa%dVx&JZ+c5_`mHWMLWz!yP=L4ms)MqrTitOZ_@3aUedE+WbDHL+9cSbOwWVe zPJ+3C+X{amgRn9}XRuluo16W$E(FdV(WZu3o(hh5<{UE-a!6ZSo2>HA4!+U19Lf&B zKQkyD(fk(SsT&8K@Iig)a+ktFLvMn_1MpV8Qa?mR(dtgW)SrA#9i3h zO!+twI4Qa*(m?~DoA?bspFpru&$-6hTCqS{?t2h+^n%v0`SrVtMkSmE}GBm+L<#!gnWdBQTnCy#8?^|r>AZ-jg)nO#@PIFL4kqm z=1o&$9LH*VF}neVw7a_-szFIj>?x3uih#?>PoH-5G%a}B)1y55^QWrjLHnBB)R{OXeHfw_{F;&i0!{-iB*q5m(i(+^ho?6- zHj=LZ4E)~SE;esfE&_Z>(abDsaj?L^OxMn?2;>CX-Nm*V(prC>&S1F8g_Pvvz6u)y zI-|~m!n2l5=S~f!XA5R~dwa`R0YO(PF*Z4TybN+^KizRpYJ;8xPtC7+J4fA zku5{A58s1s$JSacF92^VwVnD*ZiO&#*v{FhDWw&WHTXX3tlUq8c;qLi3XaXVd7MT? zjj1q4TUr61q1rM!I$C9;UGH866^AXL0T6XI{*b*b`y!eJU|yHYrFmYkub#fW7g^1S zzq-TpCt8`0)YdmPL@b`0^`y3HSsas>Ds04NxDe*TI=k~ZZ=*EOOiWB=AYJc`M%7m_ zh&X1xret(2YCCS82H7~F*UweM_tmRR$mRD&eT6dKP zW4Irn(`7{@Js+K4eWzms{`9{!U7Go+%M{_sd<}k_==}NR?FHuu#hgNqDcxAlV;tEy zFeBw0eVTG!h77B|6GfR=_O@xs)AQ}Uy}U)0m6d5==1W2vj0|y%nI5&ZwUizy&c&L>Fhjm73>K8*CMcJK?L-n?o zA;3Jv=P* z!)gtVYMnu$_-z+y49}>GQYreMWw#Z6K3UqrPzDT)1K^(e&N=^(*GHZteq4Wl>MQoNA&m=Wi=^m3Xw>iaF3(GYPm=$et7ReJ#KH6YT|DF@ALyg%S$GYK5~f z89h$IY9+{i=V=z}^gISB76FOx##~7 zHu^8L^?&86Q5ksB$!WlR!H$cH^QA2&=D0z#F5>>fh6bWUIM%mv-QvlJ{GI9OCa~?3g>Z@H$9rS*|MbOFO&u+=Qz?z{$D1xF52On zm3XPjq|3pzngS-F76Ci$tJlV&uv(XcFPGI&3eIvYD76*8TjBg7hov{FFRb|s2Pd^6 zb=`Sz>R~O5OUXp`M?RzWYc>7|9t;duodC?(-Vyw6xVf`E_*t}o)#C5XO^%WpTAUL2 zJxs8lpI=c8H4Z4r{KuG>7|;uclzdo+Krua&dDrSRakxMi5JQM8qIf1A8Y}$(EGF#K}8%@7^V= zv9L3N&JG6JI1SaHchj5)r#b&vJ~sv^#8W zJ+ZfJ^>)(_uqGxN=3XG6^eFE&rfq#b#dVW|qa#fs z-eXG(z};@VJ{x$n4Gp1G zr~ucxc;P|{APY9&W=n$w;9|l*H#Je6J$nU%=H!Gh3H_ID1m!uhql~Hu{qP~trr|&x z`cw!gtae_>hNnduv)tU=)nKMK+j+Z$G9*3sD-n7KXffMudsRT4veI~MybfuF1IkDN zb1M~&MX=Z<0m~0TK|$6H2hJcc)%Ny*r~U%rP0wfg!QI0Hs13;YY}ietJtsKfUg9u< zFkZ4VmsO#S2lQhKY_~@ZC6h!h(t3xO3!9s=6)JVzGzYnB0HAqsysie+{N_xMMVF35;lpj-QNJz@>-?o7HCf#Y6Y#$dj@K=**nZX^|FIH}7C?nzZuH5K;NtSep| zL5@H(__5zFGD^5>nwgm)&106Z1Z6v9`~nzVw6H@u(jj*9C+qB$Jlat};1yz^AcDif z!qT99j|PRmx4otTXGg$#Oml^xk*k^Hdx{1StXlQWtQRqF%+^Z;Ok%%ew&@ZrD-N}qf>zJjmO z0I#P3gd{XNdNI}$!Sk-f%*$@e+#Ck=waQ)yfC}d_$OnXx2?t#5@)SyUv!dZZ4oFE7 z(yBkl{7|UE7e)o-5ZnYbs~}4y!yMZ6Cd>0M12X`&4@ND7V2VandFNa$oI3=kLmsLL z4hg{qC~0a&IpS#(NNg-SNO#z&m5BxeXg(uL2xOlR zVD7wxVlaYFp+CMdUZ(?!KgY3p07e>|{)I%r1NVjAQt7my)0Z)Zc$<^qaoKoA09+x= zv<(>jfs_=TQNY{x?*#z%^1#|$7Zx4{1OFA0=_tEy<&S_%f}O*M-&v>}m^rmkDd zW&jewpc}7Ge?_jr!pa);;lo)Kb#-GM{OT3Ji+^@@7`d$rDQgHpZDew$ znbrY%UNLask>&CC=S4OPE(1xcYk!~6WeiI_mtV7Lze;mMA>I=3%uGqWzGxkUXY<5_ zSCE~L(@-3lfx(0k@KE8kS@)}9;o;HhdD>A>HDUOM*QApVVR!J6Nbn2}!m)!Hof`AK zh5np~;bN>m`~_lOWbbx!Bpj|N7%Pf`S4P5{hJ+X>9U!~MKvqfnERiK0blDi1P_XVW zg7YLEPMrBX4q9|D!xk531zgyOnnU~9%a<=LV z!}k3A_R+XIS*r8k8PLNqd&w%W`OK}lb{Y57GGHZwQ@?z9zqwIdA!7GZ_{ zLUviOjp~p!p}*ud;1Wd7|J_A96v_hxOY96xq;O!!DJj(_+B-AWJmUYK5y|4Q^C?gbWNX#-JOhKSypb zUqr~^_wT_G5fO8paXB!JC96|m-QSm`!vFNkUl=dT9B9KiY}pAQ3GBgxSFfRM2)iyE z#3O?=ePX>TU^Bn3EJJg`@iIT%KWXL9wKanj7Xx#RXNAAFw+kFAw|>e%nURJfX9nAs zt&*|-xCrLq5aa?SpNdlirtE4QrAW%YwOTFz-1*sG*NR&m)2egb>>)WLb|uR_Mx+XV ztjxEfq5^7TBIK=`EG%D!$IC1=S-yUqHWZnVjEoHM!y1MoNIm1wF8u-TW2<`)RHk)eqM_&T zeB}q^dcncxzqYjG0P|DJPl4$!B^Y9XHexn@LUkVcI!dtj09h_FGIC_Oi&LIDr2_en zl2IfTHbmG*N)F@$nu|*T85P>yT;hk|LHHNI7=$Rs_QC?n0UX`<{Tm6F%Pv1Zk{>w2 z(?cK*R@%+PmQ@ivH{PA5hMq?dB#9hW*>Kfr|7HMK1xhIok<)_o+u)Xvc|@pZ3Tztr zss;LW7tfzhhQ6oi>R45$f8(+JsU*M4Js+;#@2hje)gA6G^~-O=Y?MfW8C>}Tti)Vb zg4f?{q?`d!ye8&wbdXO4+K$jiWbzB}Zx5syWX=y(+2Y%WtNg1DpjPO`T}u(Q1B?9) zfLbsST3Uelm5{)Kc_Ub6CzuJN-*y|+!>yC!`YODI1zdNJCV><;IRJV{+TSOeL!O?kQ0i$ zP3G}q@Cb;$S&Zcb=m+DMAAs-!F*|vhHW3o?{2vW{7b*Dl4`@RI-AMvv^o!6XDLL=T znZ~wC?;mX|#DEk77x@XK6Oa5CsMLsR)Inu)vawJ8qy>AY8qBD*e*0EfbGo9DpPGNX zer%E6KLp8IP`}ZoAWqb)50lg3hirFiZS81?6X61hoZ#qa?G=7H0B0s+^J*0hj?%hD zN+qA-@{4Xat7=vpLc<~2>yVJp9Jyh^E?_fmY46|=H^>?XaJf%r$p&N`=J8`bIDzx{ zwJazx7zKp_dtK;`wE`-eA>chETluL?reYYis10w>g2BOkX2F_vGR zP@<=xiHGx~2q`@g83=&7k36Cy*(U_<9>J!UctQ;zpK1F1IlGQOS9NoDZDB!cY9wPZ z7c@jqkP1wq6@E7RsJ!EBzxXj+1t5rfLZ-acu)=wmJgPha_^1!MwB%MagomV_o}OWI zxbibx-lDFPFUYdR7#IAx>NESOky**Q0?b)S1Hkb(eNE4vuzfd9gh+5617_yy=Vws7 zLwe$bZqLrK)kHX&FwVEa8e?E;`pab^amxN@eMA@unCMLYf15h~H&5*%qYO$6=E10; z$d=T+(#Aq1gAssIWX>7PKpFgM78$<-vw_DZh6^2(CuZvF>c%D~Cogl7lznMsH^lI4 zg})quVS*V`*nGDCJO%?qc@M}~J~(Bt#p?GlQO<)eMp}A%2^BDnCl4OE6VUGkP@p;^ d0M8PR&fu&l(%JU=|KSHQQt}V-?>%|>e*k^;CMo~` diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/container_cd.svg b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/container_cd.svg deleted file mode 100644 index 3b5a98189..000000000 --- a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/container_cd.svg +++ /dev/null @@ -1,418 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - image/svg+xml - - - - Benjamin Kosnik - - - - - - - - - - list_update - basic_hash_table - basic_tree - - - - - tree - trie - cc_hash_table - gp_hash_table - - container_base - - - - - - - - diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/container_tag.html b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/container_tag.html deleted file mode 100644 index de187a94d..000000000 --- a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/container_tag.html +++ /dev/null @@ -1,24 +0,0 @@ - - - - - - - container _tag Interface - - - - -
    -

    container _tag Interface

    - -

    Basic data structure tag.

    - -

    Defined in: tag_and_trait.hpp

    -
    - - diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/counter_lu_policy.html b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/counter_lu_policy.html deleted file mode 100644 index d9d5112c0..000000000 --- a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/counter_lu_policy.html +++ /dev/null @@ -1,259 +0,0 @@ - - - - - - - counter_lu_policy Interface - - - - -
    -

    counter_lu_policy Interface

    - -

    A list-update policy that moves elements to the front of the - list based on the counter algorithm.

    - -

    Defined in: list_update_policy.hpp

    - -

    Template Parameters

    - - - - - - - - - - - - - - - - - - - - - - - - - -
    ParameterDescriptionDefault Value
    - 
    -size_t Max_Count 
-
    -     		-

    Maximum count.

    - -

    When some element is accessed this number of times, it - will be moved to the front of the list.

    -     		5
    - 
    -class Allocator 
-
    -     		-

    Allocator type.

    - -

    This is used only for definitions, e.g., the size - type.

    -     		- 
    -std::allocator<char>
-
    -
    - -

    Public Types and - Constants

    - -

    Policy Definitions

    - - - - - - - - - - - - - - - - - - - - - - - - - -
    TypeDefinitionDescription
    - 
    -allocator
-
    -     		- 
    -Allocator
-
    -     		-

    Allocator - type.

    -
    - 
    -max_count
-
    -     		- 
    -Max_Count
-}
-
    -     		-

    Maximum count.

    -
    - -

    General Definitions

    - - - - - - - - - - - - - - - - - -
    TypeDefinitionDescription
    - 
    -size_type
-
    -     		- 
    -typename allocator::size_type
-
    -     		-

    Size type.

    -
    - -

    Metadata-Type - Definitions

    - - - - - - - - - - - - - - - - - - - - - - - - - -
    TypeDefinitionDescription
    - 
    -metadata_type
-
    -     		- 
    -Some class containing a counter.
-
    -     		-

    Metadata on which this functor operates.

    -
    - 
    -metadata_reference
-
    -     		- 
    -typename Allocator::template rebind<
-    metadata_type>::other::reference
-
    -     		-

    Reference to metadata on which this functor - operates.

    -
    - -

    Public Methods

    - -

    Metadata Methods

    - - - - - - - - - - - - - - - - - - - -
    MethodDescription
    - 
    -metadata_type
-  operator()
-  () const
-
    -     		-

    Creates a metadata object.

    -
    - 
    -bool 
-  operator()
-  (metadata_reference r_metadata) const
-
    -     		-

    Decides whether a metadata object should be moved to - the front of the list.

    -
    -
    - - diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/design.html b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/design.html deleted file mode 100644 index e83bd4dd2..000000000 --- a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/design.html +++ /dev/null @@ -1,96 +0,0 @@ - - - - - - - Design - - - - -
    -

    Design

    - -

    The pb_ds namespace contains:

    - -
      -
    1. Exception classes (see Interface::Exceptions::Common)
      2. - -
    2. Invalidation-guarantee tags (see Design::Invalidation Guarantees - and Interface::Data-Structure Tags - and Traits::Invalidation-Guarantee Tags).
      3. - -
    3. Associative Containers (see Design::Associative - Containers::Tree-Based Containers, Design::Associative - Containers::Trie-Based Containers, Design::Associative - Containers::Hash-Based Containers, and Design::Associative - Containers::List-Based Containers, and Interface::Containers::Associative - Containers).
      4. - -
    4. Associative Container tags and traits - (see Design::Associative - Containers::Data-Structure Genericity, Interface::Data-Structure Tags - and Traits::Data-Structure Tags::Associative-Containers, - and Interface::Data-Structure Tags and - Traits::Data-Structure - Traits::Associative-Containers).
      5. - -
    5. Associative Container policies (see - Design::Associative - Containers::Tree-Based Containers, Design::Associative - Containers::Trie-Based Containers, Design::Associative - Containers::Hash-Based Containers, and Design::Associative - Containers::List-Based Containers, and Interface::Container - Policy Classes).
      6. - - -
    6. Mapped types for setting the mapping semantics of - associative containers (see Tutorial::Associative - Containers::Associative Containers Others than Maps and - Interface::Mapped-Type - Policies).
      7. - - -
    7. Priority Queues (see Design::Priority - Queues and Interface::Containers::Priority - Queues).
      8. - -
    8. Priority Queue tags and traits - (see Design::Priority - Queues::Traits, Interface::Data-Structure Tags and - Traits::Data-Structure Tags::Priority Queues, and - Interface::Data-Structure - Tags and Traits::Data-Structure Traits::Priority - Queues).
      9. -
    - - -

    Associative-Container Design - describes associative-container design.

    - -

    Priority-Queue Design describes - priority-queue design.

    -
    - - diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/different_underlying_dss.png b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/different_underlying_dss.png deleted file mode 100644 index adee1263600f811c4fa883a6ce11e6e840ea0eba..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 31858 zcmeFZWk6J4^fo$-qY~1gBHfK5Au+=UNGaVQB@NQuASEa*A>BQ6w*u1Ah=g=E3|;RT z{CWTPz8~+m8-5w)%sxBTUh7%UT5E5EQ%bR?$xE4+AW&I2)}{Vk;5(Ipq@oN63!Dg z=s^WSLx+RFcs{K~=#rp)Ul8QKClxfMR;pFm<#;~-J(^Q%)0O}C1q8OI^#LU$cII>b zdqK>{^v=J=ec>Sdw6n7$Qc+abAc(OX2#xy!5X^sLU7}O@tgPCbKlnR%JQNKwxRnTq z@b7F6QGKTlimX)aNk6Ozkr*&R?$J`M zSM2Z!*Ykvt@pGyB-Zl$GH4EREZ+1Vif-e6W9}js(DoXwI0U9BkQ7)zE1H7IS*}K2k z8N?j%mKx-nj}HeCFDkfygF3857|K5r2l@@9)&oo4j92_Ze4Bapz}haL6@o$K(_^zy zXTOT9{RN@&M83LVZ?h`$Z+!|$fJFSk3;dtXV&;dgE>6@+s?RfSV)gk{Mf4tl8GMKc z$KvBW9h8`)3-aySh$M>vEgc0kr)SU9b0d63U@wic%~GBJ5irYYwzTuL86Tr4KWat; z^f##WfWi|N@^ze!0=iS~)?yO|(Ul58awftN1dqzq4+24u98nOOvJdBWnH8bXcAMKN zcsejxlt7*TepgNpd*5e@VN6sjOa>oN&x|YYrbe&lX5dCkukeZv;g%m<2+%PXwr&jY zb9z*Rea*3Qu7VQEub9aVho#m}!M$L~dCI`ndy6tZ@Zzb^Ao4r1F@qX){DPyUAHHz#6tgM#{1pJ4dgRkwi$q)M1=c+Jf`~>eeYB3nIh=Ek^=id6J8(+ zb=(-On;Y1!nU#g%gzVY!mB}RXCJTGR6f#ekjA!Z{zn!#~a8Xh6iJw*;?ElZ3(je_R zJNm{_!JS$^53)z|i&h4SeAYi@KmoHvJuk_H&R(FmcFqXB+YcT_@1}d~`$8_%a3xj? z58Sma=>M7&hMvYvu3v-`z#dFo54HAwR^~ig}jAFHGnr07~)A4?mOYon{OSk5ZY?Jh+$Oc5YIH1J9 z0sn8EOj!oUjJs>-#P1Y#z19Y)ucicg2n$7z`Xp4%sMzE|`8qqLs)eP|{)(iK2yb`V zx7T$A|LmNv9N?d(bH5v z({=d+@{6R!yOn()h*TRih8^)X;t}TO+SAG)RW!p)S%gN_O6D6jFT$UX(MH81TUJF- zYb5-)#sKF&*d@8h%kwl+`+&dnIesU8zJe2f%3hb~m7vq?~a7M!c zx3g989z_7+2wXAI{6Uyz=ICi;kO<`u#y4vt0@@5O?{o4nxW7NIfbE=yPEkA=Jv2*& z9UTlQ!p_>u8I52tqeuoyl%Sgb3Ch#~jqVN|7xz+@+?=8QP3#;VCILL=9D@ixiJ9l9 zS@U~~_U-iM(Bb*X4g^V$_)-(ik=do% zS!$q0yA1emG(2*9$%~g0*=EAju!Tt^>bLlRyY?mLjwn+r{}OC@vK%F&Gpzq)L?y5i zaqL(6dc;e_qy2xg2*9WU<$dhCJbS8)0JlYd@GIH*kL#@G$+m;npX2Hp&$&C4Ho3oR zZ4E47J7ilWu(Ks&xgxiYo?J0l&9q(bC(h>hydifY`@?>|i`q;c?6X?@Z@Dqy5*GB` zC}%|AicGy;Pd%>k{B!z)4~85R-BF$_Yi55^(sHpBod|^yALgqSc}OoEE^~VGD||X( zUCGZ)Ik1(mNC@{rW+Kcy2qMB0hn3GR$8@h^bp7bZvVdN>>`aRE%hgqS`cu@8LSk?| z-bK<;qJSS|?!(Wm*`C$l@bI~F*^OZ<%|$0ll->upkB=}KBtp3Go6^d7`ik+u9L}0L z$U^{3%MW-2-_N(bid&JJTOAuNvCzQl`0u!*JcR?D4`>7Zeb>@0q&$xDOl_PW2_pT4 zVuf9PfC1nN8$MP@^K<6IIW=@R)Wbye76xn#xi9utq1$N$8qP9WpCZ$L@Sq6T0Ttj8 z+i=BvxDNbEn9-?p6|?*RrxZa6psqNq8zI`?pYr)_OtxNsDDLs?C|`k5Xm^(wUf5MI z(y9SKWq`+M7KR5S>5mFbQdt!wp?7EViZe_xDRl~F0U8Piw5G#z;g-xSu?M{+r}>nrC<)O1{zf19NC_bYGxWw*C4_KSWn7)XI)k#E=! zK%MvIzA3Qv_NORNy}*RJA8-9>a({S9U*!gPndvtj6t^B14l-f=cx9k*;3cMt0w#Uu8VMxAFyQr%=Hof(D8ciEBPyAb-?q_dDUkOdrr0ej2 zSLH&-Ve1dy)L8`ib4_lt`ESzVexgL-}U;lALe}djq>u_N8lAU zV2FppGo@|f-*)O&Q*gcZ{EBXRdUzh)0qA}!KuNm@N9Ve^H;_4eO=gEH{j|k51!`P; z?)RMGonWH8sYKy?oSqtFZXB~T`_7&%d95W*x0GLw8Y%kyo#TAXYdFvv`}4N<|!)1^!aN>AnM z^SvP9_t)hJ{4;x%W}D6<^FZQRqU4s^B{p+=>g_Q+kOxBXtLRsYEt5;?b>cCIE;KRgE1Q#dJK9+4bjPeeXuHoNq)jYZ_k{4wic#>Rxag;ZIOjcf za<$3D@wNmI#CToSZrPcpeLOzZN@2*(5$e?qE3Z_@VyX+JM*s3d;|my2i!{LK<#A0t zIc((;%(kTwT_2xYlW8Cj2&pUe;9>YVx5|qQsAoKmYp6Rx_^BjmwOi;{xM=;yMrr^d zA%NewJAc@sE@1(^*s5S1VQtU&gB(m3J^uwQ$S4ivT{z?%jU3jOyJFGE_ASlvpqV7h zR>Xg9d%uS0T0sK=Uh9crO?X8##8UnN#m;?EdQm1>y|nlUdno?b_0@$XrhMVO;o8ru zf!tPp9^xi+o`&Iqsp`jcc7D#!G&`+WI`_?p;q|Jk0j_aUBDYo{DdCfAPcsf9FL)EV z67k4xBJ1Oa11{l+5N_qRHwoUE3b{jfBi`F2Drme=LCZ>JthzCDfk=wRvO!)ugeyEiO_~FEN89vn zmSZ1t*^yYnRc81HjxZHH7UA)TkT#0^XTJ?bQjcuIAsyw6plzzS^9T6V;y#*jQP}SU zzKWo1%Lmwli2GTOq#VS)EXKbHet^xtzNjip`ekVF%>#R{^->9No}#c78qrV+Q%p#F za1y=P&I9tz#VrxRHo6QI!@IZUT?T0FyU6$5j3KHvg?X|(-GGY!V3Z_#)o_}Z2XRbC zzm<+U5VlGGVyWcZ%YGdv(t|aSuH)unHP7!q_~?9c@2nU0JU^)T?%7{6l?G^w12(PA zRBLN*+~(tW{ki4!+7ou>(hma1VnLxu_N2|*kV;P-XsCb2vE((^>Z_D1d&HzTVn!_c zu{lkE&)qHJF*0hrADkeKD`e_4C>@FNx@hPh0f;nv9uYQFG%=2C9BVn*;Jo|0!X$Gl zArU&n`Y1l#;q&E~<03u6J+4LbMBzbYXfI0T;8ZB;>93P&u^q8D4mB<)%2ueP)5?`T zV(wc^nBLld%5O#>Gqu4zCUvbiZTiBS9w8L)5|DB{2jCXbn^oSv^vsGyuc9zdH)GoH zJlaiD1sFkE%ywiQ4Lsxyxu8>#<7?4SYxAtA2|3)ZwW{zyBw>H;^qqd?T^xV-@2MC}sgDk2isQ7)b* zfVXMAgB!m~XL#r2#YZE$zi8}(3up{(Hjx?8tHD7jx1kZ`n&~a6c|Q&#)15E8nCIa) zr{NqABS~)I%#IrHoE?M{3S_?d6cDW>+NUU(gX01-p%|=%fLmyMKpEsHlxKawWmg044zv@V*vW)EznD{x~KT%_yDmDQ4{S@zO z*A8FgOkf)l<^8$KV~B8Xk;)6$MXw}D9&2!vpyr|DLOX_xw-rr#*I*dApgIxnZmh^Q zkV|_9bRA+#92oWr?wfk&K8_2HoteQJKtf#@C&OEE!cF>t#Z}hd$C%H;OD?-S=XD=y-L0^r>oKxi?NNA(L2N(0OMIks75O zDT30WKEQNLo11f2aKH&2MKRl~gg~^v?X_Lud2viD5yrhNiuaNC9tupf07ZDO?Wb=* zu=lmyerK8=gE}Y%_Vu%dRL?C!7y!RN7ECSRBQzzwDbS@p8sWY+>Mnj;m!To1cbmlW zeE>|1%K?)iR1Us5K|E(WVSBLDEgFPVMOtw9U2`M?`DCFfd}Y6K4z-E!EvjjlRjjIwfAslV;~#omA})0!FXj{k7VE5E9V} zctxV#p_UZKkzwbKP*n=r-LH4L|AGV>021IXA_ZQwS3X4d1)R3jH)8{HWs`^7P2LF` zT|C(Yl-3mhu>Q7zQLfKES>ccfS>CapW58DsMdb*w$~yq$bmhuFa>X1qYA~RF1im@( z7P43`sDp=v-ZuT36PWx!XYP}enJHDeT$LjKB%3Rm~p<=QqL3dvd-;6 z!&}Ix)x$~qu~IZXR3ePHnRm$kXk%={8mME8&Sb#!VC;SgB5AVlP+h3l)x!?|Ehw5i z9#fbP2Gx?gZP+J^r(n~_)yc_(lyyun`=$O(sNCE0rF(z}V8f!)D4r7I!{WS`{Q_T* z6;L-)KR_u-5`6=_P00X$D+o69UiL~){sP#Ua>lQWsm~xyu>w9#8tBl}p=B9yU@4{ZfS-zzRv@^*rU9T~?PpW>UUpEIM!};&!~GvX8T~{O ztq}RDzU=ew@8TBTK7RKU{E@me;<&BKo_dhZC;mP(j^ruAjSIrd?tNT@4K~Gpt0bvQ z?vrvf3C&j_kLpj1Budkl+eRMaj zhNxmv%`nt!OfWc9BQmB#XnlH)w8eVy;jDTaq2o@lN^P2gE7{mzKO~S4jh9p=K#j&h zVnX5uVHKU!|AQC3hz_U$J!w>tsXqsoodFnuIIe>36e2{3FJ4~ttrn-{^g_16^1O)% zRc_E&(Z5K-?MzU6ZRFfeKt4HO42k%ZC>CxNcpf`=#bp0C1_U5P12A=?Wt`9dESc&q z08yAdU(jxSBY+#Ia7Lr1aX{pe^!cMVqGEPV$;mbI@twTg1C(9JPyCh5^S z5Qh)k7n0@Tpqm8qoYZef$#Ub9AFOOW*S9kS6L2Wl(NW(2akx5Q{il&X$-c+~83tt3 zojXnWnOZaR!arQXNSLSq?#m(G?x7x;^A@alR?qBU;nL%ISLVoV&Xq9c)7{<~2p$K< zX*&T&*}+Q?@um78?KO~8N@huukI->-9e4g9zEF;CI`LYwCA!~aASLGB0nwXeI|f@+ z8VM-aRFg7#J$m=8sCcX^PRHI|S!3Y5$^GQGHsUo^gfLow{W-ST@AkAy){g;q03An_ za7a*5UyTLNriN0YdrK*cL)K%0nGiZ2NI9b(+Rs16EDlR4&qoDKIQmjSU_dy-()e&{ zWWDyL{L{a+om}P-_|<5?s-h?rFKg!jQxqrD$@R}R+KY8t{wPUfvX#(B?N zSi;H!NiSxzril>%REuh&?4~lw4EunBvQfB}edTy>Zi^`~{NiL+7^o+2Me5_YPk(>K zul%Fyeb5_+RRe#c&s?LOzNBcQlQM$-%YYU=Yv9XoxeKeW+(k+X1E%A5#1c;-IZzqvT~hb2qMbER9NprdT{t;JGK zfwIcCn3cN2$O;z9;A&a`5e|@E;@xE5o=91rO*vEw_7s4kcxC(YRO7+EPr+exp*NoM zIJ5zeyT&vKZ5;L-Bk`GDydi^NrU`W7yPXDPR3@B^=&Qm$%i#Cg3zP8S?Y$pBoV?mJloNU?1@6G0O2v?}npZqA z=<=lgHqTGDN{Du#5QI4EqHy%)wJZ#|$6liak#{{Q7X?W@QZY!yl&oL%c6EBRjP`v& zgTSV8RrcgA*fh4klczm1$oz;+C5V*kK9edW&(Y0#S?pw*{O0;Qlreu{k%HzuF~`xm zYM9g7PYFNMF-)!#I$NM;zJ@TQ`Q+L-jaP{1#$w9l@{O@P1r=KgJ=)19-&N1_`x*YD zY-jyV!-&G{g4Ke=FX2AN7P~#d(pcDW*1RjfNyO^6 z`?C{L2o??j*9N`BgD=k>Hp78G>(^KcSf!G4PhDhjrm z&q(_)U|*%e^ho`Ljpp?t393wn4`=B(Y&J#2?MH5*CqWRsT70`eCQe$9R1(}Z6NL}- zy{@36==f3nmwkH=Z9s=TO`1gR2e>bflfT*>`;~(}j8icyj{-OhM;d`oMfn{D?s`rM ziD1lYjN&J0bRi{8@iTcz=LaVRPyT+HsW!RX=xjUBkK{tIvpj=UeSs3OqNnB8X{YV*|&UkBAolQQ{{>V1Fl7u;flK$z*jRyCo^M?W`8 zjFDe{UD%EgoWn?LuptMudaPtuv)B%lQdc(j%)L_HnB(8V)f`ZOMY`!&B#2}AXa!Yr z?@E{$T@+@g+_QZQ;iA$@5Vv=m4r*eeDv%OR9#y;-)8_vY;8?&**jQ*pA|-8An4_e$ zOy5Qf$!QChntIMk_9=sKXijX2cbsF(f@lyf<+!f!&DlW9-gm4qmHRkkFB~_N{}6Z7 z|8GOPS&rRlax=7;_I!rdGM(Qw$luY| zUX^lq8kvPBDGUEbfo-6263`w&dg+G?bGg{A`L+9L<026I2@!qyMMk~!MlMf$LZdNJ z{D;;LVn&u;f6>QgY*WGcpZX~O373Gt+tEV!!IU({y zpOc?QQViSc_K3^bSFwlMuX9{2JZ#D1boY! z=~MV>MA&mxaP}V>Ucd$lH`wk}3< zVPgr#QDmj|B(Cj+^%d>2taTXX!4!e+)u%_K<8n(Wu|A8< z@{4L)_RHr^fB>pqZgk#j(`; zekCPZCFvKDO~fkUnecQWmjf1iOJjAtv;rjt!-=oN6^&>?PR`>q2Y!TjlpYRb6n#u@ znrGWqccQVTxPesj(O8p&sqnKbe%B*2SNpv!|INHQh=Ms^w+C|1x+&9hZ8>q;#Zm75n*=VGb`*_*;I{CoZ~7hhByC%EdP; zL&@zC{dGG9-NsWwc`qQ+KqBM(1~AeXvQrz%8jaJB=>hz|7D?Z%*Ws65ygPf)kgyv10a#VxTKxrQLG2`KnO&%DlzwaSD65AwS{i^-0TsXBk!C^^)B6lJ>5fny2-T zBpaYTB=r_h;@4pS~0fmNJQ6ujCT+jd|WBw3{aqEw#1LJUHz=^U&I3@yYVl zucjSGfjeD0SXbSo!8e~5MfjDC)lLEeTgB!EZY~FAZ>~>f-8K=&?RfMv%#$T~CkcVW zXL`aA2DqL$STdXiT0yj;;4f;R<(7cTR4V_v?zi?jJn`B+sjO(mNiMB;bff_9`l+iN z_Y{qfQ|%@6tBU+{p`sqji;2#imK!hV^ikTc_183q07jl<&?zvXOXs|TD|{%9Ued72 z-imp>t$Wk6ZdZ2h*uV)phzwtIuDiy)*~3Ld=3%Q>D15Lh+$w!*XENXHvX&lHN!Ews zcX<%kQWWC7>puHj+AU=*oto`%C?MKFASQv`w+@|3Yis+DzN*|aXfM&8&DKw$u|RNY zzT3Dq=M4TZ-$66&R{{4X+`Nj^c~AXM^VuQO9`F5pTzRR@v3>0@`b0qMzq4wz1|G9x zx~$m>7vfXib(vGzfld$Dmvb%|o98FJ-{wJcxb?~I~xJYR{7%1gOY|4-f3f)wAk%)(~fV$EO?jO}*O-*Vs1 z2B>qak67C!-t)_PAQHl{p!tvI(`1np3 z)@dq`u^Jr`%=@iM2`ydm4(|Fm(6cuIu>YG@a1xH1xe)2ea#AqHb{7_6o zl`C~F^prc)Tf>O4FPF{wTx%2k4_V88S<%L9+;iuk$ji{~r`d9QIY-Sl{*hcoTnsPu zsv!)lKFEZr`j9FWP`-vKxk2Df!fn^Y#^z)TTA9w^67w;V_TxOm?E zOJ9zC*T_R=w`mXV;(~n*gx=s>Aj8++^X*Oy$zDUdm>aC2a<4Yb-pL63WT%wF0rm)C zF?Y910wi3LvI&*OYa`0Uy=^^7)0>@|s z-!QD#=XJJe*f#EJO%3{=RgO0SqJ;@iL{2{W9{a6|r@B0YU#>V9PStlxltTcgv=T*2%Nk(K2+8Iow+b0{V}Z=)b$z5~gV-7bVt zySkxb!c)&j@4V$2X@VHh;;}`eOFL#eOqIyVjptU{Ou9)ZA|WoP{L6k~eA{SbAxUzvkSe zKvuRZdjicy$vw?8lE_wWY>yBdRWVwb5z`E#&4}2QtF`7mwb%HeWY1VfxD!SeS2A1U zd1KbHV#SMyUOjx-ir+Y-LyUR3mP9jE)vJ)q^cwc5b!@6j1Dz_)nI>Hc$~Ru3Te1tBZ}QwK>-0LVNbOIO zTN#rRa;*ani$YTbw>BF|gQ+Eg5ohfQ4oO-tgia|$i3E-bGG__j{+!R7o0E3uGjcgP z^)f5PsKk9{6S*8FxHGtTogPFnynF03(sFKPp+SG9C2?QqrAd5I@Ia^VwQZAkz-dRV@eEiz6Z>h@(*!+0dgGX4fQ^_7%zaQrE-?aPF0 zNc`UWwHS~0CcveFwN(C8v)N-r)kt#2g^2zTK(#o{De4osA92tB9xTY|4^oohVK5y@ zL4t-v7b7Jo&L%ox#&-gwbKnPUxWYxVmXe+f9-3M>7#VmrZj{tO!$Qxsa*3JomTP12c(&zuxdc}VRxsJhK8aU zRi~$dTy)Gn;zyA(uj6_qS;Ay9$5uEPk0Qa%8SQ* z#5dnIO*3$ImUnihOFzd)s~l`7@gS(8xF}7tR_#d>;TaT}iOUYxx?;0P%h@TFhow08 z3PrOcXIXbY5nP-a8C6huYK{$*-{X?16k<}PNp-D0_An=RS<~6|Q$D1QXpLemJbJDV!?3Ct{-nOs5@#f@;d%MtTq72ivSE^aPm|fN zXF++|2cBwHJOJKl?PM9+U0_QLu8eQ?ct&4MCl-sj4zaDI#Qyj-0(*;j`3D z4GFCLw4Yx`vk{>^c#-+3*4`IW)wNAtN`)K=j`*8S zIx9-uY2K$n-d(YBfgD(T%*#tglokz>1_|Ob5$=+&y;Vqgwq!Xg{}S$ST1*mn>RF$O z*Q&GEDv)-#>TS8~J=YniHYo(=$m;VYmo)a+J!WUfc{}nn)Y?O|(7Q@EcV(l~&D8B2 zaOv;eftZ3dG28cZ__i6VA5e=!Q{K-%9{QOSjw?F+0zI#PN;duIYGiCU#p6J#3YyHG zIcq-x-=IdtEsclCyQ3J=v*+VA?@LzCJrS;%Wjo6Zu*v3E*)10{yIwaJv#C!gNj+c? zqLd=uC1p|1m9HiaOra@%ypK)1t34RX0KRlyIP3vTqC#};2wX(A;^bqihD$<-Hr)2w z@_R}haFjeZd5InkDdCNjIBH617;mv~gZ_G-Y6|VzY1nO^vTo6iUDKn2j*iaJG{1D> zdE-&J?6*HeeUF&Z($3Ojcp762Hd(j7-V=>XMvtEb7UHsiG4oJBN1R>$en>vgMzehT zv)Ix#!x)0shNeUlP9@{aB<0d3b89nj^1$sQvQ3#*OZDXNta(JuAC}ivb;~51OYMw? z-|W>GvIbJ&JYN*lp5ww!({$Lk-~yY@1-s|k-UthZ#LHG8)0z@2Jh(Zgo7eh$_S3*u zGv23dl-EF1Saa@vRh%3AXZ~`PC6Lb(T7c|}f=(LuY@MxoUz=Q63}^&=G?XhkjSjEs zJr=sTJY0wlhb|uM>q{osfJyGCp{w3Zy6T$;Iq9x>l?|Ga5?eV&E)5fk9#13&L;2oc zsvWB{afhCpm3QuZD%-+1dBIOdnVg7;$(gx4Ic9gPP|GHe=spCPIXT7yPIxQuHhc<&>FE=yw zbJ9UJI2>{kkn#xl+NlI&wVz-n;IwC@SXv#^<=MerwY!naB*|$bB|8iKlvsz=<4F-Z zjjWA-M>P*=iGK87$dRZ!4(?(oap@t2ZXsRBxraG|5j9$J?#P8t&@k0_pYT;Eyc`eg zrYALW+Dj^x{WAP#1hihtvCyrD?TFG(R_bSe3ZCvmH_KmAoibx@A_k;~3~Z&Zq&Uaw zonu#DY(BgyZqc00LSDaP`Y-QLc!o(O=sa0L8rx^wi_4wBVPL4p=st?)zO^u?0XcU0 zK=V5d^4=$337@o7Rd<0|USPSXJ(;(vywAi)PAw&iGQmd_sr+iwQ2}4(#LAL&#DPFm z^cQ#A<#S><=IYwZalc=1LA_&Gg6x2**&zk7t?mctP-K)oF1X2gb9csPMw}&S#9FeK zVF5`c9}ApSlnlH=KmAD2tFe1XGPCbmrbhaS0P*JYBTXmOFtB7vV1nG-;%-bR=lNr% zl-wSk8H|ZVFLANek=@946>SX2pNDR3wgW@!=HYkWHt48ir#3>Hx^2=EeFWILcgFWI zy@!-=FY{Qp>f0sO9b*LFj>|@8b5zq%58c^PNa-q(9}bh zt1IEX_mdmhs?xvZpBF9FSFyetKqVpvNb|9gPngG5Qdr4i6bosgs}EG%**Q2@Kl8Zq ztHM(JfkaS2i)tRP4EOjB7jOtc062JjJY#E$v%a50vfiC7&G6b#PKkB8*|Xt|c~xii z`I;uO2WjPgygO^{VHocx$K}4nuwT|cOEwm6Do501I4lh>2a>|HU){)gM4VwEW6qup zmOb)^H>0>bS7V3GlE&eyp7=v4szI_ZzQLp83N^a1Sgkc_p=Dda3*`Y)ov=viM2o^8 zr>4ZPzjL%HCxp9M2~0{HNse7ayPfAq*FWDEGw3FZCMNo*_{*w0iyvv$!@ux`DhOIo zMS(Q-(`hE(g_>>Qr}jvIvu_yYM!M_hc4XjaPW`;5_0x3Lg`kiZhd-WOblx;e8ie1V zrt>Fk<$DZd^m?=H4I(2~?6cLgtRMMmVd|Vu4feZbLHr;19&+jwfiaGDS$~^le)sy; z7BDU3N4T+`-JQ_L1jvYpQgG`TeoklMwWEZm(xehbyEGez{l|YYsX!xZxK=;3AcpUh z$`oQBLBjNcZ#*N1DN-+JGN8$NQ4=rW`xJ>Wmj}I^YKerZ7f2TzAz}%a>__z;XXWzT z{dF7}VZSk`1Y14m8)U(f2SPn5a0DT_VL?{7`$q{ghaeX#swFEv9QXH2uYWLIW^!6# ze`%$7tVbJj&cwYePSl%1vr~`pDF3PD=4gm2T9%-QSGb7iNNVCa#mxmxDD?W|m6&@5 zoPkgV?KTS!+3Eh2!r;vLk$MP^kbGb3-C-9X28yC&NW{RM$xeO5S*5H^nc_PPt{|w} zpgT@?c3EyzprUY;Q5f}i;Mn@<7w&n8$E1BBDC)65AJg{`Oy-Pq_QrtyGNxoCnPE zwN34=Ga#E-=sX1{UyxUHn5DZ>KeA@TV{CCP%@GlM4unX>d*NXhDi05Xx!EeINAHYRUwAA!@U`JOoQ_>aW8v<%qJtKdhHZ=pPKsCTf*ukr5aw@&aB=c(# zE$5rOlB3qZB`-|7CRnbIQ4noON1I0A7`FQ79o>RoTUmX3prZ#wzMUO9?LM>d+g$K& z?U+87JDWVCSQyXQfti>)!K`ovyX?T#xI~NlpwgO~^=b3xnI`pb|6|&}c}I(he@%q8 zds<8tmsj0k&19=xH{W1d?~veplG4zJ{)s&8D|_k|M1J#{2Bs5U>%kood$7*#v60O^ zv4|03=tnSk8Ylh@{K+Qhxu6k+(ds9RsS%8oB*H@HlgB>_XcftVhulA7;#*0 z_&|DvQ!Ndr5=6@q2(rFeRwo$tGeaGWAMM8(U>6EX+FqZ3$FcsB$|ga3ntZCw9ymGw z^QlnH9+}%Ia5V8$PGHBAO)gh-|8iSuE=)E$49XXv!8_$`u^@Zwf7q=6x{LEsEd0s+ z=C|SxB)+zkF*eRbi@xw}eS%O*oj0)DT&oi#yfLW^emW;uVKVYCA%BJGOlH2?ys2U{s!hevPJ$RPS8kh*H1gK=z9tiBJ~Xz z1Bo-ffivbg}%B`J8FI>)e{w4sp9qVvX$!WcvPMB&L_hg#^rfHcO!!d@s z?#jxJJ1Tc)s7o32Tisw&V9JOI_DRVt?F%$vf6y^bPCJ|8-A5nBW26mDoEYQau4kt1 z=Fu}9YtnkThUS|*l6sb&;>TFxE5_ltZLT?H$s;+PE}I47sZG?F9h)zpQoV00dxl|} zeVY-%zJ4pBX}!vz{DR}Hz0`2yijzdANE{QB-J)yrAI7}~a)f8;Xa4R)c_Zd;ih*lUmr_4jvfYzIR)0I;KWtdKH*4}Hr+INr`XV!&D@dtF z4U}({W5zu_BH*8;&793~HKr(RGj3AITsdiQzvHZsersLAr_hcnZR(qok0tr=aAT_M zMwagOn~^oM&1wl>Cd5i|I`k?p);(sxeuBKQj7*ajj?kwwSTm60noNlf)AHjxvJ6T5 ze8TTPHIkz4QBDF^l@fFY!h~~U{RkcFRJW`izDct*l`rig#tY(HrW)4W6i~(Ol8I=H zRCO;#%KKcT3UR*K4Fr3t%|l(ClMSD?QV6G6|jO94tbK*s&twp)B$L4N<`(ewXg4vu~vy6 z$|a4k2(p`s)xxc%zPCH$ab(Q=n9lvZv(4|!WBuc`$Pj4Vez0RrMEHPbx~sL5u4&?B zqII)|u7fHnfztsT6JorV7nE=K_54YNgzgqvMqc=m!moUh`5&vsaxS3^(S8H6NCa4t z+v9*4U(=$=W6lM${fkEr9vn-I$m|V??!Il{mKpZ-#S$Sa_HjFn6pR|u3X;7hlF$7r#2C$&&u=j^3|tZ+Ej^iTgBKNC0<-^bElp#B>fi9{aCk77Gmr zyLc5Ylh9ES{BI4!(R;xG1gGbg)C%Q*ROb$Pi!$xW?f>6 zhogZ0j7fkx0Pz6F_Go>j?=ZiLeo&B$Mh{UWh&UK0h#fbB<3u|kz)8%jmDx*#It_bd zfq9%@Q}lu*3^a5$0`);YRwF#pk511?&{EMzgDjhH70C;mwR^FrSB9PojgJ+yBGJ>} zK5uc*&`$}}$N74>(6N_ZM>{BB_$Li!1k{kuelFmR;0nn(VZ_={PTz)O!Jr$xAFA@MB{(kZTu+yTwXZefwx zRY>1)TDA)?Bb}+Xg4NqQa)>ZieQ6FvPeb-G1D7{WdC9}cF z)w5vh016(P%&=+FDMo-Y^e6JQ%wt=hE(%{8Tovw~ziOHCotDl=)=U37C(1H+W%zWz zH6|Kh8H<@03Op(^JP_4=R30$r@ETcs08C3Y2%FXXVn5uwk&jZ&{oS{h|8$fI4XSf= z?sASalMv^XQF&)NSr{g&V0UE!@n9gguqt`=cno|rLsUJP?sgtT>2-R2v0LLy@pled ztSZvkzf|f~`A_=-kINXpo(M6LKcU2apPy5YhDeyC&|LHpST9MqS8O;e8ZLAoX$?y` zZeQ>Ng}jOa{$n2BYe<%HrAh)tNs7i=Kw{=|A&tl)Rn%T6&C>V^lN0X*- zPa@9d;K%C5SfPxo*;qVsWUb7hq#(-l0r*I&6AS80JeEgkyFAiRG73LeIFn?OK)@8#W3U5@AT@qEntpY*V}vr~u;T*5rNhbaseo@01lbjg zryT*0i6_2CFWhR7v$l> zE1MLY-gS{hG~AXQ?V9PPPloPFV4b1ChU3c!IqsZ$>G4?kQE09zanQ-T51KEopC=F+ zm&kFF$%8>NJ15(Go)%#vyO^5BmrW&<($QuvOqi~7H=gHN&9ppUxu)~Z;$(gnm-V50 z&dVg6UK?^P_g*QrevN86d4v2xJSsn5StI8p_s`EA66vpKEp&tA!S)OE*qs z504goKK%Yf`S1vY7Cd~sBLm@<(~toT&OwlU<)id_wL(kReQU7|EAl&VJs9o$cq=)z z`0-l;^OnU2?>Y|OSKh4H3QRq&`ts?SakvV1#huhnk7Y%PTWSU>l-a8vB)nBDdiea+6}n=rO9SyXM# zBWV<;#W7BH%Cw3lyLv#Gp9CtN)eV)5Z7<`jmCm%itCSMJVnh|E?|Sf7Mesr5i6ARc zaM7?ySVR3sWUj|o8HmDtZeyUtTZD_wbUA-ktL(yaI35-6`fE&uwVS>y%HbeTVcP%p zE#bkQA^CG&TPVbMuJ8~hQ8yfvR+mz6bi}GUdC8jM0LZc0vFCt_1`XX{r}ebRh=ZYv zgBL*LJiF7eO&QM}3qgXc*YBp%(wyxGZQ7jjRKGZ4HOGEb)xyT|bd&cdI8F=Sg+X>* zD7nCtwL~+v>3h`aZbJBBpQ-*xn7wZYj!erlnDV|+_Gu(}Xfmfp0=?NG`^rkrS3i)} z#*?HVZHT#>1vZ8_<<&Pm!?=)zpO9fo7!$YSPLw++Q0!of(;=WvO+JvX$ez_<3`ZS-_Pxt2vc=E zfW5bnzNCM@ASD&xR5Uv|0nQ7N8}j8r^bnDAYwYC?PlQomddlO%_NeB@&rD6)G-P6N zK4SK)0Zd=oxSEwbHB4(Hwn(SE&IP(`S2}(w9ZnPgG0qQ;uGWC`JYDbeMRduNIzZI0 zy)}eZziTp)-5CZ$i_A_WJYPAd+fwy<*b?8dj5dBvo@;#gC-~mYd^%#m;e5WM}`0RWgZkf^?a2qQ=w5}1rw4}_@QU8 zn%`VR@&5F)v?}+K`o$=zQ~P&dD?jpOIOFCc(@_sg3&ZbXGgteK^{X@or>RI{9l-2X zNumORozBa48BjQDVguY9xF>1QoEB!BiedB`C56=Jn+_)Gdbd%tK~HKt(bC!*pXy3; zUYI5p*Y`b9PHR1Uk~sIMPQ%av1Rl$e_QqYjCKu!bZ-@rHsLeld4-Bmk7)~ZGC)r) zHjxpeaqiZ=Z8eQra1`ehiLZ%NuUcy!*s2T)tNeAdFzD@;OWsD|9HB|e)+5R{VTh(* z!UTN`?x#>?zg}^*8sXd-QWb;xnLtU?kSuI`ec%FBgHdSJem~<}A%;JzSzjS6&6#m1 z$HL>_v$Eh{Efr8~Fh#BNHfu9;l~PRCUrneQi1Z>?5Vu9^?+`u^xX2~T3!81t+W(u}I^JyCE6bO(G9!3{DlzXkP zf94)IZV6;tP3A5>e#BWL>2sbc(^CJV(qL6)N9TkyzMRFK);yGF3K4Mhmm6Au3{5C~ z){-{vTe-_H&+@17>%`l_V@B2iio*>xjiEU22UV||gj;G!n;h9l*;;OJ;PWuCHSkxG zrb7c?FnBxceK?q1A*2$(@lB0Z;hh4GgkY-N@9|%qrYCzIDL11&X~xA`=Tx~Wg^0<< zD@*a#!kOETPnJMpgDaY^Db6ZrO_gmMHTj+-{nlJYmK26ik?NJTBHz^jpul$%nfR+2 zRD?;ku-<7FT}lhvA8u?=lHr+~bQ|4^Hl;8KY-k`MNEyEu&vPbl8A}a`toMJ)UHX#N zj7~6c#>U?DpsZv9W#;S@n0at*YopNrI9Tkkeem8DD6$88=db2;nWnCIS)=c6Rs8Ss z{%Ln|4vzXTxa(C>C3|ipvDdtpZYKg|>BICSyfhL56Xec=N6nC|i|Y7{$v&Je0D)wT zRO=>R7q;p}6CWjc{79O6Z6E!1RF=u%KE4>H!s~c#FN#eGnrTr`IMr04rki!~AZt8# zFD`i2LYPuyrs0N2#QCpDkcsAzr967|Mc?JZ-#|;Uqq1y9CyqA(LXS#l&#FsV292LlW4(UL%jz7XOJM7+y$7-!O<&5 zFffkt04f2^>U8I(DG=pdD3Nit+jGI7J@CULf*Q~oH$;b7qCzx6-~Z0aZE9-rsLI#- zYiZN~Vkw`*3>D zDnzsaTqFN-B-r@5F!$ayp8*QP0ickxGO#GP`)V=M-4&W%di;bL%ZB)}t}CxEKn-01 zjoKO%1>tSEXDtSM4Nw$}agr;td4!-{p=EMj_|Eweh$%l4#Bd?#0S*IBAoSo;QQ#S2 z)4_?QSo$#t6_rMpJrZakcrxJ|^n3_P;w=9isfl23xCZbMQxO*&+4-sQzd96^ zDAgmL@B#6+jhR|+2_RX7Lo#&&O0FaNF#u6Pa>J4kW^$J50vG5vcR){kCOJS34Fj4{ z_7Gx6BO5Xd1NhRLw?Fkdn1Bixh8C-)Q)5Si!GLB6?jFnle`F7_3qFSqg3ALmNbIAO z^X!Pfa=jP&Nu01%{8)GUqkAHI_L&GF{o!zw02tK0&&cGy0OkkCkk?7+Hv~Nx{AZpo z44za1&+FHS-D2Yp06CfyA%LWy@K5sQXW!+7se-2C9WZ?>ZVJ65;(F)eve#yH%jdAk>_B<@*ET?3Adx@gNA5li*yFYDM>?>5b_VHy{Y!wi#YCKFW8pDp>{`34)KU6XX z$OyFxGzyf`hFs>#MH55ybrb;c!4D8Fc7-lg0z2daOiY6}d8CXb0_t6zw;coIU=X}2 zW-R?_ArG~bUA|4CyjBqHunp50ST7s2h4?290ln)Lz;ty?vU` zHh$HI!neXeQ4H}!5RAW+4zUo{4c@^c;TjK0$m&EM@GS{DV8c`6@wGe)O2H|0b zPJ;fLnWI%czDHUnF`K_;pvA+oo->RUeDjifs4)~*h`Vn?(QHKsRNi>nsg##$I0}K; zP)DEp<)DU22qan&EseV)NWOlCu9q8|T{QT+`=Mcep1=GxNmEZSxu}BKh__ewEh)x=MdHDh z>4#&3px0O^{e)a*e*r(SbLN6ZPpDL;1oygiRRwwsa2`2%)J*6B9tThZ@{C)v1}~_i zD${}weICx*{X#;y1d3ut0aFG&T0QXm{L;}ggV?@RtlM0JLfk4B6F2LNKfk|kwp;BD zgab}Vmk_=!J}Ef~ctG*0H4)c^XWpALT7gS6)KbaP)F^J2&pFs!E{0;?qJW+sa;(Q= z0Uu7@zjJN>8gbFQzfYDA%mM%5iKtov3gYJ7z+3m`X*sjJeHJ{FQUdSJ{a6)w0Yo?! z6o)lX6YUMUI6NdbCsk_KP}Bxr0|sE?80TlJ3+)18Z`=egQ-b)a$|_#622N6q*I|>rCUiG#1Z^#UEpf+mG-+Z7@c$FVB zQ2Ak<*%Ko{Taw$W^2GmDIose>&d)AD9l>K0?jM- z{v5ddX&&t*yhAgd6Y#y`5HEpBy=q9z-{_V0Wh9&C3z(2%(6=lcicwHgDfiUk~s4m)gaw`f+W% zFxGr)zUit^q4KN}?n`|iOZ$%z3D&^vmrO#5HW=6#poP8?!?UB@{3o-zH@Ooy_Pszj z_``KIi)44wB$>7Y5OFcUkMHr7jX(+bFI&&o#u#zrOy>==O_ zEj4!sLDRL*cU5yYtu1KAS@t_~k9w|5wd2Wg_sMa#Ll;Qdeg^>1HOg)xI`?$1v~WtT zyLa~|ILLT#wEYRez%^cYlt%j=;Jd0HB})tH3pz}eXnbm-2!FkTc)|}%Z+N!abR8M9;D)04tiOm z)Xg%jyk8N@luE41uvxKT3q=khpQKdY*RS%w_Ju~!{!XjoFSWOo23knu5D7$418i{| z#5;>FJHqv{J2}pCQ6fL@+qLMcY-5^WAv_XIiztJakyP9L(qkvvpCP*zFYCw_Kzq5|NsrQ# ztJ1o|JQXsrohXEkCYPHUdOgKk*)2RaNJdRYwj(hsYsn4P(ByYW#}{xk)V%c~Jvy+>4f69_jEbQfZ_Stcf#I+sj>G(CN%t zRYp6&dyqsZ`__YI+3A;gR`#$|?0TDVfbZ#ImV^v_WVyyJGruR<#D+2~Lb zITq=Nd-s$(%IPIavLgTp4tZV6GmD5|6Fc1z^wrrSuARS~wG(z=^yfDazuaj$-F$KC z{O*eX8aDe6Hvz5BuS(Yk9p)ClHw?d~v>37SP_Or@5>F2?y5@M&ktH7+iyCnnbo7%z zCjo~mGm^Dj!3oNk%A{4N;S&Mh{LSLh(5Yb>H&@%HdjD&{V zr3Oo$C>Z*3lZG|+covW3#&37r!2D8L{){#TmMH%!uh+QamfQPZ`IJEpd7-=vT>Fgy zhu^AATNKYj=O|{K2z6wEH1hNW$k!bL4WP=e+zIt#UD(k=z<7;+dv!DpcbHOPZj9_w zZ2Ty4PSXyH>&EM8@N=6+uQ1u=k?Eh#ujnfL7r|5oc5h5I@VGa~1I~Rfpb!cIlL%u0 zpT7LFq5xc(hW|GZMXzss6rFM2ypu$F7I zYMZMDR5aiZ%%*=6vL1E0d$;J`NO=Lh$*acPnkwA0(OAJ(nZ8OvX*L7M1V_y+9oJ-x zL3FDQYHh~Ujk&E#oAGvpEE|CBArWlpqY)u(D*JJax?{gA2AFjvkF_m?dMv#PbgxTl zI%*9zxG34Zd7lcY5ZzQ-uDU%yM0QTW@j(h55oZP}4-NXTEOXSH3Muj+@A@3`>iAgL zYi67i&r7Ryp06qfX(f`*yQ-U)<;dho8_-eiB~|W`D&J9LVO5 z`Xi)6bcHL`MPLMxn{rTeW9VTGHuPSy>Tglg4&>GFPl$V2lI)33K#m36W3R@Cn5VQ; zJS#Ia_`u|mpv7#g8jzf78|CG_QiT!o_{K<5Q04En(N|X&Ko5voU{5VS2|`l{G!EBW zZoWrJTr9<1u{CD2{ei8Y?kJ{LoDFhCI_I|@TK01i{!dp8g!+rkSQ>l}4Di8eaF^g; zxkb||@Vq$I~x+eZ}cXknj$c zdMB>+CviRs6`xy1s=d5cc>?Hy1yg3cy8h0#2F}jTeHJHpKALT&=Duf2@h>8GAWM^* zRfANjuE%YNI&@T3S2!8gnkOvPA`>#y*%E;t2Tft#6}bg>V8MbY7~}Z?!^I-$<0XEn zrTl!?0GqJ339yrH7xSM7AIvUO)$YAv{=BSBBCXdiZG}R(9KOGB`69rFRctYIIb7TP zJn*=BpX^5E^$?hD#4W#T&#MM4W(=4a`x~paT=mX}g4%UjJEQPv0^h*<7l*q|^lLY3%N9Ls?)i7{6>Ao>l zo;t9>9Mi5lz80^!<8p223g#7ynJe>y$~)V*J~IQ`Y6<9Phg@t@SwN2#3by%Y+bg4esP7{cy7^E~@fF;Vg`OQ?)36ip*!7PTB8R?$7 z4_nB#omOfiN*tc1f@#M;c&oeefj30*>kiLQ2|;V+s;&>|MemNQKaxbt3N(0!s2nHd zE6Fe2!g)SO;l4c&Pa>PX*jK0LYiwt4mMLV+VxC5hDHlI}^86g%KOX}3g?tI+jW0)R zg99U!M%LC(r4YSDPFB{N6++TKkKk;%fhLp69JmVB(YBT}TbN0y>CfnDBWZHJAtx?- zF}pFtV9Fb6#c%bT9oc-`hf1q76ViGR{lL3|^dhl(FA8HK5p?J;@qe5~;hu}l@0U-B zu&gGLH_DwS8|q{6G5!WoS%l;^FllG_M^&@)_aTjZi+Z43cF#51T{#%c(>x6%FmB$8pcj(iI@^$#Li@k3*xPlfIpWNbkk8{+eEeyJ_j>9)P zlkJ?z&FOjRM^-$e4NR}@-3nZO)#@Gdw6#kLXLwj{?WCE~;8Jbu{3==}jjZ9*EuR>W z`n)<6P754$dWntv!psEsAl220%q#jNsS*=wE+qHLXnNNS0`y|r^nHwT4nzkhd}CG1 zr77}18XIf|Pf9-(HZ!AXF%>&WS$Xo?`ez^SP(4RSg>qGci{FbZti5q{q6!3qU$~Na zUMMNyMA&M_kK8)E?J;TA0;~())xiw*oB#^#w88{GL3JMz9cox4@ai$<2ymyUbk#f8 zX+;Q?%Qm`lvczOgzVEtazwTIbI%Y0^#1D#3i6ht1eIj%=`7t+=hZN`+2EFc|rJRJd(K4r|#N0Xe@(6YEz`~6`lw2y(4}FN=EPS?(Y7W$(%Xmw(>Wm zbP>Z%lOM&*_r>2Rk$y^_$Vss!Em4kb9Jx~KHG|`QSE=}L+HaqIt-_h-Dw(1n29*!; zA0bZBsKmzR!O4@i7$kI55cYVh@YJZI!QYvPj{057M9!YAitdbJamDJ1_F*BAW$*j>|OatSfT4$mfni7G+TEWFe=6zcd6Iyg!Ulo6 zL0TUEIZfUOsm2ec60n#T@}|^%frA0b7iTMolFRq6kAsTH#ts{ zyg#k)rW8`G)QT3kkd=S|74y#)r&L9G1@TdEwH9LS6tj3IzJrAyGtNN}L}-HKwLp2b z&;Tq)0?pjB&XT#hVQsOe7PYAY&RM`m2!Tt3{QQ$GdvzeCQV5AY9)3oO_6Fe?79jP& zpfKBi&D41??Fu1`8qUfDUj6R_|4az~e^nICW%p0r5#UA}yo(XQUjg9lU7b}}C#$6I z_TKs=-eY#^z~Er3ar81F&^-WT>SDch)Mw4?(I)3vo6@>y zEY~tPc}(7UnFAsr;m{b6Dm7v0v!B$7gWBii%uWEfoQakzCPkfW05|TQd;Y7K`^PTe zfVBYdQ4v;d8pZO0PamJ~_U6ctJ_aY+|C}g;ZL7cY{@iIkbAk#F`g58p`<7?p7jP@f zL?HO>+@19b1pJY6y**o<%{fdUSPJg$5T&W7h1?}2b8+A=)+Mi|WGTRojId;~7 z2}cTHLC2WCTJ45ANY~oo_V`UQQBodzj^nL!g>xS=|4fBpmrzTS z%d&^uZ)t$nL6%Jp46^gtp(>9#@~rrXc>N8_TZ|le1w;a9>2-apL|EUX@3I>0@elA5gCE^1` zaw5_Ix#TFzC1@gYQ9yaMPD!0t76hYMIO?bdT({_S0W?;I+$y(Q@nNWoATQT(%IARj z+XfeCId8odAXm8QJ0&GiS1z{*w5(Z`f1=f+rMwBa9&6@E&e`b82XK*d_ZwWezrUfM z!M^SV%p$PdL(eY<;0%Vm4(?xNjgsOuvs13lBzB@ksjj-=FQKq)mFsAl=afF~=U1ZH zZHYR$1pSYH4hT|mi->U=xd)}j<>6Dy6_1^Hy}{1bKgf*^bs8p!Ie3yC>($RoQXYN4 z)V^bEoJMOz7a{m&+$Ony=$v%Ty_MxUrJpVSgD%@GN?gU7Q^D$md{@~;atAe%Z8fOc zH4l#XxyWIcfx#7GFw{vBAa#gZN>%Ouy?akPe8yG3kazxft?vHuoV5b-=|{L5Qbs;N zC}NIkzPw`V5u_<{E^S;GD2)rPF8isbtyvtF*%}5E1r!Av@Ullqd20jxg4x&gsR`xt zfL8`?C*5aG`=V@_Z|{A$V1NN)Lm~0&g%757TdEJ>bJBP7vHf|@MWzom36|x zN2p`E`>e3?R&=&WQjen5+yc^4&sfNprB9({EmFS|J?X%S&G&8t>`Qr1VATe-CwZn*wh#6oc#dA zf7mY7^;tk7;4{H3l!h{SaM1W13*kw`4F3U>+26})s@4o zUs^nZC-RlAvhygfMnB$fF4YA$14U)Z*&&Lkm^ouQzVfWryh6kGfV*`gA|Z}#I}0Ye zx`0y*;TUQ47*%Q5H>mDRaKHvUihI*qkG1YE?_)}5@d|O#&s1R*DXux#%Od0wnXAC9 z9pG+3s8N=TVB(zI=4_&mLTy%X9P;wtG--HsFQ`Y~u==1Z%T0k{oTZQVNu3-(2ua4eQq-^}$poBbrkK2kakG0jR&sug3lF2Xl zToDOaI9c#*n|zp?W$=)@`HDMh-ddpKO)dsl2?%!)BEPK@7f6cx2K#zT>Ud-bXwrPw zf(EnGgBa&Nf8D{L7~!yKUK`! z3m0E;jJb(Z8hW{)^!mD?u8mOOs%UgINk%N?!CpyU1OgcWRtU6OR`zqSDXmJapo2Mk zsY-TXgs9kSGqmf$lldQ#lY08PTS|eE=&0A^0g{(^2iVZyW*~HH=d0arIPzNoDMPYM zX2deTS))U$x)aKRxY{c6z(Fcq*7n;gfpCR^aF6J>TFlRmEJyRMB@VOm^0gdZ-OjLPU6UBKalcCzxe6jTrxEVL+xaM~-POiQOeLVQZ4vU`= zN;I;1lrRE2DwImxcSn(Ld1#?wU=u|in?8INItrFb{lE!?RI0V4`8z2?{+B+`^@s58 W6yvb$9jrYB{8LfTl&_Js4E=xd(ty4I diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/direct_mask_range_hashing.html b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/direct_mask_range_hashing.html deleted file mode 100644 index 19f8621c2..000000000 --- a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/direct_mask_range_hashing.html +++ /dev/null @@ -1,167 +0,0 @@ - - - - - - - direct_mask_range_hashing Interface - - - - -
    -

    direct_mask_range_hashing Interface

    - -

    A mask range-hashing class (uses a bit-mask).

    - -

    Defined in: hash_policy.hpp

    - -

    Template Parameters

    - - - - - - - - - - - - - - - - - -
    ParameterDescriptionDefault Value
    - 
    -typename Size_Type 
-
    -     		-

    Size type.

    -     		size_t
    - -

    Public Types and - Constants

    - -

    General Definitions

    - - - - - - - - - - - - - - - - - -
    TypeDefinitionDescription
    - 
    -size_type
-
    -     		- 
    -Size_Type
-
    -     		-

    Size type.

    -
    - -

    Public Methods

    - -

    Constructors, Destructor, and - Related

    - - - - - - - - - - - - - -
    MethodDescription
    - 
    -void
-  swap
-  (direct_mask_range_hashing &other)
-
    -     		-

    Swaps content.

    -
    - -

    Protected Methods

    - -

    Notification Methods

    - - - - - - - - - - - - - -
    MethodDescription
    - 
    -void 
-  notify_resized
-  (size_type size)
-
    -     		-

    Notifies the policy object that the container's size - has changed to size.

    -
    - -

    Operators.

    - - - - - - - - - - - - - -
    MethodDescription
    - 
    -inline size_type
-  operator()
-  (size_type hash) const
-
    -     		-

    Transforms the hash value hash into a ranged-hash value (using - a bit-mask).

    -
    -
    - - diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/direct_mod_range_hashing.html b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/direct_mod_range_hashing.html deleted file mode 100644 index f3f9295d4..000000000 --- a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/direct_mod_range_hashing.html +++ /dev/null @@ -1,144 +0,0 @@ - - - - - - - direct_mod_range_hashing Interface - - - - -
    -

    direct_mod_range_hashing Interface

    - -

    A mod range-hashing class (uses the modulo function).

    - -

    Defined in: hash_policy.hpp

    - -

    Template Parameters

    - - - - - - - - - - - - - - - - - -
    ParameterDescriptionDefault Value
    - 
    -typename Size_Type 
-
    -     		-

    Size type.

    -     		size_t
    - -

    Public Types and - Constants

    - -

    General Definitions

    - - - - - - - - - - - - - - - - - -
    TypeDefinitionDescription
    - 
    -size_type
-
    -     		- 
    -Size_Type
-
    -     		-

    Size type.

    -
    - -

    Public Methods

    - -

    Constructors, Destructor, and - Related

    - - - - - - - - - - - - - -
    MethodDescription
    - 
    -void
-  swap
-  (direct_mod_range_hashing &other)
-
    -     		-

    Swaps content.

    -
    - -

    Protected Methods

    - -

    Notification Methods

    - -

    Operators.

    - - - - - - - - - - - - - -
    MethodDescription
    - 
    -inline size_type
-  operator()
-  (size_type hash) const
-
    -     		-

    Transforms the hash value hash into a ranged-hash value (using - a modulo operation).

    -
    -
    - - diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/disclaimer.html b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/disclaimer.html deleted file mode 100644 index 681af4edf..000000000 --- a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/disclaimer.html +++ /dev/null @@ -1,34 +0,0 @@ - - - - - - - What, me worry? - - - - -
    -

    Disclaimer and Copyright

    - -

    Revised 16 February, 2004

    © Copyright Ami Tavory and - Vladimir Dreizin, IBM-HRL, 2004, and Benjamin Kosnik, Red Hat, - 2004. - -

    Permission to use, copy, modify, sell, and distribute this - software is hereby granted without fee, provided that the above - copyright notice appears in all copies, and that both that - copyright notice and this permission notice appear in - supporting documentation.

    - -

    None of the above authors, nor IBM Haifa Research - Laboratories, Red Hat, or both, make any representation about - the suitability of this software for any purpose. It is - provided "as is" without express or implied warranty.

    -
    - - diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/ds_gen.html b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/ds_gen.html deleted file mode 100644 index ec99c4d5f..000000000 --- a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/ds_gen.html +++ /dev/null @@ -1,344 +0,0 @@ - - - - - - - Data-Structure Genericity - - - - -
    -

    Data-Structure Genericity

    - -

    The Basic Problem

    - -

    The design attempts to address the following problem. When - writing a function manipulating a generic container object, - what is the behavior of the object? E.g., suppose one - writes

    - 
    -template<typename Cntnr>
-void
-some_op_sequence(Cntnr &r_container)
-{
-    ...
-}
-
    then one needs to address the following questions in the body -of some_op_sequence: - -
      -
    1. Which types and methods does Cntnr support? - Containers based on hash tables can be queries for the - hash-functor type and object; this is meaningless for - tree-based containers. Containers based on trees can be - split, joined, or can erase iterators and return the - following iterator; this cannot be done by hash-based - containers.
      2. - -
    2. What are the guarantees of Cntnr? A container - based on a probing hash-table invalidates all iterators when - it is modified; this is not the case for containers based on - node-based trees. Containers based on a node-based tree can - be split or joined without exceptions; this is not the case - for containers based on vector-based trees.
      3. - -
    3. How does the container maintain its elements? Tree-based - and Trie-based containers store elements by key order; - others, typically, do not. A container based on a splay trees - or lists with update policies "cache" "frequently accessed" - elements; containers based on most other underlying - data structures do not.
      4. -
    - -

    The remainder of this section deals with these issues.

    - -

    Container - Hierarchy

    - -

    Figure Container class hierarchy shows the - container hierarchy.

    - -
    -
    - -
    Container class hierarchy.
    - -
      -
    1. container_base is an - abstract base class for associative containers.
      2. - -
    2. Tree-Like-Based Associative-Containers: - -
        -
      1. basic_tree - is an abstract base class for tree-like-based - associative-containers
        2. - -
      2. tree - is a concrete base class for tree-based - associative-containers
        3. - -
      3. trie - is a concrete base class trie-based - associative-containers
        4. -
      -
      3. - -
    3. Hash-Based Associative-Containers: - -
        -
      1. basic_hash_table - is an abstract base class for hash-based - associative-containers
        2. - -
      2. cc_hash_table - is a concrete collision-chaining hash-based - associative-containers
        3. - -
      3. gp_hash_table - is a concrete (general) probing hash-based - associative-containers
        4. -
      -
      4. - -
    4. List-Based Associative-Containers: - -
        -
      1. list_update - - list-based update-policy associative container
        2. -
      -
      5. -
    - -

    The hierarchy is composed naturally so that commonality is - captured by base classes. Thus operator[] is - defined container_base, since - all containers support it. Conversely split is defined - in basic_tree, - since only tree-like containers support it. Data-Structure Tags and Traits discusses how - to query which types and methods each container supports.

    - -

    Data-Structure Tags and - Traits

    - -

    Tags and traits are very useful for manipulating generic - types. For example, if It is an iterator class, then - typename It::iterator_category or - typename - std::iterator_traits<It>::iterator_category will - yield its category, and typename - std::iterator_traits<It>::value_type will yield its - value type.

    - -

    pb_ds contains a tag hierarchy corresponding to the - hierarchy in Figure Class hierarchy. The tag - hierarchy is shown in Figure Data-structure tag class hierarchy.

    - -
    no image
    - -
    Data-structure tag class hierarchy.
    - -

    container_base - publicly defines container_category as one of the classes in - Figure Data-structure tag class - hierarchy. Given any container Cntnr, the tag of - the underlying data structure can be found via - typename Cntnr::container_category.

    - -

    Additionally, a traits mechanism can be used to query a - container type for its attributes. Given any container - Cntnr, then __gnu_pbds::container_traits<Cntnr> - is a traits class identifying the properties of the - container.

    - -

    To find if a container can throw when a key is erased (which - is true for vector-based trees, for example), one can - use

    container_traits<Cntnr>::erase_can_throw, - for example. - -

    Some of the definitions in container_traits are - dependent on other definitions. E.g., if container_traits<Cntnr>::order_preserving - is true (which is the case for containers based - on trees and tries), then the container can be split or joined; - in this case, container_traits<Cntnr>::split_join_can_throw - indicates whether splits or joins can throw exceptions (which - is true for vector-based trees); otherwise container_traits<Cntnr>::split_join_can_throw - will yield a compilation error. (This is somewhat similar to a - compile-time version of the COM model [mscom]).

    - -

    Point-Type and - Range-Type Methods and Iterators

    - -

    Iterators in - Unordered Container Types

    - -

    pb_ds differentiates between two types of methods - and iterators: point-type methods and iterators, and range-type - methods and iterators (see Motivation::Associative - Containers::Differentiating between Iterator Types and - Tutorial::Associative - Containers::Point-Type and Range-Type Methods and - Iterators). Each associative container's interface includes - the methods:

    - 
    -const_point_iterator
-find(const_key_reference r_key) const;                
-
-point_iterator
-find(const_key_reference r_key);         
-    
-std::pair<point_iterator,bool>
-insert(const_reference r_val);
-
    - -

    The relationship between these iterator types varies between - container types. Figure Point-type and range-type iterators-A - shows the most general invariant between point-type and - range-type iterators: iterator, e.g., can - always be converted to point_iterator. Figure Point-type and range-type iterators-B - shows invariants for order-preserving containers: point-type - iterators are synonymous with range-type iterators. - Orthogonally, Figure Point-type - and range-type iterators-C shows invariants for "set" - containers: iterators are synonymous with const iterators.

    - -
    -
    - -
    Point-type and range-type iterators.
    - -

    Note that point-type iterators in self-organizing containers - (e.g., hash-based associative containers) lack movement - operators, such as operator++ - in fact, this - is the reason why pb_ds differentiates from the STL's - design on this point.

    - -

    Typically, one can determine an iterator's movement - capabilities in the STL using - std::iterator_traits<It>iterator_category, which - is a struct indicating the iterator's movement - capabilities. Unfortunately, none of the STL's predefined - categories reflect a pointer's not having any movement - capabilities whatsoever. Consequently, pb_ds adds a - type trivial_iterator_tag - (whose name is taken from a concept in [sgi_stl]), which is the category - of iterators with no movement capabilities. All other STL tags, - such as forward_iterator_tag retain their common - use.

    - -

    Invalidation - Guarantees

    - -

    Motivation::Associative - Containers::Differentiating between Iterator - Types::Invalidation Guarantees posed a problem. Given three - different types of associative containers, a modifying - operation (in that example, erase) invalidated - iterators in three different ways: the iterator of one - container remained completely valid - it could be de-referenced - and incremented; the iterator of a different container could - not even be de-referenced; the iterator of the third container - could be de-referenced, but its "next" iterator changed - unpredictably.

    - -

    Distinguishing between find and range types allows - fine-grained invalidation guarantees, because these questions - correspond exactly to the question of whether point-type - iterators and range-type iterators are valid. Invalidation guarantees class - hierarchy shows tags corresponding to different types of - invalidation guarantees.

    - -
    no image
    - -
    Invalidation guarantees class hierarchy.
    - -
      -
    1. basic_invalidation_guarantee - corresponds to a basic guarantee that a point-type iterator, - a found pointer, or a found reference, remains valid as long - as the container object is not modified.
      2. - -
    2. point_invalidation_guarantee - corresponds to a guarantee that a point-type iterator, a - found pointer, or a found reference, remains valid even if - the container object is modified.
      3. - -
    3. range_invalidation_guarantee - corresponds to a guarantee that a range-type iterator remains - valid even if the container object is modified.
      4. -
    - -

    As shown in Tutorial::Associative - Containers::Point-Type and Range-Type Methods and - Iterators, to find the invalidation guarantee of a - container, one can use

    - 
    -typename container_traits<Cntnr>::invalidation_guarantee
-
    - -

    which is one of the classes in Figure Invalidation guarantees class - hierarchy.

    - -

    Note that this hierarchy corresponds to the logic it - represents: if a container has range-invalidation guarantees, - then it must also have find invalidation guarantees; - correspondingly, its invalidation guarantee (in this case - range_invalidation_guarantee) - can be cast to its base class (in this case point_invalidation_guarantee). - This means that this this hierarchy can be used easily using - standard metaprogramming techniques, by specializing on the - type of invalidation_guarantee.

    - -

    (These types of problems were addressed, in a more general - setting, in [meyers96more] - Item 2. In - our opinion, an invalidation-guarantee hierarchy would solve - these problems in all container types - not just associative - containers.)

    -
    - - diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/embedded_lists_1.png b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/embedded_lists_1.png deleted file mode 100644 index 9470a65b56852600adf6f89b495c50ae45e50d75..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 16350 zcmb_@by!th(>DUrB}jKm!=Xh=P#UBTB_MD>knT9Ng!B=lOArC!&?zn5Aq~>f-3{MH zZ++hT`QAUiKfdeQ*WsMa-m_-bnl&@)H!~qGlx46n$S@EP5U}NBrPUA+khp>GS7?a9 zCv)x?74YYtqngZ9gu;G`b>Ii`Ye^+Z1cZ_(%qye&z;7B8Sv4gD1P>+z1m6GzgbU!7 z?-~MvGeBkI6#~NJ1OxwS3PD`vG?}aC>LOHS0c*|aI59mU7cj5J~ch_%kP8)O9 zWss#M{#+lQA)4puAeR}ry842VYUVRn}IvT{k*ET+k#xlM!jq^XZ zx?wCR|AVeIVmGW}`<|%bpOIc|q07P|ywK48jwLaT%+NV?;+w|xhYI%zaHm}i8Ts$n zAFUDbA=Xfd0pfcP@P1t+P~eUUH6r3)b_NCRp_f*Qeq0UvLpod(xKo0A@80iMfKT&e zUu2zWs=>p*VzsCFB2P{P`y%{DawQ3WxHazD`Clx#zCCoIE0w=UI2!G$QCIBX98p)&K&!jd@0C&hQ@$eA-zEufK#{b*&NT{UW_6g3V zJaIo*8~P-E)tHV-?YVchzhvlrZmMDle-rXsYKbR+%x*3JGZeZL0m|Lel=QC-GduU-8>3IbZlhC?T72ijeAywbgVV z<+1PpQXRgY*ZJ)Ku)W3(4AEcHpT5A*)ESy83at#cVCV%G85EHAg5XXOzX(d~0-_zy zwqa}H@t+*@aA|pvd;w*1DPUB~Gj1CHp+w~8jZr#o0NvJVywI$AGGt+y_=Q1`NHuUc zN5yuslyUL-3>_jEd5!ZxTzB65K6n{eB@MbkDaq$PkFBT5O?%?5m#A-ZTb~klJa|PY zu5kQ`IN-hR(q>P!%qHgpS!M}Co~y(7#w*5pNbD~~Sw=s40lWUmEUr^!Ln*p7tRk*Y z6;K$?1k26EKYm$0S)+=Kc<%xO1R;&^x!yE%qPcn(btey>+{a-5@SWImc@OQIA%^aK zPa?Lam4S5XR4UBD38qhHExr4Yd|g4QR}!%O7sph6uyJ)jTMm#fm^!^Lr{{vYO zZ`pjtd>AkimVuOt65Eh zDyKe&r?1?)qo3tEQR?muhKd}$ctE0uSdR~Jf-9=8R6ShusVHw8 zn~$T(CoICS^#$Zu%80osy=QWS2FOvuI7lr?R7p+VITm2}CT8MdF`1r47@4Ks^T!8+ zck+0CXoxLSZ0z1I8Xw$KuL34mnqY08daZ3cuplv?AYvsMWTNNE2P+BA33@0+YOmb|ei86r7TC^)e^Ge zVFyk#Z2wrIg1ap|b3awkH_(H9JE{-`dQ_IEbF>X;$!}BOApzJ5RAsA1j3I?f;m+tI zl3VLWoYFsbYl&Wq8tl~$9+r4c$&+Ig(MO~sNdU|lHc4P;Vv zW>gCE>uQV*y_p^>Rrcn7dd#Z+&p=5G040X)G;ua_cA|iY6o1If-7f9UuS$EXe*Bx6 ze@vMKnJ-tvnZHFxvF&~F6ifG?o$sH85pB=Zx}JqAaNew|_;edq+0NZu&fTVo_BQL+ zy6%d(A3&05YxMpZ?6D#sRZIWjtH+y7%IRXM=%9WwX1Vr;B*&Frqr>YxUX%9l_2Hag zpMfO)%`rXOWisyxRe>Mx$jB2l4qxa@{xQk?4`4L;=vxUyw1UCT!<;Khr@F0)OZFK8l;D_Gz?W)Q^Fp7ciW z_N|af2Z)JHN3nhPyr@;D%zJqF_l%_g{>yQLB-o7bU2(6jG>KX`7Adic=6$h3tnr^* zFd@e^`$UFcx-dur*u3@^t_PB)(%QM&o!&f3q@{*!;a5d=LAShijq z%v$qeV^WG%(lrVxn_7~<{q4BSLjbR(Fi-hJKsBI34=JR~<$QDfxAIg1Qd_xua1{*G zS+Q2*zn*PTKKbnl!s!5q6#C-yc2?m5ll|CrlLq#0p>L=GQM{kGXoqlzlzF3+ykWeP za7h|ibMe_YG`79Z+5DFTYk47e3v%=x7`m#S^#Rd>ct{zV`JMFuwEH6%@V*s`1)uFg zxTWCuuY9_4p0 zgwx(b2N^2Iqa7|s-RjcYuMDz)0K5_0Aec(rJB7X~ES>fNxCmEKA&THNEtZha z%m@)7)9-bm1{iTZ2c@KVo$W2i1sjDF*HjB?+c4UYxDP-kO7NjhIH{3SFCz5l&#Wwn(2WV zQhC&8taoLA9b`ACJKOJ|#_iJhCqxV91!h@xm-k)T6ZhyR9k@PcEn!>@Zd2tJWoCW4 zHBRf-r*pS}(=GGA9KOAI#6#3o(3yr$8};O%GeU6oY}?i+xieANaV3f0 z@?>WQy4Z@&xv4*zoQv0Gp=*3G05Fs0WU|6?ygyA8dUJKIs2*fT zYt;U(2RB_0>>X{hCU%dBQ3|2hhCQG)2%8*S_|kpn>uR*xXPJo#OJcRHFF9#X)vTt< zL*^w@-CV5NhN@~bYsENHp^78s*+Sbrz(lo2XTl5%rF`Q(&(Wh}S$5VQ6D88|J zUOrYmT-CFc`Ey2M>p=R=QO;M#)$D`^I~A zmeV7Y5kj)fNRb`4)l^rE5$%&4ugjAM;*4(#a(Y=cda^#Py0gmoe|kEBt)F*hLE{Y% z_@F6_4`ESaIxrX^QSf1%QOpbH;O5H)`;U!>onD>hgg@*lM6aD>Q2{eC@Zkw?4xj zZ<79EM1vSR02?a+A4300%YH(FLKmGS-+`g?c_n5Krgqx^mc3J^{|K4F4F|TGPAZ+m zRk02Hr{Z$4dF}C-o=WQD(Jy3Guiz-nC@4?SOW(gQ5VE4dDfle_{dC~+{g6;r)d8I` zY10bH`F@ezCvJPMq&?VwJaw`D=6`=^7s-00I`H)y8mm_{A85!)Cqr9M76;{JbzA*!GEBv2J%))1*|A}ryQEfnb)7jL3#OSWciT|B0uwV-n7Xq^KpNapNPP+X*0S<$3|gtruz-9$_k3ClS$VUXC~HKi6IN4-X6vO-J0dM2LaOuTwk}rwpb3 z{hp5eaK1|svJSsN&BZOV-LR5iNuy;A&C*s+E0@B>HYs*4CE1HuTJlK}!hvpB1Xi?t zo$v7oyhpj{t0s~{l{6!t9F6@z*vFr<9-9T2Ty@2AWg@5S`6r(p7`D{>4fls7uCz@n z;oYi1?4P?dYU9tDKop}pq&1IIGCpX(v)QHdi#PDFxIEboAq9amN{9-=Ms0h|eobz- zRYdsfe=BD%C$~`_ZGz^&H@*@BBY!9&8E7Wd#4XTJ7HlqB%J$7?rw5%LKJPn@vj)woD{N$RLE>2-2=DG7;fa{rg=| z+k!0O-;vpQSXt-#Ba!m8iV7dwcj@a@TJcP_!%N$0z7gDeNLZ7%5d={L7wT4oYMQ6z zEshYOm;T;ZL;t1M*Y_ou$2AS~c~E$VEJ{s-yi7HWmyjFI7Q>c%;^XIH!k407m{9v% z*)PSp9Qcu;k&~b?0(%BIVgR-~I68Za4gAEbtA;1i z<%JEr4vGJlp#fA!_P>bK(Y)h;Ozx4!LnNCs(?OX9&j~ckwGexa8_!pgF^SkG$}NTo zRG#qA^cZ;VKNH|s`oI9*x17;tr2f0_WB$GGN1)%tZ_ic6%;y|>IQYc9&3Y4f99I-? zcx-3uM4>0uX1K2NiyG*>0iQs+`1;~#Jpk`kB2;v*3CW3IrpS1hKS2~KFuA#y z9*9XCS@ScPLY4m@2}JyXr6XBXA5KiUD_hoM$En`miE1yI=ukIlqFL15{T1MNKxDUW zv7^AS(R(QKS=;yrmK?>;38yreCf}DWs7r@P5`~RfNJMI99S20KgZ&(hjs1PD)?~z+ zu~$Z8z~ z&bZE{Mo}}dg-{c*J7BB2UY*&?4@$?c6XzHw?Zhux;|H>Q^31Y`wa#Uy~ zm0D?!Aa5!4y7E(OIGu%(Dz(@qH2hq&JBS9KCL>!CW728_EirFdb%^|^aoz-i7g38V zJNozs&cV3UD~ooC-fC#tO3a@pV2$I+qFx2@g8j2wB?qy34BrE^yMHaYd92-9PMNPXD-m2vXQruR5&94glU=+$}ID?dUF}1hykw zsy~#6pR29f=X-&1OG3BL`Fr-Tj30AQ5DU=?HR_0VZq;HA_}21OA)zg}T8P;3q&+7w z*ZhnHAA*f!yJL@}X2r@cz?~hmuUQHg7I*hjGYB(q z2hq_P^QyCv2#wG%2~F4iB!T2u;1)~E7Ba3!5yw}n7cU2M?lGi?r)q@8s+z<^eu*}% z$B4v_C5r1h~=a+OCH72AMIF5m@lg!4N`zGP{;^9zh7uzE73PlhiuwYpAi8 zHEtO2hf?c}L&?$VCrzGB>(xV|Vqc4BL?Y`1r|_F^$g+TCW*B-lK2FIe(tp;b1haVO zsf{+hjMe^eya>nAdHIuMmQm6St?X;2?tA0&4GV4S{z?8PUkF*U&q5Bf0-jP-<++BG zA?u7L@H86u_flBY->>9sW2dKJhY!?u$EMBw(0n@b2?z{M$_;H=-8?j zW+eoTdZg-0tpnc{b0%6+Oo$>ymY4}JC@k9(&G-Y_*XZged8ZZ~v=nu@l<$ezFG_z! z3@>VKbaQXoE$v7sZCnI3uHGjVl@J;jyd7|(O#KNCwa`AE(;pgH}de+z$M|Tec*fM>Fnko}9w5%gb4F|K!N&6(qGtAL^ z&sPorKk5)@>rmcI2(y5_wU?i?R<;w~zSkdZw#yvaI~xM-g1mFNzI^(qad929{LCN0 zc=pZl#wZ6^7;5Nh97P!F=MflWqUk0r{6w@DjM{(x(n8u|y~?eOx&FDB!bj)fc3#Q2 zftd?FAzMu!wLHt{Jco4`XlL-S?jJ_NV!^kCC$o zIB3T*g<&RK>9@Rr3#wT`uEO6k^{nJIH~j!;*vSY4FSe!~5%F2n>!uW8oj}S0>}*^c zzUPR7y-&f)Fyn>BnWUnv5SpI+5(D{?MI+55_RlgTFHGt`7`N^7;v}&Zp6%!^e@o)BSX1Bgfxn$SO>eV;H8NCM@$}93LUJ3(yK0olb zmIRxa^JTT${^C}c*{uL7rbt~77XL{%ThX5B4{X67b{ivKUQmM{@irV7f7nKuBvkoO z9)rQXz5e4UQH-|~WTHcRU2=qTA=S zoqggx+_THsl2lN6@|F@u*7ig@LVI?jt%uP2v`n@3m%}QcKxqX)Ay-rJi5+whit6`Q z;S}N2#D<iG|q-dppKVxDf-7sut85LfNlk+Go9fKLkLu{~~XJfk!u=*kfPId_%K z(Fknu?%mmLKi-1Ng<$H2n~O~;XwE>#uD*NMmP8O%>roC?W)=^LFp2oA&+WB}*m=Ny z?A+ng^z_mrB5LdjBT5v_-_m9kpbN;}m1P<^lu-G9E9@n}LVkc*P+eo~h>zZfNU@u*jZS0Gr! zJcjj0vM9Jbi3X6YhMRfDyn#QF~$$(AA;m?UDgI^ zZxqsfrmd@nZewb@#w^@;8+b`U8pP55H|4&sv`6Nambvab=XCg~*gq9JLZjK}*7G;A zbYF@PT=Q2YX-vBaeh!^+9^alQp{FqC1&ezvOO3^7RajZ9XNj5S;-HtIT$G$J0*`N|!en zqBq}LU1>Yl5Pkimj4^Gl{u%=`qJ3__AJDIDeeFw@-yN(md1j6?G6BF6@|EB1NHM2v z>yO8Hh9F1s@bWckYS1@LEj!)}m2`vQi7h~4)iKTb=5KIKVlz9@irki6K%E?FsvPDO zqc204({e|mM2`lg>fU+eD-?Hpp`lNeQV)@6mv->-vJ4RApNXa%23L36rO^M zT1}D;rty+!4$PwDK2s1qwKRQ7Ul_Amm|s|v*JUdrj|kW;1r4l6gh%q_X>90)Z9Vu= z_vA)uIly&4Kb&=YSUvg&@1_ky7}$lDEcBL{ z4HVfMcWPYA8thWzu-vU>=*3@?zKV&^(Cwtj5=9D%S(=2VFqi}qq+>JTkSi-E<$vO7 zdflHQJhYxZSa+^iv++3V@rIgABD{>jI}^%NwG>esGH>Uiqp>kxVLYKJZVtXvF zC==+xDBt@;53pM2GkU`C+uHT)Wc*7Wv6`dG2SK%1IzlKyL)UPIL&xXx#`-8WGLK-i z3hcvK~3MVQPAoS#{s3?);08XTz$>H zR2q|b>llJ5orO*7`m~TGrEIL?);tsbFCUC(vp(kU5C~bcWPdw#=$@7@_E<9cK8u}m za7VPYZnP(hTB=(;5}nTWBtfIwi1tW4#L#AFn|HlyBqx9BD*+?~Y5=jje9ZWo|Fh-s z^EK8ao_0tHbC;dk;%uIoaa7lbLMbsOQu~%KYybsh+(5Vd_^yX}3;o2v`X1C)IVggz zaa)pBe(tS9aX|15JqTxqqcYzcbPmRJ;eR+;PLsc7&s6Bmv2 z1aR5##SXoCMS~YgD5(+?z$ya4Q)E}za-n`L6>xyp(sTr9j*TYe5@~sNhw}_2G0hd$ zF2^(s5JhwDFc76H9)L62y1p}GfPy_0T^x8wm5{6fMShlD<&kJ^p3n8!7cfwFL0$(0 z`f0PUHqy;Sli$@J>+yPD3xn-ew~D(7{%dUQM@Z=goW+=fzL%Snm4B$yA;i7bX#rmGqsyG;>hDt>0c_4$tWGYq zz`|uzUe)w?8AcqO1fI!!yi-V&PkL?sMm}BJSqg+duMp31&_Dtkhp4*CcC$U?}^wq>pRz_dX(j0wQw4|MUCgs0|RNm zDw|S)pfCcgp>smW-cv`|4Tp~26vFuFvErH$T81D?<7>Un2+h%I#s!hO@CyJk+8E4` zVmy@Cl5^ay827%~@4(qq3zh>sbYa+R<(2MCF@o>y*u6v$upu;+Y>zR#*>5AeW1TN& zVt=U|j;KHq{Hm6*M|F)luc3?|Y}x3Kg;+2GyLgH_wS9v*!TRV7qFre=_WTX}IP_E6Ij6g@cKEg4Z&^?6NiiIOS>{Bqq4R zVG23Lr}SHRZhOK2X0Dw9;%O0K_x;76s6LDW)uoX?w9^WHhl(k%; zEwG3KXBVL<(>ApcQWdBIu4XDeE_U>8b2%5-3FXqnTHfq8jNs z$@I9^0B8PuHP65;2A$3ugm+VzLWM2WEV=_ok;ZJ)B~zq^F!GeJ3W^%3(Ic9XHn9c>XP! z9uT16dhY=_sxyQ>`yP&};$x|p^K(#kr31FQhIEg<>r7it|JIv*;4l#~;H$y0G8{VY zar*+hx88L>i}1r7`Ccuu4hM{vrCmIs)Dy^`kqEotCs|EbTIa&VZ}y|mN=srXNz?D* z?0_eS%YL|Dc}7S)Z?0Cw%Y3bR&p$3bFxp#Skhx(K)6x4(8F*Ywe;z(?+Ed{Ki6PAM z10F7mvQK02?z_gW5?D2ZdJzFOsm z{l;p(^P`==Otp~J8mueQd$*FmiJ4pp^(=rs`d!b*uGZJ{o$-ib*R#|Nm-0_Ec*D}) zdxCVvY{kqdCv*MzxTEMs1{!;IvClO9d+{9_I&j~Fe-Fl`#N|42S0aMQ9L}lefE%QB zNYkzOC|6=A9h1i)OTDjOF;@aKZ`1-pUyBqjFXb>$H-DM)lrI-gR^a2Fw%gKWIe;Qj z#n9y6cgSvM5>*v}=1>npDiRip2CvK?v!riP?B7#bDPpbA{;@A^G*rLI^;>07g?5obshaZrEhOebVx}+M={>Dj`%Q4tdevei(w}$t0R9;aS?{ zwO_K^_&he(&;4PB_l>@{ZBr3Gq#btn#_Ic#ikrbrpSLI9r0>+D`4~pOcKI0Wy+poi zf<+n6Z271NUh1U=tI$P0Zo!txY4x9{C{O4l&CrF5+A+SHAjyGlTq%CNx)P&;7!krm zzM^gynRE7YxVOdH4eMOn1rlg#@yZ6PA|JJD7rR=@zZdJkmkiT(@BZf)>h5%$5nCkz zxWMxRqqpH#tXtj#`k^ZJA`hv{yjj1}VE1;RiRk!V&H7FQNpl+9{E~MLmw8=GluGnx zN18DqDggj^CymGb^%+tbdV4=19iU7g^wMrvuy~rFs>!!VIewigv2p6+F?nlbv6wfY z{VsoP&(LW{+%t`xVs@KXsMMgbj4Z2HX2j7zwUy4pB2Wr`Q{$uoZ{plQig1h3gfhoY zwhrlP9nGgUXH%I?3l8Jem`k{AGnN#;KrB;FCCs{HY?->=<9I{vG>p~o=_rqLTPPvr zRI`$2=ygx`S1Z;zaG%QO^;$x4@OG}6FtbY9k9z2-FO7)DQ7*C$V|Z#UiDVOk;JoW0 zZIPpPFLpNNP}0+OznEuF&&!3TQqRja9u@OT3hWuZQpym9F|(ab72;I0n64-lnDC`K zDfam|Bp7=lorbFLK=v(Y(CDco^?);y!0qxZyLxlyd&B$Ws&E^7W#9MaKspyNW47MI z1#;-Cu*1jf1dwy0)w!E7WF7D6>!cCwkK!M@FvO}ImkX}G_)qSnI%_ASL&?sv3L`so zVp+u67}`2mzxVcZ&5pmNF_{g0S#++h@lg;F$eEx|-`u|=z0}u9H6dl0sbuQUo*r{z zSnGnUBPI&YCnFz&q{>E{J|BxG?+G?Dh;gQqV-jN=HVLH;*0&RQ8sMjM7>nbj5iB=~LRRP+K^>I&N}{g~cD^5+gR%x=%LUY}@o?TKDfiAMm& z8QX9DQ>sk(12?y2g9Af}_e)rx?xJg-*4XMWOHpe_oMf};bIzaqH zSt#P?T$}}UfoM{&g#?-&kkX2?~q>fCKdm znFWPYui^pS3(rtJW8!n|V-A+(0DJ$tsRHsHuC@skt-BFQ*v>fbL%#Luik(cDgc}3+ zo|Pml@JJi2L-+IZ*&=tHyV`{eVekDgL+*g&v)M|#pKXBICmhi>@jPf@eS;--2N*r= zt9--sdHH;Vwe4UmRK;Cq<%zeVKX*NhJEpk_e%|erK*>tm3(TjNp-%pICp-JgYP}nd91;Y)*)>ovU;xxN zuAD)WyeWv}c{IKnAR!?J{ zMK^7yZxODx6C=HDI; zh*S3s(WTRfyf7gKKqnyn9MPWXd4eVe_;ZCg_AeIxrQz6%>d)iO!_z@G)>}!%L5i2( z1WcPYJ_6vc;bV8lh#SZ?X@CP4; zZP8Bvzlg0A)M8VA4903nt1LC0Xjv!q8>nhH=77AIA1)NFYtjeK_q=AkG@2`Z1F5dF zU(Nc+&hVb*gA3?7CW)w{7tS!*4_Er$;_kmS!ph&Ck{S~p$Z>`?++Ob*daQpg=Spz~ zg6=AF6^|$*J;ePM8Q$_DAcSZ^EgEV#SlyTqQ~oSW+my%#U}nS4^R71vSbND^>_p5i zE;HeF7^Honbtu=oq~;gTgB)AbY) z3X{a1mU;(!5jb#HlG=+3m1Pv@>c|iU67O|CqZI_Kr=0fYzvVcHU)|*0-tct=XGe0j z8crOx5~%##UN|Lj1aQiceWPv-)$PHwY1_usXXIKh?b}LCdkXunUwWS}uZ@3JhzCec z5Bfu1V`azCB2j|hnTgl=4o$4%cO*s$`shqbZQP>_^4W*ZuD2pIq8~o9uJ6|w9g-3* zt_Ki-&ay%BRgu>h8-2-w!?vG#uN(^%VDDM8Hd&N=GZCJe<@znr*G)>r1!ilfyfAGI z#1+Th+cz5kcN9Pbrr~erU*N}`24da`$Ffd!!m%E$SMmq<$%u~1ePiKYr%_EFEzxCey$u_VVz6U zY`1dA7QTN>&M0YhcJ(fg0A|5;dAggkyWE!j(dT*MkfiAC)nOW&W*7~9W#{#WE$~yJ zF;;#0tuI_H=tTI=%eDH^5`60=rLTcBi0cpg4giW(AFL@Ar+n=6&b>tU{9_5s%QSo; z2?-VFr^>N_?Nw`(AaqcheTxldd@la}iB#g~DwpGY$o+##31cita4CgBM3TD`)dLwjA+rUZdsqPkt&a} z;1GlrI)%IvJ5vAfqt{BFNxM>E=_Dm{&J!GC+X)L1#Zu5cN^dUZcR0y?$3GYw<6R%Y z*AznuOj`5>clTx+R(tZS*gG=?+Zm<6GSm;Paot5`E&HZXiW+~mccZ>^Sx%T}QDppD zBEP}>vNzN3@dYSr7RcXH8V$Usm)S5soZXW20Bf2gGMOw`OG~YdaSUBHJa>ILvpB3} zx&Cu~gZ>S%sD$*BeAFs#t)_5k>08g+>r?UbpD{S-+87|UhYU5D1cX0F^RmZ6{g|et z-W0rHwagM-a4M)4B0+_om6ri!H+J;W5_eg3dn@MpuvUgQ^ix#Gi?zEA)3#7;)*f&1 z*zYEjZ46!Bhskp!2m4?Rm*+22j3)gW?W;BmE71b5>p!K>E~d#02~;`Ihq-G@QDn3? zbHJJNoij8j2oxmaa!GolDwNBaRR^#y>G!L{XQx{rrlVcoJS`!qBGf0(8ga2M!-||k zwf2cm?@zRlotR&5&rvmeVK-^xFCHHOO<(qv>Kton@ z!#vJP_JN=}_ZHU}|6l9E&8^6z2;xpUeC6cqpsA~+Z1%yPG-e{i` z3bDvS=xn88|3*cy$kbIpHGR0(f;-%fPfmhf3Dgsew;G~-S=1lwPUwa+l8>E!rwVxJ zz^V%4v6M^d3y7+E3X~){Z2Z=F)O)Eg>~QXHXymCj&+tUY8dkJSbP6&=lm&gQymn@8QlH#CvpCA=G-47}Y9l(55+R z^&B$~!oR&;KoNt2LLDQ>+`XPJ%8r&>liHhA@IKIx$vMLM&G2u#Omp!^n#CT6@c;~QQ_9+rX8_=S+3ylzNBxOZY2LG%qrJ!gP?D4a z@0Zt(adrWpXgkB1)JcLU>jj~*lra*@wk9cF79c!bbm_-9F)VJjCoiGf6?~&kk}mzi zs|kDdqxr_+a^hyy(%;C_8>UP^27_-^l?@*xj)Zyh?_+YelQD@VUhtK4PY{ZKT8Abd>0S>w{kdQ30=iDB zIanEcf0Cf6X}KEqK1Iol8%rFK+`_I4^G?@LC4(qoA)-OpZ$-_9qoTH}M3V(=m3v{N zh3NB}Yla!H;+JFVqP}@z0VbOb)g^iaVq&Po~q3yc)5@O`cyy_bESw$SUTyP*F^^ zfJ&t$gR;sNm-4jQNMb18C_Z<+)2679pvntGct`FKe0`ds1S8I6BQ!dZ<`a0`2ok;9 zcg8f;f{3%lqccdPD4)`{RxcVtjbEDO8xx6j-G(ZZ^&^v?^u!MTLzjOgp7`vRpFpyy zj3uc5WvTAoYMw%0xZKrEke0kW_c>&OIo&`v)_WF9^m#Wrv_9+cOO~nos~@vG&DZUo ziI0{)goL05B&X*jn@1VdaJH&11}q6p#6*8s|n30mHXei%tgjip-(k1z%ECvW}F$>9Ti?4aumEUfN-`!1dA@ z#qLU=cv&2+e zO%W5J{Xz_T%^1J(+DDQeBWr`>ep$ z5I^{2ujJ>!a*x7Fmv0Mg0=3tXDkGQEsj-9p(arKWPH-UhRaLEK+%g^-fG);$#vVYW ze+~|3c6B#?Dh&@f(LSbRX)dnT+qzHcvPU)WgTit{2Au4y8k;Fl7>%=S^o>Bg&68VX z?@O)gisbB;k&VsvR7D$fIfkUgN>^*fbMOd&m`qnW`m@<#rV~=VpJq4uuZ7Bky}XFI z40|}%VgO!@-zVj_HKecYyHM2Z3POHb=;!HU4+?6; zCx7|nhc?9(Z0X}JhjQ!?v@F0^rNeWj{ppP514xEBxOeCl1c|;TlW3YoFzN=-Mm2k? zq@zM(XmOSiR5qHHsW}9(#j`lL@nEh!69`rngK2w&enLNfe(+@Lksl(B{U{0b5z*Z7 zUIG6JmKA>AqSMwwvb@VGnI3f3`*Is7ACA6W9JDXjGDzIV=)ocOR6hqY9{lYc#hctL zq48|Gd?Gr753t$O=x_VT*?peDj=l9$(R&LY`U|?}Lm=N8krX=52^tqpuVN=)bLyTL zq8A3THb9y8d@J$A29RO>ZhNTJfF$cKk90crsMG%#>+nc&t8sv6V-nZaFTjG0%U^v` zD#m=4s`-(p-s4`GlK>4iPnVq^UEZhXXA2Y=m1lb{exejV-d6=*;hpf^`eRZDpZsth z*Qa>*VfAgEO`r-ArTJ$Wn&ufL_w9 zNB#3Z&1=4B<#IsTztV-r?{1J^&jKwribj80N`T6Ij=QFu$$K7k{~;&)@1{djpwgd1 zL?Y^MvmhSOWYG4zKknCO`CWsHDeBt(??V4ypOV=mf7=A{{NnB!^R^H~4gP6~0m}4& zz7(YYJU<8mO7P<-KX&}5+mOTWlT4KNejBldI9Df7W!IOnl=>>Oj9p}biInA^jv~4j z((@A~Cg!F0Br8pOi1>7vn}8CuW+jl?pMgHUlZYefxv>Z8lg_1&|czzF%fo?mmmEJ@}7|_lK1rXU+TDbt7Hucg!4MWnej^L(Dosanpg#g^jWE0?#M!?Vo9splO0H2UB~$qXEE%&&Y|0+J9LRM?M=nDCwY*f;n3@ zr~!Q7U}wCV_dC(|hnVU?-GcWWit)}X|=Eu56MGp0bl_5^5n zR5W(Uw84j@+Qo$bZoL4OEg_{TC*9ivNR9L-@~#4%4~>sc%d93rV=;YcqU5G0Kox>W z2eahL4@r>9AE{nBAX0>tyY9~3$0ULg(hCZV;&xlj*10R1daOK>T$vOpRr()~_CA}n zYr%%JVq|IGsA%asj{+r^GgQ_rlGze})ohLAp3`VFqr%;(ncai{~*$hpQMOL;C3fh|^w%&hhFfDwf z0Q>3?91e86{Z{cubj6nAoc%Z|4aXpW>$@`zXXg*M^)Va zGLSFL()^yZQhOG&diwwJZwa%oD{v-_WA$Mma^m9O{rHg=*{1Q@MftPhLr7K!4%L&j zy#D_hJ`}AE*c^9(edVif{wm_vBZTJYAgvu3&)>Cph77c(^i&qIQ0qQ^IiwQE*!l4E z??3hF_5hp+Xuc78EZ1IGoD#JDe@%5LTJiaP@{oOkjIL_Sz9fE}^Z#1OM|68Yalb>R z>1c=o6PsKC&-yxEA#$QrPA9|v*v(=WYxI0N=TAuW^gp)0a1aCZ;ru8J{#PGJBoUkg zX_nyoiyD*1Ik0Ar1r$1a9FZEBF=R5bV@<0MduRB2A zK9i>L`;@+iWB_xnu->~y(_a^fv*#xuCuY9< zqyG}fx_1rFrAS9^f4IH}^!BM^{WSvbBzgb?sq5lP^;b)204p5&XDDDm^F*MPtOsXs o=`YJb%b6n2|8L7a?{n`xhSv$}BMwiX0Utr`nX+`@(^vlg2Y%q-j{pDw diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/embedded_lists_2.png b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/embedded_lists_2.png deleted file mode 100644 index d2ac91c1ab0200bb03a3d58239aa6b03f72f6d2a..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 18206 zcmc({byQUE*Efs^l2S^kw3Kv%v~-um&@nVf=g=VnLrV-2A|(w&cXz3DN=SD%yoaw} z{oTLke%`g-|K7FEI?No-6?8ihxiSg>h|!416aykyceeK=7nNK=2DfK)3`R z`K==$xB$Iu8X_RPPC`H+v`?v15kNqYOpy^6ee15jlWMR{s-Ajxg%c4ovBOj6a&v$V{5k$F14b|_M5Gl$3T>JGavMM+aaQ|LJ34TaZrPnTQ z|9KQ0B5(UY`h8DBjy?5_>+@B(AL@sHE=GX|Xz*Y=M8v<{vT_1XGOR_;2>*1g<&KC4 z#`uYZ^tUHN3*d>^gx@a9pUIT&Bfab)XhK8%)A5IvZ@`oH#Si8T{?K8#h$bD)XfX(73KZM_O0(VRW;K};4Z#NQu=paY~7}mz~;K6@bm<&Am|HdH0 zFK2gyc0Na&1tmfkzv9v_+t@dhuz)cQ6EEz!0Dt3*+q}kyPCyEO-}^>k_z=hf;|hQeb8V$Q)LUe zSV?4H_dc6*J4jw+Z4Y1duv?-2cLg%30S-*(%MIJVFm&$}I$sFH8L>~=nXZ&$NTMkG zDEZGK7#;#^LSxV=h>yc{T4d*4@O{uezRZi5ZsFNVVaLC`V`WAhc?$k{G30i;k$!8b z%f)784a)1_8UKQ6KAa}#zHb zn+eF-u4&NC^h6T@)*E`ACm-Ivjqxn5oT^hsf+Cn8lft20cQ-%p*!=c!$?hAj$F(3K z6Sp&L#Y0Q4zti@0HW1<(ZcUWf?T~U<*u<&a7_S<`)$^_>lyShbZ!@KYf4LCi;`j^r z=b^#VuYb{2Y4wH(pOI=YRxr(8Z>QK06+~rGFF43+x zV%)KZA>$-<@8p?>m|ob}yqu}b>oY(y!z)E#*U71{KoPp19Fy)nBfru5%b>vnG%?SJ zzTZ64;3H2!wj8a*Lb(9)tbbv%d-Sc5d%HLF} z?z+_%%}Ur;jnk2Euy=U+NX|u*yA^!8^AI+uf#$SNgw55&Amk;NNCAIB7Vrw z|M7w;_`KxJ6~FB)9yoPLeN_;L4uk#O>!W^B=yxW74B$;?B$%zR#{T$Z;`Ga^`qROf zk1qnArVEcfO%HX%@h3p)o9+)F<9t`)mnR1_(0-CM#K=2LoWm5X%@Y}oF`UA8^eay3 zeO95gi8-Bw*_VEa&m<3K%A->acLKxb+IlL=o%z%1WRb)_llX_CvO~V4);?j3s=dzg zuAZrknl3=Sro1lT2Du<&wc2=Mnf)ShsYL}N_01d~Ip-$&kG=uM^rT_M6&>f`nqyW% zSR-IACZaju>zLJ>2>WeWS{48iepC|h{kh0z(u|v;@K(|r8?*6CM?JcKHQ@<4pb7r6 zFPcz`#IE>y@Xm<}-URIqXk691?pW2?_o|~{lR8gz*}P#?fBKK+ z`AfV6EX;?>c?nqPZubO!aq(ngdaz<56Gt6geVTz%4X_Ew%pDhK7+=r*U@0sVtXXqmBOlUJTKvmk!j$+w#ZprB%qM06eGE4gX1Fs z+bx4;F<8$LFcY+jDGS&yOt!|0ma)esi;+MlG@6RA_sl3x-aQO+7Hh%RHAP-t;R`QR&}05bd|1(eoh|cg z&QOF6McW~_gN5prH-p*hUNZu%rNSfE&(D8vCzt>mZOHf0X1P^^9_t{6mK$Ac?f&Lg z6EK#SM^4(zSBXi18a(qn9{wrXfBIII0(c+!?c6s#3pI}Sxo`VhG(g^g>sA`*ExE`j zLp-Ttit~Ay>_0|5{CNX>6(V!$QU25W zH+o>-Ry=TxtrbtA(g@{{O6mjj5NPn33;4(Qx@V&@Wg*Hep1GjN_`NXzE;GDna=B_F z>7d72Jb300+a`+cw?@MUz!GGuZ{QhOj&<)9#qi3Ns)A$hS5zL@jX>4-m)A$bPQP4F z1Yfq*6+N7ooeAZzew5O@YZcD^_ab#Yvk`R^Rd7UqqBcyuKvDQ>}q0I%FMb@(!jS zev2^212lH?&mUN`CSe@r(FR~9+|>a$%qjKo@^bTGpI=mD8NtvDI=ISj+G&C1eD@iY z+;P{+zT$hk=F7gZ^m2JGo)`n8oQr$?I%r6dC>fQE)e6G*?S(@eHz4(n$h>IyXv|YZ%b({I;@;#y#Z%vMu z+M~Br4f=AQnW%c5?#y&!s2-f`#$zW4T<^Ctx2GV1OrYXmvGmFwz}<+dl+KwXyF2gR zw%+e}qO?6#zP1$3qTlQz*#B`{*FK4D`Eb#tzsv0h@-l79mn<%XrLIDm?Vrte$=1bu zXR}TYdF+%g1U;Y9pPnyAQPE?);1yXGO_Ay5De^%5G#_zImu}^^L?y(gH;{dEy)1l7 zbz}o2b}iBrsxc#)|AYnN7?F$SYDe{~;7fys^(O_w++YTkPscEK5wm;_Itf`Ck5y+) zgp=+>Q@(eRx-UGaOy4JH6(LKjq0Bza>!K4{dNT4|cY3(_W~RAFub#ULvwoa`EP?A~ z&r(6A1D1R3ei-t*z21E4UA7_-t{j2y7|NO!g-X7cBlkTAKkN5-?XZNjLt9#=@DUVf zT#I=;t8^i4&uQVBon<8~SV6`@u@WDJ1d>m*^kA}reoL1mTz+MOfjO8L@mYcEpzNpb zn=Gw_F4yw7bjBy;k7CVfB;Xa_amwR zz&y8E2PrBpvrwhf*PX#?Z@#O5IB`!|ab=^&s`M+{NvAUsqYwL}0t%}P+-b z&Vw#Rq?i$k8SvZYqz$uTc3CKbqu0siSkYLLUXSZ5#$;Lzc*VeX@yT{^I$+54F)WBh zi2j>C1~N4Gw9jI~XP0BGc|?iW+Oh6Q_9fF9op-g=s?lY^=#cn`qV>k{L*$W!2|L}Z z8{8U9EVaL451x7=$Z`GQqs@Qwv4*+^5PH2g`BNak+o~Dsb7wc6xk1l%>BQHZ6uR{q z;#+$WG$Ej{%JnTOM3+OZ@tiK5l;$m3{d8B6tCoMyA8w}2;gzllnKO2ncSDk=UviT! zuRGRk!~5+6)q4u%qYqHz;*M08-l$#Wef3r_#8YJp44fYRFdg-KK^b$lxau_m3W-^= zZ`BZa=H02T>WAV$1sX+t80@o_N2-peroTQ>j}#Lte5FcOUZE)1fm#h8MvrmFO33?- z1k`Mw$3k36-Q_-tr6c8^H5gLeHjwL-n+?i~p0;7I=-Rg;dnXIlK|D@aR;Y{!N6yE5 zJS~Lv)0j%Ueo=&Pun!iSHlkrmm0Qc^?O2B1vJm)tSMM{n^JBK(NYfXR5+_N(0D0 z5lgzRf6LhOTH_B)pgQ?v{f~Z-7wkOxkA8$pv%ZtF(n-Qwm~HFCZ>JCnNvhwPHbT?& zScxANIFbj&kqCNLeC|58GwMAc3AwVLQi`#ZmApozivMW}ueK;r+Tc7s%hcrOU2DNrdLtNLXvlE@y(wx0_@`f_i-&~!g3wggT>9rA_gr$2C5&M=e<&kV#G3Y)q!hVv0 z1e-Qu^8c%~jBs_%rW6ts*PZDx=f&6pEK-4Wcm&8K+(lFtN%`%1zPx3b+noSc!p{h3 zXCDc_D^75NstR7EL_pzhB{=y%ltB2ww*!~p0)|yXg4cRg1N$sc$L-V>VE1qXc9x?q z=9vQn_r+lRfPuCi>G#hdM}s_&YUhtUqks6s^WS{>E`vCtg%mW#EQ-hTUh1W8ql$5YfF;+ zwNQ^lBZceZ5vW(lee-Hu&9)hoZl}yFR)I z+`EY7yzc+mfw{<@xQ2g6NLURqbYe!JE;fYzo7e({^>>)GxrdPTs#c-YWL$ zn4RjUks%Q@^>xuuc9OB_v_?|Di-O& zX)6hS1PVs>e-PCAH1`IuOFQym6hr8r;=Us$@q!XoujCWB`t|a1`0W|ll~o4{z@%qR%N;Q`RieC&BAidTT61 zTw-iGCm}uE?`rQZNic4(n-MYRJkI~DkiZ@PFCK3rERqm zE2z)K|HbQNkK|jBFQ*F*eFAN^rOU^iRcy)OkH*(TKC-Gb)00X`3Ktm9id`RCRHh$P zrH=*$5cZDtQ9~N6T*WV>qa(h;eatr(ROR6|V5U{2!BpB#M*M;?8kC69}KnFsPBky;1wT8c)Ap`$Dw-$yqp zj5R6{!I0J0k90QtJ`qYZPkGHA^9g;FVLnR*F)Kds0pehKhjz(m0vXy1jF4pG7kZb4 z^T0kvN_Y!ChBVj4F-LMAo_BTx#BfV*&sK-tt@*$?azjVxm zxjSY}RRf?X$*y=wM_j#2vVXRf3;1@(u|aeh&f9VHJ+5H1g&S2^ zRMxNh>Gps_Q%G{U*Va4TTGQbznjS5wnM&)4nlRRp={L27%a~fsyYC9xyI|ExmiusX z5yYF>6jSFLFtP2>5POv6gE|7loGv2x5vOielBqP3 zm}qo-`U|*DcTfyhtm&l4RSeBmEe4n)2rU?`Q1e;Ko7zXZC7ckr`kQ5e1y9rD)8pA~ zNPTLNwizJ(Tk+({AIKS;t9qr&v_Uiq1V4xStp-%WU>?B;>@PKgrw)w3i*Wg5#-okoBM95fk$DS%E3 z^{ywK!V?O+3cEwl5znn9W^C4N1FqLueS+0199m2Sq{ zfsqT>f)*K!q9U6p5o~^?D0sD99(I7;VPUlm`FTa!0k1BrNx&VMR+9MUy}$$qMOhgOz^>gi#cCr(hcnLq`ubJtZ3-h%A>bsdLg*`nDH{sFA`9?@dK%=EUl&>-=5fxXiRafud)(;Yg8&$R{};vEbdH1q=F6>1}0+ z_v2uPR%Akv_wPR}w6L`|Fgutb;1W9zNs)OwpY6^8(X*f*VfYO9C-PzMU8iv$)RJA} z1&e1QX57a(l4d+@N@hDD(HPUi7i;O*#EQ6nKMt0=VFIH*UOLD-I1VlETCPraGSd%< z3>P)TY(HK>87tE{mqYNGAuy}9CO&It#p0IRzZF)0e z!>IP7{gV#DWuEdp;y^j-j`F=;uAcV{zlh)S_&m%4${82(EJYErU^!n%;}R0S{2sM^ z%nW??S27AIA}y3%BajY*?AD^>l>u@6OsS|P)kYw7aY1N-g7u<>x+{7vHQ5eV#BBW% zjcQraR0vz}SlQ0&hb66^PQa-tQl|EfOeoD+*K@ncOJ40(-EtB^d}r;7(Z0@hXc2zP zl(8oJkXQTJXh7y&eS)pk>F6_oA4ta}l80jjnjHB@ti7nNo1^r%rUT6@2|7e~2XkPD zXT1q*E~4)@->5#V;$rz$@%gqB)7PlOU#U`TUJ{AFfOhKrWQ@_U;Mof?R`g|*BVp(1 zt>XIKo){|E&k=jM5(qHjZ+b+aCcnU=gX~nBckV_W&I51s%%?-0SwldCJEc_YdGY;N zlm$MwSp?EzeUVAO$`uCFNW*6DnATaa1@;kc!ebhYQ+$8LNO9Xv9|P%~a$k)0y`&0q z6MwuCrG@kn{aP)(Q)XyW=1HyEU0#!dHD?dmO&p>DDW+LM1PspV1?N ztteGr7BpWLv|a>Zt5YeUnLlC+lKXrkU>va|T>vQ1aInrvCZq{nTIRB)m%4QKuvfJ_ zR{~ek0WAeKp_syp%R5xA{o{LiHAb;BGO-n-*HaDxjLMUTR)zFrx~6&-Sc&h~)6lH8 z0pHobaWocp(g!#P@LR!MAAsL~*k4~uj)X}2N(BRi|l z6s4T|@c_AC_IiMm)oIPBdjPD3IQLMq=`db$c`^`Ns3*`OptChg9GQ6cMV%}LnDJ$< za6%=W=3?x2QdJIUQEL0Rwlq(WB-@;tdG;)BZy<<-_jGI=7&^P26)t}6{Pt=CJmdLu zqQi|y3DCvV_g7tqgMkHgTJ`dSY0jQOCDa1yaQJuW2+$I6t~o0(xXCYJW3J7n>-nJC z9W!$2LUb*upeMyl2kA#*ca_zw=dU7VoSrMbD_C&a$WClJ{vpTo`c)$Nx(7pB=Qc2~ z>lt9OKG>|B{Cav`BcjOt#7VlEJ8HTllFvHT=~r-GJi}p9&NX*X40!u+blZXcZ2;^W zzt%Sko*t*McuoDOwR#eN1huE&n6L-g0s59jYly9nlNb+)qNN-84O<`D4bE_O*j4R* zb&ukDVbD_xRPGLhFYM~WwNO?NtjI!Kw6V``mVj8A$12QRJL;(6L5mJ7^eHU|6`$y;qrg>ADp;KNVA}8(Yif^-lb-XV z^FmO0PUTg19Z!i2Ps9~{V)hG>@ll5v2_j;R?>^d5#*toiUvHcb#T5^xHM0bnmcCH# zX+b=!R>GX6Kps@oW~ADH+G(syKf$?kTaMt7j5KL*hD}Qn^`fzhbdx!WzMMK9dRdkh zsN5n(Fcq#V86o}rb=?c0p1hvOK5pU$=o3pLKEJ}wcjmiBU~w|Ik`lTX%eMk&0w@Rb8@dt7$1%Y(whEM}iVrg)8X2=hvxL1}|D~`l# zF#4YE;Cuaf`l?l)_vQZm{>P_v(3r<|h11GzCofjups%Z%9iHkki?LjpvKJo(c|gVC z?19++DAAt^&ZwuWX!t;J+(QrtH^JrYZOu;A%xd{q50*WVTqjR&p42tYyzb~33 zH0UArV20ZffhrA6p@F3R$(25EX`x82G&2q6Wu<@&WWa!$z7TsI7bPe5XT_I?8+fX< z9-ux2GkU_0VQ)8LpMYZ^`e6Iqx|eH}Sz9OKNpG#Yk~V=n=G7_w<)%C>F*Bv^5}Sk* z8ac;9ulAn&L}wL~52MrMb0^@7fmw6woM#*k8m_Sv8`G&B#_|n_ zJ&Zg*S=k-iZ!{|afG$FKYc{`C7WuwSYQQ;5vUSXaJ!!QtM*M}z8@oc?i% z#*}c9hdqVjfG66Z_0}D~p(XdVA7h%5{4&}1%9y>ueG6GEv?lb_x3x>drlA6%#ox%) z%FV@ZvSad&F^1G&7wbfHJ$TUd5RtF|Xo&kfwGD}C>UnKLMDpA~M+`>f6IZfl%&z#9 z$GmFz$Ui4n5)C4A>nLNlkJ9f1^j_yAzj)X)fccXZ-bOQlETpOHAW=ykzV@WuReVD7 zwVW;iN_`7pA||(z=7@C?M@`MUujc??j0@Jma(#Q&Jk0QJrS+9^v;&q|fO%&QU5^Dy zQFVv}F9&gV4G*4Ou$lgrXwVpE$L_C-7yPc_W z5RB~v!v{ z)5x6`N9q*2-6@7c28b1SDy-eq)4irale_uRjt4UsjHIc7?z?QA(2kE-9z zX=~LK;)4a$mnvmgiTqwkYeu(X4EkU3lxBQGktXw{abDPYq-2&UbDn0q`rJC-0foiP z`r++G`klwdkL=)VnOkex&+(~X293g+%gutHK(=7qtpa22VGpAYAeiha-RARYgh1*C zP(^p47X2WZ36U|yvMRN4aGkY1=AeZX*2 zw!xuleUz-9R7_sJ=03iP`Z=$&J6SPve)6eW^2TDjP@Px)MfAXVmT(`$LDJ396%2|v zP^iiko04(8yE*HAzCbEsMpFwMa}Im2!5=htn@qYRrGFX;%*3o34kvU3sq>picWn&| zaE)QPh1yFO>7L3fqLjG$>@&EC_Az^zT;$6Primv<)Dy3MGK8{gP6>#1iFzO=iHkcau`%i{<KFL9|Lf644S}EUsWLi7J_R3{OVs?b;aY0vds~t29`h{FS$2Zb z$|L`mO4CBxuh!H_=z${;@|%1(9H2(L3i#qT!rED8!yhl-HZdNPZ@K}g#$c7y^BXu1 ztpaK$E_k85kwEx31KWXe5pLQ)`927x?-rt&jBn}1`|N|m8c@A6VPxd3pQB)i=YAxQ<3AV(9=pR>ZXg=#R5yai%L!z@ZKA;QCjO!ybk&2MeDV>zCj1QAOejd;74su6+&qIEw~g+8Awdv~E0 zuT1)tjT2>&i;cx|iN}ulC_~q4-LHbKm%Y1H@ku$=0Iq4a=UxT;Wlze%^vvi5lfFU( zek3ORi2!5SASG-&>GYirvJmVU!+sf6Y?7=(oI<=(&9vbQundoNAu(Bk=R~pIrwQ;{ z8suF#>Xss4*|!Odz!B$uUj}Hcg<*_3DK}~1B4uaRHJ4p8^JE}}zY_iebq{W(f> zMo0Gg9mINt3)UM+P@d;YTsOeB9G6$dp1z$l(?IiyC|wfZ-Ts>JoreaKhmg%Tvb~pE zoPGlX@19AHf5c{9gL$zlbd_+@Hp(pjsO4g-H+-Q-lYgdIARkaD)&P6<$>WQw>wv9j zoQs9BENE?PQeJ3^ZwXl;L6u^9=EqxGMuVmX`*P^;{W31%heQAAoYC&-edpbDgUcMf zrz1@(e0q7IQ)s_>;3|!7+D3R_y~V*%t*M*1IrbSppYNO?{fNQkI6nV@vY0a`XLWPI z)&8`WqpD9VHTB!gs5t>H9zroOU_F#**h)lO&*VcVnh+0z!&OJ*^o`1N(odV)I+n(y z4d{>9L{8@EU4c@J{Z(M1XHj!pPO%4POBV2eX9WvD|1^2Mj8?452~$^r!Ae~yS;5lq z!>$`n?zamAtMg(AusJs~B4Q@88Ijf_G@W)Zf%d58XGRl~MRcJ!8{t%_ZY#{n7)z2X zFX)~@Y5@aecKQ)95I#>v-~Ma*i15$7=vIZvO7m!(V|-&^Vup8PeI~2S*B(ME$gSIW zzpw_O*ApcM!sWGRI3i|eOhGYvKnTQ4>$EjCAlM%c-7)Et&4 znjiR4ACUR}z+6!)7BIq2dv&){8zC>Py#*zgNKp0!54+E{0N& z1q+T<=I+c?Yhth~jwSKofV~XE=U<7(E?&Mm-iPHboZyJOKbTD(j4lZ08xC>XshrR- z=-JR2^V*)st0L=`p=4!H81Vm0lOTVxtCJBdTJI|ACuZXP*nWVCPgFz0gh`fPU4dII zqH=+wkq^IDe+FBOTa2E+w{I$e$9tXA4=UU32qqZzs5E`qDlespn(j95L0ihCP;!Gr zFv|m@F*8Ur=~V#wR#ONxHIIyLqNyCRl@`_T@tBv0AP$Em+vt{T5f+}Pn&A6H9vsrw z=j{Pb+8Y~CPpFwGEeP~5{-$ycIeJkW8yeleJ#hMNaKa2Wyx1OsAz}UYih~Q3`9eDi zl-U$L-AZLG(L-aFpf{Al$Fb?ydv1j|%2KKO)s57DwRWeIBSnPIqVTentKh@F&T)dH zw5TMfJU6$Bp%fRlQk%dKCjT2?5|<{xbOln0UcC*yyTq69wCYA{{U# zUvJ>P1#Qxhp1jpK0~apP`#M{dcw`0cFQ+44N|_UtKUo-Hhz-z~O)Gu48t+6fWk-Er zMky}VG(Skpk_(q}2`bUfY0&4(BJXeJor-x@p3H0kzh;0jD`aHKv-8)hnV2eQxMvq< zeyIh2I`9Bw34IfsbDB&XYL^fs$5#J+cdq_O0uYLUcO5?@i{uCJk~Av=h6i?pwUsbE z?x(T*19iqUAY@=ZomEtFrAn=RXScZEJ!OjzCqb9h$TjUk~dc}s4#@;&*cOIz`QXz&5S zah=S8tKJ`Ov9REquVn!=&x7NrmX8R14+trC%cjdd=K*P#5}){$DN6*9YhrZuV@!!v z(&bq8bl7g0wooM+y8?IEshUoT;uCN|f(A&tWc#D*YnXXK!YEKcGq*(z9%DZ^=`%tC zt&;W^u<1sM&uZ@Rj8~vr9@80bwj`LaD*tC3mBFYcUrhTrK?#=dkE!6vQ(&Vc>sQMAHaa4Rn(eY#N2ba~cr~t?5{D~T zMEahG_}ZtZ7;CG#GO5Ntu8@y7>7o@b`qH(~E;GY{{mhZxM4rY&i0o!vs&UptfotkM zP3v`uM&3V=nUjx_8s)uh0=l9)Nq0QOh)3+{2sL(Ice66Y=%%D@5HGkq` zN*J%+Xa&3VTtNuH%xeXo0+m_LYxtiuM_`Q0yFfW~BjCpKC#M@HKjY`UFUA5Q_WE~T za7%oyN9hsId1%&OatNJw^;u=QnuND_qJiqc0$f5jNYN`yEOIRkuNoHuFjfyXF44e% z$dx`mjvf#Idp5&SMrGy#)a5qy_B35p=*J2YHcB*4nR;+U`V(2YohH8{no5&=Vw|b4 z906h)J)`)JGIo}etwv+{>K2g?E+#9&rg?$vIGNXe>wF)nBh`6nGlPSP1;%kjJ%n*q z>D1i!)VwRV8UZdqmfYPCEO$8}Aao<(lQrw}W?IY6lJUL#RqN>^ftcr057k{$Bq=o% zx}Y8ysF_+N+hWmdA|vNXqA&?}FDd(lUUEmu>jiu)TPUxok4ha6mjxO1i+@c>Dv1<}bdI^B+!ioA2E<*v~-QnJilds)!CENEs&N zD$}=TorbBQm_o=Lmj_`_YPk0Vs4)YF0f#&|z(}vYo850x5^~!?E9B5io%pSpbv5VH zyEm?wV`<(}QRlM@?Q$H)CBWgSHAF+!4I;HM=Z8}c9M%# zGSO=SajOzjJ}V3c#1izcXY+m%I4c)k%dKPYc5JsJ1eK8P1?*YJk98F6h(0>8!4~5v zLJ=zTO1v<{{?eo*gf<Sjc55fCeKL&GisBC4(7BAOMC>({)K78lxcQH1iQ zj)3yQck>Mw86l*Xq8ov{49>Mcyq>v%no|~((fgsIy)mX5+!==7F-pegn6>oQPtvVK z`ug6t=56m2!^Rdi6$-k5%(>|cO#%f^$qXe8c)pVj!(0=(rct} z{CyD9QERE<4ED3|mP#P$e}}e4+*imCsWT*vqg7Jl?P{BVdvI>95p(4z*HtC>*_J)s zWv@maBu#6yW+Kx>l*C)@enP7Vj_YKqo>e6x@}L~_F&ztTfoFGt&96=Cjr?xAjB@FR zo~GkFF|swn{LggCLK4xS*m6P0?YD<4ckmZ_6M2G+NTmeCU%MEI12E6brMxc5#0vH% zjhn4!n7F6-sJPnDrp4w|_QtTj!>6*=UX4NAgWJMdJ6@Pfg(O9^5%nO&DA{k0=8ev; z^@nXU_P|Z1+hE$V0$@F;XwgoqT{m=Vp2z*VlV|)X)&^k*sm7~=h(R?IjyV%)&ZgWa zu51b4<6?M!MNPhPK0LHen~Vne0EP3+mtJO3bEve&t#X<^y{KH0eUaM~M>$rEBj8|; zX&vXVV;0NCJ?kxh25*{hLyABFG4Jr$sx)%#S!=|^QjL}{agU~+676YE(?usB@8EM% zV4x7~mrLF*;h$MhnTgn}tu~>}^-UULU&Q5NIyT+Dq-`Bjje5Fowbl^d=doK>m`m}w z`R-JWRgA0q7hD^6Quir8TXvmfi))~&YqS(u;g`rPI2!(ETj=~YqYmq{TCcxFP4 zYnn_)Tk#hi9dRzt=*A*LbIHTsV(xb1Nlib=TkAW)_0aA5wPRGqt^@rvHQ4uEWtFsi z*lAd>JKVb{9i{K2Q~&wJHHHtoEsc;sB;n2wn{B)3#O;HiYkgZivWK_XZW%PHM36B_ zL+U^igX?rgr{1-QD&3XJ&`ncfs89g=b1v;bF8^Ws>I-5#lDy>*CWxI|b!T6jHkf;S zMU#o)$IJCBwgTPw!&}%%?TS%nXqv49`IomNS96U)K%CcG>EqQK(8nNP|cY-{lAbUb>JUV||z#sYf0y z{Kw8AI;2K#5s7x>gU4AC?3Xn*7an~N?_GWf6QAxm&tS*O)DP2d7FM-Cx^XN>xRRRb z>oH@Mpu};_r{@RDn4b7Y!A06bIwcht0F+~Z-b<#;5r|Sh#^tmTCEbu@Z(=?*L_4i{ zn-uP3-FE7=A!qOPO(9a@Yc4UF*lJlG40m+brZ?U`*JZr@U+)@ioeoJ z_cf81Zdyu@dHyL5j`E};%})<>7Q8RQt1c1&k94_7Rw~E{uvX`?jh9>7s0An6Ti(t? z3ay1+sI<-79Ry&uE~*;HMC22RHP$y6u&cKwYkPYDRZ#}|7w+*4d0txd#?)Eb5eL?t z2=69h{TzhyzSN?za~~B7q0*I3inrBuOaZTRmDVvD@nRk4O$BZdp&T{{bxH1f46+Ri zcCDm%Z?NNPV065}xe;)Cddg~F!`PZ@HVo9)Z{!~YK*#h6h5Xy)?0R*(*t&6o=h2%M zcpPCYM6EsMtuh*f=?;}kk4v?S%+R#Hfj2nlhXDRNMulRAO~j@o3hFDp(wF6N-O+RLv@M5f=odmqmmSB zqK93scb=6H8lGz)rHl-Oqh2#bCh?&$shV!}wj#wINU?+s_3P zI$!T&o?Q{osRY3U!34Z-BN$-)4=HpE@F1^?16XP*nX%`Y<0dK?zFa=wQjP}7c8|YH zktv{m{6y{)D(s@d)HTsbn&>t$NJ?15XA8+cgQ9JiM3%5+dLNjD%vMl7#v9ox4MEzW zfHJB^Q*1PxzvRj{hW2A|F_%NEz&W;2;qOm9AKJ8i{a!dW^D-E7PP`S!x_$XY(?h53 z#o>5xX68k;L*e%jqKh~^kkz9O?VVA(p)|5Zp~~`$i+r&aPH3M`;y6ZQgiR}2i&O!+ zk{KkmCwx$u~J}q%bdF|5YAdo+YS*IQC zeS4H{{@7vq6sPw)5HSDpD8oI{OSS*i56}{P9ri3vqLlW~&pwfafzY3Wmhi|*dnfR+ z0VyR=23z6r$6WGEo1$tHiTy+U*i8Obk?N`td`a$n`|4a5a~&KA0EzGi{D6ve6M@|Y zU)PcnDyhg60S|bpAS%|`8H!r@8W79WseWgh(fgILBZWVG^!>#69=nu~d`_3q_if9@ z-k7SO$9Au(z@zVQmyb6_uFm$bn>Fp|Q;~^X%ULImueo|8nb*|!t!$O9-}jpq6lN(n zy>nBSer}cMR9}F&W5if68EuopZR}v*9Z8~)_h`C3Uw1?(iVDD^a&nACjwV&R9SBojkuY^fwm8x{4#GztGjahmT&QO01&CF>^q{JdoMg ze`WCz@Aj)8f!MT5Uo!$<>pE!Ie5HXte@t`xX3tf0GF?INXLdrg`&SS zggeS}Yx*qiv*7kty~mN+P)=dAsrbQ@BBQjSaedU)f!5#dqi?>$+S^9 zzgm1b)q^9hg}oBju6+jEz>kL!m4S9bSY7j0n#7qr6i5xP6LRbZ`sPE)%L_x3Os-A) zIO0&!%_OTQ++v5K0WZR3Hw>w2AFD?WPh1G^OmSFUvu8tB%$GR?DKkw`&S;)$b5 z?^7Z1KhL{(JeQYwoom3I?f8Ppsf_+nG?Au$EpO@?Mp8eqip!NXBiO9Q zc{8L0Bp$A1XOtVeN9m7=AQT=8E&gqxEYPv-PlGjsB@HMzPKl(&JIc|p6Zs>k=yr3u z@a6klk>m|>?0}=~47p=F?7^OSCZ?kp!BwkZp!jFD-RJD$w4Lvb*umlkB80bw$`1RM zVteE60U>Z|a+=U{GwmiKqJDcq?&V1&@_Y`FP1gH>t{H$_dtEKIrV>Tn&L~kW$JcN@ z*i605o<7{@^->^^M z?vI1W%wHBV+rtxq1Y=QJq4^hiO3C^X0KQRdY|a0M0^Z*d0Js|0!+*eT|FkDc0ubgc z_@8I~LhwHT7_;fWuz3KdevkBAK>xP$7pD#Y0sjle|L7j=ZjZcv`k!IQMRU0SAY6f` z5AQMaHHglT{|p>WuJ-&d&K<|!9{}Dx)_qX-8>$Hm-_nNXe%MR<6Tqp4r4xdIlCYI; z2P&-JK?#{(X^83nkf&`#w1k$XWo3iB%NXRsX@;-NOyTL{^FVZvg;0 z_IQcG-KU?|X8-%0_btVG_46KUsq)c{hkXnHZl19FjY5D8BNsLQU$QqfnK(qbznsX* zQj6wv{r%|!R%Aq)&h4KLMVhkF3K=(fn18t->8IYGezR?k3jgPyc@O^bSUv<{Py0TT zBN-iG-KYxSDixHe|1PLuqay$;_{44d?E6)`hIJT)+7|ww#ZJQVPvv*h2Vgc-p3V0S zBb5HrkQLG3?s6iL5yTFZ6_#tqg~&hF`ojmqVLsfHn zT8cDR*9u@CW_G=hu?3I7j(*HZo zebEnZJiBW2A}Iu@JB)o*js#L2qcHi)>wMG(Kt+1;q(!TY+TU0I^x^-%^uG_(N0b&> z4}>S6Ngk^i{?{06xbC~PYutA8v(qwN#ic3lVgHNW$`XEqER)huB@BfwbpUp%7+rz{ z3W%qS`=7G_ibGQ@rT~0Xr>w3uqbCijCQyqb8zb{~MYxdW-IpJ8f@;#CMa;@3bhVtl zveDTf7Wi)<^1X3*kFbd@+67u3D~1EoF>gHd<2V9DLESSt`&SXVWc}RXc3#WR?~}?? z7=cvnM=GW^>%)-=FyQ|Iy@7aM diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/embedded_lists_3.png b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/embedded_lists_3.png deleted file mode 100644 index 08ecb0ffe161627c846b6cc048986bb6fd8e7bab..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 5612 zcma)Ac|4T+zkiIOK{AL+r9qJpAt~eukrWk?k+o4WM9DU?Jkq9xlVcatDW&X#oa`-} zv4lg&T5(b+Wf@!O_j$(I?!B+qz4xD)d7gQHKl}Q5k$h>)M$@YfWwzwy{q;|OP75+9ziy8y&-mG$5`V` z?8vgZs-R2W`6QA$sI)QZC$=9P#t%hZ8ubYOpFO_-<>!c6*N7%-ba*zh9NuzB5C<%GS;wn z={K38#;nTc`KYxW|A!2as)g>@mE2!A__73GS z+06l^&@1>5oCdrx6e7_KZK~#%h@uk&g6)I~@+Z^PRFtx|gfOVEBvH~TGCRqO2l-Qg zW&)wJSwc;JiDz?J7}|b82>FxkWl0byCu~-L%Lg0eBeDkVkR=f)YK38_)_J}LizPmq zs+8#MZwbhfHrQRj-c@o6SyGf4$b)6gN+N$5MTHVAY|k?xzQpGhi2te>L6)#iZamok zrK-~(6QPTkgDK4H#uaXzo6;T8QxJFqu}r7 zmm!Ap!?Zv&t&voZ4pFw&jvbYbGgJo$N%rld)hKQgH7#K8A)(|^POx?6%U_2JwK^SC ztz*R&xM5i-)MEm;v2NHf8__9Fhhr#6Fpyn$)p~36&5UDl3?^E3{B!x4zA}MGu+%Ky zmgTfD2IKRad>elIeaK?%H(yJYj+A_(c`Gx7XV+1jqdig2yFf;^?*p`*mEYt;D zx+yY#@rl+ww4GW#(*3mpm0UYHeAqGe%T;uiP{haD5HfSO)OL-{1#()P_R+C*QPrj2%k!qX#t62#W&BN)Jk{vHW$yewmSoDeJOC;8 zRc{dR7+39`q3pg{DkAtc4I(Wq`=<$#?uB~wz6dGR^?l!>e|xJ;B%LQ5{sO1? zFRCf!B|G#3df5YBk_4i=j!e*N=L9ds*YsQ=TKTw??nQK3PiR2rnV-$Ne19*wi96{U z?~=n2>>9dBf!15;CNgiHH`dfMBlp(7^x=b5Y)1HY4=wCU<-ySTk;YK|x=!ZI%2Aa78MnePf975qYDty+bxV4?de$uBa@rEd14V z_M2i-Ou^}Z#T2|0ZdplYZ&4l&x7)=aB_CLM#o?!%9LLJtt*=FUWvjmEZ0X(+9#fFG zPcH!n8*iaR-z@aL7O!VQ>MjkR(ZB6ex$Q@lA&a+IA!Soe$$Q+x%+*jW6OPav+2JzE z-x)u)-SyVWs_evVNy!dFYzLT>6qyN^GBBy9pk7tzeMT1_M7PwiqUOYc19k z^5UU46AF|X&$w-g5IE(lm2VHx!Q2F|Qr(4|ue@&Ye8rIJH3yc5?m>YYeJtqg^V&i? znfH|?R}33K+VnZ_uX--V5F-V>i96oenEs<0c7-wjen<+?F{eS1gidNE#{TH#JF9 zP4V?4>xb$MQI{Lz8gU>Ug4@I>nxL{I(=iHab;t_LT=O8M2E&`jTP=y zwfkTb2mR;mH8nL|U0oF$l2szoi?^P9c`u@1W_IMP`ICx@-P0m2swYb&4RFfWARJ#Z zMW4$?dY(CBJRf=YQr^po6RStRdHW62+-z%W`xL#+qgsk{#*FidGh_Kq|un<9*SY7P{D3^xM>wUuS*sF5D{Yjg;tgY;ove zS}OFb>9?VdBr{&>z~=AIJ1+^XvbMI~{rz*ns9GD>uqt3!%f}lO)_in(tL{u6YU!+f2FXYk4;PVcRCf$O9f|!RHClyU7!;8;_R9`wa2{~Bkjzui)yr1>k zt@U;@^vOk}W@pN_3w5*oEHNm5Gs8*J?A!BuS3lcYs~yX6cz*tEHuvKII^qfsb-q4y|W}?K#a^Lvd;Q` zW?L&oe^5Mj8hgPQf8DE0bm#t&H23t^auO|Yzbvv-roQ#`NttG7De}>r4twJYh3F5b z3D^P3e|s;(%Wd3XHjn|qEm3j|7T!hY~S4Knz*Ji2I z`n+krvMb6K8*s*{<{CoSBA0RHs5%Rcd&H$ z0sNq2x$E&_<$@(!(zV1zKbdlE>8|pkZ`C(xmToZ4IB?f1W#XJTes-~>o=vcQz@>8_ z`=k`19OziOb+orb)A0{^Kl1XLxc_L+Q1&hUtyWI1uA5fWE*5>`Kz|uYGjuO2EY#%C zCmRwqEI0Vf&x}2a+F8eYOWpkR$j-Woe&4L-T+Mn}wGas3{lWuY&yp2$zI^#I=6`*C zgK{23@Grq<`YM8h2A|q7o*zybSn27m5&})^zfhTUHgh~Wm1Kuf>Q&C{CJ^~W_xajs zwDp_WSv(G2a|OX>p}x-c=w3&#p9FrE4BKzl#I8I2l=v9bd#vBRwW0v&W5=~oRH4PY-w*b5`VK13x{eHe*MI0BI&;PW)&p% zN$U9)V_DP*Pe<_tuf7hb_Y zD37%e4xJvUwc>Au(TfDZLnl+3BbJ2I{GF&}%5;Ld{;vNRbo!w`#k*7Z6N#K)f>M%A zUirYhd#Q>u(lKD7>1TF_$eh7$Bqt|d%&IKpEDv`&LLjbyj;G1bLueE1fo2{Y9PCKx ze)DGamS|5;Py4cf{1lFrUBFs7H3QHfVs8PBK)fZNS6W(HR(4@}w6|P=mYJEUqoZT8 zmNItFMbFI4Y>X~5Vp^v6LX?sh7KT1SQXh&@4wY4h4$9_Cp9 zjPd6M6F5TW{Z-@;;gCvJ!RRP8t{`o9o$$=7+r5QhOY zoRixt>IR0V->sY4$2i%e#BWfa(pW!M7fX~~o^Qxrfy8Fb5IkpPOkPNx&8qCn|UVX#<+ z4Sg+6@i z3qv1lz$Y)rRxPANQDCJqC0gS6Ix{(x=>YJ)uC6s$Ab2D2weA(5F9ew?L}2XtSMj<5 zK3;2bC+jx4l?PLfFAM~7d5{OKD~P1e5G|9uFfH?gVfoP=oBmZJUvKi}47Vlk@bU{v zBC?>)=T^);&biqo%tO$C`AH)tkN^h<#ou&wl?06SSD=2g;~(f9Ij?pwPl-|v-3&vm z4=Q?s>00>w{QcwO;`%$FAl28`L;Fz-9)e*SZGsGHs=5r<302aVw#;=OmMP`BPQu5g zGzB9VAF%@>_#mEE^+%5Dw6yxP(!}q{*U(Nl)XB+*sc%>;p{M9GA@O^xZ*0dIQUlzJ zyz=^(2-9GKA+wae25VTT+c~Lw3C)Hh*|9~c1frnCr%|dg#ix?hENCl<$$;f#UcWL8 zLthYj?dwUjQ5&ruz9;5Rm0))TFjTZ1Q%7dvhmuceauoUu$ULjg*Mv<(;!~gD;P+?N zREKU^wJ7jSRMJO~^&J^2IMrm_N1cy6t1V7xz6t@d@2+PIf?XhpRxjS^ALnIHv^5+c z{&U}xVGi+^b6?Ad=@0(&cM*pkk_5-7)nDSP`XO@qFB{|gsXlZx;XPqhS@0^$MH=pc zFhvLwN$6VEP$;aoMS&SX>SZMIK8TS`{M*-ods3o@;PWK7`J}`|01V37GOfHs(niQ_ zv5Qi-AY#nflkiypaZ?Z(sQdR3F>vvk z4Lh}M28`D#$i=9H zRBLAm{FAfz@&b1UO0ZVhtyKaY@nNE(*@yO;I*=Z}RQS8Pa-Y$s zp#0OKe06*|fnD&gGKG_cEiebN?^5yqV>_>EwoJNt(kb= - - - - - - Examples - - - - -
    -

    Examples

    - -

    Associative-Container - Examples shows examples for associative containers; - Priority-Queue Examples shows - examples for priority queues.

    -
    - - diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/exceptions.html b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/exceptions.html deleted file mode 100644 index a51e8ebe0..000000000 --- a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/exceptions.html +++ /dev/null @@ -1,46 +0,0 @@ - - - - - - -container_error Interface - - - - -
    -

    container_error Interface

    - -

    Base class for associative-container exceptions.

    - -

    Defined in: exception.hpp

    - -

    Base Classes

    - - - - - - - - - - - - - -
    ClassDerivation Type
    -
    -std::logic_error
-
    -    		 -

    public

    -
    -
    - - diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/gp_hash_random_int_find_timing_test_gcc.png b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/gp_hash_random_int_find_timing_test_gcc.png deleted file mode 100644 index d86299b7e3ec1f3fd57d866f3b5edb7fd35fdcf2..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 6194 zcmcgwXIN9+vJNGb0Mb>8fJg}{q6R^VK%^r`q)C?=dXZiPBnT)V9Wj6qrFVfylOiC3 z7`im+MWl)}m72T4ckXk~{ddowyC0IBnKkpyJ2QLM-t1?nyQ&N@P8b9NVNh37(t$w8 zkq`)(0}TbxlyuV@K_CI%{YEWjd` zNWc<79YLi*0RS&x4hjvj1*HV_05pL&CyYyeFpwTNU5 zmVpcoBIp<>B*+hh1rmWsBsK7){UjDA9VPYiq)8-FCv_*a_oS30jwjV2b^9b?66KQ| zNX!SEn?cF@RJgq$(+`ag2Ub}JS>h)BgSEnHmwo-K^q@G{K`m6DG zIebjYdsuN-@MzH{y49bZ%$?x~rL#4>D?S&n5~6l)BNT`G z5_;*9T3@fg=;672!rrWPOOOz}pk&vF;b&;B5qBik?nwC3p}_D)7Ax(MflC4nj!$KR z{>=*msb-I}DwM)Wv+W-CkrP`=&@t98l5|3QY?YtP)Xw^&_k*K{mk*j71mrufE=Dn2 zD%TW>YCpP~z@3%npY}xetkCbOoKD0X7n(h^#dgb>?tE_n+sd6``p;qQZg#`^ejM4w zSht(($$HWizl8p-eSep9fmzLY@HyXuFHpO+93 zPmSSVQ8CN3&*g83xu;sinH=q{y`%1TZlbu<@8#sXOt935zFX17i z&pdlFjVW(ky(R@4Fv8~Zz50DBVBoytOli~K7A9lj(Tfk_Un=iY4EOG_4))86)VNq& z?2NqiTTf>PTZ?JER;Ts4$)-F0YN*JzsnCt_&+DH)W{A_4W5in5#rnLKOZ0}ejDpkf zky6`r50Lu-VR}q~sbvycrX5P#v*yrJd}Kciz9cEF*H?3<&e!NSU$K!42Y!}p%rfk; z5zOOf*OxaLJ4$V){!6^AKd9sxN3ti6o zD1nk1dpgrMr5J*&%&P#tqQCw|@r|>7rOZb07vw6`T5h-&hEd*AQ(_;#lpB2lN#O9j zUbg@>omuoAc-Gp~a2Z|^BZxu;e5R}Y&~05&)!I~fS#3Jr*eU1C!suIJT1q>w5?t{= zuB8FUScbqv1$UKZSpA7-`?9G^s`F?PB?eKSe(zCcT`C3GT!P>QYn6NtZ|VF(fS;EQ zdj=DO*}aC37L^38gq`B8l}t6i4E@>@*`tLQTvSzQU>2ku&Q8KnZs?;}Pto7%QAb^O zg%|MOQ)KjFNsc)%hYtPXWt;jn)?Dn0$+_3)44*q|=X;pFSp7YsZ{bb$>?=yav;83` zzc$I0mm?HT{BK>ki3BVC4gJLE*a%;iWLzocSR|)^eX#lBaab$Y>0a7UgZPK}tcEqQ zAwt*AHIxM!vyG9#UxvTt0@vNLrO0K;&)k zT~_=b}aGkO6^??%S7X9T?7#~$}sE5_y!kdps8}T+q36QcE!J_?L=5;gu~%$ z>P{W<+f#~nMWs2X)lnE8mF?Uk>UOtZL4W$B;oRMBiob#gRT)>LImf~3d-j}iNi}6@ zGAJgdWr#W`mxzPFJGU-F-)-`G@yNC9hf|(f5`ec%mX3;oy!6;;uT$OU-EoD6<`1eM zEi6z-h|vFR_y5}U|Lw#9+cGFwn*Jm=D(Wzty0Df<+55v3Idw(jU4)C=glOHmq0xN0 z*mU&Snlky2>-7yT!!mQHeD3r(e%AIv9;W-(U^=g8R7DK_eDO6g|5FlQ%hKGcKU^bllZYfR&U>Q7Ckhw^+AFHxlGviO2uB)dr zjG}7n?*bt~e>~zKG_Ayb1-_Ado%hFx>)5WOu`$h~R{Cqwo^`%HT_|oN7nIzU5Y7o>V zFAe2o|A?-RNJ4%2)|61%+^jXB)wQy*^P*fkmF^& z?XKsJqPjgFv|YN2{l>><0RprP*|==-QeDG3#q#+BI>Cits(Yw6N*CD-p1~s%`eux80>lO)uB#jd*5UNIk|QA450974B5^reb|V-?&^k0FNot zqk+PjALZT?Xq69>euAm2GsaEy>poZc;h2*bzQ64?|HQr_ZN0EMSOgV8weq~FT)AX= z&gUyb2o9rn<=AI6?vK9c+qGI5Gq)p6=ur=2smi+8qaMS``Q2egoxZ6xM04cG4&SOw zM1|~t`bu#(%>OaQJ}!ZHi;xMiA93VvOjtI%l^Dy;#_NSs)98;+X2llojpS=K;msTQxVyq68gSpEF^67)uH70aqenJ~3v_g17-I5B-W#d)&F`c8?YGtZUV z$Hv8nSMP7#irC_0)-AFLT-M3u!C+Jt8jtu;RR26H#Tgb3Uvz-mD|u)P?cyEGJh%_9 z`ZG4kC@6YN`TXR`VgICsKTOyVJp4S9EKjntFYM}SNOlHEe3B}RVPH|aIs76s?97M|Pb^9t-ZXPQAoe^=Uhw|?ML7@l>iNo(7C(+Bvr zaYbv*&YhY^2GErUc2)62doOEqiqALby`x@cm=_9Q3A`|rEAP-pU#>S|5!Hvaor-+$ zTk@2!XQNoi0PeiG*rH5rT7DQV+$HoH4iPn2LuTBT)l_0hM~|5vVh{dP^Fs704Kviz zo4OVvGPLoF)|;s|LNfcWelLs3uI|+7vro1;+KsC}oV9o*e)7bK=M|Xtr6s^IbbbAY z0?PQWiA-$b{Kt>_xJyO~YyfOI&LINxfqf}vjz86dfMV*5OkTM-Voi8?kMa!7og39k z1usN@J<==;U}rp}4wcm`>`Bu76Cbu!{Xt<=$1J~_ZVD#mH$(nfxW_?7n{y%TkJV#p zHcCGQ6kKCgqYrE1|k=1P?7vH)4L6DYTYW|FZD8+Fm(B>|15uOmd-;0 zkHiI5lM&k=?=z32Kby(1)l)=B&dA=Tu31j(y@zEOoTJt3Y6x>5LFl(=WFky8*!(Eu zDt9m9rE6moJbyOmBm2#I&9keeQze^q9o#-x>dT(JzY?oL>uB}qr6=Q?_nBcoW6g8~ zey5wSGZ@~Vm^l8TD>c1)d6jSAeYI$f^qzs+2iN9#d;kajIK@T|J6^dQ_x{J$E#Al- zD$QKxVzW${INhj;$T+yYTU~?spmhV8U2=ouZ->N^4&(tcq2ya}f=GkyhM4y>k^xLu zri3s~RL3 zMi!-C38gy!hOfa0dIslq!^-^E#WC_Qg~sNO4Kt*r&=-ybI`gF`ivH^~6Pl~=pMNIF zj6KYY9KAMTdrzO2i!|q)(cX8lDGe5$HF&*(lagBm;~iO+^#P^i%bobbdAD`_r-Vys z@^9fF(v@Aa>Ysoy{3@S1bR4jO4;&Mp#MK-m19X z9KSByk!vxj=}Q{&3v$^@t{kjjw5A9Sl7qMQlc?68rWTEpnFoao98i1K%YX?Ntk7xC z)Q{IL(c5(8Sx^id@Q@B@eeds1CN139IS(y1Mamt!o5XhaGm`K9g(YrFkp{BbYTFLm zaG&{|b10H8_hLS|-9~tTsEGwr0fzG%c^HHj{aAHj@(~x%98Su01FNTHNv>eeAU~ug zGvT7{QpPY0QuX(3$$p1S`Gi(TAAdn=xab!JXW(Tz23wmkNJ!~L9SUSiC;IKC1e5a~(-n8W;ZgEaZpk~I zSQZhV!dULx(C)_apELR8_R%vtDIVWP@2f_rk4AaRr~QC;o;EAoXgI^TUUT#HMD(NL zbF+VPvfcF0`RWZ*=r5%!-W&3bERzX_N11f>xGbya#zw?0&JXpjooV#q5dW+^H0yNe zc%1VN(&;Owt^OxuBamA$h5xrjChy4G%G8t?+?8-~_Cs~Mrvmm8J|?fkIpfv^e=u=H zLsw5XvUXXHIlGoGY42A;?28{Z`cuA|gd5Vw$ zF=6g##aJ@cT%tBkp0K69R80EH%0X4RYQ6D z2RCI}ucG>%=G+4$Llaw?JU?N267z_)%!05NC&G5(1W`TxV6W2mgGP1{I*Fc z+ulZVm1%@ssrBWB?Ur52%coiwzI9P=;-BR|d53`3Wj=n5>z@;`T-QVfPEtV`IJ9Y< zzKYPS25Ya^_0Z_*?=73-xjYiq- z9y)9*nmlJu_Uj0|k$L;`*nl2?W$^yB0LQXtPtq=S%Ca2vD8KQD?G`_|gA32UMX}olciFtVnoyCw5|!6G5S0j)jAJ){Tfub4uU6qPDFyjTB9-UN7r@zafNdl-E?eG z`J?nP9Or&-nvQ7RdZvT8(~d5Hb$__|aA(t0s@jpO;C3N4*9xH*jIcZshAcT%yp>aiL1pKtO8Z>!Ysk+7Y=_66OkZl`A$HB3b#l zXLde$vVR@_I$p4u@vYDW$MQ-`e?K6Qzg=FIbUbBd~Zi0_okz)RNlpo2hXPR z*i@ejcj$fp>(u`}dG7J1jY$B{iC1sk>wTdQeJ9Tkda+ZB;$Le9;Rv*z=Q7jX9SXpbrhdK6Oe6a=39ieb-?p2gy^srdoVawexPg k)eDwZd!EPtb}ycnf8c;h$fsZ#CB1D`SH7!McH08;U*LCvTmS$7 diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/gp_hash_random_int_find_timing_test_local.png b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/gp_hash_random_int_find_timing_test_local.png deleted file mode 100644 index 1b31b7f27ca70c8909918fe056b3a64af5ece172..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 7916 zcmch6XH-*BwB}9d(xq1s3spdZfFObj(tDE*0-=SDgiZiKl&YW-=|z!_bg4nA5W3Pr zlOnwrDPrCYZ>?GLX3d{@Gi&ZzDf^tgzy0lRpWK{#?@JvmW$H`pmjD2uR#j2d0{|!r z03f;KMBqqFn*k#L5CJ+G21=j_05AZ60{|KTumFH3STGm>g99)$0K)<>JYfYBj|K3c0b+yD zAQl)5dgBRs2nQSnL&IQL7z|HH3tDhE4337uu`oEEzyh2^!(nJN42^}M@dQ$!FBT5N zqG4Dp42uUjf}t=x9EL~3@K_ig%nGsw!9da=OOO^g2POuwL1+*Q48{`*BG}-8hQqON zIG#`+m=?6qXgC@RN8<_Qf-JyEEEpdKJiFdCEtx_wbF zf$~KSgyvt+B2;jZ34{ih1K1@{Jg}yVR2M7p|NEPLKoA$0l)^*B#2Wx8FB4vn;pvdS z;NTS>r6)f6?rJi%r2N_QKKl-SkyGP0ONZ~)J9T|OX|nwVTA z41fsG@$is9iSratC`NL+L?{HR$D^Qd>AySaH9k0Cy^^{Ol{|v+e?582RowN`{wd5cuBDnI>8xNv(A{3zhBt^JGF;_`Icsv@79P1Tn zs7w8Ia(==zA@1=zc~&NMaj3_|NEub%v!oFi+_V*v%mMe(-<$0fU0&{v_T0}s?sxbd zQd>0Fa@qZ7iQ=OVt%812RLg(=a^vmp$EIHCK)MO7lu<3r^7(T1opt4?tL7pM-1-&I zrlWUbE$9fIZ z>Dn}dt7d<737pkU7Q0PkT@p43cbnR*FqOP2Vp6a9VlGdz)^-q%7n}N_eCD>8ur+pL zPBLU^A^Fl^aag{EM$!=JV&wGfvUAme-51BYf`p^#9aYKN#TX~y;KPPw0UO=ZyEmoc zZ?^>RY_p!5O;gmKpTQdn;y|~%@ra>(>B$$gH%d98lf`0zTJ!JuY?V~c0o;xd--O_# z@1q)`s~A#NZ%#zf3NHQ$=|dFqTIb0RE~DvH)F#H0_*f(PAE$CU^o0=73;H<*(Ycka z(z{*0g3+n^qoTRw<>!H2qmHwY#sjhFH}tG3D9vltzx~U|4q+N>($Rp)h>AK~Mv%3T zic=MJmSrAM9srE2wIX~0Im$N3yl zu|U54a7qhl$3t3*Dz#@!R!r8-kw!Bw;)<7o%Nez0hhc-f7DK}cRzLsM>&!`!e4do` zH&&Jv_|<7S04{#))QgG!k+Yzb)n`o)QM8I?GtK*^5%6z%xA@0gVFqm7;meQgy#*~c zz6Hu?9%ljT^>x0sI!C;Z;`l;-osjXTx?%6qyH6eJRx$0#L5vax&>zWRV_(uYgl6M} zr@sk|AaQ0(rk!KNpC?_OHHY|I{Z{O2==5NcaiZlJE_XD@)BTytRU^IkXi?tGv6OYm zp_#6e%j(CMA7RszgGlAO7L}Bj_AFS{p2S+|tjl%a$jeI)m(T7;-LBcUk$4yvY*pVX zqO10V&*Y#a@PTwk(-gbwuGrvH77Ua zBuyp-L^aZXF#mF^VS0~rDRD;uRxuVe6xo_?FFWI01)g!eN=Y%S9~yskwnw+gT0Y3~ z$H_~bQq3a9k!W&M+zHVU?El=C?iDe=Or@Gdj+qN(V!M%fi)~jHqZukE)~t+oFgZBqAj+6(3J?w{ViVW*#HZlZ=ULqxgfUv=hAbt<}h!CAm5>(D^ow zVxpts>we8`q%#`iF*J%& zF-NK0y8~6sf-ZfsB*zHf_VS`Rd-*R_mPxCR&tzg>aMkI3j1o7t?>F!~HHDNSeiw~c zHNd{XRxB5vIlcX=_7>&VvuA>H7d>X(aVcwYb8F!?8XFUKOMFXF&hxB{o9u5ul?ku* z??yPZKP~aZLDFJ!vkL`Kr`);e^>J`g?X1>axXP`gS!j3O$@---&M`2%l>W-CpOS5@ zwoai!zM_7YCq^y96690rSk;{SvVbe9f0jLEbLk*8(1~-5Vs{+0s<7XDI>4-WPNbeYT7)f2 z?mkRYR=4dT>O8xPd84(3<|sP8MVo~mr$>_M;~_UO=let7q&h6|zVCO@fJ~9m2FLea z9-^JOAL7VV-1!za);0RxP<^nLE6)(VVb~PG78pa~qg|VxSop>E^LBNk3W^?iLp@ZX z)<+1l=S0!H-FG0QprKCnpbJWT4fxO9!K)JDjd&97PCck^7gXC;R84I&{!S&vxY;Je zgL=f!%+s1`!+4LO!M5)xu{#LymR;9b8vI)ztq411`^LF`!W>c>9BO&`Wwt|Dkj$Y z2ck<7kuUb1S*{Mj3F2n~1RK*!j$%9r|KDxb5H~OyM1HKHNZ}MGfOfv|O{Un$pa=+c z)JskQqo&R!AzEmnZu$X@fsog<^^>qM`~TH9h^?Nxg>IMu;X^CyzLrdqU#gQDDZg$l`5LP_tL$?tQ-u z+L9zG^6^_rbHxop;9&n8VyK8|zIvTm8P(8~ry9cqO38+R?7?T;D4ft!*(pl5m`oHo z5~cQh8K}&C!4R!qea{h31^YKGHKL*vYu|A|ep&e|QG(5*8hX~MHPqcG#fbP)P{Rc_ zfj#_2mMm8-v61s0O_T>M=p%77%BjrZaav@r*>Tt6vJFqlADO(s@mEC49+z%T5Y-%1 z$Sln^{?V(8X)3DVjwFCE5PzC)obD zO{=>{_S@(1R{e3cloOmGEh7061PYPlgXUQ$I9_b7JttAL8(8LO=2&$P)l@G!z& ze1(Kaj|bCg9pH~-p@jr0CXgmkGJ|K#{v*WrwbL`sUbw73u@)b3pdzh;al^jfdibu) z=!=u>EBLY3|H_qpZZ+MR@0CtQ{#`dhjbE!r^|SA?FXU%yPxg$QuHQVoh+JMRqIb7G zm(b`q_de`$v6=tDP0aj>>?qoeYcr;X5m5L(=-OX<vUsgJtfcO9sW4w> z<}trXUYf9KhidHQ9j_-++HA;3Z{;a-o6k3E+=BJ)6jcz7VT{sp(a{XcCSd<-a`MRF~P1ZH1V5j$O$rs14tJ8+hVTxoKqZ&*M;2U4#AcW0A(3 zX>C^DIRo65h?(afIZW_9&3I-@n&M2$8X18l+!)UF_||R7?O3s9|DREktpb%UtztW_bEu zBZ{jo!?mNyE8dw-?S;+cW6G!w<8P%8!W~;vh~EO>SwbK>8T<=_{C6*I|Bo( zFwZ(oRD6kgtsc{;9Tm*;2>v_1ZO?HV`P1DxA`hRp4TYG(=Xo$viYK@J$G6*%LT4-P zK051J-DVXONjjan*`9iNtzPPi+dg=eldzZPZol7mUMMdN^VCCKeev_b0kvyw^DaH5rdll{f;Qe2%WI)A zXq6(1Iv5Mn>h24>dj8Cs_4g4b@gI9MX%2)Aynm5QLlP|*D_P!JWGyi-pZpJ6&%hIP z+mYyOM@)l_wfiIWMjO$P{TyVNRI(A!jT|DC3}T9X{P)GMl>!plE=KyyI)b(h^~J9N zSO_F;iTE`#n+d#s$%QL;mv?IcZo`XdhmXqcb1%I?8tJX`oE!S^DGb#w-A&{q6^m{# zZTFr~m1Ezs>%Uv%)PC*!qYod(X`Zbfucq&m8Y6BU%H8=xopF!1M<%Bk9<% z1LL7|z(1V%%b|PEw7H%pYqp)Tq5rQhGqA*%1D26|03TA~E#gW!u!|)!7vi?=H|f)W z4qK@qp=pbf?k*y(F87ms8R#i#J^GDpzFy8Nzx3#|XhjPZy6M(DyEIeS|26%IU|VEN z6HaPCznNZsX;Q~N&M&Veev7!S_R}AEb=7s>o_dpb<&>EH?Xk2?#5-zRu&x6>g$`4( z-b%X+4Z|RPH_j6AdwDIWcoOo*0F?7Z#ohRC=)`)8Bx$-ivE)8a#{TDwGQC6)nnx3y z%D*&JvMcY=S>LuF$&5_OV+`B8GI8NQOpzo^XMI=yHG7XaJ+YBwm##E}-aVT)M9^X$ z=Zv%GMax7&sSEsR6atxI-vNkGA_r}$=V6ewy*Fnh?CKqco2on*PyP#!0<@Sa1VW?o zom07>NYCN+|HbVpj3hQ-LbyVj#4DeqXnZtzn<;q;$Ebk1m7-Wv%2Gle2M~`#O*V55 zdZCaS6r0kl$m1r*pgx>AD-p?oh&F65k5X{pwf?^-D_GZ zV^8_ZNM|kd&V)blyQ{&Gc5^!8V>neJ(=F-3ag!?iQJd}i-8bn`oluh@sP6`I7O^y} z;Q{&e?nLJ9$20$sV^h4yvdbjD!X*j7VJn`(=5C?TA5AnfM3xhVLIYR8(TF=N!ne*! zx}{pwRD)mugD%Ia! zJDqF)vSpb0oIry=r}l^x@sl8yZTh*s_H9?MYP;Lpz4H!VZ>W69w@1D)lct4aP%G^R zK(vmy%`Dg24ZDz|N#ng&jiW-9QCJO3b67{kHg4Zo$nOrs_RK!SEn~5i=1o#42!o7d5ebr*mb<}I+<(vUyk|GJA~0`mccR`26II zkJkYg^7oqW;0Ud`yHh9q@=;OI>DyOlCVerV$ez8zciSg=TPNuWxp{tz?%JW(p7_@L z+#aU)sW)q|vvKlEb3N%Lo^+sA`D&7L-qz>)CtdB0!xG!7c5R5W@-1hxpPNhK(*Xt{ zom`fUu!Jm11ry@J%ul;QckVs8(^JnWZ&_13qcjpxpA}K%i>-!A&1dxaQC-dJ87BbGi3lZ6`Wvfl5%BvyXgeWkGZPOrsFz;NxKPrI_QU*xuN zfU0)mvG*O9#m2X@B+ws!M$&jsu2 zne~?E{7x0f!Fln%9aL=+75K0&FaGi%m#%8SY5yYkfCc6V4~`{g zCT(H*y5yLaB7aiWtbhF(8(4EXF8JrSUr)*!$@+M4_alz|sM0llSLBK14x&@uHPx9Y zDyHu2EsfLcpRkmw7&ThpWaDZFuT0dihsNmWA>L3+j)0TmB&#e*y6y< z=IFC+Hhs~6e*${3q(rJyha#W#&IIStKeV^FT3RWfe|g;L=JMEYiC0&a<`B6i0fyW` zT}x1jb0hL{iC}u<&y(HgeBN4jx~z;HMT+CQmRA+Tc>n9ufZXb@=+0zR54>GDgjw_@th^4$xamAQ~^c$3crl9Qvi zoyuWs^xMbx_N%NvDUt8UM14Hu#!BVOejm=-vKDVY$OTjV8Nk1OG9p@ zExGKQ3n51*?lkukPYsw6`#Ik-hnpBFpi0Te%kP}~JRFAJt7djn7wz>TsXOK7!Hgcj zsFE1wJPj(D`(@OMt44bJA6h<8Km9&e1q_r#f{x-peGkGlX+uD6;HU=Q;*@FKVuf&9 zx~VVRZ|4!&AD9~HBh_^A9`7(f_G8QPF#J{;<6ME#(=4uYigIdxh%Ctf$^ZI%#GT%{ zf+esthGWORv1W%elD>JA-TdYoviZ7*Wn#a|l3M*$o%gW|W2OtAfWe21n7N9Ts=D0W&x&*X3Ooz1p{hIW~mnR!02D*cxX^c{LZ zt~vD7;oR)w%uLlq>p5`j=Ip$XeMe|&DV4rdj^w~~e}s#NlZv{6E=jNL z>x^QctTX`@q#3h+e2Jv{;3+e1M^6LQ(-wWfQKvolUfM#;X;R>avC%G*<}|o*0q`^1 zvFdkH@j#pdwFq@KuxXQ0Q!}5_JT;mqsvv(WYE{bSy4?H4FD0!Xvl+5v>83}G%&}t| z{$Be(wPPf=K7BA+y`JC-hT2f942~O_|9J0`(syQ~+zENF8Ru5~^*Sv$sVNU-WbJz? z!mpvOt@`N~g61H}^Ppz_p#mzh(F&!FdnL4Qkn(QwdV<}BZ(c1E3-pHd)hl#7tn~l& cY1qk?UekhZYt{S7gy)2+N?MAg53R%h1HxK@MF0Q* diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/gp_hash_random_int_find_timing_test_msvc.png b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/gp_hash_random_int_find_timing_test_msvc.png deleted file mode 100644 index b7082f2860514bac85590c14eca7a93a1763475e..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 6140 zcmcgwcT`jFmJLEcqDYM>y>~$gNG}0G6%uI*CzVGa__dfUDuQnE?}w3kHEen2Zed z%ps5?NC>m00;3Kl}a zLntH&1q1*aKm#mL40cnfeW(W(fxsgWBm{y&Z3`kS7JM^K8OU=b8NfOCn)O6rdiE0(-F(JeESjQh+?*2cQY6 zfgM0UAOREt)&LBU1}wo=zymY}*Z>+}QK-&Qmq82;5*|;X8VU4)wjd&r@FWWG703lF zz#^VP!c%~cz-eFr;03k=qk&prCGZ2#1l7O}zzGNj3IS^X21tWSKnw5yjR7`*rcg&j z-3^vO3=RsI7%&p(18qS>qEM&<{4;(ki$4>k&hyWZsHFb*P95(bE2$j+xI>-xAHh`0 ze>6~s|A!V;!Jke58e9%wO29mz=})UaSK|NsAD56YUeJ{BwxNwL1agdx`b#q~6|oPJ z{C=p*eimL>zd%PH7YND%BVcgD%h%7>*~jg+pMdf?McK3R838#bArOv0BR!;LQ1-9*rIeB9#5pQR!T#K=#|a%B=hl<(QIV5c?AxbV1t4 zyA1!MlO-kz!fSy-&Y9jVxr>7^OB`JVr^EobU&KK7il->rFuUxXc@68f2}PG2#7PI8 zGP`maiE9??n*TZEYKG=F{vnS<1`|iPZ=+?pXVkmZE3}Nr;?)t9D~5|NJ>#xJpyz&J zS!!!Nm!(VGA_LE6+RKy#bV_0plH!VLg)DC zl1Fm4nB3Uz2SQFg?Vz_`uiseDxO^R3RSi=lQ6Q(mj7K(BU1-_n6@6f+Md`|}u*U<- zkMiL>7UkEA750{YatCX7Ru+=|eY$vLGRi+T!DN>P74BX_|1kn|VfaMZT9-(#}u7cKcquLtQi=xP0SEb@(#uX>(O)H@PIg=@ye! zx@5Pj*E^f7j4vm%%qm$Z1YKESYzaTr#!kwcqc-7 ze$zM8nxfKc*;(O$lGsiyz_8D&t!y#P(;XzsvzJ4k1@NT28A%G+uW>bayboC(x#^oPln%CyvFW%i80*u?(=gT7*Y<>cSpzclpy8X( z^=$i0?ua;Ol(Z2v%H@ra5%7NXZiH~X>#YI1vg_;4627eYIty1h{d!v-FnXJ zbXDgd`MmBxXQKFc+0hcG*#;Z4k8L3wyFyLIKQ^q3ue^~;S+dAz!e1l_%^Ov;_#9`6 z=B}JL=hHTnQorC7msGW!Ubb<9IB7cbM4Whm<^CQXxw)KJd-^f9A#-jr<#S5A3;!c* zuw%~=w7@}b7(Ailx}>3%OD4{8jC++3KKsEgVy#KCc6ZO?p4;@ez1d~0kxLg`*9lWw z56cAP5+p3uYLQq2x!xYoGKL5L%1PZ|H_n3kMZOa%0H2;`ySPzV6il@$NqIg zt2Z{hcPI24L`J~B2kdt+SE;{=_Kx}TRlFQdEZPOu&3I(J;1gR4WNkXw$a z-Pe=;aKgwKd4Tp}Tkiyp#JCXpsPh5O8lwyB$C@F(NQ};r@=-6zsYxniLE_^5{xfo4 z>6w3~Bq(fs_dq6l$mHT??Cjq%@#V%{Rou$)KrTg&+6&hSb`Y8*1YQ+5LZ_zwl%lP; zeJ+g09l=SDTlM{2neJP6=lXy>2g{ZI$=I1a5)<_qRr@r*aRT?@;6iIJ_2V@)v?(Y^ z+w1N!jy#br&=&K`CcS|?X!464gSprfuZ%E$T-hdoWNo*?z|D>~$r@r5yd+8mkh*fm z**LoQY@lf|{IhwhD$NxE_s$pIoWKa2?P2|GQ03vp9I3Cw>(4JDp_90Ff1kbCCc1#{ z6nm~e?{C+W6^+l>ru>G&lk$)H!#B`1r>7haq}jAOwH&>1ED})iZPi?V_TR2-gI(Xp z@8RfBK_Q7k8ef^Wf0^tr>kEb-VTy9);HdWeEEHw+sr5)^?G!y@Y@hSK03~vhov*E` z@{@XGOlP`s*#XF}Zdmk+&M-uotprNA&sc(k&~&Mje4VbfQz@2j*WU$)ZO5lTCdkaJp$TUg*69 zBm>Qp|L*JJij?70eAYo=tMBIF1oOL<$+BS;aK5b$7X{w z?eFUpbK=++8AbM>R5$g*H;0EJS2NaiYnP@XJQwk%tYN=vMpWb1w+$%U`o*&+T+dhA9C^zjz-!WrU zGCJUvX;VVueWSuNCt58zFY$S^nnHZ-s@Q?OIytoeu9Dp8fnYenYJs@^gvTaHAlCX6 zIT2QNDp5QfyIiSoD&L;oVKrjEMG>2Z`%CIysSr0%Pa8?aK?Zkm}@C zBTU~6kA+-fGi;5}@u0T6k+)v8YGb;Aj>9khiX~@^xCU3x7586Cft@t&OcIN$uUOF` z?p1bHZFtG0TSmDK)J_bLO z_wEVpo<56@Cl~2PhT&CvcHmRwU7YRY6isGS?NZ=wq~_7d_cj;z%U##JUS&Los(uSW zRi}d5pX1_8ZSZ5^+ne!C2-t*WBauaZ%B#?N|YK*ZsrHS3t@S6zaro50q!mD zV(d(f$J~>r0!b&_hW#fJ&pD%5C*OJv_nmxdUjKIQT;h+uzq&h^k37n^^Utkpj&AJo zI_4J%wvHEmC3-!?F=W2=9M)i4PMISDh7ZH?pHGZvjf@)T8wgs1md_2X zF~O~AIi#mmgQH94q!%WaEwsTrOPy%Zp0^u$u?p8#Rn2ol4yD>B?^+4kHhm51SnyQ% zim=OP2kFn>ShcL(zuM&SCDMn<~7ft{Exm8?tu(6!P&3<^k94P|o`|-a7k^l_L&V`FXj6G{nBg(5ox=SoFH`JzFDKxnDcD ztx!Od$mB6II7L*&$1+v&^6Sy^Wq&Z!S=8#td;zA$wc0ntgU!$9^ZpSx`~s?augWOn zs@elwh)91*53uIQzQEhR-KRryO-5}YR|&0GS1alNX^5i-?|pu{2uL`~S5{kQ9e%oj zbHsAb*oRJ9l{C=Jqn`;h%x}c5_Jg?x4gA;t_6xq!@WtR5f(WQq>1)UQbj&##+3K~$ z33{#4P9QYqXcPjW2nd~z`MvY!P!~UHAacHAcmab+yz;UZm$ti zijVU43T4Al-x=ISf>g5NBr}3Hf(E8D7CRKYL>mikXvvFph9vRJg@Ekm!I_0ox1L|Y zWFLc9ef6}BOa3?UpB;SpRC4`hbU4ZPdqlPdU@$mWZ)LG};oz$al2Urj61t_euaxq% zw;t3Je47)#Gyqqe6tfx z-#Gq0Uu|l7eqL_-{^VI zjzU=Ge6PI9OCjU2k2y-W*i!tqOvH>56PzZ@zphMTt8R)r1zW5u0t%5a1WQR zvsppe>Icrjk2dtWxi1CRyyTga*~uAuKDp);5F&8ft2yC}nQR(Y-C?8Hu{8M4$t*c3 z!TB_evv%QGxWn+^fb$OZBZrC(C6@3OXSvhw4khcA5~WI2>=GLUO^?MKHMrRHk;jg? zgL#1S3+`BG{L$KbeEQZ#hRVH2ZZi2dvf!Sl!OJ9B6L#X}PlveJLuKM_(0+bNoA2RN zgdU0_Gkfo(Mrfdhp*nZNU*~9w;*UjH>FJkV^X6L23qJx2xg9+=ZE|V1ncu^^*Z#0Z z@^!7UPLcM{N=+WE&fNs7zW!dm9%fe?jSek_96~Fr6f_W3P5g~?5#ya#>-{9GQAD;w z_ull0G`^Rva!RW-iO4-W!0K(hb0%PRZkBDyd3wBs(6<#Ugskgi{%&6^H{okt=txKm z_MkjIlGEKX*RzC*!$&;L_A?ANp8ulyBfQ#4_sOlelw)0;yo#1uR@3k=af7~KbJLdp z$$~2esb0e0<{k{S?nPw=!4Le4zq~?ca&a{|lsZZUNv32+J_XrN07&Hz*GFu9S51`0@p?5J^TD3C-lJGQk^q9cFR|*|1(3^)%X|VMv*}S z&V_bXW;yA%r5hOL_>wk%e_i!vL5E=cD)^i&9^;xB=5>`{tbYpv_y#Y_V`+Iz399gk z<dm%(*2eRpL;Ut%U%qB@@iL`Twmtm3T>B$&rhV(2iBM0z z+6(zsBikK5(9NKJO}9Rge}5?dpGDsN<*Ers!VQ?Cdshdwks54XR=g7#&4tnLUFin? z5u;=OE#`_L>Fo|j6Aj;5C_jSmdOILR9z~Qmj3(c0Gs?8IBMaoI?#w<9C=yU(JIgU- zr>RnTRdR80B0pbtz02_tebncl*-0%@cbix&1We0`S6uWp&qyxbl*JkxIVtXD?lC8Y z_~mAVRIPuuZr1c%m?kbop{w2}?exy|kK%EPP0wXI)qXjNsaRc3(bx3<<<@I^OEEHR z8cVF>($VyK@!6J1FmKz2_TbMK8Kz}u$8Gi_EOzp*rYv;v%!_B-XnnHNDc8Oxuj^J-nWp6E zK4;YzZ8xj}PxTI(UvLf?_Jj}VoASeE5}krSq@2s^^)_lsa60`UPu=Q_A9kfOvtY^J z%D#m(H0&xB7(J6*+Edpt7IuDo)#jM%wzO4Tf4e9}+oI}LJN!v~m2?}%`xvUTZYEhW z&t3ZLo8gI9RU#HeOsRq+Z?ucUYKU(a#~isw{CkJ8I_qjuJ))!rVex4O+#_jD6}9(- zW^HXg*6XCXLE9xtlb4OFt;V%a*AQjqNa7g=vcD_fJL-Fu7SDty3Y@C&y~#G|Gq+9F zyDn)lrb~^Ux*O&(-1*pC)k|9L#-nYi(z>FT_Uo@}EylG4x$MkW&gapYM6JuAoK0e< z=6yQ`DsFffRgZ+3Ux4?tun^BkZe^ll%iir|6m*HUome-j-_ZQK>Xt5ec~y0f`tnMG zpGbs$wy}uB`Sg$5ULz`^BqTVgDO*+?PM(^oqo&wF%G&PVc5#E0Qy@bS^nZ8NS6>zr zEOrT1bVr>C{bqBycyrIdosFwrD7tA?W~J`siK`EF9n`Z5w~Ad&)?_d&(MB@MYv%6Z z$=9c*3U~S+57WYC1Qc~O$Zq3Ph5lRwR~#;=(k}3YzuHah3BMORBM$z=YW4;i*vtzv z9jjRx7vYWD=OGvt21Se{^i0Fe2jxRgWzVY(ev?IqqJBv0-sIr^koEwlEaTH&=iXeK z9oM~dR^2VB{mo8)%_r6@b`iW1qvLsIZLWW*UE{x?;-bl8P$f!zZ)$`x)2q_ChWihk CJ2GGZ diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/gp_hash_random_int_subscript_timing_test_find_gcc.png b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/gp_hash_random_int_subscript_timing_test_find_gcc.png deleted file mode 100644 index b9fbe00deff6081db30bf14fae9d942fe652f8dd..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 6110 zcmcgwc{tQ>*B@kQgvc&i`5|S=P{`6)8cSKSFA*|i&y4J3kiEz{cCwVQgb1OCs74qe zgfg=4``Wzscz*BmKF=TTdtJ{z@AtZ9Zs$Jde9q^bbARu--O>8G2nHxO6as-TXlbh7 zhCnFc5D3M6Iw~+z)_uwx0-=KF-!#$yA_M}1K#&j!76QRTASAK`gF#?O2n-8>;UO>* zS&4)}kVps;3qj%`ND|o=3xi;h5G)pg#Y3kn;AOLIt4X}VSuqKh?kRK!rhK0fKFc^s(7Dz}W42gvy@h~Kb%mOH}NEj9i!{T9B z5}6dR#Uo*OEDVo_;YolaaD|bOFcKCc$0PA1kUby;Y>^}^l7vT+Kzg7afF|$; zmJV0Q84WI!QiCj6d8pzV@aTnpwgfKfEO?ag$CJzQi6H_n!p>B18@QfgA4&{00u|{Pe2Rs0D%EEfF_Y! zM79QMAcKblItB^}@&jRkgeQ^64Loi?nZ`}eIUR>OUWxzjUk?6(yddaFPfc?a1VYb3{!kFcf)BwY zKU%{KZRmkS``CIpKr{^X1rSaiC^X96>%J#iK<=`vgp_pJ!)$g4gw{Z*!m$7qpKT`r(}ZcXgAXo+94S+_Do|E?Yfr0J|EUGF0d zgyBCLobm){Xo{mT^O+Dm3Tg^&{nL5mVeG=JoLdS;^@mZOz;!Apr3@H|C#kirCXZOj z+XteUBwQzIqR%flPTa+z+Kbr`yVd-4B2vwr!ZOIgmHfYME;vA!*P<|sd>>m<-qd$? z^BMHvgBXqgX1U|y#o{MrFe^9lwWQ)}E zZFhxvRHkNq)6SY3f1!a@gTLEAOS1F62^fs{f}Suz4nOH1VG3%~Dn`ycu<(2ui6Dri zG_QIebUnUzFu3hiE`U;fjL{`v0yc314T6uwW8V_h;rro6lEo^&)3GR#B@K#JHr|U) zqqJ``&u*=sqIT;%fB)#hx_O7@NMW<6Kz)G?wOiJP!_n8*?I#WkQPTX=C+cq0_-(vo z9DdC~eZmwyV-T3z@F^4niC1QQz4u4Z&f=kp;VLXh^u;9|OH@*SC8px>gm;;vkOcaJ zSGDbq4oPj!iQ@$In68yMy!BqcPTgWp1ggK}S)`}vi?XeUyvw0Q5xgbl>_>?yIk6N1 z?-F`Fx>M6ASk=2SuM-GJelB4``&V55=3BkR$r$TOfjJ3QQ|8LKJ-_^3NAIikKArM5 zaz6Zt=|3uC&Y7MG>UX^)Eo#E=XXEXt^i1Jix9?R4h6AjdeQSJQH~wn&&3Q=;t-`CH zI9x<7rM0A3wOrmkXv6iWL8~V+w=7q0N&b;H>qiCT_vXxrePzKaocw);<^H&`VqZgM z`&>bn(zgD_pQC+;C4TRcGS!5&L1w z>U_TiJcPwyHfTXlJHR*%{i?Y0UgBH*sD-AR%Na+-;uRR>Kjw1|^dt7`tDwJXZ2XQAWu$)2C%GWAq;hN`Hp z^fdyg(yu>x90$6eeivrBmG*MXd9UZyR{xfMBfSuuQSH+oE1wl#xHSVJ|Ir-Dj*Z?r z>-_!#B2stx%G$7|Mds?MWk=xw4@NGSHFvYsg%U|a+GX>`Y4aa zihs5pN8jpcsM-}}Kf5Hf@}VEP|GRK>SVQF1x3An&oDJ8Yhi>1@mb~)wO3!kg6jrvb z=HsBqma4>Lc;21$j(w!N@faiaOlGr9<9dmo%8J3IW@S<3U(Z``?xBS%`r>I?mjVsw z0}9{4SQy^X&4x1%(RPRg*61n?ycRyUfVAytyRvucr;KRdDu8ps<%O`=q9^uE z9fI@&+dfa0q~Sk_*12ETl3eF+X8g$tg4Xhr7iRM~&Ty?dd^)Kuvwbe_%nd94WJN)* zm%h*#1i|07r{G4HBRu+}%?Y$BQ_UV>A&ejr?t(hJBAU~^V(2M5V=fuS65mV)Wh;Do zRkXv80xHB6_Lf88_kJFoXxF*~b*(u+I$Qa}emo^(J=rdx3Nc9AQ6&28-l=8l*?uUc zM@c;9{rkL7i2DC*>3{F+|1wCkPE~UDsq__DJ?lfUCMnFgX|D!Xu)UV7?(gy1xq5rk z#$_{Z=&W9IpuD8(kGenmpSL^GETFMggy*Cf(;6&st+XDCwS-T8C_CCV!K~1CHK#96 z*9Y$r0-#s_5_`Pe-|<4D7=zdLesg~~E#=_y*wQ}oCAJ-R(@=1-VqxH9h#p5V<4|p* zC)>_9tx9EwFG>E6Nq^b2Wa+>|-ugEwF|ieian*`Vbm)m{E*UC)tNYZDCZFTG=fy{@ zG1+(UlFLVqrAs_96?6X70BTP@ofw^n#^QRo^i#Aq)chukXNbH-!}F^y>3y-h-5uZ5 z@lWU6XYAI#q(!hMCmN(;pln^!s7rh$ib4#{hVU%E=ETjND2A~r>dRwWYwf_SWu0pQ zsS@WPw9o1kfkv*I#y(+a;2>o_&XV4d#dY)0${(c=Q6`;7r*%Y>@9%rVisHVYhnHCM z70|}PDql62xf*eT0ToB@c(`gW(e#;YD;dVaAIcu-^G?Sp+C1&cP_EP*-cRV$VMPTaZi+rYP4jQe<8nDbG7U9GLppP6k}^cXof0*`paanqT}`=_l3iIZBw05vX#My_02sm45`PC#H@`MpUU#@J}6Zj zl4jYjmHwlsheU-K*wmR-eCQOxIfuLq2^ldynZ2>(Pdd1^jd}ANMt!utD0RU1M@C@Z z$R+U7-rhxz+Z+Ug&62!K?093M%1!)8*{3e4bGey;Wm9(?hGFGKG>XEE$H0-D{@FI z%B25b-r-4nFxjZ&_1U};0@aTCs27^C64SyOp7T2hT_o^YQnK(ObtuQ=VCk-{F8d#( z|6i7OSzXI3ZXR0TzMF}4@P%P+w0|qz@t?CO;>BQYoFM-5>~!83SL@6T+n1yyE93-nwqAya&kRa^Ry_(%ORM5s8i@Ns$;c9o-8ADu#DZ>)< zPn-BW;_W%j~|atqhYE zx5SxC9q60*4RP=fVY_evCPN&(&j{bj)AhRd*S}kg?ebB3sIe+~hRLyr*hoF2+56eR zd3*@|`z-wTz~!MdR89RD;-N&vJ>;QOX)SdZ8yCR?_foe`k6L(>^Zd&F0l4{)I@&~? zDkmOHr2P~e{%F*1f2HZ0t<2B!mUmBAO!zaZ`F+0|?MzhUmYURJ`nqM=(<&9UP_*k$ z)%R#-dcWMUk7l@UtKhACO{mj*RFXNa(Q!1yCQP0uibhesp|+GDzMmG1rzxP&(_I}z zDNY)9Yc^i4YUV7U=!voEcsWo$skASk-B2O`NMy#{Xp5^bPj=7kKF__1f4zt#*DWWu zwg#-19j&1)UN!i6FQsP{_vlYieuO`wVLjorOB9GJY`t@Mh3@=)PmU%Wh12zaD83`C zP7wuGshq+f@yRN5Zl}9C2TOxRKb9W7qG6Rex2i?O-J;i+FD^yL3I6=|(!tBmLHX*n zR=-LY{0z-J;c*~T@Y5J9+FuG#Yw!-8u6X{xiJakTonvwKs6}&uhn-edL#0_`sHf*Jm=?gsE+Lxbh1HK`n#0tzPG^?0>Pk3B-hLN5XZX+Z8Dl!T z6q41IjfG}>yqU1i`JBxkyYb;=o_!c!+rW4Bb{hv9w^;)pJR~d5HshGT)%lryY>JAp zy9!>VZUdfsI|sx(rIVJ%4G+rv+TJ*!;D59XMY?Frt}<{C+JNpl!J9bBG8= z-dNl-KXo*%OJ%YD!rPsQO*A{?kBR+%oSp>C*ZNf=$RO zRA=>ibE^0%ePbllfmrO+#PY>dU(Hfrs%$*P;`so7F|*+^Gv{LML9!oFw5X|_PSKVQL1vm(je zcERs<^Nn=XaRx#cF_G(`4j)gg%9kUHBlwN!CW4p!$u3-Fi#B3G7CW{k<#$gt z%+KR9P1guc>X%P;FR_q;9>l$?h_6`7EqlnWB3hKNNhinpO_{cY?P^k@X7 z_HycAcaToGv-d34pKtP7OAv$1aWAX@y|wK1ta zZE=7rTWm65Hmwa`{An2GOQ^ARHtwWQzO}j5rvA2>6M)2AV`Mqkcsqed*do3VEJ^1{ z5T(2;i)5E8GpVI_%Lw;HW~DpqoRG8k!eP8xFI!M~63xoLob~>%bKrlhlW-nrH&`XD z`;_!V^-ReCCBJ%DBrs41hpSB+wq@|M zjvTUu9}Z9~auK6t8tSxDxb`*+^KcF6JSWq63qREwm*TrhM5wXfTUu@WKg6HFGZOBN ziWwuP3`KL#4aV7H{X+bB9=QJetbBi}UpV&<_y;^Pp=b2phJ&)uwc|?_C##V|883V4 zY(-*ore6N!qJvnXxeAeUDZ}Mlelb)!O}$0NWNKTgcnX#pZq{&+WnbPBoqV|(V-{NZ zJ-Fpaz_7F}YOhQ3@yI3pjEgQ?x6CXZ*f#UW=bu5vzAN=_RF%)ag3c3lFH-jfR7p=> zNbf=1A-rfd3tcY3mm`H?UM6??HXFGQB~e8 z&~y7Tld&LEToM8p+2iU$f!`&z4Slxt_h!`IUU%f{oOxcTUGBO4DNsAUi)+l%!2MpX z%e*%$N-Q;F?*%@FHPRwOui+rc_GM`NNl{bN?E2(&KTAKjN0TYMxncZ9_Y6VTjVfgp zUnJ+M%#|uOV-x$;D(1s9s*`}5?JkmYR+cXYlhNZ=G0&%y>`T4=)Xox$zS{cSmnr!wUXK|nrs2`@-b7hL^aX449;KxpI2NdGPSd+i8-`<` zWFzdq8F2!msz$0N%Kzws?4LJknq^s+TVl%ZdrZCNuntf0m|zkXl39w++HQ+|HPP%g zpDDN1k!0ZWRK+sJF%%=}S?BJY6kVrTz4YPv@4jcXRL}weS>n?|`H4sbPi~zXyk)1Wyl)t`L}!m1AUF|vR!RAjt#pEu&LJX`Vj zOW?c2w~m@Sc1fp-@&%x{tOwIXm~vTyxDe*_-Sp&ce)y=``z7bBp5(K0VEtiA^{{ahy;*f02u|4aR8YFkU;~) z2BASLFd2*{Q|eF-6by!g!ALL|nNk+CP$(D*2SbryC^Cfw=)|F5I2;T|g5k&%QeZ3z z1tZ~LBod57204PMFfs~8#=*!W7#XYzvIfCG(jZHa7U%;DgV-Q6hy^B-DGgC<@W7!^ zBovBF=?^RmS~wgEM?&Gqly*TDpp%3{kw_>K8SEY;1;(PtI24(LB7^OLdVn;+Y)}rc ze~<*&A;=m814)A{!BCI~SQx|xp+PJ%MLCKaw84Xf!;vXMg8hMIL5oDfk;tH~V7nj- z(1|0HaAZ(NP-##AkQW#Z3JrD(N(t%#(gd?XIY3Te!(fLXYY+@14Q7J0KptRW5F3Oh zQ$|FI2Hl_y9%OK0ppamHU|G;2k;#++{vAJs#ovii=J|I>6jFb6r;PWnloXDC)uBxL zZ^IPIe|w+||1T{{2Y)Mp(BQ`boDwJ=*wf!qe?N);-``w=Lj}O1^xps2`vCw08|4KV znF;?5E(-Y@*!f#|q5Ls7eO&E$JC|Cn3VO3(No>K04ME zDC8-O>4Y(+?NBbWC!AJqE|lBEMJxKrR_m!hk54J=>hT=T#vLA?{9ZcL+O`sI+Kcqd z-Vr}@R`F!GB$k$$@j#8)Xw2XRVN?L=4=aHgkuL7^>dGqa;q zp`ReXnQiEFv4}H#3$I%~4Ld}!&Wkoa2pyxF>&urjMK)+-otKh+YEKNHje z^>YZz7*+D1OVP!0%cy_d(74=J@)gr==18p^aee8fgi8n*8x0hr_T?RHXQjTr4CAY4 z6V04nx|3wNUqC!y7~)Cy8_NNMpMNVfrbuJZC&S_^!FkN_>RYEBi5Ecb_VZ{q@d24~-YHcz!@XB;COFoIXQ%hwI$g$kZURb%_{^8|uMZ zF*PfBuveOgjNtodT`N0O=_jz!H!UjJVbx-c^^CK)YDurFV_CbAz==$4(Z>Fc&350n zE`8asf^a6xq?9EDwgFVlUhQU9&Mf$;=o=k;)b9SrZR3b3H2uhp+Kp?u(%Q8vYGH_d zh*}dDa>&O0djf`~>Z)KP)B4$}_rE2-thhF-PBxwo*_Tw@x2Zqo@{itmgeWYop5;dO z4=>0lS4~W{u$38VHlouF=I(Pu|1cd!O>>ZD(ofN;>2r%D9PSb7Y><&o`s;EU8*8Vi zXf8hsR~Na4jXTqZVX;WmX@J(H->)-e6uwXvz5j~TgPrXb_LtX|*q-6IJloCt{P1UH zX%M^D_t}IklyfrXL!+78WUSl<@F`VuCTMcsRC?QeTZpVGR_z^Y-*o7XITImOV6b(I zBfGRYp8TP~BqYJVnP2F0auM^5aPI`w_eplL%kSt4p!`?qrxgFR92$JkxFn>yY1??) zAivTVt?Gc4_=HU^j>aKMYNuWu*O5so`67~=xdZm)vHq%q18<~w5<5AL=KCMSdD)(} zUUUfJOX>U0I{wOSJ2C!XwX9K-laAH9pZeW5yJ9(6x!DfalO!AG>S_Greiilie8Sqq zYMOWVh6dP$rQ1`Rrafu4w&MviJ&u9>Oj~7*Ojp5V8Bu(t^j5P2i2wwgdT`TUnNi-% zhz3fn!+#^XxvV_vHD92#&@Fp|;l^#QMa!XzS4?Ho@7RU}WugH{uVp7&?gYFoYeTM* z=k{#0f<4PP&uhY|*Q#&*BpeiET(1m02yF?}xLm{FfX`B25SziTHBHzrvp}GaE28ye zI^vQD!%;pyC|xm?rq521tito-FcG0OfdN7fpYF7K2QhF7`|Q~Dm~sXau|f(r`P9v$ zf*qJ{Av$`8axWEznAgoaiS3nAWt+Y0ykCm(Re}zsayl4D&xox*d`{G^Q%7O+>V);& zExo$Z{P}wQP0Sjmlp-TPn#8pB*ozNn)8YNT>#kpcJe__VTRZ+Ib1=!n?;ejVowu%o zYo!|3yvC1@4G5$-W=?dam@{BmKmU(ER-HMpJj+3mIglpODDQrneBENf(&wc1H*jgM zlCzsk+pggUhQ}K5G5U$^K?qzyMLD;J2S*4a0YK#bxk+Q^;NIP3VJ&pjAKzS~E7$aZ z%}8@WrqAu(FWx++Rf8!e<%eSiF6Yi5WH&3#vz@jT85S#@JcTv{iiGYap`M?{_q86F z%s=+ZqGwJ8zAVDyixEXo7k zD(Dq#hKgk+y1vimTO1 zHL$D3&eVCYlqK0|uRDFFr$9{0Wt(aRa-{Q5n6jJ*eS?U8I=| zkr?DewuBsqjnAtHN)S`V^IJ=IB_M{)4eE6V*56mgKCRgqKH*xw?S5+D+Udz#nr|x2 zdZp~Ogo8UI{^Ta?tv)Svk)4!`IO5}$iCEvsseo^sv)Pn9H8G@JHGc048|Xb!Y>wrY z6*=fpY%68_gsj-+G1-ij3{@MuOE)y3%w1m7PT-8K?{q;TI)+E9Rs3*|YHclqXu^ss z;IhQU5C}`xT6C9L?@?%R8qvc`vO4bcFJDI=J1qrjCqKDBwXv2=gW)doZPpKsb-d&8 zA@gDg3)5lt+>L7H*#?^!-axplN4HM+R_T|sRps~}W;|#59lOMb2@fjZ77w&oH!x>D zI)quS?Q(BkVeV)QM@lnuEHLVeAC-NZGR?er+XnBk*I~;Kf2hfvsg^OYN;BA8^GB?e zNLf;46~Meau3u!t-B4j+0W-5ZDx>Zc&``NZ-fT6cTpy_z-AMxm+8$3TUF&cahod5O#Hqn=0?=!M_3}I|Ea2CITQYtNN?`VNO^avC`bC!tTqab3^Im5Q9d{0Kal`Ll2uq3+zpDfu~-fY zj`Ry@7!#8E_h@yn;wTV9w11kXFghgXprEjSD>@n%69ZP?v3+ZD6UHQ42=YdBSi+c0 z!80rOk{5UCkjQ@0MFl^v;3w%SS6p%g&^r|sa0Oa}E8ggVGM8=kif%7-cch}kwJ4WO z)2T?u!dY;Zr+S1#FUDFic@;F-d?*rtzr8#CiLglIfgAn2`!H}r?MA{kr2#xI<_!o% zO#mL!q->lwaFghnmMrKluIN$5bDlCJX3uA&e zUpr$bH~}3zwSUP{^j?g%xV~c&I8pD@$L`FoG@i;aIS*;%(3_?ck+AZfzw@(F=o7?O zaF3l=eD3q=-KgynWnSkLIJx26I)g(yudFBkJ57cRLn(XI+c;wD z_*;cMv-O&}YFTC|H9to9Ia5(S6WwMf=X{K*@x0mhWxL+WM$zj2DpOE4aDVGj>nw|! zOK5hA=2bt#;CLh8t1I^Y%Zm@zQYQ{Ct~_PA?cM@@zbhtaMKf;JD2mdmZf+L4`Mi^IScd7Xf97$ zbUq1DCE6`VIc+4g&Ud5+^I&7bS`gqQe5%miY+k`bdhuRi#Q@ciiLP4JSd zA${OEE^&=^Po|_nT!lKh=}JW3IL57_S?RmfFCRC31miGQVoIFKJjS@@Juzx`tF)Yb zdgc53&+wd-*qk#tXN~;U@kLyTPTL3c3>nz)35N?6ox`1Oi_?~05?9BDb6I*rurEhs z%hkopUklcHP;p%#=Zr`#tx*lv1f;%RpB|CmNj?6$9=$A$*cx!RQ=JXh@>ZDK(v{*h zTB>MP|IBjTF}sbsnfp7=s!??EM|3~IdVTY`-PJ|{JWTQazWxWXy8;`=)>=xcRgHqaw_-qZNB3OGhkr+C%>5tgl#n|~vU6r-n!ATg)iH&u9t*MGKtMNfGr zoHkHmAC4?PP;?YcysRGcUdq~470=0?)d84`6-5t7({jIdDUj_tyJDycUf6rB9M1Gt zEd;+}Vjea=NK4)&)KM0>jOa<%Z0heNs9`rN!Hzn_qi$_qobh%rz^<%Urfa z2y3H7JZ%DAOAl?KyK(nEy=eRFtBZ|!2%lMZM@oMfavrY0iWj8fWxH+gHLMM5Z3a}1 zKE63N3prS$TLHT1q2l@`p4*3upLjksPuotv+0orrxDtDF(vZ*BvX1?Xh5#8N#Cze< zSOC^l&V@C!O<+9!tx|^0Y5;@Nv9nLALs7d> z%hM9(L&GehO_WpMyPJELaDQ}+3E&VR|@?^Hsx3U58J1s+$BTwn>TdH z8wUtDW_T8V!^PDy!!QErMj@@Q!>RZ#oQQ{U(+w%HpMqQ#>BrFj_gMzLh0XEq3>302 zu>649Ziv3RPE?CJM7ln1Q)TeUpCbwLBU_cZ>ExqiS245G3SaPQ!!utmjW`P}+s_?F zy1zHcwy}>;XPrUko z>~l$l8~?&*{qp2THv~QY`Ppcq3$x_jJm6QIMUKhcBeYEn3iE*uJ!4TqU za8I=V`W_$8h;wfeG`lpdD#fYQ5_cDILL2k*vri#VIzQ$2Z!{IO1+Gxk&TQSmeG2qN zn!W3e6gde%@_gMTru^Z3L|Xuv2mddoGSfVgN>ssjyhdJJbWZ&PZDJRWQFNyY*-3cWTu(f90+!sUwH_>t z&gB80gV=gsrWeUBp>hJTac|36($DuRZKm|>grD4_rGQrZm}mweZ8`8O#FLXnVWk`;23eCYR)>7p z&1{g(Ajsw!$HqNMqiOu|8h@Ssn%zT@6B~bVqIq*x4koDXm7nK|WZJ@X_wa^e`lY!? zd4A}!8bgf{XCn+$!(p`dy~9XTPOYcy4xOJ*c=*7?2h@ZD?TE8M1k~DtrdH$L*FNiR z)s>!MskeGZ46AlnB(*TnMmAgjsKb-)O<)pBJ?ntn&(~13nxdqB+#w zQ$e__R8H*S##hda?})4STEf|{soi`^1C?=;yQYVejw1Gdg`alQjTblZ)y8t_5BTMI z2SgxU{rDfkM3&jb&I%Jx`!01TS8lSDdps`m7Arz^UZAIjGyfZ*%q}J=OoT|{mLvjf zzRA%32N&>ojDc5{0avN^W*u^=_jyfi)Kj-CC>@>#HaNC%Ra*Bv03m4GHcOn;Xk%qF z6AQLj3uiC3Eu-ZUX{g7cvouda8V)hv^{2udlKsN+wZTQ|aJ*zj_JrVVxAzhEkh?b8 z*a|!DN}{n~q3>_kUgMj$djR`ksAacY%L%51votXy`{G5eckx^%i*A>gD3c&H|P=i0EP@88tkd$^kS#JS~mN{-G6Y@xWK_=4te(qH=1BKBJ7Kx z*5AfOgr`T@xR4)4TMly*qvL;njg#s357K&($bPUA5pXJkG1ut#$%o{Pg&-v%uZp5- zb+?HIlWAyFne^9*7WZH~X2dR(C5P;5ue=0DA;hh)YJwZ*pDOLli1(Wc_Mr>})iN=Q zHbnto*`}qwDYpYldJO8@=!n8(Z~3#h?`w5zaEu(xVm;W z@kx%lTC5_SHtd{dpfo9F*r~!4W94h&ugv$|a$80&ZpFF1y>*P=ygT=CV_9h?*gCw2 zUVc`!!8DvbuNww_I>%WNtkXIn68x0RUQ`O&Q?)h@1K2|C~NT7O{({|xF z&1r;P`p@+N-b-G~m`Gsn#9v%n`tA?2U1;5hT-69??hLF{F2fa~wp?tbLqo|-U*`qh zC|pw^UtP4-^Sv)N?YS)H+Zm|Kwn~j4X8Thfd=`Ifwg?l){d@UxMN`sUI8V#ncES>CHkv_}n;=L-D`mIyA zgZWds-!|u-z8u{BF~7=TXM3wt^4XjL4Ubx;YM_n5TI1-0OeZ?qZ-G3of2%2Mr~j-g z;d?FBo*}6;v^v|+lxG2s_z$9phl%!SdNuAKJmq+h+786|G9Jk7_ycp`( zOBo1Wt1)j;CB&Wm&^E=8F`HiOV$HBA!{W3$9~{hvbkF#N2w6~?s<8%wr*P}wV`@`# z=ocXmw;s%1$byV>^NPcp+P0a+V-w<@h5@#8ztffAN<+OGj0GG=&BZUs60JfO_J0y& z5ZJ6OO19Qpg-eiljB?0AIVLXWe(;q2J85@gt+Ux&^KV+c*Ud}mxu@pgu|(o__1L`9lWEpo&S`OC0=hNlN^H~ZmWXoYMiUd& zt}}5Hb}V*_N8h`7oi7wV-1%qjCX*cdD3ecDLHdsq(K|dASg&f@jJUNJc!5tsz_mpe z7e^n6bF+r2Q*Xhmn{WSQA>53YJhR}6mzvi+-S2tdc|`qdYvot(%I(AB){2V8e0fB~ z73|mWH`pgI*Xa#>O^-}PvFc0`nn{l72@p{SJ#3CZqq`r5y*YwWmu(at-cdAZ56jK8 z%gVg6J3cl)l9G-kKjyb~__8*ZggSL7S+jZ{?>{{R#v3QAou(XVXv!qz1?>xu>j9mj|(WbY1$3RVI iNd3Pbw@~f}{!opI^i+xH0BMGZnEOSUW-``QRm7-B4g6dGZWB|BwEk~Jkm7+aPxB>Ub%!pM@H z5Xx2}J2B5Sp5Oc4_x;EF$9o*l@qCY&x#rwI=jXg;<~!G86XPo^j694G2!zEzU*|dm zatscEP`S`k15HUcvo!=l4KXn^*99U30)s%%5C{$eAweKyiUfl}U}y*o2Z50wFfzr6 zhC$G12pR`LlOSj^#TN&I;Ls2p4uT^=aAZm-2?imdAtW4xM1qjWAQOZPgOJe>G7dr} zLC8P=xj|}>3j_miGNlgXLc?G<7>opikttAI2f7)Lz5{efDwm=;cze<35Fw6 zKmlJ88b-pwNF*4E3^0OF7#R&C<6vYGj0~y*)F2rE4NwADzy=C~+#of`1%k%MZ7oY$}5)Mrwp-E)WJpcuK(PSK&OhS`Edw>rB6GQ_# zK>q*)=n$X=$pC1861V~!pfJb{QiEJ%3Ud@QkikX5;m8ysL4TkukVqsPi41rJ?E)0Q zh$EA5WWXa}8V~?*0e3(&=oU~3_y90LG@t`u0u6%>0cwy8fCiBO7Qg`tgWMoBnKB}Z zH!uSkTx2jYKqTl7lm!xrOr{L*X#5luM-!#Y^JqvEP)EE|#(P911>+GrlxZI|Oo4pV z17-L}uqYiIRRXEOb^ucXxN^tS$JfWv+vTpWfbvBJX<4}!ei@t)2#1J)4%|H8<*$t8 zDuMvp!(E?oWtNeI1MtYp;Jw68U6@LxGckqQo@k9_e$Oi7C8!Cx%jWM4Q9mO_zxn_R zIr0Cs+`$V_9e?#0yVL;jr=q3eH({HmEC&*I$azmX?Bsf6rOj`ubVM)Lk3(-yIbPxi42Sq%T0EV8fINM_Z8PMhfbpihl4|vq+ZW%P6G&|LteMQ zqRaDT$p%G1)qp!PDRx?O&qO6Y@mV$N%61SErB<{tb4iQ)QmBI8N(zbG`&6axi8$(swfo{JN<Cm}mr7opeLj9`elZK}g9YV$OPIXen zV*?_=S<2%E{HfKss(redBBwT)Es=EZEfbBt@)T6$#20#VW?%m0dG-6(FsHAH+SacS z)17mq?|LnV&8BpbSND1+(Htu?%F7=|QxqV{la8D`m zpdzc##IhyEd`ZPRTYAD@8N)lluq8Bm9?59BNF(h|$lf?Tc=L`YY0wE{G?td5UVn32 zR6;Nf?L+InJ==(gC%9*(Y~~UUgGFH1;PsbuB<@9F{iH|8pX?$%lZ)_W{3#JUu|Jj8 z6?iI@$BAMUP$(C>QAH^4oY%m;)Rv`(XJqGYc=^dx2Nlh4I((${Doj6q{}RUMj@BEG z=(xRroVXZzM!lx=!93d%n^%aRae=+4x{%Qvk^~}s+au^=LT*y!E@2N+&Jy9S!Ebw! z&tTuDT(>ZrU}zr4+BA@{)~7#KE5N#mGuRwYDB*PwDnpN+H5fOT%?Zx6wzGQuHu?4N z4+6cOVJ6nl^oRJTxu%FD-`KPOf=rnFL&f_o3bNgARt6(CeZty&6%k8D2t(Sy^8B!8 z96rKCe1P%F(Uyufn(MsrqB~Br5TS0Be15Alg#9oe{6`lw-!-MD^UDtn!2bcGT$a)& z+BN^hFRyURsZJ^r1pM=OSrirRf!-s=y?DWzb6w~+V@=7XXZe%ddAZTzpVTDFqP_nl zSJrv=X^qUMWsPqZ3XE0|Tv|t^=5o%cJ<)PctBW^C`S6vo{-%vc?gGB{68r%jlqLWy z?cEJ(6M8(sbMx+Sx^b(<1Jxj-_%Y)^AA!V~SHbH)^c~zfd&aS>)#U;E_cjEfDVw1-$0w*cZ!^zck{Kpt3|nKoPBF@cGUf4=opWw@0pm4y2EFJ za;BZZTkF>u1tJF$3z(g5gR6P0LjvuOYg1nkwsuu^8N>=Df{n4i1IpMw*=R zJEI}3-+OD!#6&D_ge%FU#|t64DBxp+bp~K7rzrJLa%)j z>hxhzXVPvu%fL{r#?2loyzro5Tdbej%fGC-wZ#MaMzq%?z!*+9`4yG7dQ}AncUHqB z;;Hpw&qA|ahxIp&;QXIQvC+K|i5Tz#74B}E^(f5HlAL=e#_=F!-hq)LXrFi)YmT%#+qbPTHaN24K&JMhI*??*H$Sz?^mgBY8;15>^j zU2z1~X%AXl5AWQJGBvH?$LXbq&2nKTG|;(#6zo{*3DugO)v$9B)W?C}%8j2XJ8&=Q znAF&JgG@~}@ae@$Q?}Em<=GxE{P)KCXMg?Y(q4ombu0UPa5`V+7~IezJnwRKHAHS4 z-==9jqhVGTy@NSu?Mw^X`O_qP)fFmNM)I&(S8N~(_8sqb?Lv58{+k}ygq<+<`i;A~ z8=3!iO1+{;OG&LQ?pz(y_Vq)LsVM8D5~lU7ga&7cf)0$x_Wh!vU!K)b!y$1Wr(R^Y zXju<`kBj~Vd%j+6udz#drLP&H;>x|Uj!Xy+b<}iyYDSn-8n1Dd;My0M9J)*-qy<~k zitsmwyucoY>=sfh-OiI!sZxD-;&n)58i5G`8ycb)z4$aN39G%i5bUS87)wOsY8 zh?N)0wQz1}%f8mVm2Ft?EJ9)N8;5TRzk9#nStA!~f}^C^WzEhKKTQ-hZ8`f)$#22f z^XJ5(yS{J!cqdFlTb{`D`GpMT0s|c0l3QPDzhcEKk`3oDCrb}JOhU}edGFR{T;wp{ zy|ME=eBGGwwp>5;tVE%ONcmu{nRue!S>{54iu4>qLh*yOz_5&Wq|+@K|kTkI;!5d@9_vjro25ZCVR8@kw@dgc6P#;Nc9DOpEOs4Ap}{4I z*tv|TlO4W8LVrhxzH@h89MKj|cp;4(%a-G?DEzU%%>GkscO}+#)_NAN=+CqAt!Q}j z4DF_R+J(1{Wy{=*K{v(^`L9=@t|43UnKn0!ENCRO=-WA;3Ngdn#d#X2mlm^PQAqai zSkCj@)}5cnQx=pW5@rnSLmJO41=3Vn+@57Oo^$3RZ#&N5`utl}V?__lVQIchgc${?UArQ!7BAW~?F?@x?3V% zc)2)<9;&0Kd6v8A-l?b|WJf?h!VVb><7PxHl#f_xJPGqafa>2){B+{R;A@;t$94_XWIc-h!z+jF~M2jAH zU{Q7-INm4JbY9q4b}w;oUII#2tSQNocfHaPHNth8x;{raR1J?`F8a>ItgSr2@olvx zMMjpMf%aZ?1N8<=(cte526whvz1KNA$exo^cgwypF~8r9agegV$(&h^;MrgTUpBp7 ziHX-btW0UR@D+i(lG9V~OqlF%vc2EL2fhzttJN;VyF_8%axBEm2>N@HOxQj>8d#Fp zb|g_EqTLj#bPH2tRzonv<1C1lwTMghBd83~vR~&sJNJ)Ke{;Q;;R|i7+7=7IOa4U- zCMg$i3%MkoSb6e)Z)pFyuLVoe+JFy0M!z}$n@-vusQ9}2jh3qV9H&@xyLfBfUHR9vygnKR*^&3Xv*iWwbxAEVN8bow4_hlImF1ul(7U6Dt7=gm1h+%tz#T^Fr?FTM-;G6 z`FhR)vwMW>)8m%!DtP|Soy8*}@|-N|F|7xR^sD+rx@?wXyR|31AYexQr(IhYRso%MZhDBYtYk z1y!~&vC&g>(Tc=EJo|yH_&@Wm~}g?6Yr6e{IRbu z5ZWk4|7cb7@u?8IpR6Cn0_piO=Iy&zns#x?MyJuJKW_s1MXG7Xv$tSvzL_pOpFQpk zb3eqT=&a?@#UHo*6O*ZCe@)X%Kj_W#F`^&dea3^oJ$Z6{GvKOajlfjR8<%0>fTh4B ztkr;4)*yNF#;w@RE=%yaGi?{{m=}Ajc(VBYZ6@vaJ7MjuhrfHC{F>hS6S|gXV{yU# zS)^5FA3V+%txPLt1=Qqk2#V9lsKts(y?<)VYbUj|-;k)2DWp;5QP3|Lb138} zXmx^-V*shXNIdi5I&({H%LaW-m*^wjp!!PKeMsZjJy*}vxvZ~O)Lq6#oXofL8`!s% zv_>oW-3wl7{KO5OEohp{yDX)lulZE19ZuKoy1OUBU6wCSekgRk_#0l1yuxR2|A||g zYKziu;#W=s&*2^x#~AzF`C5PB1HP5$frNsg)i#6t!x{{Mb@3YVn#_*nO4rAlI}@0w zFYYQzzx~e);O$lktwVZNMm1~QMpqU6PfF;Q&ifV%tPd7%vZxVWj8&!7mfok**eb5% zO4sUwPQ(;`U!Eyau=&9>wU}lf))H#qT+|h=(UD-w_%ecbsVc-ynRvZul&2wR=EQt} zC0lXc{FVq^F+QqU4pEfL9~SrBpvSVkV>Q2POXN|CQfcW_)L32irVs01)P>cIsaHMN zM#QEz!rk6meP|cB6a6@~=$8VIeG5ul5cZ=RScjfutoM0@ zYdUp9oC&YI@p5$76ZEQm}@q2X|RRsCn}0k>#8p8c`wrdsOC-7NWq6e~C^%#+_%V5QCDWp@PK z$@sivf22mPuGA>WCbc#4V0p%%g-q{UyDj;+X0^rOfQ!MfcYuk%+xbqytFnN8Ja@H4O|$ql_}<$gAKKu}hGH|9t|@1wV{;==TWU zu{^W)<2dYJ{kJB)cNU+m`n|#v-6OD3h6RyIJkYUbChfzppE3uA4C%J^`F~=4gRb|E z+LHc>f8Gh}Uo?O#R(q~~Zd?_jdcv2EIr3u6H)~C|v*MiN3%r>8jHkpvC_`~^W1d)Z zQd zso`#Or^Lbssimik5+fSxU%ZG*uNjwe^OR`Ug3IM*#8W>zH{_WHmmm9zz~yi%Ui7RVCs7-iz#RtvOYs^T-xsSs(q^`&FgT;%}e zTb-wjQMFXph?z`*UNI7FM}FUs>>GbNQ@A)+Tl_Lis^0ec8QBaBq9^w#O2yxNiuN?m z(Ggu|-#F@Kx`M7)A+(7|Ta7Y{#9pPS2ps3c3fX{4(FUj(DXNP9@QMK{0YCo-S0Mj7 zu>05j&A*-E{XdjXZl82O%@Kw<=iFo(>ANb!$n@gb|48*4LzY}K1ewfki=Zz}b+ue# z(I13U?gfiG+2mPmuHI=@aQ^iGt1Q;to3tUn_^nU1DepEG8&LA5E~z_yu{Y0SZfB2B zy1CGL>j8GBBw3bLMRJsWJfjIB79Fuz7>ng3rde_<5u~e?zbM*f`ofo@TP03YPI(P< Ljde=3Z({!oHCeXA diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/gp_hash_random_int_subscript_timing_test_insert_gcc.png b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/gp_hash_random_int_subscript_timing_test_insert_gcc.png deleted file mode 100644 index ac4f838fe261c5bfdd897368d9880ed8306e6031..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 6763 zcmch5WmJ@5wC)HDF*MRGA`Gn#2uKWrG)PHEihu)1hjd7&fTVyjbazQgt2E9?Nte>y zNHgaf?^)}tv+liX-Sg*uYi8cr@4NT2pZ)BwBeXS@$sx=T5C}xBs-mC^0^uP*pc{6? z_`pmVhRg^A!Ut(<=qUmw2m}LxkRT8W1VV#ASeylefnZ1w3{V2BEOHP&5pLMuN~N5E>0aV*w-(76!s1L0A+Biw0o<1HcBL z0W2UG@W$fu;5H--hJwM+Fc=n>7O;>=7!n0TqG3oZjs>uYLc&le7zzzTVR57YUo;Yi zM#0c%7#a(31VUk0Bn*p!VbL%wkQHDJfB~cdmH;ha4M+@N1JD2#5RAnYgtLJSg+!u} zNGz^CAT3~_P)HOSiNfN_1y}%!XcQ8SMxwDm^#Ccr7l}n7v1lX~C=bvBpb10+asc%M zB!CJ5)&Lkl8ej>y0z81k05$*(U}15};g$g#*w82x7AGW7ACMNX&}bAI3+M`z3$Oqd zQCKtz3+MD*EUtn7+K*%LucNqr{%aDB)IZ&E?foYuj^jUdaNYh_ zFpl!S8gR}3M+;ZMzf1r$usZ-<0>lGq`j_h8p7{U$=Y_978<3R5Ma9S+1R|xueQylU z23`V_93F~KJ)SrtJ-nW~y#Ogb(dJaPb$0h~w{o*{@!*uWCnkLN{wL3LdJu?yMO6Wz z=bg5lJ{w%hN%h93(a{0_uN55l*sT&K2I;vFD!8@1Gt2GeOyi7_pymKU!wX44<`lF9 zwsMHqg#V*KR67oYKcav*e*C)dbqI(YN<0V*(SdXx{<_aS75iW`F#V^R4{}uzhOqh~tY@dHItjArX9N zc$|1}UcUahA;n0z?W&#cXV$5GO`qJ5t(avKa6$`Ya#7fvxzXl4@cr2O#WVH~Ecc@& zEl2uqC-hmmit|)<7usd;{1JWIcU1y)i#;tcQnYqKg*3m3^V1_azGdHC8hWQ?psbXb zU&#wL@4;U@zMeOny5z1suG#3Jui1awTPL$%%N66#t{ZnXCpaHcx$(VSW@jTwb4RD{ z)~2Hlra*WS$fxPnQ@cBR-)za~{uACmB~x-=Aom+nJJ)lHWJ)p=ZCz@_^ZT7Bm|*7l zf+M_l^VN~+HI6~>A~yLK0V#9bhUh-G^^%#A-#N05_zGf&cI8>{H-bm?$Ax*VTc7gy ze`VA*6+&uwr7i0*nX0QV+{PV}9yCMFPi^ww=bS))aETVRwUtg+7ld7Bs~}9qQ%VF) zQU=DtYBogLg(RL8jQ7DyF80pp&4il`O~(r->BiBkC|Q*WvwDGWnkktd(#0`L7v;(0 z1J8{QS0$cgR|L`(&$ve}q*l%UsdBF3O@1_`Q9_?HMWT^n{%HN)%WrpEH7j_m?C+OX z^w*Hq2j%b|96D5FUHPQBFSSgr*cri1MuIA>dH8Hgsp9+7v$8@-Jt-&OyNp=#ua&-A z&I9Kj`5lNc*G|;>=_C1|6~{xAP7A82-dCTmpU8n?2AE zNU81-JM=L}oO_4rdjE}#c_3uk!@c>(2wZ+moJ*%YDDzNn(2KT_(&#UDsgV@ZY{%{D z5haou+NHE4Lq*AD)dIf8HI{YvglC1DI*5ax6$R9Wv2jL{;`AJj#$RGo$2vwJ{3<5- zSzi!3!T)t!zBBZicq57&*nWZF{qZ#I_+hHnPc5lsOt4(!y9~^xOhi6k!zXaMpq1;` zrh_I_#Ieejly=Af(LJ!!%r31zV@_|aC1GyAB-BftsaKE{rF_o$hmSiuaywr4Pjyzp z3qfS;q)*cln09aP;d(;1usOX)b<`c*!Lttx+Fv`|KbLk38`0-!NtoE@F)U5gGJpvT zJ<76%|FJd zXlDv2!TTZ0(n9No2*VC%H3P1?8bV1Wh37_UBded5=(V-=W1KcKJ4z(&r&y%tsvIWLS;YA6rV#{mf#7k;BLcszcQ7-}j zWtm52Tm4P_kHT+G`iA~;4JAn5J2DvnSmtYn8~S-e9)5Y>M^@nT)5t^AGcN0S4+GvFhu~2#0w{&Mma(0bk?P+*Sd*!V z9NB?`8%C5678ZjD5SKPp)(xO1|Hpv|a$s1tm3ahfT9b^V7;^VuCF`yW`NgkQ^YSOQ zR$;)qLEK=hWAQiD{?ChVuZpjh9lsUYicOb&yhOk2`F5*=zqjQcP0$p5+@{xqhTA)8 zu64c>0T3^DC99jdOL8`y|pxzQMW?lVUUj5xtC-r8x{B!Noo$!r^xozES6%OY4*+0}w zXD&XR*k#&Io=DyKX)3rsy`^SJHbQj4*=eP4n+M2$w39wc!Iqe)U)2E`Cm?p0?$L z8XpNtVAITgtrfzh0(D(Ua7=vOY(?Js6wzSPS`(p_@yAK*2nn7|9Q@O{8i-I?np*bf z>Fq70^C%tiOFf}wdJ~e|IJC5Sn9&TrrEU2{_Q&S7=U*pqlK5E{$#!a?irjQf%MUue z$3BfAk#{^$ZLZUas2a-93!R~9I=u;k*~e+5bW8e{9Q?kmA(2y@?hF2voL*4TJ2OtU zKYqK?T_uJbtYR9}+(LE1jt3+kAIOyEoCrYM>G*AA*+7ygA+O)iknW^|U|q+n9r#ww`~&Tl;FBfWmx z+?+GiVI$o z@aD#a|1V{}YSpcP$J^e+Cmvo}KH{3^7l-VDrjr=m!BhfTde3Onu=mHy#8*DC46P@c zb&IO=&1bWcn-v?E-hA7d4aux0>PmuRlesRlL^F$UM5$T6|3o&9Z$UQl{KkQLbh~nA1m3-EnYq zl)C9l#(Bu0BgY4RRn@e(Qmoo)9TC3%A@)1RRze*axK&dwFrxkDq3lIgnR{%K+a0c- zCsq_vIajK^K1OrAS%bN!`UAS#L@BDH?tCE^T+f~AJ0t{sPd>+)L$kBPAXPO`c^I-KaJrm_s8^ZuKg}NyrnxQ|Oz5MG*G`;;*|#}NpdHdxmnWm6m4$yv z#jH3x3|Tkb-r#g{W|I#ZWGx>rvVNaN^!bb>M(TQ|u(E@iUqyC!%?QEadRS~&B8o{l zF1Jc!^^aZPVsP%H9JQawS^9nu?IgK#$^6K{@F$Kc?q@+M6a+Lq&QQ19OXU&@;l7t&VR zl!voK%#TgUJc$3dCnJJ#|bJuMxYaHD_V(?gGhk zug+yNQ-G=Yu%VfI%C0xHSwU?Tgq4Tu9D)&F zCH_6-kq5Dc#fw6_c0=!eAk6=5MlOdB!4u8mlHdSO}+gXgLk=i+J*LMjU&BGnUEi^kc z5<0LV{>;tbn8rBxSD=O?JSN6J^N0&BGEnX|n~sl_zf|yWKHMG>a?kbqbTT~Txptzn zvqE40fg~oQ-S_1}@p=%p|FC$}&c)o&T^_6&q&a`vu3~j(S?k&6oX20O)6E^nYcq#y z!6$nfWgp9@Q7+{-ClizBEt5>f8Y_-4&4w-Y+UQD(>C78+)3o z0!7*7a}tI_9kVwM8RL>hZ1%()k9&1&eqpZidOqteO!~8!%+iQy!!b#W0y3sKT9@@& zFq42>7UlDd4B;Pq5jtLrQf6-H9;7B$BkNxlK~6zN4}{8F3&hBT=FfiTyh3#-9))u( z4W6>yVb9Q~S|Do8SSdMq)**Mvsjap~8EG&%UJWL^mCe~ni3dK_GN6VNC(`)R;)eLZ z>B2WccM12Pc+A%h>{yI0S`?663$AV62Akm0fWddP3wSaB+ z28FhqKSPHDdm>d#-V-hTbd^-i_IDvlotYTkW)3>)-jNV8CTl$Pi)8O% ze&aoVs$NLcqZ0i9Hb>pPixS05#&jpkdFd?*|0JOkJqIEG@g=Uo*8#;a!{NVX^KZy{-?j ze;e|)r?w>Jp-_au9MZtEo#puxibBc-RjKE}z}bsaqjblsBrL=r2piaOe=*DASKgZh zM!QFd+m^=qJvU->i&&CtoOHHsm>#ba?dP>-+LAZ~2fOqjbQN3$N^ixy(%Vc;CJ_vv z((*OHcQ_4w%bW3D(MfUfg@N5MK|pH^FL~yX2vsw|{+u-Q)=-JSoCLv{MY`z!{qf_! zpH}|I7DM^V1?Xw!jFh}`9l z=i6!szj;D1Ig0X~7#v!AMjLin2S0<|8D5%N;D;Tot0D~D@BL@^`%-joAukv;(e{nE z^^X!BJ&|3tqiYh=+1=$1OH3>Q>qTn1%2zIl+zc(|v)aBwxP9v=)qziH-P}v!vlfi8 zvsjq_oDF#t(ZB21;_ymgJd42E5|gu?tVY*le`mZAe35ZG#hxp>0CNA6LYwF}T^aeU z115F(kjf1AvQhE)`$`6J7N?PptJ84nFU(QNvFDassbu+$)durnbzP-dlyxPNbe-OQ z1*=wmqtEGnDL>wY{^mFaAcIw^T6B;%!ZDdm@h<7O}+(glu-6J zJEqEMn3|!UZE6GjcN~nY#gIhB4V2^d(=H_bvM0VeqYtTVpr-@9R&? zv3Sa0u|RKC#cuM$j(NUFt2?ms^H4@5D07S_S(VlY^Sk(boRHSjU}r4N(yS2Z zF>u6xWpOCzy3!%W#o*x#p6`_%|Fvo1&hLit|BHSa`A7)!t}^hxpjg#D{$8CvuW-Kq zoPqfu%dWn*b47#BVPox+X}LQO-T5d|wch6UpN;3hJ}p$8B|i0~Yi*=e#_;y&Enf-@ zrK-FB@^{nF|JhD&)mZ?KRlGiW{6X-%>@V%i_kt&oHHDn=2{F#M7CKqj|l5?9}*$$`@^uMmR z|9RQ{e;#OlaCg@BmS>jtX12P}f3&;0rq-2*o5aKY{s=nMHC%h#xjyPjn6!8Ht*0Hp z1M4JrR_~{aD7PO$E+p3gVV|JiTX|9++nn5@K6c-5fs~)0V9|+q-{k zXtp^S(E$Pv8S!QdxEWMauXz5&mqXAVMXL$ePU;;#NjiVR@Z)DK<)^}OF7bi5w)a=P z+RTugsv@RwuAbqS!VflQ8C6524J2a>%wpm~IlBb!giT6=eE#eGbaznbve_7AcGLv! PHNC2$rb30hMaX{ujY)wS diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/gp_hash_random_int_subscript_timing_test_insert_local.png b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/gp_hash_random_int_subscript_timing_test_insert_local.png deleted file mode 100644 index 9fa08a0c2c307a32fad055befe104cf103fa1984..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 8499 zcmch6WmHscxb|ikT0*1+L;)#5WTamOk?xc(!J)gQh7?JW97#z*x&~<^g#koTx_baY zN@Bi^?-%Q=^{sV&oU_heGsE1^UDtKpduBGzeygr3M@q~<3;+PBg1odQ06-7`fRjsz z3$8?UXj1_IE}*WgEd!bW00RIx03ZPX4FK3{3kCyVZ~%q`U}yk_y>`N302~g$kpLVG zz_Hh{NEm>G14tx*L<30dbt)PLpy2=-382vc8VgneurL4%2e3#0iw3Zu0oDdfgSEh9 zFdBQ^=lX!dU`QAY4TE8?+kzGx4ud0Ma5M~#y+#2#k#HCi2}7b`NbEHzFcuAmp^-2& z8ivM#7{OE+77oKAVOTT_3w8xjgT+A5AW9Gx=mQ&rwZYP0Eif5-P3YPN4k(Z? zgKp3U4=gw_P)Lv;*cP8V6Qh!;ooc;uWmtLs6nrG9(tcRSq0nvn>GVXn?EQBcM!RIbb3l?XR|sgjO-S($ zf&ZlkM$E!BCQ#oKY)5tfEWY>^5etMsDohZ#Iy9^a_LwJ9h^S9`7}@z9)3YH*FR6Ra z`HwOvI4hJj1D+8UMl^NTLj+%xG`*{CsA(uSFRNcj)Ru6aks)i54!5y=Pg-@O)227y zHyM#-qxFv2$;2bZwoIDbyY|D|aY=VQT-0xWeC-82n%cEtQoPer=`oi16H(gB&Zwgu zKgRFO4s!wPv`UsVWmlU7U|4hS@ePLltHlH+)u87|ERDqx@ds{xIApq{hRcjK;eOry zX`YTOZSAh2bk@0#!={3lXPzNgbvlmuWkqUSnt4Mk`vZ3GwrNmV8@5B_qdyKMTFgiz zELQ5+YaJ8?`^M^wl1v`%-fP1Vm`TdQnt%FQHvYq^M`1=5F*@d45TO+D?xE(ky-MM< zX>SZvzNpQWI_&|zxWUNcc#0bb4)eEDi@ndB5)$b|uRmy`pJe8>`Vu(@j!#E*corJa zKH+X#eovH^LEtDvaYDH;XM5Va^ONt04NBLnH7h{l>p$hT;w6EztC^i2p79Mc;TIdH zZQC`V6Srpbr!fmiqox~uBThMe`Bnc}aBbA#3M9F;XLBzcVs8>?)4Eni>#ZDM(pi6z z9xUL`b2hX$zgNBDrGztH%&9pTdS|Rt;-%drVzp!3do9jLI9D z4SDXY(OsEJ2DP@D>f>KM&7ot|L%;>*FUHm_bw~U=J3%;u3Qa%4|TSE%&KDRUSK1>-i-T2s>L_8Wb8%c zS=Q5RL6H)`BUicBD+jw}9&O>KEl~X8uq@48istuXwdmP1i)kVe@>=w*X|j;rz;w4- zK;nV^AJG$0BYXW{KjrsehTTuH1+ANFx{9MdkdMx0*>g#H*3>V?%A^n1b$E$KNx_Ef zNZ|xz;nLHMs>K_Is9=8A9k&$AejL~5kB*NPHTzXvQw1t=+}(Phjy#el(2pLwpWBjs zW~PRlLO!^R{-eD29(BkKd3&5q|D}Pn!&9nwFHf#7mTPV3<{@Wkv8}kYl7{N%nYYs< z>dxNM=;n6L=k~lWHXa2zEM(`ZaNN@Qil>!rHNS60zi}c+KyPkW-M-Zorx7r*PldzG zgWJ*jJi7d?OUu>*T-`nTpfOU6-J5SwTHHp*RJzChpk+x+{z8(Tju(SZXKJT3ztuHw z9h;{}l&MsognYQx7829&$gO~?DWp%F&^fT0_hv%V-O1$F-=hkJTFKOiqAuo1RvJPL zOU?)mNAeeV%H-HvQJsq2tbDk)`ztDFB_!!hx-}pYgn^_-mR~}rQ!TFEsh&_z3=X!Q z&bvPrZ1EheGG?5?E~3-2tj2zdD5i#*6zC<{ioTh?A00MX!hLFQ>f$>&w)-uaGSs06 z)-B|uPF6Mf@R1K)*5fP{KTUh1sOj~>^T_G0Sb++vuo5m0#o{^bUx-m+=c;sSV$)62 z%2K1qCNI~9@_PTrDY~maf<8e-c?Zn!hV|+pRDv4}y&WQNsv)pVW}8>zQpY2HU6{OI zPESUz+#G#;#J5HTcqZipzDLUSP%cuq5&f>JZ!ri{M&YH~61kkp_xN{Vaxo8^tL#}h zB~(?xGa;6{Z8Y4;i^?ZSAj6$V#N!t=DlYk0)nl^XP=o1xHA9GfHZ@7+U6_Tr|CiTy z95PltmRc62Z#!ewcpM3icx}TS2h0cI)fa8t%9_R?cfLKY-C@{!tw29n+jaIC`L3jp5`xBMNq>nJP zzbiipiuNPzg z5p0O(zoz=XrnB)F^pG65r1#wa?Ol?2(*RwNa( znvUv~{5@(KsQXyr>c{qGEVY0wUGC7u{>Jvn;M(130SmVNwp)D?0mJzyv4g2*=701M zMZvpfto;n#8~l8yRW#Y<(8?c=8(12wsxl&mj+h^ycFd#6ws%a%A<+-MSyiqQ`X^wz zP4k$%Yc38?u0DBq$~jQ~Gej;=6v*goXjnTF$f!=4?8$+eR-N;B^m{kv=_zF8R(sq{ zGxa$SyV?x5d6Xa^(E_BziSbKba*dStDJZ5czOofWT&A~MW$GyKb^f?}45%I$H)L?0VIzgP*78kFH%Y%B>oIw>T# zcNAGV^CxYKD-4bQhy6%?udf9)=lf!!%6E}5VgWCMB4H+}sJLd-&*kpv+rw`sOFEDy ze*FZ>&-6@w%U}dGgl+PzHPLtGJIZ*0b|m{u*Y?IA3ZB9DO?4N(VSwDVDSF)MKmC*< zjh4`vLSS{l(6{Y2#X{JHsP~;)Q!?Lfsr4`*qWYcl9u`$>sBcv{V*B(yaSLo;K8?gh-J^?84YL?;?au$WDHylRLpDQ%A}&y% zX`=HoTzf?v3It`>-TDF3-+wtH!~!Mc>!x17v-`;UEtob$m5`+?gXl}!b9pw<{hbKs z??vto3I5-|)t{Wcim=o(gBQKQ+;s1jIL(i*nmNJ1oNXKpypYcosB@Eg3491N_!Dq# zx4nc)62ET$|6L`QQ7#nV7%6*;(abzXkbtLp;p}5~z5k;N4AB`ayW za+k%J*@XT@9x~}7t>9%I)y%UC2QCAXWxoX;GVPlZA3DmznM_@>6nrA8o4VU|87ITM zq{}rTCMa&ORny@dY|*zYwJ{sv97MW`j|Cu`!ZRMWz1sHEGg$`nckZPUokbLh1oBVa zT3{1v?Y3j|>k2YvJHcCr)|1lk?Rqsh2xpgz%&s(5V2ZS)+=SI?pwY@bqH_YXm909z z`DgZ@pG8`14J|fU>KJS|Q9H-2y>nbk%Ep#qCT3b6xQ--Z3$*3=r9|mkfQd9G#e@0EG=|oV;%6T7lgjeS zAyC#ti$%U3gR|^e0R*sJP}QWaan!Yu-#(rg29a^N)NE4i?GyistKIIQrT>ESy!6Ua zkj1%UVk)C+rkv`#u9*gEsLQ|kP$sji!u_w|tAr^uA?0sxNp3E3 z?^_jKaZhEq)QwgJT5-R-+)JR-LzoYIcz_#Mo6U&FJYs4mZAVwIADv~jHRObA;w)gu z_ES2wfO0?eiEL1g+;=J;r%l@15rY>=Pc#E@#Y^CR6A8qrJlMfUdMQCM`9H6wu*-4k z3I1UrR_E_tChfefd#pJ=Tm4zU_F=sb<382rrXySlnOB%{ z|LsTY3vq>QcQ`PATdkKyAb*=YuK3091+Mc&*OyDP#v z#p>5Dh1XE(9d;9$ESq-&ofto^f1fYn!>4)|0@l3SO>lTiJtBKhJN5PNnLi7e@F_gaacYhr2TpkpiadTGi zr?1Pfy#~)%NY402>fg~~6i@hf)}}@9ckxc<$r)9SP4sv^IezP1M$B#U>9YIse5KYF zW~~L@5IQ|!XkG5L3Yda_dT@;DF~ZPoO4J7eAf4hUyH%)O60`XF`3m~7NBRwrA>P8c?m@g zd8274FjCk{XX-NSq6T_iD(YRnbSD1O_d_LRl@qqfqe}AbXS&6c`X?VL*VLKkkF%!n zSKiS1uLy~4HuA6Xkm>OEE^q}k^4zd}S-=QYy0261xOA(k|1@%$`)D>c{p`j<_oO1l zpa3gIa+659NXffrC4+)FMz@B`)McjVNUYtIKO!foZA_R~!$zKb?0{$Sq@%cSb&F!S z?$E!Bh*ptD>@G{Bj^*3RhSbORS3Z*PaLzQ4>czbNcp>o$hJ3!+S@ZYpG@}KOu zXle(qBf2lP{NrP3NeFQu&oqeUh*k!PPDN3BX9y5tVxpN}i%;uo)4XLFTq%U4x@PdN zv$acGfAfjT!}J@yZN4HZh|F@OR!wTM#s|VK+?J2c{HxaAFr2_2Rt8$_5aWnBF0r(U zvz+Z-2Q;sB+|IU03o>X)rWvcQ_K2Rr|7m@ zcS`hL5r^Mm34dhmbi81mD#rg#$+wz-TzVpiR^GRIf`mec4l`h4ikEv6%W}>`r;4EK z&TjeH|HiznvAz))v4YNrOiW8;0x565EoKZ^!s3xpEPFF7hx7ywyRZ zUgPLPX88u^!H*=zbaaj7oj35|2#*v{z!Ll)4{jj3!x?HPh`?s zkkb$BDE(rV)InF#`gRf8OKQ+L-1^1YO-0arHeaN;k0kCWJ;-R%bRZRSaaB9WK24Lk z97bC&)YPU~k&J{+n)W+G(nlXT*?p_4O;<>ZiU^x`=F>ILr_8G&4!Kmh!O`Z_n3m=B zrM6hfoFlp4`R2>*(?Q+9LkZBh$Cek+fO7i&eaW~ zv3C4fmb`w=%?d;841y0wCfup?#px_W@%$qzGpZQViGzBKqql^ zFgd?@AUMYeeVO_Dvehb0w;Uwwe-0i6K?EtxXgk{rq+C6H z-(~Rzj<&DlA^_h?v{aBXQ*PDeN{@oMWj92B7+1e*Fy|6w+^5xTr^@h}wl|WQ-^Tz! zvw)t#zpKvj{B<^i&va|r8jZ*6Bu+xw8XT}NxpbVxqU$;F_updPh<3I3Bk5QWK`Kv=j9$j=Hh&NIzA1XLrFb0&1P&fAFF8C*sTEaI@|&pmp`bpAF=#SAHV7uDcRBKWh|m1S=llO+h^O)qS@M3mnZzzs&z8= zK1r2iNkcE=@7R%)#3{J#@u}^lC9^=FlWFl#&H$GX{j5^MuD+0mcKi8EcbT_ug^n+# zt7Q;Um^p#_m>zcTelfUYtSDGfLmpRh<88=+bAhRHusxJq?>uv-UnTn9S$uPWLH2ri zkY8B=abTMf9Ctw&ulH6c`+{p4F`rfWDVt;2(%A%&v)7;WNa?N);rB@P!ETj4!{cBK z;o>#ig!V91!aH+mKiQ@bZhTS?#!=AdXo0P)Y6i=id!b$g>xaoV!r$Ys^6ue57!!ZZ zMTu#e=tQndt3&Kt#5elAAv?H=ZO__$|NV#N|LxlM8ADSsUAr4gg99427U?tdWlgha z&%7p{_e*)}p}|D=g!`61hJ?-x zTvNLOa06?aschm&1p0)YA;foI);9wjUJ~YJ#_o?~9=+dpHsbEcVwHs7t{8aFnD|<{-0-4(aPf%PMPfbsUsV`ilncr^5=~ZwXu+@cNCa*-Q8Q*QP z2YQ-a@mAwmJH3NNL35M84Yeqg+4_G>IISD?ShXWFKEH5MdG9G=_hqREyS8j_64PXT zn5*Obl#+vAlHPXpq>y{$Fpct6;(jjA>G|aq2c=aO=8sphQt}vy8pdoICE+-Z(*B$^ zTimN?=x3I1(IszKw=ZCRrk9Kqu+H=$EQG^?22gf+z{}%;=D3rXI^#la+fYmom9eu% z1Y4E4r-g{xk^a##(@Y{~E;P&NYdIevbMy4P5c{~aRg))JE4OAZ4u(q9)$(@Z!TeP1 ziHxs9&xqY?i&)c|?~`-;%5GpdsKv8=nnm_d6LpVcN6nJ;?a)gHgj(wSsxm5*BiThj z@%PV$>LedAo9@8R)C*;oE;}*O$pdNOxjl?>kUY{dt=)<1N8xa^l8RKa>~c6DZE(f#k)|>( zHQo+w`_r9nsVcr%`(!3=j<8TA#bm@)grd-oo^8%A;jhn(+1re|zj3y6=q?iNTbxL{ ziBBG5;tpT8J3c{8*$k=PF4!iIeeXr1$QZH8_aT$(V;J-FWD)dhL zOF=sMACBbDUSUe*t$v7n;lSc^5bg(oH%t;7YdG!BcjA-?%4oBhP|pyx$LwD*Q^ONa zG)D?LdxghjJ>=AQbD(~VC<+#D*8liBQcsHKphe*ga z)cc^U&e(IKykvWN*Ow>H{TajC#IeK54+PDsh?E4?-}L8m#9YSjWVvkw?TjrtNbpV* z{hh)R`Q%xVbw;0912IiJe3aX{;{!--cR_oMJIU6A+8Bok%w>+y!_)ZdF zO)|dDPxOHHQf?cABHXs!G5$qfqv2xpiZgZ+cfWH4Eh8 zkI3r%es6Re2%L?9OrlvOgT~V7f)x#A1(4y*qWr4e!+ViYI5;m{19426dCK@S^Lb0} zx7y4bX1YM-TY32K726b_gLh=>H~B7_zYRFo2$QY7@IfGAxlVo)Gbq=X{9 zgCa-^Rf-@1rAesLn~=S@JF{z;OVhYpf220DuAj8~_jifD8b%qX>lpP&fcZ08nHA zMLSC3Pyh}G;0OSY4B%)-wFDGEzySmTKp+DI+R;)n3LxVEG65iy0Wu9l0%$0Jh688> zfJO#rU;tu+&>$AL7_6op^*K6lC=>yOBBM~Wqqbm#!=Z2l6poC-(T-SvNdgWAnza_%S%#^6CF5NJn6g8IO=U_>Sp z$TZMbP%g*744m*!}x&xqB#8;1Ibd=N=NAS3=?{t_0 zmy{V~?D+-)_*@L=`@T@J#Mk#~aboD+3R6E)5Qcxn>3gvT63*p6S~AKg2{lAEYe;XJ zk_kyII(|kfb9$jnqcb*MT&3eePl*Tq7Yh#8{4XoV4>`CnLn+~s==~D$g{}H;lkz{g zLgEiI^zU1^$`{di`3Pn5^r6dY&gyPT?ovk+Pzxba?(%i$cBa}fABb~95(h_z#yZuL zh_zHNo&~0G785g_%ZonLAmO{?^iPSc;bQP<%0tC=?Cu=}xd8F%B6>(-`MC3^YsF#_@Zhk{v_I}q1u^jxKLXFC9~olbe5lSNUIiOOW+Dw6!xDOdbfj5`%ke5b95e}lR^ zVlY=aBE^~gHOcla=RR9__d%g>)7!bXIJ>9l<$!7bL5ZNuDFN%Rxd~l-c3UYvr!#5@ zE{d-PJk-N8hucl9TcwinI@A}>{H3hUe+x&f*N-&NPb9AQgzNWMYhEBwzxGTL%$Zu? z><`A3lnkmDnpe|b2&AVHTri^+b?~v+va{KS3AKi1w?D|PZEkl3=IeVq!O^}cckH8I z-!#d}51!yDQZ8WHLpHNWSRTObU0Q`wb~fh34SAk%CMI>?)y9rG!Z+M{BDmCf9&~gz zOA9wN)KW^m^0n^@Bih_dAB%P-%nH19J$*1!Nk9B!Lv&XY&!;z$-eDV4vcEU*yeWBi zgBp_mKB=0qN&2q85uYM+id{!$B{Xs-)sSO2bobu94!(Ch74d#Low=aml_G3UJxgG}DNH*!k zYxO2Qch?No+7sC2)iu{0%@B=;)_8uHSBh`oRvfTgoea;wtO-|GRA)z9b%a`DJXyCw z&5|%dnOzDF3AJ%SW9M2LDyJtuyj#+I@6u12zUN}wkwucpRrVNZkFt7Qi0hwU0X_G+ z_-G>1EhxsiNd)&CyL@qVP}iK`dZGiBv9SQ!jf{S5$}HBIpwR&TlRw#1N1v+YOYpZF zk80=FGO^`G|Bf+DTZXisb6IV;d8Jg@bR_$PHN0TW;Y zT0&>ESA%z$M*B>*B$vhC6P$Q+&C<0qE6)($>9y(e%X^cm|8lPmEppy3R{4>+LQ}-h z4a;CpudqHH#GE{v;M~3eC(U8UnyCv;@%;l0mB**B2Q(H*8i zCV#=I%bd#fHdu}K9#h{-Kh6lg`w|Iul+6gjcn2@cJ3?zdIu8xKG3o51OD_8c(z4f} z5&wi9!1-F1^COkc)P5QwWOgrrEywlc9CsL7^q|)?&j;&iNT+@-DHK76&wA3;^hO<` z`{2Psr=JsDFBY8l8?p}bKb>G7h$ONYRK1m2;^VmfdArMPpZLf5-gq$Iw$hJBnDpwD zCz1ni5t}|ChIhD#DsfjfHdHOCd>l~7*=TjlIT~?)gK3D5!&MbT+2n1h*+fGI0T(RVnz2ht1=$5Wrm=A=+Kx{6<7ii2AN^{KSOFNf*SHzNy;F0cIX==ZXQ{u zt7`8^ftQ6z#*VFuR#dNLc;+u+Rp+c}if&l$2pxp*q6S{8>d%Hr)!%$<(@3J4rmDJ^ zSJ}S7_Op{-ww*l2zV2D@Z?|+oVht~8K+si+Th?2@UqlTWinIV^y}6`8L?k*3u~(V;+ljqhkCeBx#uOG zYmwu3d^SGsOV)@+A{tqeBZ;HYN+;BFvt+3;$2u1i-TH6WdUDY&I!AG98)OXeSZUQt z{49R{qt|uJk}6Vq?i;0sE3%n46J?$GeSXEaB%^SOOQtZ`=<2Ks^H8z19%+ovU`g?C6 zX6WAfIW}XfX_!Qivck1CC_o86gZ@x2g+nG~FZ3}!n$ReNMx@P_*xc~A4Ci&(yIRPA zXzNhfmbx)6NU`tjJR5;X?0jPqfP@Wn3=!o5kcVA6!?m#M_A0@%3FlwaqFZ6m^z@LF zpbRu5IH&Ciit`5I#f$Tf8dgvU+pAWxLdaQY`g^EU$R$Xyy|7LvjE4=%|K7-O4h0F; znhS={pLmL3t_cg>y3Y_SJog&bbYi5SBj`>1ZX@AdJEx5Z{i%`@1T5tYtsHx3RlwnM z0+J%kdQ$lfn}1&Z&1rC#&D*%KQJ5OWyCIptluRDd(m}pRcj17}7cv3{crpY{*>sK2 zeWbzTG-xit8f@jO3y}`(Hy@1o@_y1;ITm?z>Lf%WG|t?kRKEYuj*1wgLu`vreFT`{ z-=k+VgjN@Hto-_NZdXcLaU?GoK*0^$urPhanlzUFy>JE{=#_$+h(MvJdzI#$8j1zV z2a2g11PQG9V}@?tlMy@E2C;O{$4cHNN???A>3zcbZ-iTHJQ7GRqXlXEn58 zm*oC__-ni*aRQA9>6Jh~mU*~|R&42*)-;@IiT`j(s`KX)W>rZEf6n?^BkEwiL{b1N zymGXTjuK}ZnQ*sXtY@v{OvC_*?)>tg`^Dl-VEy? z%tvA-Bdq8x?yBEU^F`md%jTP%wqcSeZeF$!IBbYR3fC;$-q5~mf_->jepHI z#IXUXto9AgLD{VHqvn7AB(pr=A$wnDHPh)Beg~Fib6r3syf)Qqy=*XoRXighnw_=E zb6rS9_Bt9_o7!mPuq0*E%JBMH52EkM+eQAmk@oLI=u+bMym`)v7*>D0bcot<=dz?- z=JZPTX>thIy0vYlK$tC>VXSad?`$$05j5Smncp_?S6XhYH#?&Dj+iZZcia0UayEbF^WN{pSSO7d}`M=yK(!FcATR690zGI z%pUvX?{BN6hbdVV_PMp5{%?zH4=lA`)>Nd{y>K|D^G4gWB=JL# zy4L)dKW)ARxPY))C!$6W*PNpdCul?CD-v>0^mB+h;zh!k4`zjcx039U;Ri55J)ypj z_leyoYNjr4(#Pv)Bd6Ya?o+cvKu#fp(46+A<~Xc%vZue!w~vr4&l{Vy2pGQZzBM^S zTXg-q0=&*bI@EH2P-QpMKwHm5e1CV{fq&IffK~KTc&x#ff8yTOa^aA zW0#)GIldgB$c;?Srof`hFY*{!_SnP{xKyVLwdKo9Fu&g!BZZqfCpv|>eJ>W^hgdfO zE#4qDH6s}QtIng~!b?7^YVk0Rr7&MQLFFKNwNe-xdP0in6G zDr@bn@5Iy(lVw@>F(xG@H%rdtU32`a+vLxo4&|n{JL=Nr{q9VoFL9|a8%3LO)ag`+ z&ZnK16Rj`|99mbI*6_U&8EpC)d+VT`CvcEESGOS^ukK9J$oN^knpxmwz%Se!e`u6p zmU2<_4Hd#cshn>*K0)0_iPhjYyr?2zvUC=G+B^pz7Lkq~j$)s5P$&+0vsc@CkQ?IN zzm#!|=Hu7Fj55x)*mq|67u+#Q6ggGZ1l5NKN!P#!?qE%-~1LM<W>ZaG}y_ip60G$_j%p|Fu- zBnxIcZ6>v|%Ul_51nkqH*?fW%#O?DHwkLVV&C78Y)pNc3Z|it+=O+i;G8lURZjG1``rn(r77dXFDDFMpLwFZdCgy7E9&)Tsl+&{*u0`cv^3lW!Oct@Dkkw*_={ZfhGN^X z28rI29_T(Th+NW5%nb`6le}m82s#zhh-+_MtVl$i3fD|AI+dgdrME8Dq<0-xRj+EyDrp0}&pLBIL!nbgSJ92P-2_GC{?wO4@`2fTPPh9p_HoT5|V zm@X1N$#ESDyu$cb>a$pk(4hromm~Or^rL-=h$I0oUVz^+gJG8@upa=}>FR=-qNu@z z7tHLCCvC#^gDW;Q8EN=Q6a-MyynuGnT#2!^+%fh;;!G7HHtXJ+_B7GX?}j^m<$j*p zk*2MgmRB-YE0nB=Ox=uea@bkyHO!a36EpUy zZ;#UPi^&>d0^aDP@mNJrBIyGo#n+tOx)B`u+>WF_)n+zm;mfD2MDb^fz56lNx51m8 zsVR%p3`lO;4+JMzBTmVil=rLf7Hi!nPRSL3MNU-gwOJV|WU1Au$F$K!$swm2Ps&sH zloX!t)x?*kPY`K|4;$@FWpsNH$Hb1}WBdG04=f64@+)pD;g3AXIIbBVj%3}$R0%4K zHu&Te@fXybDw~4M7rGr}Uf}+(pCtaT2aErw(AnIi)xdS4`uUVysDnyxRE@KVd__^< zZ{Cw~H)os_mQCi$E*^EMq!SE%gal#j@;7_5{Ff^Qc1+B+@px5|O z;81eP(FnXzwroR-{G%gR%*3By0XFIQL!hKCKPvZ z5SuF_z^4PDP$EZOJsHtXHnzy>i1HU^v$5K*Ss7rt%6{ppcKkzMgdAGMzqaf^MkNr^2AZ+by7k4?gs`AwBklFwF``oO_TRvH5-QE_| zc=j%bXpFc~IC+k2J7|b|SRc*(6CY=jWeyX|Yt3Y@rt#xA-74u~xP}Mc(xM zuFAZvSxomupOA-BEM3gk%B6b9-D?yd7~~S&4*dho?e_RuyK9v$ZCCJ)QsiiUf;;JN zh}NyUEQOzXYYI7T3`!Uqcp0OaHAK%mWAu<-V}hr@s?hF( zhGA}EmX(L8sQ~39|$+BIgV%dZo36bt({fOL-T~qdQp_be0+R`RhXy*LY znFkSOi{m2&yCK{$!aDI2Z#Rf@aFE9Uu6;nmz zyv!+}zieRyK|fP_B=K=1nI9@D4gJp_sQ)|H{q0fCudkyU zeIKbeY&AvNTWqcHeP#P!k=D@o;k=IjW{cfIPJNb($R0Cf#{R*Nz&e{cDfZEs4f`eY z5>Gnx6?SqJifa4nTSkD7b`K - - - - - - gp_hash_table Interface - - - - - - - diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/gp_hash_tag.html b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/gp_hash_tag.html deleted file mode 100644 index 4c5f06b57..000000000 --- a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/gp_hash_tag.html +++ /dev/null @@ -1,47 +0,0 @@ - - - - - - - gp_hash_tag Interface - - - - -
    -

    gp_hash_tag Interface

    - -

    General-probing hash data structure tag.

    - -

    Defined in: tag_and_trait.hpp

    - -

    Base Classes

    - - - - - - - - - - - - - -
    ClassDerivation Type
    - 
    -basic_hash_tag
-
    -     		-

    public

    -
    -
    - - diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/hash_based_containers.html b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/hash_based_containers.html deleted file mode 100644 index 21d092a76..000000000 --- a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/hash_based_containers.html +++ /dev/null @@ -1,835 +0,0 @@ - - - - - - - Hash-Based Containers - - - - -
    -

    Hash Table Design

    - -

    Overview

    - -

    The collision-chaining hash-based container has the - following declaration.

    - 
    -template<
-    typename Key,
-    typename Mapped,
-    typename Hash_Fn = std::hash<Key>,
-    typename Eq_Fn = std::equal_to<Key>,
-    typename Comb_Hash_Fn = direct_mask_range_hashing<>
-    typename Resize_Policy = default explained below.
-     bool Store_Hash = false,
-     typename Allocator = std::allocator<char> >
-class cc_hash_table;
-
    - -

    The parameters have the following meaning:

    - -
      -
    1. Key is the key type.
      2. - -
    2. Mapped is the mapped-policy, and is explained in - Tutorial::Associative - Containers::Associative Containers Others than Maps.
      3. - -
    3. Hash_Fn is a key hashing functor.
      4. - -
    4. Eq_Fn is a key equivalence functor.
      5. - -
    5. Comb_Hash_Fn is a range-hashing_functor; - it describes how to translate hash values into positions - within the table. This is described in Hash Policies.
      6. - -
    6. Resize_Policy describes how a container object - should change its internal size. This is described in - Resize Policies.
      7. - -
    7. Store_Hash indicates whether the hash value - should be stored with each entry. This is described in - Policy Interaction.
      8. - -
    8. Allocator is an allocator - type.
      9. -
    - -

    The probing hash-based container has the following - declaration.

    - 
    -template<
-    typename Key,
-    typename Mapped,
-    typename Hash_Fn = std::hash<Key>,
-    typename Eq_Fn = std::equal_to<Key>,
-    typename Comb_Probe_Fn = direct_mask_range_hashing<>
-    typename Probe_Fn = default explained below.
-    typename Resize_Policy = default explained below.
-    bool Store_Hash = false,
-    typename Allocator =  std::allocator<char> >
-class gp_hash_table;
-
    - -

    The parameters are identical to those of the - collision-chaining container, except for the following.

    - -
      -
    1. Comb_Probe_Fn describes how to transform a probe - sequence into a sequence of positions within the table.
      2. - -
    2. Probe_Fn describes a probe sequence policy.
      3. -
    - -

    Some of the default template values depend on the values of - other parameters, and are explained in Policy Interaction.

    - -

    Hash - Policies

    - -

    General - Terms

    - -

    Following is an explanation of some functions which hashing - involves. Figure Hash functions, - ranged-hash functions, and range-hashing functions) - illustrates the discussion.

    - -
    -
    - -
    Hash functions, ranged-hash functions, and - range-hashing functions.
    - -

    Let U be a domain (e.g., the integers, or the - strings of 3 characters). A hash-table algorithm needs to map - elements of U "uniformly" into the range [0,..., m - - 1] (where m is a non-negative integral value, and - is, in general, time varying). I.e., the algorithm needs - a ranged-hash function

    - -

    f : U × Z+ → Z+ - ,

    - -

    such that for any u in U ,

    - -

    0 ≤ f(u, m) ≤ m - 1 ,

    - -

    and which has "good uniformity" properties [knuth98sorting]. One - common solution is to use the composition of the hash - function

    - -

    h : U → Z+ ,

    - -

    which maps elements of U into the non-negative - integrals, and

    - -

    g : Z+ × Z+ → - Z+,

    - -

    which maps a non-negative hash value, and a non-negative - range upper-bound into a non-negative integral in the range - between 0 (inclusive) and the range upper bound (exclusive), - i.e., for any r in Z+,

    - -

    0 ≤ g(r, m) ≤ m - 1 .

    - -

    The resulting ranged-hash function, is

    - -

    f(u , m) = - g(h(u), m) (1) .

    - -

    From the above, it is obvious that given g and - h, f can always be composed (however the converse - is not true). The STL's hash-based containers allow specifying - a hash function, and use a hard-wired range-hashing function; - the ranged-hash function is implicitly composed.

    - -

    The above describes the case where a key is to be mapped - into a single position within a hash table, e.g., - in a collision-chaining table. In other cases, a key is to be - mapped into a sequence of positions within a table, - e.g., in a probing table. Similar terms apply in this - case: the table requires a ranged probe function, - mapping a key into a sequence of positions withing the table. - This is typically achieved by composing a hash function - mapping the key into a non-negative integral type, a - probe function transforming the hash value into a - sequence of hash values, and a range-hashing function - transforming the sequence of hash values into a sequence of - positions.

    - -

    Range-Hashing Functions

    - -

    Some common choices for range-hashing functions are the - division, multiplication, and middle-square methods [knuth98sorting], defined - as

    - -

    g(r, m) = - r mod m (2) ,

    - -

    g(r, m) = ⌈ u/v ( a r mod v ) ⌉ ,

    - -

    and

    - -

    g(r, m) = ⌈ u/v ( r2 mod v ) ⌉ - ,

    - -

    respectively, for some positive integrals u and - v (typically powers of 2), and some a. Each of - these range-hashing functions works best for some different - setting.

    - -

    The division method (2) is a - very common choice. However, even this single method can be - implemented in two very different ways. It is possible to - implement (2) using the low - level % (modulo) operation (for any m), or the - low level & (bit-mask) operation (for the case where - m is a power of 2), i.e.,

    - -

    g(r, m) = r % m (3) ,

    - -

    and

    - -

    g(r, m) = r & m - 1, (m = - 2k) for some k) (4),

    - -

    respectively.

    - -

    The % (modulo) implementation (3) has the advantage that for - m a prime far from a power of 2, g(r, m) is - affected by all the bits of r (minimizing the chance of - collision). It has the disadvantage of using the costly modulo - operation. This method is hard-wired into SGI's implementation - [sgi_stl].

    - -

    The & (bit-mask) implementation (4) has the advantage of - relying on the fast bit-wise and operation. It has the - disadvantage that for g(r, m) is affected only by the - low order bits of r. This method is hard-wired into - Dinkumware's implementation [dinkumware_stl].

    - -

    Ranged-Hash - Functions

    - -

    In cases it is beneficial to allow the - client to directly specify a ranged-hash hash function. It is - true, that the writer of the ranged-hash function cannot rely - on the values of m having specific numerical properties - suitable for hashing (in the sense used in [knuth98sorting]), since - the values of m are determined by a resize policy with - possibly orthogonal considerations.

    - -

    There are two cases where a ranged-hash function can be - superior. The firs is when using perfect hashing [knuth98sorting]; the - second is when the values of m can be used to estimate - the "general" number of distinct values required. This is - described in the following.

    - -

    Let

    - -

    s = [ s0,..., st - 1]

    - -

    be a string of t characters, each of which is from - domain S. Consider the following ranged-hash - function:

    - -

    f1(s, m) = ∑ i = - 0t - 1 si ai mod - m (5) ,

    - -

    where a is some non-negative integral value. This is - the standard string-hashing function used in SGI's - implementation (with a = 5) [sgi_stl]. Its advantage is that - it takes into account all of the characters of the string.

    - -

    Now assume that s is the string representation of a - of a long DNA sequence (and so S = {'A', 'C', 'G', - 'T'}). In this case, scanning the entire string might be - prohibitively expensive. A possible alternative might be to use - only the first k characters of the string, where

    - -

    |S|k ≥ m ,

    - -

    i.e., using the hash function

    - -

    f2(s, m) = ∑ i - = 0k - 1 si ai mod - m , (6)

    - -

    requiring scanning over only

    - -

    k = log4( m )

    - -

    characters.

    - -

    Other more elaborate hash-functions might scan k - characters starting at a random position (determined at each - resize), or scanning k random positions (determined at - each resize), i.e., using

    - -

    f3(s, m) = ∑ i = - r0r0 + k - 1 si - ai mod m ,

    - -

    or

    - -

    f4(s, m) = ∑ i = 0k - - 1 sri ari mod - m ,

    - -

    respectively, for r0,..., rk-1 - each in the (inclusive) range [0,...,t-1].

    - -

    It should be noted that the above functions cannot be - decomposed as (1) .

    - -

    Implementation

    - -

    This sub-subsection describes the implementation of the - above in pb_ds. It first explains range-hashing - functions in collision-chaining tables, then ranged-hash - functions in collision-chaining tables, then probing-based - tables, and, finally, lists the relevant classes in - pb_ds.

    - -

    Range-Hashing and Ranged-Hashes in Collision-Chaining - Tables

    - -

    cc_hash_table is - parametrized by Hash_Fn and Comb_Hash_Fn, a - hash functor and a combining hash functor, respectively.

    - -

    In general, Comb_Hash_Fn is considered a - range-hashing functor. cc_hash_table - synthesizes a ranged-hash function from Hash_Fn and - Comb_Hash_Fn (see (1) - above). Figure Insert - hash sequence diagram shows an insert sequence - diagram for this case. The user inserts an element (point A), - the container transforms the key into a non-negative integral - using the hash functor (points B and C), and transforms the - result into a position using the combining functor (points D - and E).

    - -
    no image
    - -
    Insert hash sequence diagram.
    - -

    If cc_hash_table's - hash-functor, Hash_Fn is instantiated by null_hash_fn (see Interface::Concepts::Null - Policy Classes), then Comb_Hash_Fn is taken to be - a ranged-hash function. Figure Insert hash sequence diagram - with a null hash policy shows an insert sequence - diagram. The user inserts an element (point A), the container - transforms the key into a position using the combining functor - (points B and C).

    - -
    -
    - -
    Insert hash sequence diagram with a null hash - policy.
    - -

    Probing Tables

    - -

    gp_hash_table is - parametrized by Hash_Fn, Probe_Fn, and - Comb_Probe_Fn. As before, if Hash_Fn and - Probe_Fn are, respectively, null_hash_fn and null_probe_fn, then - Comb_Probe_Fn is a ranged-probe functor. Otherwise, - Hash_Fn is a hash functor, Probe_Fn is a - functor for offsets from a hash value, and - Comb_Probe_Fn transforms a probe sequence into a - sequence of positions within the table.

    - -

    Pre-Defined Policies

    - -

    pb_ds contains some pre-defined classes - implementing range-hashing and probing functions:

    - -
      -
    1. direct_mask_range_hashing - and direct_mod_range_hashing - are range-hashing functions based on a bit-mask and a modulo - operation, respectively.
      2. - -
    2. linear_probe_fn, and - quadratic_probe_fn are - a linear probe and a quadratic probe function, - respectively.
      3. -
    Figure Hash policy class - diagram shows a class diagram. - -
    -
    - -
    Hash policy class diagram.
    - -

    Resize - Policies

    - -

    General Terms

    - -

    Hash-tables, as opposed to trees, do not naturally grow or - shrink. It is necessary to specify policies to determine how - and when a hash table should change its size. Usually, resize - policies can be decomposed into orthogonal policies:

    - -
      -
    1. A size policy indicating how a hash table - should grow (e.g., it should multiply by powers of - 2).
      2. - -
    2. A trigger policy indicating when a hash - table should grow (e.g., a load factor is - exceeded).
      3. -
    - -

    Size - Policies

    - -

    Size policies determine how a hash table changes size. These - policies are simple, and there are relatively few sensible - options. An exponential-size policy (with the initial size and - growth factors both powers of 2) works well with a mask-based - range-hashing function (see Range-Hashing Policies), and is the - hard-wired policy used by Dinkumware [dinkumware_stl]. A - prime-list based policy works well with a modulo-prime range - hashing function (see Range-Hashing - Policies), and is the hard-wired policy used by SGI's - implementation [sgi_stl].

    - -

    Trigger - Policies

    - -

    Trigger policies determine when a hash table changes size. - Following is a description of two policies: load-check - policies, and collision-check policies.

    - -

    Load-check policies are straightforward. The user specifies - two factors, αmin and - αmax, and the hash table maintains the - invariant that

    - -

    αmin ≤ (number of - stored elements) / (hash-table size) ≤ - αmax (1) .

    - -

    Collision-check policies work in the opposite direction of - load-check policies. They focus on keeping the number of - collisions moderate and hoping that the size of the table will - not grow very large, instead of keeping a moderate load-factor - and hoping that the number of collisions will be small. A - maximal collision-check policy resizes when the longest - probe-sequence grows too large.

    - -

    Consider Figure Balls and - bins. Let the size of the hash table be denoted by - m, the length of a probe sequence be denoted by - k, and some load factor be denoted by α. We would - like to calculate the minimal length of k, such that if - there were α m elements in the hash table, a probe - sequence of length k would be found with probability at - most 1/m.

    - -
    -
    - -
    Balls and bins.
    - -

    Denote the probability that a probe sequence of length - k appears in bin i by pi, the - length of the probe sequence of bin i by - li, and assume uniform distribution. Then

    - -

    p1 = (3)

    - -

    P(l1 ≥ k) =

    - -

    P(l1 ≥ α ( 1 + k / α - 1 - ) ≤ (a)

    - -

    e ^ ( - ( α ( k / α - 1 )2 ) /2 - ) ,

    - -

    where (a) follows from the Chernoff bound [motwani95random]. To - calculate the probability that some bin contains a probe - sequence greater than k, we note that the - li are negatively-dependent [dubhashi98neg]. Let - I(.) denote the indicator function. Then

    - -

    P( existsi - li ≥ k ) = (3)

    - -

    P ( ∑ i = 1m - I(li ≥ k) ≥ 1 ) =

    - -

    P ( ∑ i = 1m I ( - li ≥ k ) ≥ m p1 ( 1 + 1 / (m - p1) - 1 ) ) ≤ (a)

    - -

    e ^ ( ( - m p1 ( 1 / (m p1) - - 1 ) 2 ) / 2 ) ,

    - -

    where (a) follows from the fact that the Chernoff bound can - be applied to negatively-dependent variables [dubhashi98neg]. Inserting - (2) into (3), and equating with - 1/m, we obtain

    - -

    k ~ √ ( 2 α ln 2 m ln(m) ) - ) .

    - -

    Implementation

    - -

    This sub-subsection describes the implementation of the - above in pb_ds. It first describes resize policies and - their decomposition into trigger and size policies, then - describes pre-defined classes, and finally discusses controlled - access the policies' internals.

    - -

    Resize Policies and Their Decomposition

    - -

    Each hash-based container is parametrized by a - Resize_Policy parameter; the container derives - publicly from Resize_Policy. For - example:

    - 
    -cc_hash_table<
-    typename Key,
-    typename Mapped,
-    ...
-    typename Resize_Policy
-    ...> :
-        public Resize_Policy
-
    - -

    As a container object is modified, it continuously notifies - its Resize_Policy base of internal changes - (e.g., collisions encountered and elements being - inserted). It queries its Resize_Policy base whether - it needs to be resized, and if so, to what size.

    - -

    Figure Insert - resize sequence diagram shows a (possible) sequence diagram - of an insert operation. The user inserts an element; the hash - table notifies its resize policy that a search has started - (point A); in this case, a single collision is encountered - - the table notifies its resize policy of this (point B); the - container finally notifies its resize policy that the search - has ended (point C); it then queries its resize policy whether - a resize is needed, and if so, what is the new size (points D - to G); following the resize, it notifies the policy that a - resize has completed (point H); finally, the element is - inserted, and the policy notified (point I).

    - -
    -
    - -
    Insert resize sequence diagram.
    - -

    In practice, a resize policy can be usually orthogonally - decomposed to a size policy and a trigger policy. Consequently, - the library contains a single class for instantiating a resize - policy: hash_standard_resize_policy - is parametrized by Size_Policy and - Trigger_Policy, derives publicly from - both, and acts as a standard delegate [gamma95designpatterns] - to these policies.

    - -

    Figures Standard - resize policy trigger sequence diagram and Standard resize policy size - sequence diagram show sequence diagrams illustrating the - interaction between the standard resize policy and its trigger - and size policies, respectively.

    - -
    -
    - -
    Standard resize policy trigger sequence - diagram.
    - -
    -
    - -
    Standard resize policy size sequence - diagram.
    - -

    Pre-Defined Policies

    - -

    The library includes the following - instantiations of size and trigger policies:

    - -
      -
    1. hash_load_check_resize_trigger - implements a load check trigger policy.
      2. - -
    2. cc_hash_max_collision_check_resize_trigger - implements a collision check trigger policy.
      3. - -
    3. hash_exponential_size_policy - implements an exponential-size policy (which should be used - with mask range hashing).
      4. - -
    4. hash_prime_size_policy - implementing a size policy based on a sequence of primes - [sgi_stl] (which should - be used with mod range hashing
      5. -
    - -

    Figure Resize policy class - diagram gives an overall picture of the resize-related - classes. basic_hash_table - is parametrized by Resize_Policy, which it subclasses - publicly. This class is currently instantiated only by hash_standard_resize_policy. - hash_standard_resize_policy - itself is parametrized by Trigger_Policy and - Size_Policy. Currently, Trigger_Policy is - instantiated by hash_load_check_resize_trigger, - or cc_hash_max_collision_check_resize_trigger; - Size_Policy is instantiated by hash_exponential_size_policy, - or hash_prime_size_policy.

    - -
    -
    - -
    Resize policy class diagram.
    - -

    Controlled Access to Policies' Internals

    - -

    There are cases where (controlled) access to resize - policies' internals is beneficial. E.g., it is sometimes - useful to query a hash-table for the table's actual size (as - opposed to its size() - the number of values it - currently holds); it is sometimes useful to set a table's - initial size, externally resize it, or change load factors.

    - -

    Clearly, supporting such methods both decreases the - encapsulation of hash-based containers, and increases the - diversity between different associative-containers' interfaces. - Conversely, omitting such methods can decrease containers' - flexibility.

    - -

    In order to avoid, to the extent possible, the above - conflict, the hash-based containers themselves do not address - any of these questions; this is deferred to the resize policies, - which are easier to change or replace. Thus, for example, - neither cc_hash_table nor - gp_hash_table - contain methods for querying the actual size of the table; this - is deferred to hash_standard_resize_policy.

    - -

    Furthermore, the policies themselves are parametrized by - template arguments that determine the methods they support - ([alexandrescu01modern] - shows techniques for doing so). hash_standard_resize_policy - is parametrized by External_Size_Access that - determines whether it supports methods for querying the actual - size of the table or resizing it. hash_load_check_resize_trigger - is parametrized by External_Load_Access that - determines whether it supports methods for querying or - modifying the loads. cc_hash_max_collision_check_resize_trigger - is parametrized by External_Load_Access that - determines whether it supports methods for querying the - load.

    - -

    Some operations, for example, resizing a container at - run time, or changing the load factors of a load-check trigger - policy, require the container itself to resize. As mentioned - above, the hash-based containers themselves do not contain - these types of methods, only their resize policies. - Consequently, there must be some mechanism for a resize policy - to manipulate the hash-based container. As the hash-based - container is a subclass of the resize policy, this is done - through virtual methods. Each hash-based container has a - private virtual method:

    - 
    -virtual void
-    do_resize
-    (size_type new_size);
-
    - -

    which resizes the container. Implementations of - Resize_Policy can export public methods for resizing - the container externally; these methods internally call - do_resize to resize the table.

    - -

    Policy - Interaction

    - -

    Hash-tables are unfortunately especially susceptible to - choice of policies. One of the more complicated aspects of this - is that poor combinations of good policies can form a poor - container. Following are some considerations.

    - -

    Probe Policies, Size - Policies, and Trigger Policies

    - -

    Some combinations do not work well for probing containers. - For example, combining a quadratic probe policy with an - exponential size policy can yield a poor container: when an - element is inserted, a trigger policy might decide that there - is no need to resize, as the table still contains unused - entries; the probe sequence, however, might never reach any of - the unused entries.

    - -

    Unfortunately, pb_ds cannot detect such problems at - compilation (they are halting reducible). It therefore defines - an exception class insert_error to throw an - exception in this case.

    - -

    Hash Policies and Trigger - Policies

    - -

    Some trigger policies are especially susceptible to poor - hash functions. Suppose, as an extreme case, that the hash - function transforms each key to the same hash value. After some - inserts, a collision detecting policy will always indicate that - the container needs to grow.

    - -

    The library, therefore, by design, limits each operation to - one resize. For each insert, for example, it queries - only once whether a resize is needed.

    - -

    Equivalence Functors, Storing - Hash Values, and Hash Functions

    - -

    cc_hash_table and - gp_hash_table are - parametrized by an equivalence functor and by a - Store_Hash parameter. If the latter parameter is - true, then the container stores with each entry - a hash value, and uses this value in case of collisions to - determine whether to apply a hash value. This can lower the - cost of collision for some types, but increase the cost of - collisions for other types.

    - -

    If a ranged-hash function or ranged probe function is - directly supplied, however, then it makes no sense to store the - hash value with each entry. pb_ds's container will - fail at compilation, by design, if this is attempted.

    - -

    Size Policies and - Load-Check Trigger Policies

    - -

    Assume a size policy issues an increasing sequence of sizes - a, a q, a q1, a q2, ... For - example, an exponential size policy might issue the sequence of - sizes 8, 16, 32, 64, ...

    - -

    If a load-check trigger policy is used, with loads - αmin and αmax, - respectively, then it is a good idea to have:

    - -
      -
    1. αmax ~ 1 / q
      2. - -
    2. αmin < 1 / (2 q)
      3. -
    - -

    This will ensure that the amortized hash cost of each - modifying operation is at most approximately 3.

    - -

    αmin ~ αmax is, in - any case, a bad choice, and αmin > - αmax is horrendous.

    -
    - - diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/hash_exponential_size_policy.html b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/hash_exponential_size_policy.html deleted file mode 100644 index 1089b1544..000000000 --- a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/hash_exponential_size_policy.html +++ /dev/null @@ -1,183 +0,0 @@ - - - - - - - hash_exponential_size_policy Interface - - - - -
    -

    hash_exponential_size_policy Interface

    - -

    A size policy whose sequence of sizes form an exponential - sequence (typically powers of 2)

    - -

    Defined in: hash_policy.hpp

    - -

    Template Parameters

    - - - - - - - - - - - - - - - - - -
    ParameterDescriptionDefault Value
    - 
    -typename Size_Type 
-
    -     		-

    Size type.

    -     		size_t
    - -

    Public Types and - Constants

    - -

    General Definitions

    - - - - - - - - - - - - - - - - - -
    TypeDefinitionDescription
    - 
    -size_type
-
    -     		- 
    -Size_Type
-
    -     		-

    Size type.

    -
    - -

    Public Methods

    - -

    Constructors, Destructor, and - Related

    - - - - - - - - - - - - - - - - - - - -
    MethodDescription
    - 
    -  hash_exponential_size_policy
-  (size_type start_size = 8, 
-    size_type grow_factor = 2)
-
    -     		-

    Default constructor, or constructor taking a - start_size, or - constructor taking a start size and grow_factor. The policy will use the - sequence of sizes start_size, start_size * grow_factor, start_size * grow_factor^2, ...

    -
    - 
    -void 
-  swap
-  (hash_exponential_size_policy &other)
-
    -     		-

    Swaps content.

    -
    - -

    Protected Methods

    - -

    Size methods

    - - - - - - - - - - - - - - - - - - - -
    MethodDescription
    - 
    -size_type
-  get_nearest_larger_size
-  (size_type size) const
-
    -     		-

    Given a size size, - returns a size that is larger.

    -
    - 
    -size_type
-  get_nearest_smaller_size
-  (size_type size) const
-
    -     		-

    Given a size size, - returns a size that is smaller.

    -
    -
    - - diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/hash_load_check_resize_trigger.html b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/hash_load_check_resize_trigger.html deleted file mode 100644 index b22b7b5cf..000000000 --- a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/hash_load_check_resize_trigger.html +++ /dev/null @@ -1,583 +0,0 @@ - - - - - - - hash_load_check_resize_trigger Interface - - - - -
    -

    hash_load_check_resize_trigger Interface

    - -

    A resize trigger policy based on a load check. It keeps the - load factor between some load factors load_min and - load_max.

    - -

    Defined in: hash_policy.hpp

    - -

    Template Parameters

    - - - - - - - - - - - - - - - - - - - - - - - - - -
    ParameterDescriptionDefault Value
    - 
    -bool External_Load_Access 
-
    -     		-

    Specifies whether the load factor can be accessed - externally. The two options have different trade-offs in - terms of flexibility, genericity, and encapsulation.

    -     		false
    - 
    -typename Size_Type 
-
    -     		-

    Size type.

    -     		size_t
    - -

    Public Types and - Constants

    - -

    General Definitions

    - - - - - - - - - - - - - - - - - - - - - - - - - -
    TypeDefinitionDescription
    - 
    -size_type
-
    -     		- 
    -Size_Type
-
    -     		-

    Size type.

    -
    - 
    -external_load_access
-
    -     		- 
    -External_Load_Access
-
    -     		-

    Indicates whether loads can be accessed externally

    -
    - -

    Public Methods

    - -

    Constructors, Destructor, and - Related

    - - - - - - - - - - - - - - - - - - - - - - - - - -
    MethodDescription
    - 
    -  hash_load_check_resize_trigger
-  (float load_min = 0.125, 
-    float load_max = 0.5)
-
    -     		-

    Default constructor, or constructor taking - load_min and - load_max load factors - between which this policy will keep the actual load.

    - -

    It is the responsibility of the user to ensure that - load_min is smaller than - load_max.

    -
    - 
    -void
-  swap
-  (hash_load_check_resize_trigger &other)
-
    -     		-

    Swaps content.

    -
    - 
    -  virtual
-    ~hash_load_check_resize_trigger
-    ()
-
    -     		-

    Destructor.

    -
    - -

    Load Access Methods

    - -

    These methods are only available if the external access - parameter is set.

    - - - - - - - - - - - - - - - - - - - -
    MethodDescription
    - 
    -inline std::pair<float, float>
-  get_loads
-  () const
-
    -     		-

    Returns a pair of the minimal and maximal loads, - respectively.

    - -

    Calling this method will not compile when External_Load_Access - == false.

    -
    - 
    -void 
-  set_loads
-  (std::pair<float, float> load_pair)
-
    -     		-

    Sets the loads through a pair of the minimal and - maximal loads, respectively.

    - -

    Calling this method resizes the container, and might - throw an exception. It is the responsibility of the user - to pass appropriate loads to this function. Calling this - method will not compile when External_Load_Access - == false.

    -
    - -

    Protected Methods

    - -

    Insert Search - Notifications.

    - -

    Notifications called during an insert operation.

    - - - - - - - - - - - - - - - - - - - - - - - - - -
    MethodDescription
    - 
    -inline void
-  notify_insert_search_start
-  ()
-
    -     		-

    Notifies a search started.

    -
    - 
    -inline void
-  notify_insert_search_collision
-  ()
-
    -     		-

    Notifies a search encountered a collision.

    -
    - 
    -inline void
-  notify_insert_search_end
-  ()
-
    -     		-

    Notifies a search ended.

    -
    - -

    Find Search - Notifications.

    - -

    Notifications called during a find operation.

    - - - - - - - - - - - - - - - - - - - - - - - - - -
    MethodDescription
    - 
    -inline void
-  notify_find_search_start
-  ()
-
    -     		-

    Notifies a search started.

    -
    - 
    -inline void
-  notify_find_search_collision
-  ()
-
    -     		-

    Notifies a search encountered a collision.

    -
    - 
    -inline void
-  notify_find_search_end
-  ()
-
    -     		-

    Notifies a search ended.

    -
    - -

    Erase Search - Notifications.

    - -

    Notifications called during an insert operation.

    - - - - - - - - - - - - - - - - - - - - - - - - - -
    MethodDescription
    - 
    -inline void
-  notify_erase_search_start
-  ()
-
    -     		-

    Notifies a search started.

    -
    - 
    -inline void
-  notify_erase_search_collision
-  ()
-
    -     		-

    Notifies a search encountered a collision.

    -
    - 
    -inline void
-  notify_erase_search_end
-  ()
-
    -     		-

    Notifies a search ended.

    -
    - -

    Content Change - Notifications.

    - -

    Notifications called when the content of the table changes - in a way that can affect the resize policy.

    - - - - - - - - - - - - - - - - - - - - - - - - - -
    MethodDescription
    - 
    -inline void
-  notify_inserted
-  (size_type num_entries)
-
    -     		-

    Notifies an element was inserted. the total number of - entries in the table is num_entries.

    -
    - 
    -inline void
-  notify_erased
-  (size_type num_entries)
-
    -     		-

    Notifies an element was erased.

    -
    - 
    -void 
-  notify_cleared
-  ()
-
    -     		-

    Notifies the table was cleared.

    -
    - -

    Size Change - Notifications.

    - -

    Notifications called when the table changes size.

    - - - - - - - - - - - - - - - - - - - -
    MethodDescription
    - 
    -void
-  notify_resized
-  (size_type new_size)
-
    -     		-

    Notifies the table was resized as a result of this - object's signifying that a resize is needed.

    -
    - 
    -void
-  notify_externally_resized
-  (size_type new_size)
-
    -     		-

    Notifies the table was resized externally.

    -
    - -

    Queries

    - -

    Called to query whether/how to resize.

    - - - - - - - - - - - - - - - - - - - -
    MethodDescription
    - 
    -inline bool 
-  is_resize_needed
-  () const
-
    -     		-

    Queries whether a resize is needed.

    -
    - 
    -inline bool
-  is_grow_needed
-  (size_type size, 
-    size_type num_entries) const
-
    -     		-

    Queries whether a grow is needed.

    - -

    This method is called only if this object indicated - resize is needed. The actual size of the table is size, and the number of entries in - it is num_entries.

    -
    - -

    Private Methods

    - -

    Overrides

    - - - - - - - - - - - - - -
    MethodDescription
    - 
    -virtual void
-  do_resize
-  (size_type new_size)
-
    -     		-

    Resizes to new_size.

    -
    -
    - - diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/hash_policy_cd.png b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/hash_policy_cd.png deleted file mode 100644 index f3122a112fc9dbff20f7f10a7c87f1cf86097c7e..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 25302 zcmeFZbySp5_dg0qBOubG^jwG;cvPv>hunw1*jJXq0Z*tvb?ZXf}FaC3!tRi@jjk682&L-#2r~wY)WN zQyuv5@^cq@!tJik>Um7D6AgNau4|I%jXu1a>SiN=ki{KYVG{l5Nw`iHdS{$QdH1Qf zaaxbq;1mJb-6-@m2Wq;wf;Wd)q|a8ZLhZNWWahnAmYQ1II(IHTA2$EmGd=lexD|Ag zQ?}E2c9W|mbMY06UO^5Q7oC|2GosrDlL`4S;`zOM7^rVy1Gw!q%|+ZCs;fsELt78u zF(qY7QIlcdk!W+jPsV=h^n^V)c{&xXs3OF}!y_o@I+%VOmyVv^`Y!T`W@CgL6tl{_ z&FA8$-IlxC!u6lu14lbE8&+6|YAos>Z7aX4MEg_13E2e>r_}{I&Xxn6B;fEWc>#Cx z{+G}oo5#LyNXMz=3`m{sJ%_)|$*HVOLhK{e(_KC{yYFthZ;qty&R1(?*$ua7taODk z64veu6L^}^rCSm=BfK6F4D)ggaE5zKC%KJ>*O?f{bzgqyY~HS6AtQP?#H00Ay2mtI z+V606s!-K$)0?bDn5_43r1`^w5d5Vkan+2B%)6-MUkRhbPgWtE_ymVz*D5J6MB8O#(<1`oTpp&BOPwV#1C*g!f_EjKEl{6!g2lU z>E2TNi#wS^l~!#pOeWRdujNSj8buinCake^hGEo6H!IUMzO$O~b2*#8!w<@dZL#%7 z`l-6zndy}z9(S}8!q|OqwO-U0Gx-3QS^QaT>1bl}SnM5P*sgLFZ@$0Jz)fJYoJd2Xc*7LEG%dN|Yf}z2B?*myU_h zeY0dJ@6Z{fk{rCf&b8CDo=G;L`lFfIR*L&b+k@w6t8^yrXun>5Pe$=iKi&R>@bP|M zXEP7Nai>LnbLM-|a@e3vU+y*HQ{;@4ZRm?I?`dHn! z71Dx?IhI=sYr1l&=UsKB9w(rIk~7!b4Lf-gY}~fo@a%GYxJhHPW9gAY=%ZC*<>Z!Z47Oy2EU*kDF;>}4+s#)bbh1q4H z;=b9NZu)R7hLmyd^VTO2vN8AWX!3OUcHSVyW$mXNyd50bb9uZjA3a+ozT*~Q(14>= zkAMirpOyg|!jO}4OLHb9ZcY!Bm_U2Kbn#e~YzhVvy+G{mr$F0W=AM~KkQwd>QR>tqwT zl=)kq$0L)i!H$&9l=E}`8~UZ@)@y#Ch8Q?h!V2t3qa9uVrv zpPaZ!in$?;L~mmj)A>FtGLzoG&46f1*&bO#Npum z2L~cDRD)}8>nb5bO(uII=T8_HV-)8rL`IvN7x3oaeHdr{uqJl&Y6VmNiovdiyFI6$ zLt>dY=))}?O)CYQhQRUuNS$v`Oo98YBr=c(}=k>B~k?A(#Omd zaO$}=)P_uSJ!c@jobK3F#HXe<-%^iqEN!KSiA^U4Bs-nBB`ML}Uqc`lwu-h+?R&l6 z+yrt07xmJbMowF*QbUU}pv}79g0wdwkHl*iw9jeJY&nOhqY@$AkE(*tz*nFBmJBVR znfSvjKj0|_=jQO9*Z8c48$z0C;hu3#&gmqSrHI+DZdQ|>Z=U{1erl*4>C3)HB75~d zE$faGS9I>%tq!(j&4P6k<@d!f!Es4fhU>xKfW^d;%J6@t-*Hf--J8!0(!l+8S_C)v z>Ba=uCc2rJW;J%?hCb+zzR2g3O~p_j#o4#$B46+c4%%HucEpCowtQtut_JkG~OPObR~-W?YM2FOPo3%LLk1xEQDFxUs-}|k`FG0d;K3pmGZud)q~YZb~7^}UQ@a@D3uQAuIE(xTF3(%W(^`*9UBdTx5B z(XBpVq59pSaehvhyX^Oq^S0uAu65m;vYYc_TQ;OnVMQBiPAccKy-7$_v zikE8nG@D?W4JK^!*RT2lM#8FD{p$c^hk_*g5&hi&qB=z}2An zb0zSgqjga4`<{5`QT)p9FDsR!pD=bIg{B5a+Pp z%?khHEEQ!VpDOK_U<&@p_@pjdAZ*5%sN78l7k*Ec;6^b?w$hL+nRNV#CV@$6D~<|Y z-_tOD{*rZ~&9~S;i4X2ee8G2aXk!Swzi$5q9u->fjseGz;LXen#BA!AR(#-H+G{vj zX#bmK+ndOywa{;b0Ryu6cGMveVf{^~#R2uhUA4+#?x{JW@&?pdoA60Gf>4p<&AoKr z52TG!Q~1t5T~jM`ZbC%pse<}>P6Oxg-kh$A=-|qAdB;oJaMcok-)WSQbBpD+8uDSOWNl@;=V<_-S{ZjpaACr-qSp=|`%~ zy&sa(zJ1Lu^46NeS7ma(UZ7gDj6MqGzxb2cjb3QGRb78vtuCmyNBmwQMrWWZkN;zW z>w6{)3P4&t5=az)j6de?qAg) zl!}z5LVGp&GLggFz5I{``|UpkDjZ9L5+#ojio7`G_;So=P@y08#s!?{mC9w%d_>v zM`$f>Pd<^+ZIF2%k>C(jtg&XrEr!}LAQ%oVsoSMEr zvg;y(W+I+!)vuum7dcQzMtZuG(eGO0+rr{{#9Ldf$w`9xtW5XH-5eP}Gu>uq zfA@t^sC-_?Hz3J5WO(vwUXGH)S!}wQd-L3yoI-{RX|3c@oq8uq$b-CixS2ZfVPth{vhX%6xDHca8%O0*TDX03I$yKBY zeq615kv|v=7{*xZOfo>?sm4BLS7oY%N8O2UGUP&jz!S>>SOBlp2jK{K68I*cQ*5n$ z^$XCa`IZ*;+C6PGndvdc2AOyfQ-!cwobhX{LB>eK`@-df%eUtjw9p(_flb8Bq)E(- zm?*xdMk{;00%=q|ax?LZp2fptL+-D=_F16wO0OF@tg-f~*;hj6th0_?K+re!<}6Jo ze8^6l3%;nkA69?VH^vZ0?=sQd6b647&&yeN=h+4B+Nx1>m#R0o6sK(B(_^V;M6IKe zFh4dOR?fQc{Ww#}g%u6_C*QnMWXg18F{RgE+71OV1fhR`J&}Av|DonV{kykL;O&6B z#72iyV*8rqVPMSuQj8~r7%{n`-&2hZp*!QTQSnm!pJ?wDe`0nmlONF1^^)0(`)`dc z9R4j|w~vE(T+)=JSaQmxnr}cWFxydoXT0>k%;Bh?`BIZGOIl* z`hTCT84mXxH|U3H)-O4!AI&fn1NPXn%zA^!{S><&=JP(wQTu3yEXO4Ee-ncHYa|~% zdUUYr_viPS)c4I|b7>iwL8rIpIy`&KlUka7XJ34!hVeK#IqmK3_Xc*n5-r|;vi{Dc zqDeetFMIWA<$7%8M}9GtSR$kBIJL54IXmX%FkbG(2m8+R0fEyb(#fGjnadI+SNyiR z0Vv+RBwkomRrNiI^DpHNz>l|jgwb{C)OEV(R9)G`N?^yr1oB=}hVEdL$Ki)Lk|e!yBXtDF_}BoK zGh>7xtPvRBI0kfzv;>zDR0wlpmMP0YP58WZ64W7uR+*-1(1(;lsgxMbtV|&1EL5ki zWGJPPogS`U>~loD$xZ=XI$Whkq$vsE#c#tcfVrq52VE3HbqZle^4E-%+$*6#2g4d> zl_mK>@h@O5%;0Uaemx7^`gmZxGpf@y1Y&NLs>7_!hmkz(SQ_hL2BpE8`K*vU-SVom z{hk9YFn$Tu={yzQ+Ra_4kY@sD=0_;yW-~$rzo;dW4e3du>(4wX28?gK06HD=fV{)> zRU+jY07jG}`A6KrFtW#<1YpP(OVLk-JZE6M^D)qA4dBuL8b;zmFZ&p84$WTPQ;X>C zy4mgGc*pi&iRrMs>$1GM<8<-!Y01>nbx&^E!pKsJsPkHel{zF&CafkiAtN2T+?00V)~g~AgnUKOmNXfj1DeU zf2IcTc5k5sQSbAU9og_eVz29;hfPnL3ZK*L1X{4!k+gzbpf6~@in8Fqx9b0weKX@g z&R3ZS$`3hWCSSj8MAUDiUq**WO#T&WdRlW1WK7=)bNKfAPoF*oNF`67P^CSS2ecyr znn6&3;)9Da;Ck|W-E~CiOgf-5bK`M0zlvo6y|*h?1jYZU<{wzQOnMEk8mhq|0E9a& zwb#sQ@5A@d-}9lt-yY<)G&kcSe|;Ov>N=wBB8iSz7rb8*ZG&3r)C#rIJJd?QsejKk zb)H=AR=)<|pb^YW$UIs47}WP4V4-eIEnid!D7)7kec~2e2dFxdzxL1J}tQ!Lo_nTgE}Vm z{1tSB$H=$f!?*->1w;pXQ->ZK#<}%SADU^;JHH$QNVq)8oUs-HMtNvxNUrT-!!Tsi zkl(UXx+%-@_m1HMb&xU}NZKn9FNl>0R(_);aSENz7 z2odHC!mMO?YZA()ct6pT(AxO%a-uU3IVs6+6cHx zsi}%n{88~UmTMy=ryTlY*Cu~hD#t9tgBoJIN#v{mqW|oebLhkIY=V3q`+(-xWhu&n z1=!(x9+fH=_I?V~cO*Vvh>qrYTh=h=KHj9QdvzJ3zvgRVBoSoeup(1wOb}>KUTMzt zEAPtIbzU})4dg83i8x3>h&(E)DIq(+C^tYpu-0IBsXcN?UGQfA2iLf2OfRd&HA~lU z>ogd=4MCGC3-N<_OoB$y4gL{p_#bvx5nx- ziOjl9to0yinOO%p`2$XQ>+0vflTL|By!<0izui0jXX>-DZy22akaK$P z>wsWxh7>{cnKfbYQRPn-pJyer zO#Xr2=Khy9uIHhcePN{Sgw=_GXduyz>)EnAmg>84S+b;=0h5Y6R+iTFKHL6r$4?{F z-7eHmTT|;T|KWXx=_A$e95Dlbg3p>0og~ajAp834$o+e+i_d}M zxG|UsBQWBLtLk}UGd!q4;*Mo=r(uH}_s-Y;kRKe^DLb%g=Wxo*Cj?5_p8hyewi|0U z@R)|LsWQ7r0q(M;9(L&BVx62vjtM1rau*Qt;gm{?`-7r?vWzG8G7wCv6}ln z*s-G*sX!ox5ldxd$SW|1 zM#8;eZwCDbGV7X(j7ZC;VZ>7;6g8S}%1^l_<+mhL@<=Wvlb~wC(qEsRtg<>E?$bIZ zPphO%*13QIKxh7UjS@GP#03M%RCpt0xpg9-@z;%i)u_8T)otn@B7fg)@EEf2^=_i5C65vybFy@K)`){}bh#$b$XP`mP2XY!XgfW2R42_dB@Q ztu25=T%0q5yn7n{p+vp@SbmWP&Z)X!SU!6Cdp?|}3~}?y|2(P^LO|H81Tc#fy;L7q%_P+YeYeON0uhh2j2BRngSOt2sDzk5&w|x| ztd}B%1E9hwy4xb-eNqJ;UE3UnMtb z(AQ)~Mq-<>G_fJ0p9d{JF5m9PsvuX1JjOr7uUzCVPM%h{!~fbed0I&hki_S+Dwh;B zE{jD7FWvKx=L!JsB?!x^`Y)$u@NaX@mI0==uY7uDX6BeEA@m|WbUQCS*XQW`oT}PX zDaAD_8EP5S)Ck;V)_EV_G@wj?f-1T<@epO#`GBE?Kl0_^7JBg_NgU+X{zt%qL8G%(#L;8)Fu5*=-)NOOJ9}cSb$-B zcY!mr(vEh$GnwTACDE7aK#hjOUApt`uVCkie?hR6`2?UaI)KEV%d>Y9%DJ|JmG$<1 z0X(+XhPI-ILxO0ZFMFlLlq_xo(0x1);dKW)^;`_CW1E9qr(uQ%RGA|W-p0PmedLT5 zFr&d;;8<)3HIWKWo+hNyTVF!Kdp&@_f5H3zbp*C>Fv(1*fZF?hCB zawJa&w8S0(u4(x658>qLPf4Y{A(%CS$}EHVZHSYoXhglmzKwJ`d@xU>Ee_!&_9Rlj z+vFZ?StK1}&|#0j?`eVG;|JH8%s1WffoJ>VgGSr?Y7ljMhn&#lY47vBQa*qUqJ>i_ zDWsn>FcTx`EH9_iErL%zDrASz0`UOojPVf{C*bDskH62Ct; zzqhOUW|6CMyUg*VNIvY{mPK`R2ynS!wUQT8aSEbH=_SslPTh!X^r1zm}eEM`_He# zq}g(ZZdmtUX&q5ef~x!ol>3K)T!!70n1bM+dH6r6ONv!jqanuUl!|Cd0z0l1swUK6=H*sR zwg`j90JtGbNe2jZczNQR(F6FmJ4>3R%@0&~MWQyostF>*B7T8C)@L*8;tW+{M>_Wd z7@Lsc>_h>ORM($MKh}|PPvO(SmQi8QpUkW>rkIK65w9P;A`78@I#(tVlmITD9t$^z zwn}1E5dn_)Dk>O-Qk`sU)AJ96DyXp54z~c{k*P-yqLe4r?p~A59@zZtDn!NVt*Ab) z%tijIXF5&{c?bvsRZ?089T8ZbE1)g}!02`3_b~5 zxw3dkcr7yS?A>t(BcxWHl7CzXk z55xHqTop^Bu_?&^ZqdbLnTCtspSO_S^@s<0~*NpiD+iZ>i<(m z16vK&yeU1Rj$|kpHs>(AI)VQ`P3U~+Bj|>mdB5fX(&kFHBwhY{B z0AkQDX--p_dsE8k0MHVh45PO7eFy5>&A_{H!XWe@3=N zo6koKJAXD*2k+(hE`x^3pP4-tpM3=f;5Z#4qivPm`y-@4@b+2A!5O|gwhNH02-YB= z_89&AzNN=>)gb^#j~u1eSa2ITwR8V0*co);AsPJVXL{H5QrGXL&GVF$Sbl_F;;7aP zZ%`VZkz|91%OST(k^jU6nbUaVNc5?n)<{qBYyDE}E`&(P`9~w+tunnrFw|s}>NT9> zDJ0wynkj+6e^9IslZ^QKctvuF8)pqQ2FS_qo8#s$Emax#YUgV{RiF<$%`;s9Fgml_ zRT=EiN&oLS!etNK;WwS0jrv5rM{nWbi3Z4{3Vk!EZhXve;7+TU->9{q{pI*414-PW zKq!$+^6j)BP-RAYag~$42~oJ@j4wc`yu@;f$Kh-EV4Z)*>{r9`!w*j|4)H6C_H0qIF>*Z;(AD9wb)06RO9JmqZG+xal9&+2w_ z9`_Q?5OhIoe|ZWu5%SkEpD(MY!}dhYof_`e&WWNt-oA1@Ie9u}7_bV0KX2D1$M%Fv zZLZG5!k1gUcSllrfJc|!T>$A67~$jRKTOy*;c`3K(dY35klW#&(igQ2x8(%2(K!Ha z@NYay*P`Nk<&4cYNS{C}?m~x2Q5#?DS+kIb<`{YB>#9SJlPquUgJ7+C@3VdLZz6O; z-3e`RF*6d+UkPsYBXaD18E4nDWJG=U*W@p%-BEymJb(;WbP6D{u5g``n>#_H{@M{| zG#?)2IS2;3 zW{|d`tg`ItWRg{al;%em5XF2JX0f^dL-U=72Q%n5CP}#UGdU)F>K7Sv%))MNej6-Q zcFk6sG2yxEtZfNRB@LuAf=+p8)95LWOZN}AEKrU&s6mLq%wTUe#jm6O%77*Q?uXSgq4)PL@7h3kD~x%kB|hwD zaSB^dyGeW?J@yG;5diV2lBN4YPs+%8hQrGS`RQzJUS(N>JcK=9AEnNI?AWrLWbq*J@bU- zJquu0X>{5(-9j%UR>bE&gODW(?@sLw?exAqUa3RC{XaZZuDC0dHA8!IN^-V5T3$G&OGoO8?@NQK8Cqr=JvP#SE~+U~Eovr#ec7c$eJDHGb^ zif$mJ&p?Iy*`3_XW|npdp(j>^2(MzU1aUb9*P~K|m$8Xnr4R-lr$xAYPb04v4)y23 zyfF?O=tBmqZ|#+XKOjaDWEm%MTer+Jf8zU`iqxdJnNA&47qQ0ptvtt*Y}|J6RV38$ z3CW?Gkeo3g5-#Ov8yUeyT!HTbqp_T*YI>c`3lG~6g-3Cr#~y4-gj~HgEC0W*T*Gx9<-Iu zXTd${W}ifxR?qU?AG_*TlK3E&4_~C2!Y6+5H4nb{jjxVcoLu3OcXX}a1qOy};Mndb zP=0-N z{aA>DIfzy!Jix=_#S+qhit(tEwIPO7)MPd1yoTAN&R*(_@5kLv;X=EWS!UT?KwWzp z9fx6>zv%lpP5r!%I;Oum*l;_GPw%nm^8{H*NE3ySA6U)UaSVmK7@9wqy4Ps4N=n`Q zV)rr6=ht|WpWzyoteAbxU;kAN zCu88-$QO5d85FDyDBPz-g_5|ilgY073qD#IoIVw3z`X)`tc)+%L-!Tib_6@3hAyM+ z*M^12y_7!*ff^oxW9Y>DnVx=zKJZ4o`pLITcLy=>ues07!!l8u_O081m;>_D{+XD4qihd#h%;5(B(yM@<+{uBO8| zh)R1u=wEU=MdoJ==G<}}HaYBsqzm$@77;k6Z73=oRO#k)GDxIn5BF%uzwJ>T_NiM= z@>~rfo+lfc0&pZ_eyN~9nYO(_sTv_7q)T(XxO%(v%zwcL{|=2k@;0Y!-xSPv5WMxQ zoGxPH5eSD743l;uPlv+|9xv<8H*oX4?73ZVlZoyCj9PHRxV#yGsJHo9&&?Ote%lt= zL$|4kYAeJwHTw?u0HG&_p$*LeWiiRqdTOUu#Ssn{O`%s!vKJ|`Akw|tF?I!y_ViI> z=r?d4##BTY4vDQlPEVrSkk&8#g6q}XbJbC-8ixM*mNdB%;#NHr?h1dx$E%%?P;dtb z2JlkoR!$5hjOfkWPB?&hbypPtsPrHpGhrZ9licHaL-uCl=;#Q@)ir!2>xTXI!>h^f z1wg71KO)ht)g5??ci=6?e`=AM_8{|SWu}nJLrYT=@D7tF11511>p;fBrWcUcv?4G> z?U$Sq3wsB^_qZV5c6`a3RpOh~0ZPm3>n&MJVCp;QIAc;0E|g@??Y?_SKH?ioDJ(2x zbIkPAH(7KDSc|0Wyclz(82F*e7+h~v!&~xV+fS0-{^`}G<;|vt*$d83&EFLul>H^T ztxRKob~bqo3?K9eOdiIgC93sO&cTaGbt22U}Xl-SW8cqm;!~V?fziGx(z{D27VYi z<$SeedL~g#D!d54QLA?=?wM4Tzi2A_+w19U+V=ia zQEN>_%>q87%&Y@Rpte-k+4O0>2{cm`5|~07$MKn+xv@iowOx1?+Qv-TECkasuh04P ztpF&4FzYWEIZHWbL;54??IpMEMU>goH3&YHdFcv3o&m`dy%5=GE!0Hjz4iACf5#R5 z#KSX0ZU$z}C<38@#or$afvf>UeeNp{>Lef!D;vnnYDN1zA$_~}Rdk8a+f0>awo+x4 zhMqQJG4OW5b12dhNEjMpMLrq@Pt3fU7LFJ513X^ace(wX|M)Ch2y#j`nFUJFAvn3D*4V5=>Z6==`00bhG!$n-Sh#oP^lcTGNHAIrZy&UO{i_9%NZ*1$ zC;%$7PlizFsGy-GZ8X_NQu|h`07lD}A)A-?#`#{!2BK(w>6WC=1*ipyUBozXo z#2TN5{AQB@!x%v3G|_ysyY?cf6KN>QDs&eAZJ!l)^yBfulyJY-7Anc@)Ur}Cm5XOO zmQ5XxJf3;w5fvup2k0v&P1aAgRK4unTw=EtukC3~1OreF_H{TVhY_gf@@8y4J6Op* z_p-0V(jWAJuFceC|B{a9;xl##Hw5AY99Q5VFao2%dv~r<4WtZ)Gm?e;`c4A($h|BO zEHi8Iurs*FTe8lHVytW-%pk}GYE+I25_Io!9`U6>-!sFBhrYD=%HP#L9M6%G=yKn{ zUbg58$!Ybw+P3C2N?w1cM8e4xp6EtIKOkB566)xr{Z^Y&=dSA%W?`7CdyYmQM@R2T zu>QBGDdC`Rjnh6CAu75T(vJG5ND2}V1xht6vRDG8A2XTb?)ou?BN^K)Vj(SOPMnS0 zNRcR>S#5~(n^97-zGB|E7>TgFpR8O$JelgqaMe02Efy^^@WQfjui2+I9!} zt!4!h4HhJ@S?bc;gZeL`?)paW(3(+Z<4)X#Ajv`UqPNT8qQ|6WUPF)yo;RnMpN4_| z{gArIqLQLtVZC^f-^kn7gUsyYC3ySnQrE|#}24a+U_LORv}Lf^Vh;_ z0=`>&kqk{|MhqpiTbnz>oKlX()z6Q4F89Rb8&(e^*UtQ3;rq1a6=R7G+$oK5bELe46P0HR-T) z~ihCK}V503E1_fzbgJjfieSHD$su04AOLew4m zXucLF42bUrC5xT|3~*Ci-AI(}^gUp(oKhoq{nG6>Uc(^e(bJOaFXBb!SZ0e6_L7*f z71LN8#h5g$?Tw+tm7rsd&fX>N^0kKjCro2TmIqOb~=zm?dAhhK6bdx!v!jT z0p={OdguTBQm>9FBD9x$`Xpx#+f|s$P7QZ9L2kmMAR4we)mHguarFzuAN|U+>~jP3 z;*r36-;FgzGDUdjnDS7Sd}38gp6g3g0ir8(7&IDVI++cMCaF&&rJQXuRf`97=Wa`j z*>5e%!j$wPkXpQVA6?^d8{(01aYIkmT?qAkj0V=px@-p_O#`9&yN@_K z^}9=dGGGRzk;Zcn#){$s8I9N-@w=zl=VDP7W8yD?&3VF~?g2Ue#%r2O8Q-R0M{rS8 zO|#rEa22pp`iLa@04cpdnk(rHKTK;5=6uKz4vmVC+r$0E%bA%m$I!8KSxva?d}R4C zU?SR;+^wt~C+zK}QX#m{h7iLfwMyP~qZObdKHu2;c1YIc#0K3HF0HyaAU1d^tj+_e;CK;o2Wyh#f`KZk7RZ$-1j`^RI$$@2s)hQOFCp zwRMsI(bnw^0>-8-zx7)J1ahnflf9y|l?Ie;E*o#;1cmfHJSXe^gP{wLR>q=0$v4I% zq;y(qJp~0?pe%s|vVbiz&07k|GD$V~;QrUB)vt$f1Dj?6R@Px*$`zkMF@qcAO|1af zAKE#WAHb$*%bfO0{$*s3yZ&5t0lBWwW3JZ+rYw1c%Y0LYORs^1o_|so_*O-UNRd2C zPOf~qV$FSf8u|Wod}4xCy?~0qvLoQ+=J%D9)0d7w@nw@R_TPwKb2E3$msQ6w%dVaa zXOXJC5U%$F%H`P{uGUieA91oC6@oZ!oN0QdMC5JaM2q=HpVb2Dl$n|t3>A077|2*D zCLS-WJPgMnK23eeKqqYQYbylmt_{ied0j#MLI_Hu%klQUY|wh}drRTB>F4K7QxRj! z!B-teb3bhhD3(+J!F#lk9)5UvvWv>zZ9&35cpg#Ukdtv{xEJ0fsAF4M?hIbqxfug0 z8wLg<$yLB*pt#9J;H}vKeeN*E)9KZm_FMJ~SnZH-soVh?7CIZ595GHCnBN9L=B@bd zu1Mho+E%~-jp!V9H%5@4Ld;N4&GSgRb6$s%67JW9ptwKLQ~e~?g~JNSjwwB|=rM^x z!sQA*4|RO%wCTvT5k48SEwT&`2VGk>_n2MaCE1A5RR=3lC(5uw@PSlg@w2&SEpH7E zNp^+pv<>*K9;Cwkc~kHeA`HFWaITq59%e7EioSbJJlxB3hUSkIbo3Ai6LX9YE>h_q zKcTxzz-1IQ(VXA9PpOi?ktH@pqrp}(JXO!st+&YpnAu0TIwKfj=gzJ%!;}|foN8lg zo%s);N~P%GvlAw^AUjP}^6w%ieNeou`41#!(JU?9xDd@}M8!Y;Kut#x7{N_hufK2G zfJEPYpjlN&W)GNEe-3MEQtWve1_RM!_F*JVjz}G}+mhEBhUNUha@`I1!Q~-he65vO zBoKNry0&+pwYKA*)R?3)L~z-K1&8OV)9ou+zi}YYsFFX5iM0hG?kK>7&aWn`84vUmfs^lSvD=6K}pJ3S!~CWH3bT#dBC11T<6u=JT5`QOFWi1kdO2 zUcaK6HxyB{?VpqSkA98{crwsa3>I_50Lg_OF^*%cT!T%GM2+l*21@HR>Rd=n`?#&n zA^CWWSsQ8|Flf^(;HMI3^uEdW~K61&-_oF>iPe^s&f$wM0X>1B}PY^K!Q1&hJ zlhMo`g$UEgphhfXhO3vKAABu?kLI~&ev@9rFT8t@T2S@qvCSfbK=wow?8xK9g4VpSOBHyjz}hl$3b#4e_Om5K0LEi=$)_f4d) zJ!ndu9#Ku;i2buYrF7VrZ(lw=sG<<0Ed7q-{8S9!-~Wr5PZ&ym$8or_UDa0uw@v#Q%D;p_ zco<4N%yHQi0OP}s0R^r;G~*5(4beH>g^7NzM+WZ%RaSHVT;!r6Of$4V*|2zT{8GA} zgZ>Wv`r_(|iqYvjP@!a=xJE?quiJu*YR_K8pVc@a_(tCbA-lD;^_pELF7hb%@SGJi zM<2gct6y(4_z8A$KkRvF*avY^O58Vyk#%e8VNd?Z6 zWGJzo>^8uD;0?R=E;F?=4SLEnP;;}=;)(OqXLE$SinZ3U-;_>IJKL<)3(w9ip_g~K z2}oRNY;CuR)Jb;4XRY_y7$h`#F4`VNSj#_B$0nN-s0LIfQRsL6g}gMPYzAaIz)g>V z7%2nZh$%tllgil}n9wsI9cP5$>ll#Ut8i=iw4;Qhxw+zmftf)c7Jf8{mVia8S6Szf zXu4f3X9RU*^Tsbxd9K{jN@&o4fPk3h*;-Nn&u$p|29R0XVgeZbv@e7U>7$#%f)m+? z*MB#ex{OsBZUcil26n;M!r<%pkrWT(xu3nNbZdZ!H{Xxc>%)aaW%V7!0a3ErOr3ZC z0r`&O(v#COPfj@Oyu8K(Vc|~d?DyNeaoBk;%4Om1&Wj{_e^f@s-gWim;08F$3oCsZ z2xvS%&#X*ATPL!ur;Z4`&D(54;KV>53m?G?Q^a);p;svBoHzr6C|)4WC0^_(z<=*`<3fcWW$hd>hFY7Ae6zZWl*n-jp0p|~0F zs1=iZI*-ECL`wOknlB?bkw8^!iah+|p^(*FL$64zKF7{tpVF*3O%L9)O!@W!oB2ia z!$?5X)XAI}_JArepXlctMds5M#>MQ&R1yx~NI6$r2b)FO4bf9n*-+-UDWKlXAswLE z8yxsfb60CFS^mvR(zmG#A;Z{8765W`*ZE%}WsOI}>(qHNRohUtY^a~_8J#bCu0$s{9lx;I(o zMHoOk|4}-?7GpLD#Whi-Z`kHjWnOnCbwx}4y|~%zRBzF(%q_ZQ{U6XR6AE^c&IGjZ z^Z>q7T6eDkqe!9!Zgv@77zyAH;K%$6w>vU)2%$T6G6MwAuy}@70rm?0duisZ^h5IG zcdVFzpTNb4@)dhu|BEX&i|l*D4=V|mpJwMx&RRK)R zj}hIt=H@ zT>%1$qTYYb;{lSb(E`diL=!b55kGE!VrfM67M3IY>w#*?MRttL3?I~4JB5o=!-d%Z zN$UVa!bHHA-LHyp`M#0S_wa911Yx?O%z_GXg<$zwZ1hUVd|s2g`B%~F8++`3ttw{Dii^#9;yDdbrIj$UPY+kI)k5aaRk{*pib9@$-* zd5;S4ZV-9@@8|`!n;iO(>`J5%F!RGzm_B>&;!S%L$ zy5wrv8Pvku`!V&P3rKfi3^`x(s)2=zuUWxMnK7s$GiLD8)9yK>&ghZOIL%k(jQ$iG?hniI29bo-MK5xsD9<9~TM~AZ@W$Jgw03 z?4rz!v=pCMqQbK5*fl-cc6}X_th&mgFN=O^+pf3GgNQHip!aFA7(&^O;q$pTO%%|v z!Y_2!h>!KVFO4qJOgBY7I>dn6HtTqax0ZQ6mesFkfJGBe!}I=qhh!jf(dYRnZcVRz z`v0iqO5>qy`*tMzE=$(zSq5Wktl1({mh9QG6h@Xo#vsZzge=XdtSP3+h%AFbWvp2% zlVU_%9Kw@;{FMay+~%LlLlNJvY=8)ZV3!kw$5H8Pa@QzEuaOB=xBK3Y^k3uKV!n*j@H_q-#UF?E zcnj5Dbw_WCU-nIt&)H3`ooCC#2jxBw3cru;OuE$ z&|WGB+x(URSf8GU1j|6Y7bP1M{|-eXlK$w`K6xLPqxFK(sSPBp1Sp{tHCbK3*HHg6 zw>guMNw?K+7}Tz>`E1bFC!W_*&@IO#8|TN*F5Mlm^G9^H%o&D~a_e@${=_O)f%2N$ z`Gz4-A@kvi7nw~>CS}Rdv8aat8b@c|aq1SHLzhauP-S0Z=eU7eEP|2^Ang|#=vvb;WA=5U65s(dHsYGV|EC5>-Lyhis7T3*~<ImdlD9BWv^LyX_Gq*PHHOFXxRFsO4Qe` zcE7=NJxJD^tG(i33Ps&)8Zx$BV)yk`GY_mmd@i~b9E8O9?#l=rs&(fiB=Ri;>g}Gl z#791<8fATaL5=bj+$`MwI@$8QlaI$Ldw7(oBIFL}1V*WOP{9pD9TEYxEsuQ~oe?k} ze;EqT7=4RxbiJKw7_LxPQ$vQ)3f49YT)ih0&DLKz81_v9?T|9P+{Ha}=h5x^v?2Hq zj*9#dw~FVA%7^gW!Kngj-lx*Og}}CABvUF=GE1z|B}|V}yQ?88g`K@#VlDirYaeqj z^DwXGUsln`Yj`fB1*vU}Jd$EQEYcaIjvOve&Bd_44++}#U`aH6-eO)>>! z2P`6ZkI#_>F&5}Sf8LYmb7F%*IUaCS+O5F@m3kdMlH#D=;#i5u42vu(A*p3L?sMOf zpY;>lTXVTzrrHjptDQf_l^kyLSqlOitypTI-3ZjT&ZO`t>|w_mH%WUIAW;|sQt95jKUNjtHV{$rTL}zu26_1O}JU*F(`wBUHFQ}V8bC`d;Da8SfdoJW% zwR10dx!kLm-HrRK`79B)fJmPVLdjdg)lWbE(JL0dUnHao(=o6r-k5x9qT6DFOw{Jw z+k0tv7M3sCH%h``_&S?a8AHngXC=IE-2+X&7!-FkBYywL#rFnpq2p3V5`QcfhcCx} zwo+654C0k&aQ%3d#0Rg>1RRV>`p{vLbOPUb{@Ie0cYO^tAy}Au!yfKC5at`{43D_2 zD*}%-QQr&oQf$<~XHx*}CoAk0FOEKz8xlJ?_4ce(lkk{FNY=v+b;IIVr?f`|7ih_+`U=s)gvBUgEJ=##FZX?J zf>ZU#wcu3^OZeJ4$i=C_2!M^izP-FVS}WD;aY_iRM2%l~HA)`uA$=beeV;TTk_T9O zG1sz@1Qxg1i;mcFrb2SAj&V2ro>1k~nA2c~787un{#NY5R!jgF<>U#5w*p+WYvdlR zD$7lC0E~=KP7%-l9rys}yI_TI=kW*aM_J$ReFW#JgqPbk_0rhazAZ_XeCiS%1Yf2?lmziGW9gq@l*C&U61oig3n2(}&4Mc0F zcC4;K;~YKj)}RiJ(fBK;fLfcb#e>#Jx&|u>r7HojNzeu_E@_9=#Ol@^eNponP;5dw zngEvh$acS-XobfV10$Lkq`$Z^ezHeTdd#rZk9EG4uK8Lnwi_@X+nrti-QO~>azN3g zXus_Nf!~_2KS68wX5Yg&RVJdDNy~BK?P^#c7$^ewR2l&Eud?Nn^4rkxs-s|8pv6U2 zt|!Voh3Wq}WMLxKuEmh0QX6|-+*Vnh36PW^29WIIP$lxvSp&i|k4PkK&eK zaBlxf{_k{dkqI=GfIO{YtJm#=fS5=cxc|-U)afHV&A6nC_Ud@GOLhe5@7sSF=))Xy zpU3_FikB(iQL=WviuVIQ!<5>`-2|7v)oxN|m$tSX|3qgE;8Xs|h3G~xV#QG8*1P0e(g6M!_W@=3yNs?c2mTM9N>|wx z1mS*f;nCl0CXN1^qd;f}a#iReK}}6?OPt+P@as^PTWWNpTTWEfX+0 zwNF5MBWPcI`}zehBWUnjICD*htarEg6RLkQ{7J(0*98o#tLx)mKwLLrYc`!i2B4as z+p1miuLRFtOJW1GHnGT^5+%}haS?_|~|cObh*Y8l7kbO+JZ4)n94 zr*b2}TqC}3_h3&TK30)kC}DQu+}}apE;wr4l~ZMNgx<$}^tl9|*(`kaPbl92t2wJx z_rs0Y(FTVl>F69DZ1HnuxmtHp&S5oeAEd>H6Kbq1@ww>&8fv0_k0k|6eZR>u*&a zUHtVEbQhkKx(~a_v9P_p{YF_}VYo0=cg_Z4GV_We8{(IgkKh4~#m5mRj?p!f`>~2y z>9gd6xvRb*O!WyM9RFInHnSvhRiOn>3&fGcy1RX=3wx#^u;oAoLUy>GqFtX{YXJ zp#YCMg#56ovDs9;mH}6%b6n@AfIMTKA|GGenJ2vo6NNChLCuVf*R|zyOZ!*JlSx`3 z-02BS#UX=x$bwtq2l`e^EJal--N3yGMZ}!FUcX^BNq0KQ~;}dpYEA%vGWfI-Adi;GY=7;%$H5}p2$An-IKoTH?D;g{a6e>hAG$^ zT5NUN({tvH^7UOZak)Jf@$k}K1Mx0hryHxW8pU;$5)_94(~Q<;RsV`t+F}d165ZiK zDAX6S-=Cs@Uu@h+!$y35U9P@~7|$D)cFU3?8<`BSF*x&1belAv7*Jln=@2YrFC4xa zoE2Hj)!i+%)V?-iu#ee;D9yXK)8fDvl9&So=Wf`2xgz z3u{4(f7&+zIlg=LHCH01B_$*hR>&;SQXUquzDk>PASIIiho%x27kBs7D>}>_L{23}Ewdil9v!M(_Vod%6oot6VcwF$n{Dp7O&wH{nh8#W(BYprx(d$3v)W1a< zOk$axtza=p5}33XbHiAnW3YA(q9s% zG<&Hh2G{0%*9_~t&}#)M-1z37lLgycMTs!?TYP18Y#vDD^&2;=mb)tA3<)-Ak>>+7 zE4^$h9|)SZTFY|_xMuaQ%);7WtZW>%St>z5r+{aUwsa{wMaFU1EUF>m^9 zWyZ10)- zY=o~q635j}4YpWfQd9&winY1Vm?4K~%~nKM=_09wH0iw*I#vOqhso0tl>!n!0K1nkU`$S!%K7$ zgRr2m+{TV)M2XhiN5>$|!edQHqBA1A{@cALU`l-Iw&$$dXu$OvjS_)4+gNSo|IRut z13vKSAaMwQM9ofWlqV!Z diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/hash_prime_size_policy.html b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/hash_prime_size_policy.html deleted file mode 100644 index 8976767b4..000000000 --- a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/hash_prime_size_policy.html +++ /dev/null @@ -1,149 +0,0 @@ - - - - - - - hash_prime_size_policy Interface - - - - -
    -

    hash_prime_size_policy Interface

    - -

    A size policy whose sequence of sizes form a - nearly-exponential sequence of primes.

    - -

    Defined in: hash_policy.hpp

    - -

    Public Types and - Constants

    - -

    General Definitions

    - - - - - - - - - - - - - - - - - -
    TypeDefinitionDescription
    - 
    -size_type
-
    -     		- 
    -size_t
-
    -     		-

    Size type.

    -
    - -

    Public Methods

    - -

    Constructors, Destructor, and - Related

    - - - - - - - - - - - - - - - - - - - -
    MethodDescription
    - 
    -  hash_prime_size_policy
-  (size_type start_size = 8)
-
    -     		-

    Default constructor, or constructor taking a - start_size The policy - will use the sequence of sizes approximately start_size, start_size * 2, start_size * 2^2, ...

    -
    - 
    -inline void
-  swap
-  (hash_prime_size_policy &other)
-
    -     		-

    Swaps content.

    -
    - -

    Protected Methods

    - -

    Size methods

    - - - - - - - - - - - - - - - - - - - -
    MethodDescription
    - 
    -size_type
-  get_nearest_larger_size
-  (size_type size) const
-
    -     		-

    Given a size size, - returns a size that is larger.

    -
    - 
    -size_type
-  get_nearest_smaller_size
-  (size_type size) const
-
    -     		-

    Given a size size, - returns a size that is smaller.

    -
    -
    - - diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/hash_random_int_erase_mem_usage_test.html b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/hash_random_int_erase_mem_usage_test.html deleted file mode 100644 index 2867595b0..000000000 --- a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/hash_random_int_erase_mem_usage_test.html +++ /dev/null @@ -1,173 +0,0 @@ - - - - - -Tree Text Locality of Reference Timing Test - - - -
    -

    Hash-Based Erase Memory-Use Test

    -

    Description

    -

    This test inserts a number of uniform i.i.d. integer keys - into a container, then erases all keys except one. It measures - the final size of the container.

    -

    (The test was executed with hash_random_int_erase_mem_usage.cc - 2000 2000 2100)

    -

    Purpose

    -

    The test checks how containers adjust internally as their - logical size decreases (see Motivation::Associative - Containers::Slightly Different Methods::Methods Related to - Erase).

    -

    Results

    -

    Figures NHG, NHM and - NHL show the results for the native and - collision-chaining types in g++, msvc++ and - local, - respectively.

    -
    -
    -
    -
    -
    no image
    NHG: Native, collision-chaing, and probing, hash random int erase test - g++

    In the above figure, the names in the legends have the following meaning:

    -
      -
    1. -n_hash_set_ncah- -std::tr1::unordered_set with cache_hash_code = false
      2. -
    2. -gp_hash_mask_linp_exp_nea_lc_1div8_1div2_nsth_set- -gp_hash_table - with Comb_Hash_Fn = direct_mask_range_hashing -, Resize_Policy = hash_standard_resize_policy - with Size_Policy = hash_exponential_size_policy -, and Trigger_Policy = hash_load_check_resize_trigger - with αmin = 1/8 and αmax = 1/2, and Probe_Fn = linear_probe_fn -
      3. -
    3. -cc_hash_mod_prime_nea_lc_1div8_1div1_nsth_set- -cc_hash_table -with Comb_Hash_Fn = direct_mod_range_hashing -, and Resize_Policy = hash_standard_resize_policy - with Size_Policy = hash_prime_size_policy -, and Trigger_Policy = hash_load_check_resize_trigger - with αmin = 1/8 and αmax = 1/1
      4. -
    4. -cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_set- -cc_hash_table -with Comb_Hash_Fn = direct_mask_range_hashing -, and Resize_Policy = hash_standard_resize_policy - with Size_Policy = hash_exponential_size_policy -, and Trigger_Policy = hash_load_check_resize_trigger - with αmin = 1/8 and αmax = 1/2
      5. -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    no image
    NHM: Native, collision-chaing, and probing, hash random int erase test - msvc++

    In the above figure, the names in the legends have the following meaning:

    -
      -
    1. -n_hash_set_ncah- -stdext::hash_set
      2. -
    2. -gp_hash_mask_linp_exp_nea_lc_1div8_1div2_nsth_set- -gp_hash_table - with Comb_Hash_Fn = direct_mask_range_hashing -, Resize_Policy = hash_standard_resize_policy - with Size_Policy = hash_exponential_size_policy -, and Trigger_Policy = hash_load_check_resize_trigger - with αmin = 1/8 and αmax = 1/2, and Probe_Fn = linear_probe_fn -
      3. -
    3. -cc_hash_mod_prime_nea_lc_1div8_1div1_nsth_set- -cc_hash_table -with Comb_Hash_Fn = direct_mod_range_hashing -, and Resize_Policy = hash_standard_resize_policy - with Size_Policy = hash_prime_size_policy -, and Trigger_Policy = hash_load_check_resize_trigger - with αmin = 1/8 and αmax = 1/1
      4. -
    4. -cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_set- -cc_hash_table -with Comb_Hash_Fn = direct_mask_range_hashing -, and Resize_Policy = hash_standard_resize_policy - with Size_Policy = hash_exponential_size_policy -, and Trigger_Policy = hash_load_check_resize_trigger - with αmin = 1/8 and αmax = 1/2
      5. -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    no image
    NHM: Native, collision-chaing, and probing, hash random int erase test - msvc++

    In the above figure, the names in the legends have the following meaning:

    -
      -
    1. -n_hash_set_ncah- -stdext::hash_set
      2. -
    2. -gp_hash_mask_linp_exp_nea_lc_1div8_1div2_nsth_set- -gp_hash_table - with Comb_Hash_Fn = direct_mask_range_hashing -, Resize_Policy = hash_standard_resize_policy - with Size_Policy = hash_exponential_size_policy -, and Trigger_Policy = hash_load_check_resize_trigger - with αmin = 1/8 and αmax = 1/2, and Probe_Fn = linear_probe_fn -
      3. -
    3. -cc_hash_mod_prime_nea_lc_1div8_1div1_nsth_set- -cc_hash_table -with Comb_Hash_Fn = direct_mod_range_hashing -, and Resize_Policy = hash_standard_resize_policy - with Size_Policy = hash_prime_size_policy -, and Trigger_Policy = hash_load_check_resize_trigger - with αmin = 1/8 and αmax = 1/1
      4. -
    4. -cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_set- -cc_hash_table -with Comb_Hash_Fn = direct_mask_range_hashing -, and Resize_Policy = hash_standard_resize_policy - with Size_Policy = hash_exponential_size_policy -, and Trigger_Policy = hash_load_check_resize_trigger - with αmin = 1/8 and αmax = 1/2
      5. -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    no image
    NHL: Native, collision-chaing, and probing, hash random int erase test - local
    -
    -
    -
    -
    -

    Observations

    -

    STL hash-based containers act very differently than trees in - this respect. When erasing numerous keys from an STL - associative-container, the resulting memory user varies greatly - depending on whether the container is tree-based or hash-based. - As noted in Motivation::Choice of - Methods , this is a fundamental consequence of the STL's - associative containers' interface, it is not due to a specific - implementation.

    -

    (See Priority Queue - Text pop Memory Use Test for a similar phenomenon - regarding priority queues.)

    -
    - - diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/hash_random_int_erase_mem_usage_test_gcc.png b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/hash_random_int_erase_mem_usage_test_gcc.png deleted file mode 100644 index c552506a7557aa598a9de877bbe45bd20bda39f2..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 6356 zcmcgwc{tSX*B+$45k+cHQkG;L46=t1P1fwo$TnG%CCgY7MMx-PvTxZb`(S9Xnxp+Nsb1$JiB)k+``Dv0(2Jr!U=AaDo-1%Y585CQ~3B3p1c1df8hu@E=`0wzy{C&3nYVR61fifLBZizIGg~7lgMR(g+jqmSU8FRN0G=ZfD?;?W3g~70gfe+ zNr6}b3QoYn2?RKS1UQ0JI0*$OVc{eKoCK-@)&LBU1}p(B-~)vLHh>0LAelrKM7F_$ zMWF~N6p5@4lm!+Ri^396SQ1$-U;&&2EQ&xt5lBEiAO&JkBrJ+VK#_nv&<{WpWP^49 z{eT2e2v`F!KpLK0ce73&9EOlv|Xy z{?ChE7cG_lMm)0pF$E0-525LzP3wAr?Ce1a+&Y!ixQoW7peWBZ_am${yAX_Bw1R{E z_F6C}EOTNt&K7lWxqij?_YtjWq#OC}vsv^;0kylZ&k_q*N(z%-5o6z~YsbgF^~P_O z-}&K0+FZdDL4CfAY53es$NW>Wq#_6(=Ixt zbyc{G7X0T1C+|^t)KX5^BgR^;+jLuQ{ol-kSzKE*cs#;z>!SF-q;UOQFZ?{6Rk&wC zr(d=Fg4n4R-pUnh)>%>zaaTrcb6oU2y?(%IH?^aCBE!xVO6uNKBVUu`&*s0H@K#Sd zlZHBkrZJja75?s&3;G*_j+XjD#{Ltks@oE#!@nYg`d1gqE53Nrwo0>ewdAQw-o9#j zL>2I{$g!+9qWxQkIquPq$cO_yD7BuwezSpUw`qq9gX?(23VN`fmi^i_6WNXKg6ZJF z!sOyU4wttfS5}6G1^yoRStIo>2L=~y9aP;}@2|f4?4n@7`3y+&Czp;*%Ej_0xb2i5Tfa+9l=}lln<|sF>XYlGJ|J&esNA!BR+(=wBAK-8JZmuH zW{spAy$atEo{DgPyGs=%tto|Gr+*Y@ekuGk{ggW?(%85$Q7 ztrl$EL=-2#mY44H=tp`dCcmqzM-uMg9&W|{k+fZEx)W3~v7{s5WjUq&!-t|zHTiQ~ z%smBILs{UeBZFEX*WBut4mDprQr2q*m$JCn29bbYX6Dh;IlFEPk~8z%9zpP}r{|K* zqa~<%WK+$6<32yUvPaEDutBA8=@*PsL=bf_V;Pl=X~W;!vcc&Qzeio(l%PG7A5Xw+ z3KTcjZopS1XBGiaRfy$66Z_hIXyG1n3zA7YTmRU|fOVm0rm8g{O`x^Z%cjhZ@v$QJ z+W@UjEWBG}i=!Yg0~1zd{AXvcxz5byhAg(xqWZS^`_!{<9#$g1ok<7`3m{GY%-K=@ zD{|hrm?rlofzMhd%Ejz5vM)gVzW3*P$82aD^p0*s`qcMir^M5HQJ2>xOcQ$}Ml8~q z`l(yr+DLxrp*75;oX=ML(9_|HNry2nOfC2pFlY-Pc=)+jtO8CAt;2gCHE) z#ys?x5wv2tgj?3sU5$Ck6J{9c$d2I<5{i$G*x{Mmum1GtyRx~NkdHZxbjq}E+l7?n z5;n)_wtB?q9*CW0OskQ}>B;L;^l2HC?sm2Lyiv35$~!e_wO?J0UiULI`ed0QB!sCe zh7#kXeCw3v4cwBADGdXc3JXSg7J7v&V8{34<&{=w_NqgM-VUbvUNU$c5iv34CQT`7 z+Ens%q-iGBVC!3wx1u3>J<0g~;!M``M~+~5p>TA1O?B&*VR)3m*@UQ?YP0Szf%Tya@)_}sRVCC-e+RVi}L&z$6AmChVn zlLNItlfq51_UXxtWY5mxd-?iL$gI+k`Q7)W&=hD2CX;^JHmRwXE%&UXR`;u!JYCf_ zQejrQOK9F7P=BM8t{9{ceYy$1{#T~j$OJiYf3*541V24ZD2BV2#a3J#=BA$K=Hc;_ z315k&+=`7$8+~F`n*|Qk#z8}4X2bPL1V_<)QzR*Nl*E1Qi2AcRBbb?Q7iQdr{}_QJ zLDwL#eOjwpu8kUGuh#7HI!$`XmL3TcG7m$GFV%iF*R{I~^S!hzH;2A)(2%7PIJo!J z3Bxqh6`@W+PM)O~xiHKfv%RJJ<=^<=a-=@AnEYiycAO@5pDMzv38rC$$%{!pf&qX} z3ye+*ld;WVE))$3!r;dJ`vIwtT9*YCz5tAW-NOIVqWuuog(CfjyIx5j|Mxv?xZ&9# zX{90GNh)AHdn}&8G5nbNZ4eSdJx{IuzhAGatEp z`%in-c)sD8{GFBJjTP%fHY;fjE9CVvk@!658eO%t)Hs^)=$lDxkEQB|-nuW=+d_v; z>k&Jr&9HuB<8PhoUHW@Emg`h}eRVjJN+O&YHX|pW)%+$0aN@j=ZuGEe+u6Z=OIlB< z`+ z6URC^b>)X=@msCFjx${dt*}JCk};#_NOW*t3VrB(VH>2i?)I3r)!CN>M>W>!w)1$8 z@58zb3ATSWxh@kiJ-vGylzKyUa^|mRc$i#!9%Fy{36{-J=ZgKp6*fzi$FE{I{2y@Y zuf8?t4PHk;#d@E1AvViu<{2<+~gE zzq&bLYs?9ItKjIcP89t?P26CcTap!j^rNr)cXPQ@{V{wWbJMQG-8k93_4Z>N*3!R< z;)5Py{;JzGHG^BQr>X_cGw%wLj1KF*@J4wG75LKUSSUU&Y^c-tPG@_`IYqK8m7Ny@ zmCPLNv?b2<5CY_j%#ha~^f;VdY#NeaQOvkJF)m)BdV!a{5rbA6j29X7sT9JJ(eamJ9{IyjLFC@9E4()aejJb&2;i8;p+x~uCoug`yF`-s!!tY*>g z*B%B&yp5QeyH#u*&;7sN+7T$k^j8h2bmI&piu;#D=ZMCnQER@zK*6I1pU+mN&5rp8 zcZ!F%K6@rAX~VWAbo zrLp5#hUz;}bI~cnrA7u-f!NEP455Z$1tV4my3{c{5e zkI~8n&a%Db7TJko579~WGR39Y^rg0(qa%u|Yv-@8b5{(^Jq^6mCT1O=YQSpZYMF>icNOu(UfmPcV2bPj74#Y%B^MmOD?Pjki*}uF;_+>UaHkkzI4r81Vpl zsh*>V0K)O1HVk>;MoIl{hRNjIUoUmb=AEOBta`3ST2}G;UhVhlJd+JF*b@GU4fTt} znX>iZ=5G1tOLLYg>>0$;JnNo!`y0Q!6;t&Qje%Ya_qEmaoS-S{lPvz!J~#Bw?bi zhSDLXddgf@i!p6Dc<#)xu1*(@SpjBv&dcyf1hW(UdbW>hd}BuQE6bWt%e}q28VK6; zEFp&>)$*|dPsv=!@1@rZ**Uvo9IRf&yJJ6oZy5WzY{3{k_<0^3GC~}rs5d#!=gv?T zHb^Q6ViaJPwGpT0n;;J1;F7=N-@xFY{v|~V6Mm72P#~Tb&-KTGC&+~HInp3EG-zdQ z1s?=X+zO=P!lxmJ{V{LoZ6G8bd z7FfUDi@dX*{b$(il_P%OyyDu?X&G9ToAW&NOj~Yed=DqLuXw(tCYs?_C2FEzeP++4 zZyd{pU*vL#x3p+f_}H_ntKDvHMK^aUeA3|@=OlcK#e&8G7v19_`!^_4q$WA)i!jH9 z2d~z%)8cssqIRxC8O;q`Yj}#nqoa&{rNd#=6|&!r$B&+|jxhg_-pstK?nesbXu;&q z#`{hB;h%+4Nm(@fv08lwA#Cha1}nQh6C9F==-2bQWIH zme$i&^jbz9+|xz~s&>)#>PF|Ic_%{-uXy?Q?(K(~c#b!ux#S_n(a%jBddfh`zDEIc zM8_}GE_3*NQuSKZPToZe8Y`c0Z@<&<_3h=!tC4KnyzCY0Hs?;t*2d2!1hgHxl-&;oSuU zC)hd7m)P+U8650U?3efAsO+|p&oK_e2!6RS)Y`-JALV1Avc@*E5eHAR*E1DKJkeNyEXrO6ra zDw+mWAit6RhvkMFy?*(v0}NiuFC_Km&m;RRpOjho{*V9ORKBjEBp#rD1f{T_v~PEH zHdToz4IE7Te(zLw)*j+WMd5?@hh3kBjtcurg6+rIw^Lg%u@=nCVF^e9jXaCR4i&$= z!gUs~<8i(IoxhzD64!oC zW~DQ_a|$t<$UbumzFe0B1?YR+4Q7oPH+qd$enYG!Ph9eq%03RkvH)X?Z|m7liq=rP z@MW9Qhr^zEb&qo1Bo9?0W~gPJE%#QM^T7u4taB=zg|D5wjz%KRw!Cad>+DFS4!7wg ziKo8Mflr;sF&QWb>k~8h{#J7cAgqNw!)yh>u;(1nDxgz9}Q^c}NT~8()_2!UQ+jWd`52a|pt^Hf0u}_fYWR z0_EaMFCTc87J28okEr4)Uv7RVP$|ax+>{wKknN2uib9*StcIKMOAQ)?h!%M>OAO^= zT%<~H_oq$T+A2BT**D!?%8o(r#gp?Y-zOz`xqgfm^*Zn zaRO$Z-Irx11*(p;o|!}IbdM_xqHjW%PnWw}Ro!7V{dDE`8%K#MMPad% z_D^S4ysu>B_v}IlnV8!1msy>`PiKHFQGVer#7**6IoPrxZz=t^C>xL{u?r9CfBt`c z-9Py-m|^H>9LTchl9Ol8L*0lEcY&eCPi@A$JX8~>{akg8q|F(Sn@=ri;)1SX5`T_N z5&j&?ZZY`#=Rdphg;)zgW8O3j&p)99Q=|4nuf+XWO973PuT{l1OS;q9_7B@6XpZf} zE!YNlyE@!=8*T1(Dseq9Pk2d%_6e?=R>KR_s-Aw*`@F#5`2usVrtjTVevu8d*mMvS z?emQTrPv`cd1*7#_(`)jG~~~)ouLPh)0Mh^W;KKpw5Y(B6YIaeqev9kfXr?7=+#j2 P@4@OSn##pWkAnXTmi`&% diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/hash_random_int_erase_mem_usage_test_local.png b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/hash_random_int_erase_mem_usage_test_local.png deleted file mode 100644 index dbd3ee9d3c0aa66fd5bfa7454a1737742f331420..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 7405 zcmch6cT`jVmu)~nAc9Iq1W}qos1a!*y-5)%A#_8DNazrxBTc0H6#+vR>4^}kw17rB zp*JalC{3z>fPj#9dCAkQfk>1VWN2wHPP}g9KqPAPfnFAyc-JpdbB507(oIiorlJ zBq)YVAqCWukWdl^N+Ll?WPl^E6-q`z$rvb^1SJDq0oDK*KpJ2P&;oKmV*nd~2C#t5 zWQrh43|tr_l7vK(Df)o6K!m{{F(f30Opyz)0FopOl0-t1$bfo)6i|yKV~}JLk_^ZL z`~YYIy8$}@{QwC-A;1~{14sibfl`16&=|l5paCp0#W_kEh=GfQ!H_9N0{VcqKtv*8 zNMyiQKrX-nNMgt&3>okda2hZG;02TeMgwXAD*-2IsQcjEu|KTd(cJU~-=PaO*% z5D3gn`K22E68Z;Nyy~k7_cifA`aVH;JApJ!jQF&jJ$!t99K0WU`tr$1$%sozr~75I zgFsx)x*Dpc{#hH@lVb%UtkD)j67pYTzzzj5mG0ke7iqX8_Pg*zc6|*)};HwUBm8*{t5Bi4k zG=uLpx7wM9e5eWhQ~xK-zEuKtTb^pSnnvKW^6FBCn$`844;9{)Tvpj{bNGf>$2(DC zB4E9mkR*`={QjBzmzMsEH9T~^df{Q!xaqjoh%lIhhVA8^KcN-$h<~w>MS} zV)?`>8P-eVyo2oH0d-$(vNqqXZ@hdI5DNEA^;dt?j(^(~q-^%7?1>K_9}7B6MdE-?N#`^KfRvc`oQp2o!x|!5G7Bun#5h?z2IPa%$GU==|B45qO|Ar z%ve~0lDsySq2i_zeP_){@y@1!XP@$y;h9xC6Hhd<3C!Lo1dfpdoIN1y%T-r7D%co7^b z+U(^$46OWed&u%dH2k(hwy9a|P8>=hX~zX1XUS>%Q)<^TtJHr@AB!vM$@5vg@T@~+ zneZgz63g%&`LP*_Lp}wA;CSvd^t89v`1!I~<%q^Vg0Yi1jZ7ISV zF?LOl8VJ@1Zhy~<3NbeKrtCmj3`^^(yK%b5!sgI2%6%`mK-$pWT8J3Z_nrP^_XoqM~ z^UN$+CY_y(ux=bm4T?6G7gxK>4JI~fD_8AY{UIrZuT}WOSPk8}pYz&tMKT(kCH8e@ z-|W||mb;FN$;}lmeQyy}SD-%?`p)k2^!d|cKY6+zQ|C7a4x9bd(Y`Bj%dXqc3wiWb z;bHTHR;=86B@%mq5mun_pVT?lxaFvLC5Zs_J;HE--*R6&HcyC zCE~9X`q`V31@F9MxMab0DQlYf+aD%Hk=p~K9~NI+Ox<>GUoibJ2J07FuB*st!~3%Z z-!Dw7GOI&3dcArd;98Y>X1Pv4BalfcHAAuK<8hct{F6WBvOZCT_iYK0KGVhcr+w=; zhiE?9yg680VCeNN(BHb!?=~lxU;0kgV$xhLbU?`c%w9glVhXGftmPa9}^^^TAVxy-69)PLTmmb+FWo2}@>IDyIi$ zy@pA!8tmiwVPoMtzL=ctOBRO%3qiquq~V+!lGik>tx!_t<{PS0D#$U84@E$7cr1{6>kknJ#ELJbKHd zhw=9NSVcG5%*58H(qb*;5&ppdVHIEOet(dYNf{M_FffbYSj$9B8zZSMfZ!;>o(M);48ZU#E6N7?8<@7%RkH%l%oYQ)cg(7RLt3RJ)k4&H4Z5`CwX%p zQB|NSZ%^|dQM1T4TIvp(QqNAMSdn{#$O%U($Hi|PQL@kRlGPR;ih{LHrDP!+*XmiiHEAt4 zdc&E!!tO%;TWswlXx*nGQ8Q^7B#HfyC0u{Tq;-E3+NxY;wi0MBq8qBv(bvm6x1K<%s5) zVG|0+Z9etFoqaK;B)JpH;E3jUVsnjGO;H7Q@NxZ_Iv-ZJ{u85MqdB6^fZ9TdUqQuE zZkje6mlGksb%_tVT;JOocN04X?yz>r9FbaSp2iyt$Unp7%)g5|t-&YAN_4GCmE*5t zTkqs{#`}S9#*;lO!lNb@&IzR;W(-we$-3xSrQFVMQnf#S{*ysHlsnI-_jX~HpNYNz~Svx=6KH2X^2d(WBej29+bwkaF5joq+Dy{fpO?SMPF zsa@Q6#fw`ALhom`*0|o^3h;OwzuxS~kgb?vJ#%KMvE<2#KQP`Bx@8C5)*8i@f$y5K zE=79iUX=F`FDvtiQNcgi!w{nv5+`}p3OeKeQ~`#_Po)-`C^18;a0b z(+Xx+eaEhtN4GCJ%Ta0$Du#{F*But_V+ z*KRqEu@Qi$!D_-?zz?+c1;7u5f)Kz$8)H2WYOSh@s2W&nYj;eGGaM>(n;Gc>KZd^*RfB;2;dyn221bh$DDo$rv&lC>J&L$I*$HRRpx{r98)M2r*lj61R%3@pxCrfBB zx9oP{rp)A%%b3FDlUc3Tuj$&QH?wq^0ST(dnq9sxJ{d{SiO$O$=HLrfEb=AClKCI# zZwbS$^;Yfo=5=4}d}DhNMnvt{Ai9mZt6n|MrgcbX(RGR z<;n&BcE=)H=Gs=CnnFPP+*tyb2%GHN-A!k$kmvh5b5e)4C4Ma2Bd4a;8z-O1&bIvo zq2rr(WdHXvuD|~f^cZOMg=#omy*Bgn>;2;IE?b?(SB~BWr2outB?PrE1ihIuaMeGC zG6ry4zb>;-gKtH<$W}^i#Nf+>Zx@|hgzdF;)U=l1ku4uRN;UYNx2A}cnB-8aC z@GrvTvujvwcfZHhzC-=|UfV=Vb5iRbhVXiuicEOS zC&qw>Pb=N+d6-@-g@a9GD-qGrMFsBmpKeF5{7FKD`4EX4fg5eKJnkTe!6tlCh}r%} z{Qi4koRfXiaqE?7W(2zs%N?(@9!x-*o&wyEpX#`ppF?w>p&gSwyJ>kP#?mpsr$5g6 zEXL$xxo;>1Fhl5p(I0a(ayko*@RyIz-ImUtRRo)twtB8v;7QZy&k_d8vDP$*!F=mP z9_X^^1WcrR=0)9F%_%*`h{sGd5R zkewN}-`AP5MhtXUIdUgoeF(*T2w2$pbA%-(b8jUU5e?UId`@(s+_wfy8g~^7k8T8H z+kKXJYzS}W=pkG657MkB0?+JRe?6^-LTJw|;kH<&Vqp#}aw@EC@7IuV- z7acr4=4NMK;i6kpTu3Z^l+;`tp$gBv=Ap0Tv!KLvo_KUVz+n}`zt#QlBJ6fR^1+Up znQlU>K<6k_dp6}GA1=5Eht1+BQ?vh%vT+)w_b1Jl%7XuO$@u##bG6j_kpF|r^luwV zA6^_k*Ue=zz=&o&|35w>{`*Jpe|doXP39wR_inaWw9VZ?xxjuryZ?JdZm(Td{31I| z3S@lG*C(bj9Dl>8Z%!K}$`qwZRb3_`E?xcF*Wh@Z_Y7S;^(5LHrLg#fSpBVoee?eJ zGd&S_ofk>J3tp|Cru~!&ZmAgOQ-Pa8s!iEV+?jr3JqLDTFFn7IWlytTtWB%fe zm%-|A^EPS(L2Fu&9)Z>yd#QgU^%UP&h}4x{ZhbsOUF?{!U7Pc*DZp4%rQLi}HBzBO zDeH%`)eD2yez$ZzW9|{F*2+!@^)=O2kLdn+zJ(Mbw0jpqhR?l~cOE>K7z3?fm!8y_ zs5YFc6!<7+$vj?lC@nenu8D(>&HfA1^>v`6S_K}2`$9#kk$W7Y8(~!=06F}~hzxn} zEgNwCcNOh9gT`akjd{q$@zd4diV>!iv+q|l;i6l|&$V2#{m7Rq>Bd!4H7(&nZgguh zQ$Lz>!M)qd0hWZ%=lH3D5%2t_E{>yWpffL+$4}j}BPz}>%PPl_?t3cOe33ZGZOFP-Y1j7-SmR(auRg98zzWFB>Tj3SYb%eU6|oY)47Va zvYl5yH`ZeV zMokO*i?IBTOphMO3v?p%-|9YO9MQ!Yc$8v&hWg%EF0fQ;R)Ah|j|@O~Nk{Hu=N^TP zy^t9p+Ibe3qn}5zOc(#tt>a@2FVz{jthK`-URr2ykfvH%&Cn|HaZdS9Zg8;hoQF4c zDkL_xbx&x}+PdP?fS+#L4!SVfNn(-SO-l4>+FX;S;ZYn0m(KHpuH(G&$QY_^^wM^& zjGext@GI{@)*Nl-v$QwVv#Vm+QGr~q?%moKR0>O|T4-wZR$FeN(`!K&Klox%;Sf4H z1aB#aAjC3H`fJ;9pl^%K1B{B$NewtZ8*R1ud77n_lY&~eZ)H6shg8k$FChz)iIuL1 z$t>2jAJRA2Bmvl_4F7KDMBO0LNu>kcWNZ1|gl=cXpO$Br#!JQG4_!Ps`VH#%Z$Ps= z&k?vf{}9Yr_WDK2z_z;2PJWK)>@>lxnxh3TON@_F-~zQ4IBmR~PS~~zm2?qKo;DODdWzD_rn?vx*qIA_# zjkk|XX^VGr#BiiN1>2!3Z99!J4a8v&r(#LBszdkvNDJalOnQFmg{}G5H_7u(N{Otu zB2~|0H5}R-1%dq@4t8lDdE9mOD@U=RPa187Sz&k5=BDYQ*{1Aapjd8^fS3SeRjcC- z{3wod=U&&Vgvzya@U(v7V)B(Nttrmku^{8yZz{QZ^Gx$ACE~wccmbR_5t!p=>`NzR z_7otZ<5x6x{tfI$d2d6vP=wT{fm>+v6-Y^T6kAm?Tg4I+f4defX;Q(7MQnWGuhUL! z3-w*LdKw*-zfiM*Jgv@54hFUbc^wLzotC#lI9iMJ$Mv2iaM{Wc>~H9+cCf!k?8Fm3 zi5m(8EBIV~TzMSx=1rq3(ofPT&6c*1nX$DjZaR2EcqA=N-#yZg!I7-Vb9)N?6z@K4 z7_Q&gn^(^KF)+LLA8EG+mmO8P2p0cq!|%>dT}lhE9v>dKDl=|i#P=V^wg3LKTv3M? z%i73pc13VC-De5D*3b`|7hnrL+1rgFOBx9-C^kb4_*tx{u_>!N7>SxYHUlGtt!9Ssr$Jl_DA1M zODQ>Y79+)Sjtz=r@f~c`ldg9xRS&JHTZC-~Xq7zpJ}22mfnbDD7_K$EdMgUik*V+Sh?}8Fh#oh&_U~ zp}0&YF(fo!I@~wau-{POGk>ReR3_Hv*W_ICQB)+sw*>ZMVWS{Y$=ep5{T3R=e0Wzo z=*J*#xO+zTT+l)@UO`*K=c)Y^0 q$OZ$J-pJt#4b8d#@-;{lnaXN+!OADn$%OJnk*=npM!DLi*- diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/hash_random_int_erase_mem_usage_test_msvc.png b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/hash_random_int_erase_mem_usage_test_msvc.png deleted file mode 100644 index 8c23d46da395543715ebbbac37665e0ff0fe7192..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 6401 zcmcgwc{r4B+a82Mt27iTvK9{}36W&U@mu7+D8n zN!G}|56LoRpZ6K>`~C6$@g3j${_{P@F>@c+eP7pko#%PYF~{>f5k>~uM>)=NKp>E# zI(IaTArNK&0%1ZQW&w9*Gwu{XAS@6geN#;^gg{^r2nqthK_C8QjgV}UOAI61(!Ei7b1qP!t+JX@Z1w-LrC<+WkXRrVdaVQuL z2g6ZdI68wAm`g#yC^#5}0;AADj$kQ_j)Ku~FggWB2fKo-K`@Xs$P%Olo`H=)Y!Dj6 z0*mPkL5vu@a3~Z7g`zX`fo;JEheP2gC>)(37i0k*QgA2=1x2BQ>OoRqE{cvr(J3f8 zC=c`lqzP7oc7Xap5}-nmH3$Zh23dlsAP=xHhz&x6SagPSjAJkcFA5GvXBY|U1KWZT zg@U8dL0>_+APeviN2lQEppT%_paCE+FdZ}+R0~=O`T^1et3f+JPM}~=A;=m814)CG zAT5vw*cikHq3MhfF|xs9Fa|F=I5E&jP#@S9j3{(EV}J+aXRtV!C}W-nLt>CR@SQQ< z11lLE58Po)`#>;*@_`1%@DFG)6dZH{p~0U6I3>_LP}4!HgJ0tR`xg?85dfPWd3@)d z7X-q2it%CU`4O}WZVGy9T6&wfqrCm>JdqGh6Qc{-58b`Iy&OE99(!N7E-NoBBZu`( zJp+O8V01KYnfkw7PNkM*NuGGV1#=oXL}|fL!Z1pyPc#CAjW`Zhkjg$}TNkB27Sz0= z_nYN{;BQ}+IwLjUDf0%i_DfcA1iKvXiS{J~qCg)e=iUo+2k zsMyoxrAEHuuMMG_ea22b3ardE1nhdYhw55?t_Zbwb!t0_zC0se@j73A)XETOyR;Fn zDTZF{KSUF%U1Evtv$>yW<`T31b+JF|+6gMXS)m8aXt6|3w2Z%ry1RI)C(5Rz=$F4m z(0SxFb$o+c?<>65izi!fzFoRzp5Gp9H~sGuS{I(xpSM1MYaXs{wveBO;b3{p!8d zQ<69{XEb*W+cLh=-b2GBzW+$2aRv4u4~Lkz+Lqkm-e)7NuXN`H7nrh{Zk4s4$Ww9E z8gV~-)hNtC0O`|Io|*EbdHk*7X!~ult>WF@n2sZFESf9|!py3(c7&p%`5*nJY6Dep z?W}L3EIU#cT!LRQXP-Ga@>rUtunBvVnu14|@*tKa54j+1MzSNX8YP(VSo5?#lp<+2 z1_HkGNV>GWzyHHE^5ud^PV;Zd%YCBmul`n+I{)a*W+1Wf%BRTSP$I46bMRz=hjJjd zO0L5DLk2^FqiiWsP(0L$TmTQdFSRt^PGwsxcB_sNPT|W((!zi5`-MLmdxsedbSbX6 zvd_)VLA{?_Gub>l{SY>gFkfGM=$IG9rXd>W)S5hgmGAn@eADn#DPQg^gisk((H?bJ zc2Es&ZqD!7=knBqq$Cvn<8xM9`{X2Z1be&gAHYUmBL!YsLqt%tE4?=2PhLk-o5r5f z>*q2}m+PBzlBsN;o>$pt3&lP~?El{P$)y{W}t{Z@@Sk(h5xq2T;`9uVghtdcq^x^Epk~-&Z>RoBo(t^5m#{q)v_>wl?0-m z#Ll<+O8jX^O^m$8xm$~{Or%QMPr2Tzb99`A6Df=7HAu zn|$mqwpqdV!I;&8?AWOBbtT6rc_X+?F37FcW5|DIuj`?mW6*#k5a}ND;mqxp2iJ#! z_@@1=guX8g;1Sc?Z292|>1uHc^9F#;OOABxu>}JlxS?)uq%uc{l_gtz2IeewRmSqe zeV2Eq#c<1pz)q`G^tOqgB{lx;PW4et*fE-?19x&6wFl4NrHqSnu2x9DTq~A=-SH*M zU&mfCm#`0S_Yp}>xhQ=%9eeg~7jfRnNdnPXGbXpUVdOUFpUpHxWjYE9fW+FZS$3>8ct8wT!xyFbsmCzeXX1 z9B$X}#!=_7rkm}ez*n=$7ne5U@#EX)|@3JYMLEVdqN^yDu?1FDf(w z-~j!I??8+@y>;*epf#Vm)%WC+(XnD$uL; zHkO4B@nBc*-)y_}tvo{58>swpC8UH@Hqf^i<>{PI01Xz^bI&k;Zf~O=NM7n{crGZ? z*c9$j$OI@9H?`6)D^+Yt{b{_u5yhc zx?*VAS49^Q(cwSbQ8IeEz`Z%)_QdV(e+f!Zw{hHhH}Jd|ZeHLo@cQKBDf~?$nW033 z+H@49v(R*Y<@s;Wvig2vGtR+ zBx}Ro)=;?x8lWQ8{@r>T+f+sHkJiJVfC`j)`KTHbJz*fLFtn2{u*}Ok&uTOe2eQVa z&z%&+EmxeIGFEI9`HZQI)*({y*KDKh0_xS!5w7ZG=IvkjtD`Md$}mBCKOw|7(`^K= z859py?6cmnZap38rDO5KBJA_{OSh^UrhQv8ZWG_c2J1WszU7A12WN|;5HVRmFe!f*Ku+1#9IaUb$jkAqRP^1OxRPdT@L5lEZvn6VKlnZG5R#3gtP&FAKwuHi ziFO~eRs-x9%LV}}xeD+#-K%YK@~ocju11V9d&t_QL)9kaiBDw%bb$LpV8DcCI{kkv z8F)l`$7%=y!tn6v|FS&)fS$NnyG#!nUR~Mjb8Ov;a$ioQ%!|YTPY?aaw+ia^g5UWl zeFfwcakEHo64!>D>T2LaQid_{soa`q+mwp^E=D#9jxr$HAmf)RDS?w8mM!=`LXEUW zH7X+qwDZv4OhY>->=gMN&S7&FAGzk!Ug*-8b@xPdw^S+bFv_pcEwSi53paRXd`U3+ zve&zcg}QT+eVpQdfbHk;zl-jCn6_mph``0XokF=I-ClP`?Jxk^rlPh~^$mgC^~7Nv znq0PpMI+H?%qRz;R@nwcEwUJmZ`zZN`t_uxe#^ZqJ_QF`(wZ!VElcawr?7m_3Wl=P zDJJNmQLsWgyLKL`tLsFjW_Bc6y|~7X)XgU7P)JGcA5DSuUibICz#G%V#@+Un-d^@u z+YjE0$s=2ERL#>Ke{MWFBdhq*oFAR7(e(&X$wwNsA;I=jP{l#(oxK_mo79cJ-rX)N z>Me0>V=ep$Jd%ZY!%j8USPd{t>dHLb-OlpCOZ@1@+S3JoT^8cVgKNQ_GJ&&HA-A(` zSbTe*JWI*e>u0|McDN%efYN-6qLHS>t+%#Zf1Dlp#P1+V9cvwFWtqYb>(3gT z?{0_Bu8Bh1sVZbAWV_kWd!M6SHlx$_>~&Jrj^$RNxKCl(o}z*Z_dR2~34J^!KC7mk z(^HGcdzTlHA1DJ0<21gS=(#_La+RxoO{*du`n5)dyR%PZezwVwQc$9{;+sKU=f%x) z2zEF!&)JwMTI1w^yc~C>dV?>-mmJ}soSW3ZjQN+v;Zlx^!jUFC*HpRB$s;?*7Z6jTLfIk6y`1lphW6N zNWZ40^p$BHyT&D(9$^(LAsR_Lm0BXK42XNX6}Q!a5ukzVE?FM8h1b2h87S&8bv{GD zIodDwYuoA+#o;sWv+stp*yP5SPk6r@VTs$9gkFd`tCbXt?*IwDi&0zn*Ju)c4K4~YD z(o4i1Pw;j6Tck#&V^2&y`E}aH(1dsFS$64C$m)|PnB!?Z8|bRU33INMIlei0=ZITjTpz!w~h+qx+|>cPY5N6~5WP`b>eu^@;oJ z4U233VaG>zTB z+GD!-!VRNHal1ZhSe#d($|2)D)gH3yc3${1@zO$&jC!_EWu|9a^vE1zqcv!7!<&*O z9#l;h5Q&(@R&j{UcAonAW}?%4q^Kda&@t_B?QDdM^Uo_2Bgf3<7`rCv#Qsxhhg*IR zSO0iefT#y{M022>8>^a!XaudFA0db!2@@cqN(nXo0V~pXGC2EmK6bC6Qy`%ekk?c# z_OM1IYZzXcrHVB|11e5dX4b~rI*%k`MbDEiH`?hhqwd&n(m@0Z{c4&@(*~wT20Mir%JX^1Vlck-5~WA9t8}W*9*5X-Uz{kk-KALK;F69 z<<;tqJjvohm;|m(fcA3NIJ3N(jjyXgj#iXb+2;N8qv166Y}pU_$IaFL=ldUYqXsSp zslbZ}9=xSPJ`WWy2$W2-zK8KIq{A6YEm!%dG--h9QP*a^MNTYt@*tzFnWhd8u)n((v zAwsqox$EirT`Bc-pT3PA$u9XP7uS7+8Zm9Vqb2;dkM%z`M^8b?`19Nd!CTTiIQM;4 z&zx3obcoF-xfH|&Y}Me@kJS|gb-<^nAe%aUgri^Hm1hh^*i<6pubC`>$uR;e@IS1* zWqxAQ#)7%A*o>CyS9&a`rr^psN!$4Nn5~+`ST0YeTbNyYF&^vRJ8_e;mbfH}SaNKh zQA&dvAQet+3VOJI-L3GQf&T2&jBrV2>>^X;)i38spmb%4u(pN^XTl4^yj6>Ht2kIH zOE2!-hRh^(aKCCf`^Ayka73PbD0VIG7SQo{){n0B$;S4OvQATyX}rF^ zR)@B^#9>_E)y-{IfXD(VnIz_C+1qqfd~9@tPYXAE#b0D1^0s>$%c3+}$c>IF)56be ztn3f|xr~blgqNY0-_GgmmlhwTsoIh8QkgdmnTe&yU;gf7ysQJ2)zj(a;wsypxTxXh zHpvc)_@CdHX8eHZp7VWk7?PN&d!9>QA71g*v!MlbxxP_VIGX*owEOtzI|LRzCo+%3 z>>|dRc~{h>3&sU(C1alG{j?{~2(Sr|)T9B~S=!0zwKKE3dS*qt96yod8TsavF-?OJ z1-_O2lMSmgn&4eVMh=4GZ~k{;`iE@)yc(-6N2FQT#myjJ^lyra;UXej!TqL`^B z*s3tj`AVnSi^lKZC9j$&GU9WWh;OSb4RLu1>v|L8J%Xo+;kgd-kp8*MrCsCF#9LAV z>R+RHKYo1mm+WXhmeDodhRAQxh3fubWh_iOeM~yFXJ$|MBi>r6m$SD=HgEyIZ7orE zTj?8Tb7d+E_-y_cExxmt_%7xI=0^cGRlrtl<-dNJ@~?tRzcXl!ar;Q%nEM2_HR_KR zZX5ZNTOq$#bBMImG$F-|lpERfqLB`Xzm_(Mt$36m)pn44Qv5Y^We;F#%WBX1vjd;} zU{)@^gGFFcZFPg}?h6^Ci>~5>a)7v9d-z?2S{c04tHpJirt(F@uTbAPGCzU-nMP% zY9_(>(Th}dU$;T?*QJzgWZ;oGY?VC8I;*45glyn4T(%gRdd=5rm|zB7DlPi<-8aAL ze)h}M{_-!F1JQDTJoCA;RLviA7`JRAub>&`=qkQoa!w&fsM9CtOr3+aWnAa|rPJ*; zp>{LdL!aT_?<0`0w0e%+E&gF@Y|ESPD#w?@Z$4Xh3F#j!*E<*8XJ!tNvIVS-0anA( zuH|{**-Pk!Oj|?ZjhliAak{sZN#F2_o!YDhmyk+{5)QF{`DkjAzW+AOdFGqpYbeeW za^rDKunIg{RVy)};|Jazw*B}Q8~msYXQ%(h4A#B8kf`-0*-qRsdoViedrROZkBm*f z&1GFU4q9yD+I$;cM4Pan{JQfdxmDttu<66*hQhC5wzV_GvuE!*i-JW)8GOg{u?D+q zQds$cNPC!~$nu-B3MF&vtTWAHb`1@8UE2t~ePpM+J6>t!vlfKl8`VuxLGhkXKD?HA zdwJVUVE&~Ct!KEgKhKvx7ug}7S#qS>Y1!X5%F0Fi0k`kB@0I1sr-^?Jb~v{v*z{V# z&?$u}eKGD8AIp5b73~xwtZ$vl zr#z28&Dg?)gdjK=TX@FS32@6S`QNg5!L5sFOf|>;;|GI(d)pX0c&7QxUg*!Qt?-nD z!85g_q(CS|TWL+$&3tlRWk17U_f;;>^(XEDpLwK05NU;lFW=b?1-(7_%fYgw_It4v zct3oCqo}32-IL2@Q*P!iJ34@E?6}CzMa{Hi--M;i@tabsgD;*j6K{k8`o7bW8uh&q zPD<%mF|tWaZ@ce9$4P_K!7{chbLqZ{N^40GadVjx>^0r(+}AvKN|%KZ9)YE8O}s0i zCoqD`kqt+N*?~|WC>J4{34C@s`p-wG=X558BD?hh_owWPm&ZDq1{wtQ`=S2;CrMJ5 diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/hash_random_int_find_find_timing_test.html b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/hash_random_int_find_find_timing_test.html deleted file mode 100644 index b6066e7cf..000000000 --- a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/hash_random_int_find_find_timing_test.html +++ /dev/null @@ -1,247 +0,0 @@ - - - - - -Hash Random Int Find Timing Test - - - -
    -

    Hash-Based Random-Integer find Find Timing - Test

    -

    Description

    -

    This test inserts a number of values with uniform i.i.d. - integer keys into a container, then performs a series of finds - using find. It measures the average time - forfind as a function of the number of values - inserted.

    -

    (The test was executed with random_int_find_timing_test - 200 200 2100)

    -

    Purpose

    -

    The test checks the effect of different underlying - hash-tables (see Design::Associative - Containers::Associative Containers::Hash-Based Containers), - range-hashing functions, and trigger policies (see Design::Associative - Containers::Hash-Based Containers::Hash Policies and - Design::Associative - Containers::Hash-Based Containers::Resize Policies).

    -

    Results

    -

    Figures NCCG, NCCM, - and NCCL show the results for the native - and collision-chaining types in g++, MSVC++, and - local, - respectively; Figures NGPG, NGPM, and NGPL show the results - for the native and probing types in g++, MSVC++, and - local - respectively.

    -
    -
    -
    -
    -
    no image
    NCCG: Native and collision-chaining hash random int find timing test using find - g++

    In the above figure, the names in the legends have the following meaning:

    -
      -
    1. -n_hash_map_ncah- -std::tr1::unordered_map with cache_hash_code = false
      2. -
    2. -cc_hash_mod_prime_nea_lc_1div8_1div1_nsth_map- -cc_hash_table -with Comb_Hash_Fn = direct_mod_range_hashing -, and Resize_Policy = hash_standard_resize_policy - with Size_Policy = hash_prime_size_policy -, and Trigger_Policy = hash_load_check_resize_trigger - with αmin = 1/8 and αmax = 1/1
      3. -
    3. -cc_hash_mod_prime_nea_lc_1div8_1div2_nsth_map- -cc_hash_table -with Comb_Hash_Fn = direct_mod_range_hashing -, and Resize_Policy = hash_standard_resize_policy - with Size_Policy = hash_prime_size_policy -, and Trigger_Policy = hash_load_check_resize_trigger - with αmin = 1/8 and αmax = 1/2
      4. -
    4. -cc_hash_mask_exp_nea_lc_1div8_1div1_nsth_map- -cc_hash_table -with Comb_Hash_Fn = direct_mask_range_hashing -, and Resize_Policy = hash_standard_resize_policy - with Size_Policy = hash_exponential_size_policy -, and Trigger_Policy = hash_load_check_resize_trigger - with αmin = 1/8 and αmax = 1/1
      5. -
    5. -cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_map- -cc_hash_table -with Comb_Hash_Fn = direct_mask_range_hashing -, and Resize_Policy = hash_standard_resize_policy - with Size_Policy = hash_exponential_size_policy -, and Trigger_Policy = hash_load_check_resize_trigger - with αmin = 1/8 and αmax = 1/2
      6. -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    no image
    NCCM: Native and collision-chaining hash random int find timing test using find - msvc++

    In the above figure, the names in the legends have the following meaning:

    -
      -
    1. -cc_hash_mod_prime_nea_lc_1div8_1div1_nsth_map- -cc_hash_table -with Comb_Hash_Fn = direct_mod_range_hashing -, and Resize_Policy = hash_standard_resize_policy - with Size_Policy = hash_prime_size_policy -, and Trigger_Policy = hash_load_check_resize_trigger - with αmin = 1/8 and αmax = 1/1
      2. -
    2. -cc_hash_mod_prime_nea_lc_1div8_1div2_nsth_map- -cc_hash_table -with Comb_Hash_Fn = direct_mod_range_hashing -, and Resize_Policy = hash_standard_resize_policy - with Size_Policy = hash_prime_size_policy -, and Trigger_Policy = hash_load_check_resize_trigger - with αmin = 1/8 and αmax = 1/2
      3. -
    3. -n_hash_map_ncah- -stdext::hash_map
      4. -
    4. -cc_hash_mask_exp_nea_lc_1div8_1div1_nsth_map- -cc_hash_table -with Comb_Hash_Fn = direct_mask_range_hashing -, and Resize_Policy = hash_standard_resize_policy - with Size_Policy = hash_exponential_size_policy -, and Trigger_Policy = hash_load_check_resize_trigger - with αmin = 1/8 and αmax = 1/1
      5. -
    5. -cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_map- -cc_hash_table -with Comb_Hash_Fn = direct_mask_range_hashing -, and Resize_Policy = hash_standard_resize_policy - with Size_Policy = hash_exponential_size_policy -, and Trigger_Policy = hash_load_check_resize_trigger - with αmin = 1/8 and αmax = 1/2
      6. -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    no image
    NCCL: Native and collision-chaining hash random int find timing test using find - local
    -
    -
    -
    -
    -
    -
    -
    -
    -
    no image
    NGPG: Native and collision-chaining hash random int find timing test using find - g++

    In the above figure, the names in the legends have the following meaning:

    -
      -
    1. -gp_hash_mod_quadp_prime_nea_lc_1div8_1div2_nsth_map- -gp_hash_table - with Comb_Hash_Fn = direct_mod_range_hashing -, Resize_Policy = hash_standard_resize_policy - with Size_Policy = hash_prime_size_policy -, and Trigger_Policy = hash_load_check_resize_trigger - with αmin = 1/8 and αmax = 1/2, and Probe_Fn = quadratic_probe_fn -
      2. -
    2. -n_hash_map_ncah- -std::tr1::unordered_map with cache_hash_code = false
      3. -
    3. -gp_hash_mask_linp_exp_nea_lc_1div8_1div2_nsth_map- -gp_hash_table - with Comb_Hash_Fn = direct_mask_range_hashing -, Resize_Policy = hash_standard_resize_policy - with Size_Policy = hash_exponential_size_policy -, and Trigger_Policy = hash_load_check_resize_trigger - with αmin = 1/8 and αmax = 1/2, and Probe_Fn = linear_probe_fn -
      4. -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    no image
    NGPM: Native and collision-chaining hash random int find timing test using find - msvc++

    In the above figure, the names in the legends have the following meaning:

    -
      -
    1. -gp_hash_mod_quadp_prime_nea_lc_1div8_1div2_nsth_map- -gp_hash_table - with Comb_Hash_Fn = direct_mod_range_hashing -, Resize_Policy = hash_standard_resize_policy - with Size_Policy = hash_prime_size_policy -, and Trigger_Policy = hash_load_check_resize_trigger - with αmin = 1/8 and αmax = 1/2, and Probe_Fn = quadratic_probe_fn -
      2. -
    2. -n_hash_map_ncah- -stdext::hash_map
      3. -
    3. -gp_hash_mask_linp_exp_nea_lc_1div8_1div2_nsth_map- -gp_hash_table - with Comb_Hash_Fn = direct_mask_range_hashing -, Resize_Policy = hash_standard_resize_policy - with Size_Policy = hash_exponential_size_policy -, and Trigger_Policy = hash_load_check_resize_trigger - with αmin = 1/8 and αmax = 1/2, and Probe_Fn = linear_probe_fn -
      4. -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    no image
    NGPL: Native and collision-chaining hash random int find timing test using find - local
    -
    -
    -
    -
    -

    Observations

    -

    In this setting, the choice of underlying hash-table (see - Design::Associative - Containers::Hash-Based Containers ) affects performance - most, then the range-hashing scheme (See Design::Associative - Containers::Hash-Based Containers::Hash Policies ), and, - only finally, other policies.

    -

    When comparing Figures NCCG and NCCM to NGPG and NGPM , respectively, it is apparent that the - probing containers are less efficient than the - collision-chaining containers (both - std::tr1::unordered_map and stdext::hash_map - use collision-chaining) in this case.

    -

    ( Hash-Based - Random-Integer Subscript Insert Timing Test shows a - different case, where the situation is reversed; Observations::Hash-Based - Container Types discusses some further considerations.)

    -

    Within each type of hash-table, the range-hashing scheme - affects performance more than other policies; Hash-Based - Text find Find Timing Test::Observations discusses - this. In Figures NCCG , NCCM , NGPG , and NGPM , it should be noted that - std::tr1::unordered_map and stdext::hash_map - are hard-wired currently to mod-based and mask-based schemes, - respectively.

    -

    Observations::Hash-Based - Container Types summarizes some observations on hash-based - containers; Observations::Hash-Based - Containers' Policies summarizes some observations on - hash-based containers' policies.

    -
    - - diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/hash_random_int_subscript_find_timing_test.html b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/hash_random_int_subscript_find_timing_test.html deleted file mode 100644 index 002516370..000000000 --- a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/hash_random_int_subscript_find_timing_test.html +++ /dev/null @@ -1,220 +0,0 @@ - - - - - -Hash Random Int Subscript Find Timing Test - - - -
    -

    Hash-Based Random-Integer operator[] - FindTiming Test

    -

    Description

    -

    This test inserts a number of values with uniform i.i.d. - integer keys into a container, then performs a series of finds - using operator[]. It measures the average time - for operator[] as a function of the number of - values inserted.

    -

    (The test was executed with hash_random_int_subscript_find_timing_test - 200 200 2100)

    -

    Purpose

    -

    The test checks the effect of different underlying - hash-tables (see Design::Hash-Based Containers - ), range-hashing functions, and trigger policies (see Design::Hash-Based - Containers::Hash Policies and Design::Hash-Based - Containers::Resize Policies ).

    -

    Results

    -

    Figures NCCG, NCCM, - and NCCL show the results for the native - and collision-chaining types in g++, MSVC++, and - local, - respectively; Figures NGPG, NGPM, and NGPL show the results - for the native and probing types in g++, MSVC++, and - local, - respectively.

    -
    -
    -
    -
    -
    no image
    NCCG: Native and collision-chaining hash random int find timing test using operator[] - g++

    In the above figure, the names in the legends have the following meaning:

    -
      -
    1. -n_hash_map_ncah- -std::tr1::unordered_map with cache_hash_code = false
      2. -
    2. -cc_hash_mod_prime_nea_lc_1div8_1div1_nsth_map- -cc_hash_table -with Comb_Hash_Fn = direct_mod_range_hashing -, and Resize_Policy = hash_standard_resize_policy - with Size_Policy = hash_prime_size_policy -, and Trigger_Policy = hash_load_check_resize_trigger - with αmin = 1/8 and αmax = 1/1
      3. -
    3. -cc_hash_mod_prime_nea_lc_1div8_1div2_nsth_map- -cc_hash_table -with Comb_Hash_Fn = direct_mod_range_hashing -, and Resize_Policy = hash_standard_resize_policy - with Size_Policy = hash_prime_size_policy -, and Trigger_Policy = hash_load_check_resize_trigger - with αmin = 1/8 and αmax = 1/2
      4. -
    4. -cc_hash_mask_exp_nea_lc_1div8_1div1_nsth_map- -cc_hash_table -with Comb_Hash_Fn = direct_mask_range_hashing -, and Resize_Policy = hash_standard_resize_policy - with Size_Policy = hash_exponential_size_policy -, and Trigger_Policy = hash_load_check_resize_trigger - with αmin = 1/8 and αmax = 1/1
      5. -
    5. -cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_map- -cc_hash_table -with Comb_Hash_Fn = direct_mask_range_hashing -, and Resize_Policy = hash_standard_resize_policy - with Size_Policy = hash_exponential_size_policy -, and Trigger_Policy = hash_load_check_resize_trigger - with αmin = 1/8 and αmax = 1/2
      6. -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    no image
    NCCM: Native and collision-chaining hash random int find timing test using operator[] - msvc++

    In the above figure, the names in the legends have the following meaning:

    -
      -
    1. -cc_hash_mod_prime_nea_lc_1div8_1div1_nsth_map- -cc_hash_table -with Comb_Hash_Fn = direct_mod_range_hashing -, and Resize_Policy = hash_standard_resize_policy - with Size_Policy = hash_prime_size_policy -, and Trigger_Policy = hash_load_check_resize_trigger - with αmin = 1/8 and αmax = 1/1
      2. -
    2. -cc_hash_mod_prime_nea_lc_1div8_1div2_nsth_map- -cc_hash_table -with Comb_Hash_Fn = direct_mod_range_hashing -, and Resize_Policy = hash_standard_resize_policy - with Size_Policy = hash_prime_size_policy -, and Trigger_Policy = hash_load_check_resize_trigger - with αmin = 1/8 and αmax = 1/2
      3. -
    3. -n_hash_map_ncah- -stdext::hash_map
      4. -
    4. -cc_hash_mask_exp_nea_lc_1div8_1div1_nsth_map- -cc_hash_table -with Comb_Hash_Fn = direct_mask_range_hashing -, and Resize_Policy = hash_standard_resize_policy - with Size_Policy = hash_exponential_size_policy -, and Trigger_Policy = hash_load_check_resize_trigger - with αmin = 1/8 and αmax = 1/1
      5. -
    5. -cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_map- -cc_hash_table -with Comb_Hash_Fn = direct_mask_range_hashing -, and Resize_Policy = hash_standard_resize_policy - with Size_Policy = hash_exponential_size_policy -, and Trigger_Policy = hash_load_check_resize_trigger - with αmin = 1/8 and αmax = 1/2
      6. -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    no image
    NCCL: Native and collision-chaining hash random int find timing test using operator[] - local
    -
    -
    -
    -
    -
    -
    -
    -
    -
    no image
    NGPG: Native and probing hash random int find timing test using operator[] - g++

    In the above figure, the names in the legends have the following meaning:

    -
      -
    1. -n_hash_map_ncah- -std::tr1::unordered_map with cache_hash_code = false
      2. -
    2. -gp_hash_mod_quadp_prime_nea_lc_1div8_1div2_nsth_map- -gp_hash_table - with Comb_Hash_Fn = direct_mod_range_hashing -, Resize_Policy = hash_standard_resize_policy - with Size_Policy = hash_prime_size_policy -, and Trigger_Policy = hash_load_check_resize_trigger - with αmin = 1/8 and αmax = 1/2, and Probe_Fn = quadratic_probe_fn -
      3. -
    3. -gp_hash_mask_linp_exp_nea_lc_1div8_1div2_nsth_map- -gp_hash_table - with Comb_Hash_Fn = direct_mask_range_hashing -, Resize_Policy = hash_standard_resize_policy - with Size_Policy = hash_exponential_size_policy -, and Trigger_Policy = hash_load_check_resize_trigger - with αmin = 1/8 and αmax = 1/2, and Probe_Fn = linear_probe_fn -
      4. -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    no image
    NGPM: Native and probing hash random int find timing test using operator[] - msvc++

    In the above figure, the names in the legends have the following meaning:

    -
      -
    1. -gp_hash_mod_quadp_prime_nea_lc_1div8_1div2_nsth_map- -gp_hash_table - with Comb_Hash_Fn = direct_mod_range_hashing -, Resize_Policy = hash_standard_resize_policy - with Size_Policy = hash_prime_size_policy -, and Trigger_Policy = hash_load_check_resize_trigger - with αmin = 1/8 and αmax = 1/2, and Probe_Fn = quadratic_probe_fn -
      2. -
    2. -n_hash_map_ncah- -stdext::hash_map
      3. -
    3. -gp_hash_mask_linp_exp_nea_lc_1div8_1div2_nsth_map- -gp_hash_table - with Comb_Hash_Fn = direct_mask_range_hashing -, Resize_Policy = hash_standard_resize_policy - with Size_Policy = hash_exponential_size_policy -, and Trigger_Policy = hash_load_check_resize_trigger - with αmin = 1/8 and αmax = 1/2, and Probe_Fn = linear_probe_fn -
      4. -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    no image
    NGPL: Native and probing hash random int find timing test using operator[] - local
    -
    -
    -
    -
    -

    Observations

    -

    This test shows similar results to Hash-Based - Random-Integer find Find Timing Test .

    -
    - - diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/hash_random_int_subscript_insert_timing_test.html b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/hash_random_int_subscript_insert_timing_test.html deleted file mode 100644 index a15d03ba4..000000000 --- a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/hash_random_int_subscript_insert_timing_test.html +++ /dev/null @@ -1,365 +0,0 @@ - - - - - -Hash Random Int Subscript Insert Timing Test - - - -
    -

    Hash-Based Random-Integer operator[] Insert - Timing Test

    -

    Description

    -

    This test inserts a number of values with uniform i.i.d. - integer keys into a container, using - operator[]. It measures the average time for - operator[] as a function of the number of - values inserted.

    -

    (The test was executed with hash_random_int_subscript_insert_timing_test - 200 200 2100)

    -

    Purpose

    -

    The test primarily checks the effect of different underlying - hash-tables (see Design::Associative - Containers::Associative Containers::Hash-Based - Containers).

    -

    Results

    -

    Figures NCCG, NCCM, - and NCCL show the results for the native - and collision-chaining types in g++, MSVC++, and - local, - respectively; Figures NGPG, NGPM, and NGPL show the results - for the native and probing types in g++, msvc++, and - local - respectively; Figures CCGPG, CCGPM, and CCGPL compare the - results for the collision-chaining and probing types of - pb_ds only, in g++, MSVC++, and - local - respectively.

    -
    -
    -
    -
    -
    no image
    NCCG: Native and collision-chaining hash random int insert timing test using operator - g++

    In the above figure, the names in the legends have the following meaning:

    -
      -
    1. -cc_hash_mod_prime_nea_lc_1div8_1div2_nsth_map- -cc_hash_table -with Comb_Hash_Fn = direct_mod_range_hashing -, and Resize_Policy = hash_standard_resize_policy - with Size_Policy = hash_prime_size_policy -, and Trigger_Policy = hash_load_check_resize_trigger - with αmin = 1/8 and αmax = 1/2
      2. -
    2. -n_hash_map_ncah- -std::tr1::unordered_map with cache_hash_code = false
      3. -
    3. -cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_map- -cc_hash_table -with Comb_Hash_Fn = direct_mask_range_hashing -, and Resize_Policy = hash_standard_resize_policy - with Size_Policy = hash_exponential_size_policy -, and Trigger_Policy = hash_load_check_resize_trigger - with αmin = 1/8 and αmax = 1/2
      4. -
    4. -cc_hash_mod_prime_nea_lc_1div8_1div1_nsth_map- -cc_hash_table -with Comb_Hash_Fn = direct_mod_range_hashing -, and Resize_Policy = hash_standard_resize_policy - with Size_Policy = hash_prime_size_policy -, and Trigger_Policy = hash_load_check_resize_trigger - with αmin = 1/8 and αmax = 1/1
      5. -
    5. -cc_hash_mask_exp_nea_lc_1div8_1div1_nsth_map- -cc_hash_table -with Comb_Hash_Fn = direct_mask_range_hashing -, and Resize_Policy = hash_standard_resize_policy - with Size_Policy = hash_exponential_size_policy -, and Trigger_Policy = hash_load_check_resize_trigger - with αmin = 1/8 and αmax = 1/1
      6. -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    no image
    NCCM: Native and collision-chaining hash random int insert timing test using operator - msvc++

    In the above figure, the names in the legends have the following meaning:

    -
      -
    1. -n_hash_map_ncah- -stdext::hash_map
      2. -
    2. -cc_hash_mod_prime_nea_lc_1div8_1div2_nsth_map- -cc_hash_table -with Comb_Hash_Fn = direct_mod_range_hashing -, and Resize_Policy = hash_standard_resize_policy - with Size_Policy = hash_prime_size_policy -, and Trigger_Policy = hash_load_check_resize_trigger - with αmin = 1/8 and αmax = 1/2
      3. -
    3. -cc_hash_mod_prime_nea_lc_1div8_1div1_nsth_map- -cc_hash_table -with Comb_Hash_Fn = direct_mod_range_hashing -, and Resize_Policy = hash_standard_resize_policy - with Size_Policy = hash_prime_size_policy -, and Trigger_Policy = hash_load_check_resize_trigger - with αmin = 1/8 and αmax = 1/1
      4. -
    4. -cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_map- -cc_hash_table -with Comb_Hash_Fn = direct_mask_range_hashing -, and Resize_Policy = hash_standard_resize_policy - with Size_Policy = hash_exponential_size_policy -, and Trigger_Policy = hash_load_check_resize_trigger - with αmin = 1/8 and αmax = 1/2
      5. -
    5. -cc_hash_mask_exp_nea_lc_1div8_1div1_nsth_map- -cc_hash_table -with Comb_Hash_Fn = direct_mask_range_hashing -, and Resize_Policy = hash_standard_resize_policy - with Size_Policy = hash_exponential_size_policy -, and Trigger_Policy = hash_load_check_resize_trigger - with αmin = 1/8 and αmax = 1/1
      6. -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    no image
    NCCL: Native and collision-chaining hash random int insert timing test using operator - local
    -
    -
    -
    -
    -
    -
    -
    -
    -
    no image
    NGPG: Native and probing hash random int insert timing test using operator - g++

    In the above figure, the names in the legends have the following meaning:

    -
      -
    1. -gp_hash_mod_quadp_prime_nea_lc_1div8_1div2_nsth_map- -gp_hash_table - with Comb_Hash_Fn = direct_mod_range_hashing -, Resize_Policy = hash_standard_resize_policy - with Size_Policy = hash_prime_size_policy -, and Trigger_Policy = hash_load_check_resize_trigger - with αmin = 1/8 and αmax = 1/2, and Probe_Fn = quadratic_probe_fn -
      2. -
    2. -n_hash_map_ncah- -std::tr1::unordered_map with cache_hash_code = false
      3. -
    3. -gp_hash_mask_linp_exp_nea_lc_1div8_1div2_nsth_map- -gp_hash_table - with Comb_Hash_Fn = direct_mask_range_hashing -, Resize_Policy = hash_standard_resize_policy - with Size_Policy = hash_exponential_size_policy -, and Trigger_Policy = hash_load_check_resize_trigger - with αmin = 1/8 and αmax = 1/2, and Probe_Fn = linear_probe_fn -
      4. -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    no image
    NGPM: Native and probing hash random int insert timing test using operator - msvc++

    In the above figure, the names in the legends have the following meaning:

    -
      -
    1. -n_hash_map_ncah- -stdext::hash_map
      2. -
    2. -gp_hash_mod_quadp_prime_nea_lc_1div8_1div2_nsth_map- -gp_hash_table - with Comb_Hash_Fn = direct_mod_range_hashing -, Resize_Policy = hash_standard_resize_policy - with Size_Policy = hash_prime_size_policy -, and Trigger_Policy = hash_load_check_resize_trigger - with αmin = 1/8 and αmax = 1/2, and Probe_Fn = quadratic_probe_fn -
      3. -
    3. -gp_hash_mask_linp_exp_nea_lc_1div8_1div2_nsth_map- -gp_hash_table - with Comb_Hash_Fn = direct_mask_range_hashing -, Resize_Policy = hash_standard_resize_policy - with Size_Policy = hash_exponential_size_policy -, and Trigger_Policy = hash_load_check_resize_trigger - with αmin = 1/8 and αmax = 1/2, and Probe_Fn = linear_probe_fn -
      4. -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    no image
    NGPL: Native and probing hash random int insert timing test using operator - local
    -
    -
    -
    -
    -
    -
    -
    -
    -
    no image
    CCGPG: Collision-chaining and probing hash random int insert timing test using operator - g++

    In the above figure, the names in the legends have the following meaning:

    -
      -
    1. -gp_hash_mod_quadp_prime_nea_lc_1div8_1div2_nsth_map- -gp_hash_table - with Comb_Hash_Fn = direct_mod_range_hashing -, Resize_Policy = hash_standard_resize_policy - with Size_Policy = hash_prime_size_policy -, and Trigger_Policy = hash_load_check_resize_trigger - with αmin = 1/8 and αmax = 1/2, and Probe_Fn = quadratic_probe_fn -
      2. -
    2. -cc_hash_mod_prime_nea_lc_1div8_1div2_nsth_map- -cc_hash_table -with Comb_Hash_Fn = direct_mod_range_hashing -, and Resize_Policy = hash_standard_resize_policy - with Size_Policy = hash_prime_size_policy -, and Trigger_Policy = hash_load_check_resize_trigger - with αmin = 1/8 and αmax = 1/2
      3. -
    3. -cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_map- -cc_hash_table -with Comb_Hash_Fn = direct_mask_range_hashing -, and Resize_Policy = hash_standard_resize_policy - with Size_Policy = hash_exponential_size_policy -, and Trigger_Policy = hash_load_check_resize_trigger - with αmin = 1/8 and αmax = 1/2
      4. -
    4. -gp_hash_mask_linp_exp_nea_lc_1div8_1div2_nsth_map- -gp_hash_table - with Comb_Hash_Fn = direct_mask_range_hashing -, Resize_Policy = hash_standard_resize_policy - with Size_Policy = hash_exponential_size_policy -, and Trigger_Policy = hash_load_check_resize_trigger - with αmin = 1/8 and αmax = 1/2, and Probe_Fn = linear_probe_fn -
      5. -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    no image
    CCGPM: Collision-chaining and probing hash random int insert timing test using operator - msvc++

    In the above figure, the names in the legends have the following meaning:

    -
      -
    1. -cc_hash_mod_prime_nea_lc_1div8_1div2_nsth_map- -cc_hash_table -with Comb_Hash_Fn = direct_mod_range_hashing -, and Resize_Policy = hash_standard_resize_policy - with Size_Policy = hash_prime_size_policy -, and Trigger_Policy = hash_load_check_resize_trigger - with αmin = 1/8 and αmax = 1/2
      2. -
    2. -cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_map- -cc_hash_table -with Comb_Hash_Fn = direct_mask_range_hashing -, and Resize_Policy = hash_standard_resize_policy - with Size_Policy = hash_exponential_size_policy -, and Trigger_Policy = hash_load_check_resize_trigger - with αmin = 1/8 and αmax = 1/2
      3. -
    3. -gp_hash_mod_quadp_prime_nea_lc_1div8_1div2_nsth_map- -gp_hash_table - with Comb_Hash_Fn = direct_mod_range_hashing -, Resize_Policy = hash_standard_resize_policy - with Size_Policy = hash_prime_size_policy -, and Trigger_Policy = hash_load_check_resize_trigger - with αmin = 1/8 and αmax = 1/2, and Probe_Fn = quadratic_probe_fn -
      4. -
    4. -gp_hash_mask_linp_exp_nea_lc_1div8_1div2_nsth_map- -gp_hash_table - with Comb_Hash_Fn = direct_mask_range_hashing -, Resize_Policy = hash_standard_resize_policy - with Size_Policy = hash_exponential_size_policy -, and Trigger_Policy = hash_load_check_resize_trigger - with αmin = 1/8 and αmax = 1/2, and Probe_Fn = linear_probe_fn -
      5. -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    no image
    CCGPL: Collision-chaining and probing hash random int insert timing test using operator - local
    -
    -
    -
    -
    -

    Observations

    -

    In this setting, as in Hash-Based Text - find Find Timing Test and Hash-Based - Random-Integer find Find Timing Test , the choice - of underlying hash-table underlying hash-table (see Design::Associative - Containers::Hash-Based Containers ) affects performance - most, then the range-hashing scheme (See Design::Associative - Containers::Hash-Based Containers::Hash Policies ), and, - only finally, other policies.

    -

    There are some differences, however:

    -
      -
    1. In this setting, probing tables function sometimes more - efficiently than collision-chaining tables (see Figures - CCGPG and CCGPM ). - This is explained shortly.
      2. -
    2. The performance graphs have a "saw-tooth" shape. The - average insert time rises and falls. As values are inserted - into the container, the load factor grows larger. Eventually, - a resize occurs. The reallocations and rehashing are - relatively expensive. After this, the load factor is smaller - than before.
      3. -
    -

    Collision-chaining containers use indirection for greater - flexibility; probing containers store values contiguously, in - an array (see Figure Motivation::Different - underlying data structures A and B, respectively). It - follows that for simple data types, probing containers access - their allocator less frequently than collision-chaining - containers, (although they still have less efficient probing - sequences). This explains why some probing containers fare - better than collision-chaining containers in this case.

    -

    Within each type of hash-table, the range-hashing scheme - affects performance more than other policies. This is similar - to the situation in Hash-Based Text - find Find Timing Test and Hash-Based - Random-Integer find Find Timing Test. - Unsurprisingly, however, containers with lower -alphamax perform worse in this case, - since more re-hashes are performed.

    -

    Observations::Hash-Based - Container Types summarizes some observations on hash-based - containers; Observations::Hash-Based - Containers' Policies summarizes some observations on - hash-based containers' policies.

    -
    - - diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/hash_range_hashing_seq_diagram.png b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/hash_range_hashing_seq_diagram.png deleted file mode 100644 index 5c37407dda69b82a195f69f86ab51e13377aaaca..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 12962 zcmeHucTiN_mu(Z2EGRkS2a04RN@|iw&N&Cg1|&&NO;7<55EYP2lbZ}m&I$q|NRxvS z1)-Z9x(Q91+vxAT?>Fz&{4w>W-b~F{Wx;Lxo_o*P`>egz+Q(>JZ50YqCQ=XxM4_g7 zPag!rcLss*e2DRZPbMbyj)5O|UivDEpo#$&6mUTZQP5HVf!@cHo!DIht~nm4>T7{O zfj2>*u;(BU7WgO(2?F`t27y*>K_ICV5QyF*qe)K&1QO;@yQg62Z@rNzS7h09)V>w} z`6eDUnUcIRF>n4oLVAgLMMB!Agk?7sNO^{z6OR%P-{N?YKL3~HuyWi}(u5b;iUm|W zh9w>!<2drKl}w|IKSdDNqqi21r?&iSAm{x9k`Uj4j1?MtAK%$jNrZGWVxYgV`FyKS zs9k103`EEQ!XuWq<;EZ8Ci?w52w(c@-N|Cni0in20pU{}IxodhIKLKo?h4 z(s<}bX_3Evzs5e{;L3UwuznXW<%h3@+N(x@o1w@11schM)-C>PLJwwIvLteKob>kwDtH8jWJHye za}YVIZWVB&0S9D~`z7c*h<1z>zSji2Fx|Y$NWDY#DruKWmQ(Jk-lo>z;36eUwt17RGfWW--z%7)xd_=SAr`ZivubGc zgwiI9EjkHK<9oXE#`MU)>t;Rz+oPjufT$3R>-3p2;oCXX41H2C!5%+`XX98sdpt^+ zz)J4za#$E)Hz$0J-rc4(&}VP?TVJw}O?${`ZvuDozJmLGKBdi>W;m%|xj?}Q7rK}} z=e6?}%e%5{;NTQbr<_>f51Zu*wXCeH8-_n3J4)0u$z6*PQrGx&c-FC@g!p4%s`jdY z&I5BgbSS1U@7&ooB0=f_rYV*TxvklEZpDZsr7gg>+b!u4_6vT*T8f3hnr=a=Y)3-wu={knBXAjLJw}0X-()@7Nej*d{ zbi;SU8QE@qX1DY_vcqGh3Ozgq2j@4HY?BW2IXI!4Iu|19+}_T|#PwL)+je_6Z0%7v z@-%(T&R~5z4BPa0;>8BhShUzeN#()O^5?6U=KTUHMX~v?T4{`-|Fc&Fozj)o8g^}K z3l;Vj6OwBaD@~}pIab0RA@|T0;>|l0dv!~T7In@XqbB!(VlT(fG)s!quuf57C z)>0zmByHEwdb=}9Ak=rt>7sIwsx_H?3g8xKC6T)r@X)d#@q{LREafR%G zQgXYfCGA>-pbuh8wXXQ_Hp@rZgNUNDZT;0NjRn|FGA_c3HPddSGR$?=U=iUy*CZ1! zj-WYx#j-?i9bP!E+{F=T3eyPpE$4>J`uZ4!_{|1tn!prNHOM#OtCFePZ$#^xnowrT z9FsH4;nfN_wjM!!JEh-9HkVg5Fn#4q3gitg@{2khD5&RM5v-7DtGWBE!X|m%x`4=y z_43rE!cqi-e+D{sXVGL@-`4Nsx$*drH5~EH3e#ZDv z32OT)Mxq0OX;pw{op`IEmw608E5zn38jY8z;_E+(-GM1F_bi!7j* zS#Ay8C>m0?DpFaRj$x#1Ov0jjx33Y$NLj1x+wR4VD;jZA3pAiZUVy7@9HfZ~kb{(4p4&J_RCj(xZ?W`DAN@2EKN#gmtu65?xLy!3TvF+3;nh#*xYMIyxbvTu*h$Hfu4+D zr|eBDD7G{6V8wFwdO8GF7h^**u6ANS`_l0mwk9<=d?&ZY#NOw5reeOf#l5y?oF@WSWk#8P7J=E(WxU?sq&hl+8frXfHBc5M zbBOL%bNU7!hKKY;q5CKe3(1gv0~OQmFU)dw96m(%WkT$=DwsVPt;RsxwpVyR5Qnb)QOEQPA z)G05)eF-^TZwUt>oLGKIM{Ior_*jIcII>b)c~0gXI3aFyQ+q5Ik?FBfT18*O(ll{UGl$K5}o3KLhw9?YH@}D+cR%#N?R= z&PE7FJ0^KC2L7^8fc;7xu}=nJPttm4n*H48+RAMV8htm+Z#*a%tM_>XOCqm|_9cL7 zi$00-VTKA`!*j3)Y1{hq^VxY)!-=z_*=R7j3reGxm3uvJal)@IVb0Ai&2i zdsUNLgf$l{*usdp9tJ)h5Tvjgfi8yct-2=&!5*N^A_M-Je}*W_SF35s+O+t;0dwq&;kja5Gp8Wf z$-IX^fFBx;%G;4S4|3rnMMw72-3Pi);mR2FT z$X0JYZ)4s%^k!bJ?M=LW@ZQH9gp6C#{Tzfk^+=utvYJRnF@ZQ6!KIn0NU=&Cu|#p{ z_cJ&E@uUe+R=ZGAVIQB$Kf`j>U(5*<{+=Wo@t%af92T*b+Ylq#Jqx+oU+wn1714su z`>!zi#&aB#Jw-PJ>@5RiR)VO=^p?lUK;}j*JW16_sse>sn;@vm8dp(|Qv_n9SEcWC z5BS-#5C*RIl9rNs`;u!Q=wMS#Bb`9dvSA+oW#HlV!v6OWb<4KkqochQCkOfhU$IT? zB!dP9ApYbS7iL9RK(V_ntaDZhy*?$PBa8Wn9VI9=d`g}$#I2JxnXCZ2Hml9^B1gq3UCCUF@@_OoXNA6cad(UX25hiFuP#cc5{9=Gf>g)w>DPKR)D&- zE?bd3SF;|3r0kg)?tCqYqeYNWrzem}XqsXY`g_8Le14A{{Y0}3Zk6y0KHTVkWE@|EQ0;Ce_s_S!ns7?#`X z_ZnD0nq0)jbls}KS8~3J#cyD-Aw#}#uW9>+oZguJoe(&>5o5ftF`*OPdQBb{)Fl_w zJp{2%V;)_ps=v}@(7XAw-0FrhipNZR_L!V0VYUP8*uY#DWP=#*vX~1fbvCkd)N3Oj z(aKD0X(d>F20YK?k{&K)>ww`bu0o4x_0C&gLOd7R7h>5QwTuEs+U@G-%a+q^XEbH# z*UzqhjZC#aNn|e-NcAj!JDJQ_FXReQAh}qtyEg{2!F;`Co4axQk{3d*+@(HWiR6#OT;`1z12YkSfpSq!Lx$-MVkS#m4Vp3ig+3L$0|8j0YSyZ=u8{jcr)SjowJZ2$?}btlgIsi#Mu5tV<#GHndlwa zrU-D*M@~@yf;2luc|_HqtCW99oNV4C?PVstr+|BRd8u#|${=*c-@~J7A(?*&5{Ts? zxd4;^!a}$XlrgI{hA@u%Tq!s7D}&YSaR=14k?O(6mrK z*_Yrw>&s#)If%6Ck^6Il5NkH>LLDB1pQGhUSank^C6kci^)i|d19<^?;lI~LmFxBm zsQNqoLJ6=>S#vlNQ2*|&n0Hy3D_27-M4u4ql3yUCFtMf@OoOcM`*Fq!#l0tKfbqg6 z8;D-BImh;=ieOFReQrKrp~AnIuJqNESTH6kt7%32Ojcv&e!fV69BCbO9w}L6^>P_q z1z&$3gO&Z37kSAj<3$K%H1ER#k|(T3mm6AEiUM%@XeqzxggxOMD%yXP47XByky%#BjEGgrhg)#3BBvTEw>Hq{^ zF1P|+eo`t*3N=nkVVhBe$EiWK040;+Q&+^r6huge zD;13qzb&^|EfDmTR)gayza@Q_RsNlQaExu14<~MP_WwSkZ^Aw%aO+sNhm?mdR*^;gKXjWFo7_Rto^qxCNlPMdc>ILMJM1Ox^<~U>6;_ z_w!;$1X=VArT4n+OhzNkkp^t|RE}?ft;$>8MOPulov^)BeOq~C@i2D9b%*gAlTY_` zL6*b-pwirazh_`4jv^8SD$qCEN}vce^Ij6vx;3UtjCv%2G!ScE`bx)&^j+L6p6TF> zY(;c@giNvo!2;A&U;)#-alCmtPMT5qH)y9If!RE1178HK%_tnay9-ANSoPnKBEv~b zW7)pgy&MaWeNA?ncy1*7>I45`bY9k2#@MBI#%`=^fgciiO>!e;;N$|U?Z*C&%E^Un z=DBwG-(B6-bHczqH#JX@BJSkC8VHm2cFxErTGBqUy%x)^A(_>C6#JEs#O&QTT*wCU zblXz1V^2nCH1GR~VU?|=Qd!NWeVKDY>_m=nK){5xcg&`y;~jrP%8rK;HP>op^bt}EL6k)qr zAo|6Fd6QB@`NE=O-DzFMWOc-Y2c=_rC`u5{19+DPU-UiM`}i$? z2+m$b%jjGiP8@}Fyvy%%%vynWJRETFzQ00yOC^xqun#_a2V-DI>R4)45dPemI6ZIS zN?{^NE)dubo>VE& z>afsM?44yz9t7L?Ra3`j4{%$~e~a7RyB?tQ4=4vH#fX{SwF}(hsNw(~&@1q}Jz(ns z&>okL&e2e8`VAY_^wI|lfeh1PV;!>)ttrQ9AppUC(EAd4&r} zG*aj>rc%?LGVe1DF`zDk0YL$5Txl7Z&v^!47@*HDD6xxB{W#>LI&tCg()Z@cDeE`J zT5fY~aVijLP{VfbRe2b-s#%MFX{GJh`bhiU*hXLw*#xyJV$jNR7YT=jU;*1dhdBpK z9IS=omqTITy$0GibMqEV=py?hX=}jA;f{rSEA6JpPX%Veki$-PI#v%+aS=cm2rU4U zX=O}-qUH+6bK(#_)rb}ac|%u1^c`e(95ZAf1CY3Bg;{}qrR7m*B77jlsTl~cR*pO( zEW5XYfEW9*Y4tg+S%ecGKZp}p>4WaKk=I`<&!a}*{bJQ$t`der0ort&FX#VbL%@>q zRZ$&je0)5h8h2|+Y75F*&#DemlMT?RJ>|o<&}L5df!<`${V)~BYk26?=fws^3eeow zEjjWu7xBxdmd927-)w@)6sJ~}=zfR!wm8tU5nsr~RC`#__`T_#Jm!BIFdl~+J>-8z z|2J2r=qu)E9sT9O1h;r)mwN6Xph5vg4CF>5kQ<&6OTUWaitGOhe^kduCWPy~3d0=j{_3mfw}!E4Sn0jj6{gwlJuC+LQmFP4-R-C%8dAbr%S^?6X#K$G1<9e@4`-1=sH0Guae(elYrkmWlx&)+{9aV-*}#3b2`WjW;WzcuAcPrMC=L{dbq5 z>3yK>@pLY&Ud27v7Md>ET`Gxnr_oQ*bCD=Ar zSBmgxe(g@|iN|VpvxF$?UI}mI*NSEjlV2UYjQi592Po23?lgUiT7MJ+A%`x&J^0mv z&~>H_v$3WLhI2h@_B$^A=;aoYlp*ct6?lG=Opa~qe&1S<#R%cndtVSpDJXuAY zoJw=8g`__2>=3hX9Qoo6Pv&yVjZW9CpE~Z>pu=e&QFR+JKMxP85Hj;~3c2Ij(fA55 zW*N}#Go78CKx-CyveTn{to1+%fJY_W{8w54b)G#0vU_7jipxwLCVd)W?DFkLy?cz> z>>&qk?|=x60a&DFU_fC%r%|hNTLHv94Ogkszw|NF=h%FIN$-xafnowq9@_|>=CPlu zcFhKDwNio)=SfwR2-#%(2WN|xUvk{`0SX!uBO1^(?;RUQ;+s#;&?A6XzXuCFXr4Pg zJ7_=u0oYJLOIhVGPLoYD`D30+{2Aa=X+KCA?sK{ZC`Tc8To_SBKs(O4yAeZa(z12@ zvx{uzhW8G7kl?i5+t11UF8;KXD2s-(IY9iE<6gX%d)s1$$fLw}w z`81UfP?`i$K;<%GiU9LzX~w(dAlSBvwE#kpaNCDetVoCEtpv>rfN20v@&=xiNqggu zawWs3SWTGzBUHL?;%KL3O$c2@%um5#h9H>oZA8;mz_S{T|L;1wZ9HL?Ou#M{^Z1nc z;1f3tz;UQWiAXaWKA=z(0N+mG_P9O?*#xJ<&)L=>0O9A%k4jA{D{R^;?1z_zhTil= zB}h?gyOoz%a8!tJW>68AaRN{n!iGXIcfolHSa*J9Eh?-2 zUyG2f>Bhb7h0bgx*#i8WM$lw8WJSwde;fp?O!)F}?DVPaFwXnPfv^xuPUz)E_aUG%+tFiPOgbj|kGiV`WGQd*q^^ z?Fnb^v-ptBb{NaWCD3Tcqi+5I483`aH^V!;fo<%O&}H@>F=Wdb-$oa=QS^6DYG$-k zv&F0+3*ovH(Xz4+kl=LTmoceb;n}{#sv)2BKgqtYc*v4@h5WMjqqoXy%?|_Rv?SE@8e+>iPJu+pHhA(8V4X9^>9{(-d#P^XA+ubyRlH@&(z1Z%L%eq1;?hU z#XEp+WC7@^6Xp{EFg+76l7g^M9>;q5|H+X)u{ERge|{67&T1)A5kN8gyFUfYa^U6L zKQ8noAarVOe~{z>kQfiB1IRb#{)1B#fQ|PsGAa=TBOS`=0i@|daw@kMg*Od8)h+G$rKP1$ z&xm?@db%v!T0Q}w>fBwXW0M)`@?lZ}Rr4}&?deArVpUkZ`y4oEe?5uMWOJ@PUL{Ih z3d{0x35ofPHGH6P?z2}eXc>Q{{^#Y%wkqx9{J5fXQpBr%8e`wQ4lc*HIo+r8YdlU0-UVZ}|r zh)JMrTw(`v;`)e zA7{@zWb1-{|W=A{`z!s2Ye08{h*H_6FPkHsLTcfxdy76+gTifR2)gQ2IaE z*uLWYEb7ff4L(dRG>cvX&{u;AK*NyawFhyq@;u;B38$Vxk9Hk2moTXJpH*)>+gHSc z#lk!@HE6qyW`0w8De7ds7XYXCG&~^heFh@@fHO~A=m-@#;=|T`08x;am$wEuT@4=B zv#ze@ziKc~db97XfBjlMnW}$CHr((TZz8=?rti{l4#4P%NO!8uiP{483i&1s0?UZ@ zOCOIgvIZop0q;fy>`SdUBD#u$x7tqYz>y)hK!Dz#6@^Ji%Q{%@mX>_r7toV^vC&|d zZePAiRX|iS&E#vBsh6rN4_VTC7knVBUE-Pupu{N7CCBxxTDfj&p6M@fNtd*+ESuSu zA^e?-gm>QS`zyfo3kgxt%KmH zby+hS&(@hCq7f?XR=1WgBgfXDLwwr+Pt>t8oM_R@b;8P)$0Q-LblL9~CF0p^l&|XVJWCgf$LveP|8!sxVQ$!hYQ{u!drqt7} z_>SmCtIhjfK{b4UE{ahx{;ZNZ|-RYeTULX>1%5Am#ftza&#ER zu`vzyKfeF8iTy*}4dK-^669f8RqJ_;cg_^i*n#hsMWUzg->eHILk{OgCpCRelMwp z8vmfJS=qAG&NmFW{tp3A4GF?o8q+>^{lFd3bZ(ezsFq-gn_WBKf0#2bKm8>XTHLYKvNr(0#5o!+=LAo9 zFieQ+gG9-l*bOJkukdkiA_Yt z@v@l&U=&(ohyG{u|8y&pTJ$ybV{Av;l7HZTzHn0mEpq2OJj%*k*t% zC+{;5wm-}`fEZgQqd?(J32=rdx1r+?wEjtB6Cn2zbie_}8};o+-`vmUiR2D@bwY9r zzMrzO2XB8m-fC~31Fyfw^u)8n;jrI?`n8HJ2nY!BAQP90e&E9(oAD)uOf6 z*w1+Zk_@*=p;w5j-9+d@}Nf z_W!TLC#in_v%UXc0N)X=qyT^2|9-saOzsk#m6LHHfd}|cBp@|q?Ryo9wom^Bzg
    W?8 zBE6^>iV%8NDTdxV_?^V}o%v?wTk~tytXcCb+~w@E&p!KH`?~hcbA4TnQw--AAP~qY zEzKJS5D4u(2!!S|9WA)S@Uf;6{Lpw9XsANocW{!y1=K-BM+E{Q#GKf-JqoVjcQp-k zAP_%62qY*J0@($(f__6FUY8+|SsMuCS`q|u=3!dZ?duQ-uaVXb6{E-23vZM#oEp2~ z8^2CEd^qx=v|acrBZscdC4-BMwrQLL&%5jyj;3CWR|#glyQqA%?3u!8h63eax#nXx z|2cA88%k8a`C3wV#O6rYZp}=h=#WC`sDi>l?reVUGusOAQ>bo#>rBK-7X~6C}e$tTGZp~iG{t7jnIT*LKa*cjc{h7p}1S^Ru z%v9vE<2l+R^l8C*|LG;*Jf+dThj+zY|7=XXiY?*}-hb!I2 z>jLZe0?a*Y4>pJYt9OvNYLOp!`GC1^y;X&svL#x}$uVNsM4=$mrB441cHl*-teeO| z<@qWTtmyPM9GkC4&l#jF4z}aW?P^-D=K>B`=a)7nSm)QdqjF$3J@ng0?5)s)sdc3M z9FK^&gsG8G0#on-@On=Q(V=RE#xHwLZm%ESZKdr}N1O?|#mYPo2SI-ns)yy93SkXy z9C%=Ar{1%PjhgQ2Ej^zek+_MN5sZ3DH?IdFjAYn8V$Wkms%wt_E?m;4><1m*6u~t=(kv_+n3Dp#*QBcsla~XD>Vau&RD@%F5565oe_V!U%F#u^ zgHX{yCVp(qFoGreWNC?Ih@=Zb9YU~-^t`zM$6}^nO)P}};pPo?w4w=Zl zM_c`4xL89&V{38r$@cOOOqZv(cSSk&WJf$K3KdPqYFr{vY>c?_^!@(QkQdr%jO)S$ zw}qt!@&2-lj7&@mWRT?<3QuGjKgbVT+_sBdbJ7fCeBk=wpxIK-D8C=qb(HtT6!XQV z7Dr6^0rBL@m%ANDtl~^! za*6qB?YCZTtV@_2A;_^`q4%os-!YKgc(*D-7G9Y3D>oBhBeAkA=eOU+DS456jOwQ% zq5_)TnGRxK&o=8? zf&{2Nv^CTB5Lwzt;}$EcEfO**n3lf@Bi|Dlz0HWqwR1F+9C+j7X4qY*JM$ zl-X%`{kVc!;jQ$FOM%wv36;VeE9QMU(rOEBIjE}o>Eo8dc6s;N*3XC74Un$y6wKmz z#PvE!NK?-Rm2Ha;#v-l ziKp6s-5-g@zfR<@FtfTV{nT@#>_H?>Bi;0EUcv*v0Bw1NiyJe(LYeJ9FsSIHG^18* zy)xm!qOspk)KLWmQk1if6SB*M@W41e+wATGlfccz=yV~hPSJyko$yy_TKP@(YWRKo z>ez2GVJ0o>(b-$mzPxojsj#bDall#PyY$te=>F!cgpj*wioQ$8y{l zUr2XU<>Gv-y8Q?O*u#4%)8Q}V`s*_op5zLk<lvKvqI5!)11>jP zWcQbwv)v#JsdtlY^U6IF^HP#bL4V0^^{0(f{7?NB*@@AWwBn*%q#N}}W3TV|26erU zfAuU$brXM}ljlDr1cQB)qU_@X^4o~oN;0WzB+cGJsVT2o)@ zgyH2vEs=s$t)o`AeeP+?TFgjVv~(Z1(7TA%ff zoU`U8xte=_XqP##n5<4r!XnKBvtgmrSrv9g(m zb6I!9c`Iz6u-wjs)25=6C%+%xaU^4>6F0P4sug~9(45L!!p?S4_=V z)g$!_d3zrB{eGq@CiDbVJiQTL>r=fUos7w-vSHB0R;`@?;$^1yl?BY+;1*A%=Mgwlnuunq#8l~sFv z=r}z1u_}DBm5GTwviU?o1;IibQ;}2w)r=OC^ferUPS&}I^~m-n^la5CKHc?{8+$5t zN^6;1`uf)##xDAHLoNZzOe9P)yf-aJDF*DLetQ1;{L-HmgPLYNaXq-+7d&P7a6Vh|1Q$i=JonEG)#R%NZRL?XZ>`$kUc(y?J{+Cw<^TWDtxAsQ9 zKsHNu&%YJF4NCQGzTvK-$Y%FU=1qp#f-EQ@jZOSB&t-bB8?Y!l4!kDfc;1Av&Ku!2 z%+xI#i4(!}U=V8~qQyuI{V@*e%}>+LW!miS+BgtVe+UA9z`^eD4?BVLLxJc1wZocw zi@*;L*3XL2O|Y89&f=>lj4`;{hsxv7PliJs=D?Mb55l2MY%o9;Px`T;eF1&5suQyM zR`uY^d?McPOrDYdo+>9A-YfOUgK0C+B8dBK0NS3HT_)k*5Z~ zK>KI=ixM{ZDo4fY*pnr@-@THTp6)GF);ueIK$u_PKKd_WyvM4H*mA%erIJ!QT?pYM zw@uY?D$V`-DCtdDu3pA__e-fozvOt-BM%m4jps zsvmRdL$w6-k;8_JR}x4p^y}{DStli8!yv4;jH2ctfrMVX{qvWDQ-TWQiv9V)(z*VkPf_`| zrdkt3O}(%5&Mmw@Cd@=bcSC@>P`Mw;xITw&B{9)31M_zpViz{v?H!U5|HNN2N0gr( zHO_xf;aJL1&5w2ZD$pCskUMqPgUgZ6!1+`A(Z7koO!w)O{68os3u9G*AFpqi5z6>P z)O+4EHK`%9mbN8E9T&ea(i`N}dad>8AomLz{C=`;?Wqjy#ZG!>C)rLVO z(~p)_5EXjwIf{{C?jfN^?x&(C(UlNi6szXeEn|F{%OlURP%)Kg2uubELxX2QrjZmV z9)>z#+wIUp;Vy-UrvbuU-K;Nghqqd3%LV#Ymh`u@qWo@GNmCsg_yzL4y0tLx1d z`Sniz3Vv6X20{^*1Bno{93~Umsu9aBMYe?1O8 z66Z~g9Nz!Jc4pv8>wRWM1{E;)U6eA4(8d#e!r`s9a4OME9OE$-y_Z2&wSXH^zL zqAdor>@50U1t!KD$mofd@1`y9J+p5P1-T19LODdoX$WmLuYS@}vabB^0n$yKDBZlA z^OTy=s5s?;1OfEN>EgF8lp6#(keMjkx3W~_S}X{ntg|asey~m^^%vdgyvJDzHct~+ zHuAIQaF=G9?*U@_PL1D{;>#_R^MirVD<(t&UDXyywVxEJ{Cc=}H$wF(-eRkcn-^<% zie;WExs_j|$r(fMHs>6+?T-5UqOsK>U2E?x+0u5bO}p~@ZOER8>zcU=;jSAiY| z=cCqRro*I{zah7RMOFCUU$RC9~KCwN$&?W{{ZfrnBa| zI@x;XaP^Fs@`f2ceQv1SIq+~Tqh->kZf}%Kc8sFY7N@LrQaKaQaAhYI{P^2dFYA<; zLxJ(SQ)aCjOM!p();g8?vGW%Wmm@kA_vSw>)e>zV{5V3{hRaZG7*hDooYKv*?>%p> zk^H5h8|_E7md5+Lce-&%AbWLZ*7&zWlQTS_v@clT4MIK1Q|MoUGvOViuai>rigFQ5 z^{dAL@cj$J zlc)TfshFw`1Ca6p#V*JF=o|$Yu)tG0Y}q3Qa6tjiAQU@Cg=?h>C^se4 zF2Czh8nu`$B2s|#F^KN;e+MUwXi!+7ly;otXEoalulU5^mju3o)s#n<3~`1pKI3zx0XEvEFXDqWMX zZW$AM>O|_DUatHhP(Lhh`Ta^X0&+Mv{detHPqsn;d3pIe?6--hW0rA@PNB}xvKFUu z4=s5>q^&-`O+RN~v8XEfekPUO(lpF&TyHXUf9nas+U}9u%GK1bob-yL@Fog0u(re7 zqJ-dK%OQF(ey%vJ-0<2g4QD-(I45#|$OCe>U01?bb|NC9&uGtyNY>VQf_IRRFEaJh zN*NkyDGwd??d{Ds(NP!_snprS`?!mXd0Q;LoI&c){pArdI=wgQolAP|it2dWo{~3+ zo}QA&V@=aU@Toe42ML7JZ*p&bip2H5(SoNgetdrK;oMDEB*Nu5p}=we%e*s+5XEuH z&-iq3PPSG+bz#cpWzsjvjaJb*BhkVi-FcS^5n^TU-+84o3FpF)l|PNM&S`6y6|#3) zq=U>jWst_D4XU|zUZy+9P8gy!>C*Fv&U1wdem~{M+SXa!+{^>a(fGvduqwR9+^fmH zFcPv5ml`(6+)dk`k|z&zCc8Q@TTj_bL(kteFVS=S@WXSH5Z6jn1^YBt6Qn)Pt=u z>D!z!v6N9GwXhO}`%@a9H;6eG`vlLE=yoZ^f?ghkQatr=hL!KS1OS#Q4OJ9@zagSB z=p?;#rJjSAI6cav)H7DvsK~kSQ*BD;6ZziP7Cjb;w9Kg2p#R0|pYlFB$kQ&lsCXs4 zaO*a!-JGT2B!5P`GiF|H=Dy{m`C*ilsu*2?D!c&oUN!C}4+V+f`~Zh+Q2+UClTMu_ zr1?VL+onS^uDl}&LcdWN7FsJrZ;BkAmSudfGsgkCUEo#Yn z#R_cZ-aonAa)&vk_VEMfQ!xKyLD_Ur__FA~%NDmLpZNaLYQIIUxRc{%A~fSwSFRy* zQUbMh*?pBlzQEN!X?uY@aJyRPEj>4U{4)=8c+eP3Pgl3m(_tqXV9O~4mb@pk@l@2` zcVN{coSjFXH~2Ucw`Gmr#_AN&XK_U3ipGu01*mA7*MV$Bh}1gqfqlu+{ev%RfTvo~ zid$EISEcRcWI5XG4lV1=ldiNq;DeD(<5Cm>2R0AAf0j0kdB8{qK)gaJ;$HLObWV$; zOVe&=dxpjC#4{!XZe~472|CHM+-Kpouo+-vMlKd5);nOo&8;wT%+|ZleJd%ExaGqG z36_9*y5rZ7Z_rMrCT>aQ&d~$|9j@k*Z2djcX_7$iWLru0_7730Bs}P5^a-%-oDt8= zDWOz_ZSTxvm}xAsnl-y$@JsF!Xb>XRPq0J#_%fG7$Yag|4H3|cjqn+5v9(i*qQSXl zbf<3xxlxcq14b(Tk56hLqN3z`B>*=SFkj^4Eb zG5W{~xc)^T@xRyq@V17Qb*z0WA!8S%|MbZ8gEp)2^zyR4L2ja@vX4KxGb@X4^tJ@s zcdxN-lK7xathGWS?`+qmT|05a+S&J?=JRy-w7|)<*E*le%X(kym%XW2T&-J}vx!!b zwz#2$<5=H<$@8~Mxs85r8`+Vvwlv&mF?XZi=b?hUpb-L<6q4fKE`YtXCd8YXGv+0& z&u?#k5XKIfxJ0IX%XXgoDf!$^^6l){uZ7jQI?Bquj_&uLx|-F??BrwB6|UFjzA&R)4cw~92mBSv>m<#XYu zfb?jo2oy0@bW8<)g4Wg)i?L(>l`kkH!*oV=N%OOR{O^so=@)&k2yAa-Zf_lA@R*WXqb#bX+}G(C`B;U}vCCiImS^5+`EP8@F7T%wXu6!_lu5i;qR@;ydEi|^n`-R_{E z*0itEXHV;pPM~KmDEKu?97?a$GeFTS6L0c zlP>8e_}%U1u^@zxt(je+2L{%)3tu;XT)MrnhIOd(QqsEPJ0)l zh#bF58sBa(<_=q9G?NOPL)o`4n%2M3{?_j zYErV6g~Npr_cIfDoB9@{=@tKrxI!}unx1)pG5rX+?#Sz6!u%4p!CCN=m1W*41~4B zu0X*A5ZYi$F4s$BIa8TYF;IQ(wi8HcjgU@QyyFp|^#LT1lkEy@t1Uo7Y4GJ495?{7 zl-?3WOx@e1gd(Wk=x+i4@4_80!!oKxNH8As*bHB{ePyIq+jUV(6E5p^! z?ev=7dAd#9*yz8L$RSxx*=tBJj^2m|tMf7*HQR}k5Fh5IS0t|HT%o%G|J#L|^>#Uz z%nLexp_P|*A;ETk&wuUK*po9(HD#@BkLF93q{@!b&_RX3{F@nn_Gju2H;T^7x>{C0 zUg;~eh`FG|$gTCSE@&wWDA3Ob$Yk=f<4mzmihk=D# z?__l!e}mBUJ)9|XQrzE7^!Bt6MHY&e%jT=kq}_G9G7RctczQUGKH_ig)i&e~$i4VQ zF;&7x#o;#Bf*;J3MWQLYhUN>QK7_yG0(|z8bnh?ctUjrXcHA^!o$y7D~$ diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/hash_ranged_hash_range_hashing_fns.png b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/hash_ranged_hash_range_hashing_fns.png deleted file mode 100644 index 5e0d7f4037b6c0b0c02b62c90dc0ab7c2b2f3e15..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 19773 zcmeGEWn5J27dH+M-pXcrK?%~Zjv)%jJ>sr@$^;$bhTT__`pB5hife@*xDCj~USNI?h zoCQ26xWbu1fdK!(ann_ngM8?tUjsj2HnJMB5J-6(!I}A0@SE9EMOOm?@#TO(g2Nz? z6L2Z`Cj{al2!X7dK_C*ZAP_3&%z7Ou2;^>qs)Fo&ZCf0cP^@ zo6HDUYm_BT<4>4u7*%d6Vs4KgN*Z4wXh>MV0>?+n3rvT>4L!}|d`X{CH`+o&40_(M z5I(cYvlWSk**&TxvBERyIYd9o&Rml@eC?){C9%IM9=)3qlctbJo|PuPEF?OnELm(n}zla(r9S&NZ< zaT*+V3fGNavkl-cGo`$u!fiEmT%4i0riMzoF7RA}&#qsxQZ_r_VA7_G(3AO}m#C)6IrgZCAd#(OhvJI&U6I6DVFfBusbpO7Jfmd!|M^@FjJm4iN(0hCCv6_QW# z`f|bU`e-c$mODWg{(7ZPr!0AeC;$BUgRz{f`{x{bG*Aqpx6MyW(;#ZkHmRnYC$6PT zXbD*zZqF;nn}^bMBHFyfuq2e@6}DLWoBmPglNlc;u;OO4Oz;@FfcIi*+$5# zW6!O{8a85{;j;U|6JEB{d1L9~B2YS`k}LAh&p|dJwx9uwbL27-m~;&Is)zc3#6^ge2! zRvY|+UNIk%!crCzEYXw39I_AdW=*_*Pnsa1n2*Eh>$kNePOULXYl46HhfWTbaMU>? zHi6<)x9ln)zZbwPgUs2qw59!z;x#O|jk2pVCeosS=j4J;~ zzBDi~p$WE!q5#`_5T?Uv&D`?DOM!5o+xn-ZajKMV%k%Y_(MQ9_KUA>GtOFnw^St&Y zi-Pns>fOVIl17k6`}OG}dpy|y_HsO+>t$m$!55~;U@O_$k^AQ%`Ko;chxACB25=}L zGl12u(a#Qe?*>1=&a15Fqf4UOgPCX@?q0+q&_4len1&_fl8q$gxBcuyY^{QYpqhpResy29Z?N8#OpEn|CVJA{FOx| zU@{OKeR!PgPaPwl;WZy{+c=(H6^ba#0^)ptw=u5<)p{+pD79(L!obMLNKaq6A}v9v zv%k`tkt$$1SL<@+FhS2e|D)fvrv1f8CfvaYJ^9GN#O%hlrp547EdSR43x;W?P z5p>VnLl26eRs`aRpBl5lLZZ3z;cGVhwRYQ6HA*rGuFbJ%35=2b<{0}VKIM*;Y)DZX zesuYYS`IxpP*;omd>wcthqPXcgGS?`SSW6 zN&=3*$Kvxwro^pyl*2bmKFSAch6dqc+P6&thw#S>3!#75zVD4#Y-Xb-Mf`^Y5drm*L#vG=mF^n&OM&lmP5H zfIg)w^Bmv4AM!s7-wt7JZgYZZmk0OWfX}>>kPXLg@}O4LJ+d*FsCes!2~TuX1M_ zn`;CtGX}53ZF&J?hDfv{^A|U{>PWcc?0K*9XeH1hjBR<{37_IFhS$pWGP@t)8B{~{ zn}3bt-oH)hO!f8q1TIE##gj(TpT(}Gxw(H$*MIM1e}jm354(4Fu=gRh!t)<^WqT`B zbNE)#yXNNPI*2c7ogU!|RJx9vmN0r%g?)h?bMi-9tCe!?XU-9~WsYsc-f=yv*1q+^ z?|5&fNqB=c>_+Kgc5ae0bf_@;?QB;UT-pCS+fvv1)hN~0(&Zo3N;fOZVQQQ?#5{MN zPRTrlNP3`=v@Y^~8mj#{gox7^A?ur@;&Sf5IFYiO|9Rr^!QokgvGnE}VuG*AL#kYp zvA6ekpo;DAT!E9u-QSHAr&%KYO5GWv+3Hx9&{``l~`p_+H60%{%RV z6S$QoFiJkb!U7yP*~t&pZ%y7ylJzV98eJu>D{Iw^ejWWOKcI?u<6ztC%{qPdCt@}l zr3j1zNuvF%d2%k-rD0nj{-ZnZlUiGylWgm(A6a z9YiW3`&Cqajja(UX&+)d(DAkb3=zxcTNZG4baq#MdJn}xT0zXL8Z$evDr!@)RmhMx z8$xekR81eQxrS6}>PdC^v4pRVnFQ!%5nHm~w5mXd6C&PAPB#o2bz;hNFh-tli70sL zJ-RM#Sp9rF=0EX3c3ars>u`8?ax-%*dq^#y%f)BP=o3t;-p0()g5e}g4CNZm@Y8(S z;N(nW;t3P|b-MM*PKvojo0^J?hZ+3a6rww9-L0A*;}HaOXARPA1oilj5vDB7&)iqi za78D2(;wd5Om9=oA;n4uv?L=tGWiAb7-C@~v&7IL!+12fcc1Hu70&lyDoZBU8Sj}6 zCzzy;Wd#G>nNMSKlUK}@!2ozN@QC!(-d4KZz`4D49a%f67qHG7e=Zm3^2g#NFZN1F z)ucES_LP*x%<^)0-;e~BGv2kPVY%Pf~4K@)A3Wnu* z4v*FKKE+pe3aoS29@SEgKP75ayP1Iheq)C8P1yCi>Kq?pzK{;^ByBc?sE+CUW=qtj z+~C27q>CSZWPYy$B_C{-u7}MYIx_!I&w43PJwxHkf8?&fe$a9Q`JP8*HL$4KncpUg z(XIk^gBj>9=4bVS&miGbyQD;mXKSBkS1-gn^CxNlJP2^1iGE837hK{!eJ8lFCT1TF@_DeFeA-RKP4{l9!O66Mm@1K{SRL65D=~#pT6536k-8=1nyH zVgiM(UYkV%%5^fom?Wc+uH>^f?hlUem$11u<|XZ z@D_{kbS;Ahs{~rv2)(?E@O)o_EJ%753lPo-*}=C4cve+fGLAjh^}W&;d7n6q*gX-E z7IkgS_=JKSw~P8yvJRR^dEZ>NbzV0O%PVf3gx{+d!n#!wJ>moSAsBab@SJIS&ke%$ zGED2uc4~x~O1}2?mIdiJ_Z>H&RUQM@gE%-8)`|7R<)glVxz#)8kwLZ8EljFl(!?4F2#l%(NPA{1ESb`UBeXT1PVyd%g+SL+2qk$@UW8hY!d&*CO zIuUH!EsD^RBj#SY2zd7%rbnh7DK2lwLh^~i@Q>%yY-F31vMaRt>XSz@lmrPh{8v9p z#+XXH8-}{IvUIZmi@~X9C=r8tlK=3X&#fP`lrCAMzX**Z&;2L$>N#a1KXU5d4&CtN z4xt4yWB=@pG$Asl6-}U4RZpp-M>K)2#KF5PpO8_f^&$4%HUC)GTfTD-Zi79}{uyl$ zAX$jpAsm155g#$X;csgFD6!+AV(`9nEcFe=8Nn)aUXRUb`mP!@4Vc|W2)teu+2CFD z(VW^%-Ezya!HjFP&qbP9+9tPEI54~hdEcCDpRTW)0mgqWbVN(ze5w>PEya|6_%d?G zgZbv~-Ux!zd36l_;&5$-;!ML04xlH*YU@4WI6LN6?Fw$(IBLPVA@{`6$QG_g<$tSG zVzE?Q=AzzuOAA)Cmn&im#Y4Y!zsjLLOPnsRe)~pK8J@&Yy@k3K>(~Bg-~{r_Y}KGp zevJ>on{TY1(uld>F$x#u;KDZEOEo_HMutl!zp{lugK%nv&@Q&+{PZv`E-u5(FRP6_ z$D+!?m`BDm5v6hSeOD^`YM5mzi0AYI3HQyAIL#3Ls|8XF;&GI=CI&cCx1aL~M$!w( z0HV$;-YD*p6>gq7N(jDgwA2~mRDG9}SsE#!hdlMq^w{mC^y3GVVRFpu?1iCYHzgv6 z@M{KF#-tcn5=g(XQ@%&{wng3U_b(q$1ZSuAJf&I*X{Lq=wKHV>-k4rg{MD&6O~SOy zXoaykYJaW!YJ!Bj3s4^I;deuSkO;Dmxd?NT+Nkx8sn5#QecB(Jg(SyTR`$53;y_Dc#S zv3Oa%>q?ULt~HR&42sgMRn43~mLEjX8lau8bhl>gwf>ogEGeX}7 zP|62io`~y|_dag*KVFo4*&7|DmlPrD+8MIEk)Am#aqb3P7hILyfTj1sN1HYZW9?=& zdlx;WN-V9{6%_y@p9yZgzYit4k!U??W8hX<#7nB4^w_$fJ3Yye4nz&S61tMSaS$GN z#|ayGcb@_$tMYfePGOHjGH4Bw39T{^Sp;`EB70tfJI6b1^$nrV1mB_wuAMHht@>nV zW#wPpw9SJvrw*FuIq@7s{P{lT)d5bDxjZSZ*?j zjL%Nks*ifPXMGm0+DBpWCMLgllmX!Vqjq(NRd(%j(~57MJGN0m`eS`H383Fs(KXK4Lh#ZM~B+r9&MJSRxQeaDPadr=xj z&c;p?diRxNPEvfVsLJZ3Q=LXXTQ|QFMeI5h6g%jM5tiWXLhwrs5+I zFYUf@-{ku__r*iw^q-jR_LCX!3r1|k3k9U8Me}{nd00dY37 zZAvv#i&6agfkDttcI{$o)iBQlvg`?!<-HfYmvQm@)NDaSK-WJF4T>pLB*Ff@c z(q?!Bj?=~2zIlcJO&dC4DSfu4_!`Iu;mzl!V&l)}jXx-rARv#@-CRrhKB4OVdXQdO zMM)VqVsvIta%?`}aMthem!gM-yUlvpU}s~lKVa^TW#P3VJfN&;*{A0!UWz$h{eh&f zrp%Z7F6Kt6l6l>dFOj0ltf-k% zXIb@hTW+>Cyc>K=Fu6?V>ku{KzW(KRh6v5<>wX8DG|hT;jh^IitAE8ZPYUX9qfPO2 zhPo(P5wmKb@~QHuns`3lM1<6~B2h2HWL(&3|Irn&H=-P$XxIgi3hrdT*~v+B2dQto zIJ7$^BPTWr_s!Bt$;6gPR`Ez4QKlQUwPsWHtdBL0&HwA-)iXsxcwXk-hs|e68Hg)4 z-9%EcU#w+EQ@x=6>h9O|vSm!q?NX-V^Wev}x<2Kt^k|e@^Qv1&r766T9YxD_zqZzM ziuYfz9a4Wo#O&)bXkf2Q4qhYpnR~Y8yuxS0>$fq`o=EJ*xb3X=n&a?=l5*JWgoplWbcQ<&J;t^Iz>r%DorDG1_*i0Gh3}J*o0EVoJH@|{BSV>Eiu>gsnT=9L)xzPca^!19HQbS z@}zrtIOGl9iQRQObo;iGpx9R}Hm|VVXbjZ{c}DTu$TDOI?jeLPs-dvli06C!$NS1U zWU`h#AVw>eYN<~Z2R3pA$8bz)N1oSNz(M}wU>8}1RkowpwL}yL&;)5Pxm&bY4@UTR z+sqUDXmn^lJ7LDv>i3yId{v%Eq72gN_rQz7wC1eq%7TZlUUeY7CthM+6k4HsqHa$0np;!+jio9x894pB z&|I1rgm$C|?a}8aHO@;G1k%LBwL}?gfFS-QiA)MWz20Ky@T;b#rs3gXsmIY46jibB z=p{+paU~O4biwlK30@E3XMoxspRyFxZ1@*mx@u48M9veieEpANuR5SWmKk%UHjDQc z6d4tmX;uuBe0qdR&=El7X@14t2tftETa=O<>MBctB!y*d?q?m#FY0}(`QR~+izs{r zcJh5;-4F-ne-{(Xylid}u)LD+vM1=0xXUuouH6EV5S{B~21hN7l^F4V6C;Zt$$3sq zvFf19H%3T@@S47lwZQ?;JOmw}UcY7*bI&mvBejlrQa(FNi*1pUuWogbybovL*)X!p zg0*L4U{ixan-W<>VC$l}Ty60ZqMHqOnqN#7yi^7HGttbG1pZJqC&7NLLxwU$g8VLn zy^!ABt#>Y9za5;xzXU+sQ0)xCr+-ax$No-ogU;sf-|<=ISD%hs!F#~Di4y2ZzHC83 zpFCj1`(_;g-Q<4T85osOEJh9Kjwyg42e7cB!NLmIZFWBAO(A%4t%*=k{5Tt=86A~sJ^4baVCbUU=R;H0qVX*cU@Aqd z%WiYk{fHZs_4I4>DJ}Vc)0%{EUe(~c9R~*o*wv0ayj*ec-L$7j;tTNY!l~v$Hn*jP4Ii3 zpLo2^duT61ITbC#_iL^xBb1)LuQ%mCbHWp1O0tkplb6TlqQXpxgRuN5IHVJ`N^w1l zxf#tU(oDybd@u|J2Thzo3;}S= zj{D0QA*R)mWRgj?ONuA{KAtWkFX9Gk9D^MujH9oqSGngkdpv+F?@i~(q!u6O62jX` zmml#e4r2dehT1+#Q65HinJGlM@w!vsy^f$0sn4cL1#dg~>$z!=07w5ILmgHyJ8w-@ z<$FG`S!`B%%i6+mQihJ=V2caq_>si|vJX4q2Nu&bYO&9~ItB1`3F~gYw25U4(FH-b zT1=+rxI(ayI!1GBDdCfqX0V9b4%$}8ox-l9q=e5TY~%Xn@9WLSy-uE&gxL|w%!B4B zZ#tzurt8y#ce}6*FW|$EI<3NG`Fh!5dbJlj0+%~}^QR_mL{QmuWVIfDXLIe#B2PaBFE7tqrc}s;&zZg^5ja2snG}N)>Q1FdK z-n+$R0PUAlxA;E91-}azry6#><62`;S3bOhz*7GrT~uEs*q_><9G_u0e+cil@bZ^d z%6uP869SzGFsgbI%NG(0Ic=L@=OBUeYPQ_C5gm!Tk`Bze!;Kk<3;~>)^;Noz6yCg8 z1_=y%-2MY70XQ>0dPrm{iWzl>Q_Vq59@>rgosjV8SkgBXz?2BrIQ15LFmc8YSj*j} zQ4B9!TR7Xd#2~#u2T_;=G*4gc`hzIg!Qr8nrlwlu!;E5<7FFf@6dyVm7!ptyV1?ta zDg;I>3;Jd}34Ie53}~n6CSeV8UOXOcw&Q#<=VqB9HFysP45Zs=aU1yqRX0}r9rarP)766 zq4hylPaH&YZ}RP{Y-2-YNIKx1ee8!%6v{2(x!>jVl0E~c%Erb<#OJL5qB9#{@sirk z+z58Y@5nPZ>D_I<>!`J4BT8xa43-WYZwJ;M2?G+Wu6as0HX?y{RQrU%WhDBqtEjKJ z05s2Sr#Z}w>TGvh@bbn^bQGnCEGUjCyz=06!2vUc?z@> zK7L9;wcG;u`~AC&!fF536==gFN4%=FkQXOi@3yLW;c0I! z0u!4^{-IIqqO6S6CIKvz{X8@hfft|Yy}$lIo_J&Z4NS^15Y%_(u;KOa;`p&6T)X#W z`iIH%cjh9bX5xt1{vj(3&9!LQe~hNY`DUl9g5k^F_hf-O_S+;~$c0K`V1__9It1YU z4624bnXOk;edpLaTxO5=%D;poSwa{1u;?hA;S~-%bbnElpv}VD4ANV8PdO^p!N#9# z?n}8rWzN^MChwd#U!FFnO&9qnk~v>({Q29?|0+NQ1x$wuTm5uYX;JJV`s|YdV+GJx zgxcLks3`AU-JWYI51p@dvE1aVE(N?b+K4VS3pFtp}9KV`6K% z=Bu1eWDL9BBfmptJsQ2N8_@ul7;n4BG%(;oh8VJH?Eh-m-btr=Sjg_GFZO%kbLe&H zqnu04PCFMDs_dbHhG@p8{p6F^AKN7De!2qJ5_*GRfX%9qF?xz2k{z>-k0Zx z4PH+b2)^_FeEXZ&p1ZL4cONKN+B$1Sdc=f|5IpBY)6JRZ48WPfbL+19$z7h$MV#7p z55du*m_0oEAO`Rbk1sj`JFLNbYo!#4Pvs!F-hD+Mm>VS?le_C`YyNy&cF}1pYwf}C zCYyhy?dfGB(+GttUuUVaz;i)l%hPHC3Eswqtel=kLpJBbU$gJDva46BF4UNB1DTm& zeRD^IpT44Ip6B@$ASkXSVmZ^JlP zjK+diXVff$Fw9eOlzcOcJLZk@Y8XGx#!}*9$FUgK)qjM*d4x|iB^b8yZ>(FbnPaNX z>UfNAv=Vx<=pn<@Au0PNTvS#r+^dy>*6T6hBg6N(p1BUeBIao|1_g%f}*Zhvwa3l-3V2M1mIuT&FY@lN^NOC?*VBm7}zy| ze_vztkCCZv&MBiL`;Chm?N3}99u{fj6@d{ea;9en&q5i)533Ha>w-bZDh!= z{K(Sw&rUhp+%eBhcCaNuI4)*CtaRUUwJ2M!Js;MRS-$V&6){Sx(Nq`(#HYY^U0oF> zG3uccdG)w`tbCw=XXcwE3mIjg=gYkY!_r06TjsUa;Z(*S#zUE}hR2$k?hqfmc7vUQ z6BGp+d^#-sP{m9lghB#y&sx^WL#UXpvb60)nb9NW^eg2)L7V37X+|}qv%kOp<;6LI zZ`>OGpBH)$nz2?^*6Gd9G&XM^VVf5t!8=?iU`{!`3rhXV+)CBFay$u|ClL!5t9mb z?K^<$`z&Lh@50^tr6P#-9hdMe2p)|w+@9PTzAkxK*ZM(VZdJsmbRamt>$jbEh5D;M zPlG(09^uPXtRP!n3wlQMia!kiwf-ak4UWZKYixOa67id>%TYeh9Ptxe%_RJ%297lQ zTqg13y}kz)3lv&S3823CJEdiEa`M-&4}ze~+5-%f(DnEgRWl+S(ap=FuQC^t{ec|Z zaCcbX$#C|?WcGPlzlsDqGF}D{eQ|S04vt}I>FULxqCmM9lq;WO{SJOBTHcUd*hFkE z{s?d`6z<&#A&O<+VyxI&a2!zGH}lYjssjr66z5#nNs@vyLM(=QYD}u%6a6_x(dJ zsymq#R~g1Ak_eb|8f%IfspjCz%k>tngtJ-nOyp?l@K)C>_FQ5?eOuM*4_}kWJZAN- zf#Cv5h+3`K;7eL9qg{6`$YbxI7{l{qWKMpv5z7Az%OgITq}U|d&hdLnD0jtJs^C16 zJWqC9ER+75q*O8KlU0V12esiYZK&C2Swyp4M6;g>XC-IXhynHsdWF(-(sll(UaRq> zf-W+XV5C-$>$1{nW_|8`=KrXs!dj{Gu1z9tW`~1-l(s5+YD+LKescug@FdyUiTY`_YzJVfQu)QRVh{BELSV`h?!;K0 z5K2Iw;j@p@qRRhxpDQ!`!;4RnC^w=4_Q^cw-!%>d&DJmBUKP?!Uq>SfLD-5(*Is`H z`-Ez_^;$iR#Hyq$4?jCtMa2qXhS(UI@B7I#KF;g(Mz>YsePbh+ zS}Pe)Jn5TQenaVgm9Ff|H*gxjokL zg9Fi*Go{829S$bWTbr9bkg)PQ5x&UVS8JUA?tMQ+O<6;{>Q#f1P24D+Mi!&e-a_D z+HNKzP9WUQ`QTk$erjVoIU2C_YdK4sRc7QZdO#x*=yiS&V!BzV~cu(KEWjj=$aGiyUyj6?;1|LkxX{l60b)Um$A7~=BE4rS7WTSbDMRA_13&B z`(IW@;PLJpA-}~vQaC8=^%_ASl2}yYUQ&1Wx>LW8R_5(rZaXpR)i%pT1zn>5AdYP- zVC&dYhU6z-PN3&H>B4_0V#mRA+e?`~I`T72Q{==&& zrfT2-^nLjQpKZ6i$_Boq9z1KvOWtSCWbc%)WsA{ay*Lst_VVP%b|>KjMNa<0lQm=q zuk6ul2aX1VXI5=vce6^jL?a{R$7$`ZV9g1r28k0P2l#Q;y%o7xTw<9C5_pOE_sy&Y zBmAjFk<+;2zvzeDKra(5=vEO9oZ|~=g=_DzJUQoEqUwIyO?iXhrgm zpzUi z<}^cAsnmY$LN^JsXo)9ZH1G+KZ41kTo*)ogh^D;SV%NTf6GrZnP9$YzDg9M>C54b6 z)@o-H>D&?xm5<~*6cS~U!Sw;>R zt-Hja4>ceYlay>Ydb{{QjkWD7QlM4iYyk;ZbTuPXD-evdw>Rh)jY&ea0ZtHIGaY9y zON6Y4V9@%6y!4drMdW!j%Dy(SZYNiAuP}tsv48gT^z01r=~+hEiYB2dz(c(eCSTdh zUPGq4ib@8u0>UQbT(cU89!0F6=f{WmxRSpm!72<%HAe~AKhH$T@YqYHqC~)B*Z>+S zNQD!dySZ-gu;)hkN%bUKid&kWM>E%3@f5s-hj;=K{p-9Td)^E>P{c$q@Efn#&asB9 z;FVn=OdxfY!f1Z{v>ZhSwtF!fVP9{=x2^2k`KG5X-=V|U-z@f28(9vQf9g*Z7N5{!R=yls( zt%!y_Q7f{#CW<@XXQ!T*im4wEK#?s!`Lf%DBNIPn!I1G}KsYo92PolIO2LsACz8Ew zdI9(GEW(A+f+>yz?M>QTxmwc4VOl5?1PY$-Gcej?6!v-(?wwtK#${pYQshAQ_ zahe@rL+28+af8h#+nsibU{>{@o9HM_<3Vo%stE8ZUrDopJw6yxm(BlYnEkmn3vb8y zTK0vVSi7ymM&hNCoYMMocWP&znN4SW%*SKUX*#1ANDvY}^! zK8H;J%Om4+9(Q>ZhYgYA6i!!zE>_ifYH^P#hRkq)q@r?WTz_;Bg;6=AH!^oqNWeGZ zRzG|?_@1Kffo@LcNq=E^#d|1e&xEVvv)0^_Y*^VcL9=b}fyBFhTv{g(S)ic*b{)n5 zhtmy;nNOgwyhpyX>=ktAb$tA?)PK2Q{`{A?MAlOJhc*eCNMg2z4wU|K{mFI`OM~!X z#JNfr6Yxfx_l=tOdz}JzPvo=c_%ADlM zob1Y6y1Du-weU;ZXd6}Tf##CVe~XN%Fg51iSc0i`%{MpJ$#oB(wkuFlDj$!ex){q` z*){)J7Ht{sPrdO1qxkWt(;-D~5=SYqA2v}qFaenU473qaM!!8*$x(#rXJyaw5xi+? zCHB>$Zfj+|B;4n%7u9c?Kt~$qk4iWg1QCi0e)QdhSPs+CwGLSE-urmFxgE7$0YjF7 zRLg|i0)rluo$RMgoSu{b%|pVMO;7QDeD~n8BMme;dDESFwSCM<{$tDrYvaYKLw0K8 zUb(U`O?UEU?_q9d;%Y&)dX6B_N3GC;Is`fs(ob=4-M;aC;6(m(h2X^yCr!V&$lKlr z^dweqXZQmOcHW(B0#R$42 zVbD$y&(Evers&w2*;$4sbXrKvgeoOYiZQqgaReIWUb)FaLCV^!V!go9O|z@kDZZGF ze=5;u5d|K934r||;=wy4V1&o2a>@7b&s=7*As=SQ3A+TVYc*OId$D}520ms6Q3->3 z&K)R?v{>E2&8|@$iK=76Tl_e~)upciX;6~omn*|qU-QaB899)3f=rbgj)^mdi+$9$zq+3Ca@ zaYJlIGzJr>YQ`0k_S)GhQgT(Zp#ORJHKab1xiGm#DZ_jICIPyMH9oN9-)cNNNm>g= zL|y!hPW6k>Bdfg9U$Ob4Khw&rIwa#kB?XX=4wW5$1osbVxqDnDh--%o(@E##@)1sq zIj*Q57GI{vPC1Z-176@ONrE8w1G2@H(XYL*y1%+4O|Trli{yUMtD?)m8t?Lju^Je$ zL>OQl$ZPYmKmMAC;)iK!Y9f|mPUb%LXIq`dKCL5DLNS zm=u-uNEj~Jvj;aEe+M_)s#p**bWAGiFiO3>jWFA@?m8_GDQf~tUk4ORmk%J|!m`1H zV{MVwK@?Ek+}tc{7(1Qdf*~BbLf87;db|S{0;fLz+*2+(VS>%?fH#0FW+T?85G4Tp z?DCrBb&RrYZ7&~Ec~G?S_<#AvVRYf;=^5{mhLN*)FmvNke#E^7z;zA4by4=!00dVI zWGcLOr_Lbe_nQfrUn7@jM-?a^R#k!pwp5KAqw)UiR+gmOAjwH zkBdnxMebn-1scHXw>nJvc{p0?sTJ#PcxsPh6Tc%MX{e`6zb^+=QY=L4y>7OsWQDK_ z_yy8WyzgvnqhST4WywE<0~5A6=ouj-X+^WDITC>0b-DNQL}Uv&N?y-y(+3%YPV;X- z`gjDa4S7R~@zDG%({+n33zHE_AZX(SGWGF{!5GZAJZ+hqdp+u&@vKr)4Ky2hOsJTN zrlPE26JhSYzUd%ifE`FcK|_J!z%~Dv0Q<<^@^t+3XW8l%yI248c4I(d(#;pEHB^*a z5DjZ+$wXkAz?)grrogn$h#Z8$)74cs`t}J6kW_3rPHo_ny$la$jI~6g3eV@Cc^wi^ zOXOv}+mMKofR5PL*gHtf#3I3q%^1PXd}^nPv2FJrFwl{0+T>gH;bk^RF#Roj6oUjf z%HesDhnK_if=?=Dx4O`eD0Q)A0Epf7;nWQrkhEI>5in&%q4YNit`MN-db<7r2OD&gqPvq; z1K`&hsOt=xvRQRAHmDTJYj;IM{k|itKLd*ba)27WyM@A)B2da>N51c?XNuvH*J!h^ z)X)E0bW{cgPzw6>>(@9Y8UFq!d>{_}51c($@5rpk*GS+OMssfm%xWod1y;CwRWo?T0FNpPM5{u6V^-`24)wU(i*DkZ&U>;^Dkb8Zn>P;f;+2$DxCxH=vZ z0UI?2@>?ZrORI=ik--lnRu>I@N-?GlI+z{m4HHYi)0nFdy((BxdOrs9lqX;1v0y1d zmO%h4p#%RrLwD#Cp3J@hM&#eYpMR#a^5BiW`_I2RD$lPF0pY?98KqrSaI@z$lkJ;g z!vta1QNjvu@S}V1yC6rJfn5R+dLPSa4K5D_APUKl?-zS}l{%{)M$m9j0Hk0<^#TT_ zbN=3(tk9AQ-(hYpc1|#O`W8o2RWl7=>d#*;e$WqSt|nV|yg%86K;v1#|X& zFl~PAu5vA@#S!K$f&3<)d|}c<$ts!B(vLmWYlx$(IG4Y?Zj2~^(ptPP&>r_L5@vxgW7%0)V787sz)k|8p!=XKJ4$DC$LMKrS15a-Bxo{V{;y!H%$XDR zJa&ZGjk#r*)6dV3&glDgd&kd4oxk3-1{thiQ@PsPI+=Utdpp6&@lukO$tQmr6KBP> zx<8r)juY8CeuHA3v#Bj4V6!aAj>E7Jx1d8NCZ_8$FMa~~(K%4KjdNnp=`>U80!m(o zbAEAD*BPZ2+Cg#acv39o%P+RZUo&;PgUU?dF1?ZLE8ET`0AN*=F6YKtkgG~K(V%+$ zDQ2vuT2TtxSqh4g157&`=ZEvxxo?_$rOVxa9dT9_Ol-Lmc|2cKKK6O7`9F_^N+sB- zD5s@^>6WR>jmuOG$EAMsEJ?o6lB$C zi0n%@KsDhGb+ixt7`u*{xmWY)9#wSMl^SfRRVj1d6%rDCn($8Qk*FCeBa?IBahHu7 zdV;H?zf7lxhaV?p!C<|qQY(=3YsC@{szv6A;@$Y{`ELmG#R z7(G8t$mp^0u6Y-95%m~Av5Lm4iBUPYN=1{O)+??A>-hnYZUDS##HTYV+Ch*4CDLb7U+sqyzARmZ0{RiAJz8 z8*sr2Eye$w0Gv%bjDOJB44dAv5s^Q}tnBIs?dxwh?)L5Zc)Pl`&Qo0U1C!kYq7P9r zbOT=;3L~M)6m<3nJ58{5@$WlVvq9tDr<2iA&FskXK!E}yi|dF&fECQQvh@)Tm_@*R z;q?)%jGkuGIWmU}P)$_$?8hGe0)UCe{@ORtTzmIi_)%=fkXHGLPNYUu!J!&64X{^2 zBgDy)APA9g{6-&>pKY<9N1TDs0KT3OV4zhY1D6-jSsoL~;F--q~D9wNXskVyN3w`YrI)&La2ad(iFm~ zE6d=J3Wzg=lr7iZq0g}!9sa*I${_mx-{}93PW0?+(An40i}lhuLmx2bGCwsrX)wFu z6}aj(c2H3t`P=SWp#6UFqdtK7=3c4BTgOwgvsW#DH8)LhhFAbRJSWPE=tnI?0$o1) za-8Y%4^z-_x2ef&gx2A~!B{oT5VL_y)rknq^_w^Q%GvFp-P=s-d>?gE5uD3HGxv5iMaXjNd`*t-7PGUW}W zzCrD&1eiT=Sc};cPZGlZN6Jep-51mfeQaiv_ksEZN|w~7>4ieh*!G~|`E&9E+u2TW zS~bZ;6dxd^Nr1*B;I{a8rtcDE$`Iry_?2MZxY(4yvPrNp(+!L{ z|Gz`a$A|^LJ4ttPp`+bMt4b_ZJaqcJAlKzYIsaTyoJ*yiUrpL|S zeg%1CN+HgvGQfEv?YFT@^zgT{Dmik1Z2Zvo>TV>pU>rX>5ftmdNI0Xkzt~q))G21P z^b7SkG3RR4Ge_nSQ2>&u7Y!zH93&|z5)68u-&movi%s*cNbM52zQ(%oIrqVGx@_-e zqu^or`8jRt=ww2O!#>ZSJ+x$I<~Zxe5ZDy9MfBD$-zGQ?`NUVIpq_qvO7<(^hUZhr z4!1eBRq?f{8W2B&C_=<_D(f{wU0vp6Fz!gS#9Bv45YV%C%WD6bYabu$6k7;AfQ{?3 zr=rQS!TI^y{;QJnM;*6sc;uxVsT)~hy z)sMG<+j}~HaZuB|moHE*vkAO)PEJnHTf*ORQmg?eoq5W-itVF8bVdSApN+OvjfKh8 z;T)_~Q2O}$-{siklsSgW#Kp#f4mprsh!7)C)=KdhUDto26aPP=mau9Syqc2=3O^nl#rC;slF=oB8ZYkeO#>Idh(RsK7a(k19uvxjr%m`m zf}HJ1EygZclVi&H*8vxY;u`XUY27~MRh?u_SGK%6AWFr?wS7eJGo}!(A`F*mLah#< zzBakwkYja?a7z~YpR=qOT*3D4%9|oyWaW`S^q+C5>AS{09n?e)kcZ&SOKAKV zntTp-#$(o!)btY6lNsiN-}&;9Q%|P+>|04T+TUV7iH-@Im-)9GxHk% zziaj7&C)~#H)m|^!GYnq;fD8jTvtuPnMI^Fwyo%@>`1sRY=SiaMBSn%jx#^7U8ijR zKc;Q!%k`SATdQ1ZT<55>Zma#5WKJb}<*j$vVI$Sg5NCLvo-sXfu`GqHxefenzwIYm zP+_H{RCRO==4fL$$)c({sgiwV-K5x8@x96oK7#GeGrhZSdjrSQt9;RSa~(MpL(#Ps zXQWwmv3}~X?;vfFvCq5uPv+u3MG*n9A!BKeU>awzk9eG-s7~|3@La9SxfAWmDAxt1 z-67zFHLt)QYC`N312=yDv=w1Sm^s4b!icCIcOyziOCJ@P&>Q#FDJu9O<2k|3U%L#x z=fz_#89>u}D%=rd43n}MURzrOS-xZU620!$wAZ9nC+w>;c(x!rU51?l=3}L+)C?X~ za;L7lsp(Q+Cb99dabaqD+HYq`wU4e2$PAnD*_)E!5-Nn&WJz!3jkPj{|F;Cl&IxjqX!Q}02@e@Yek2B zGb!Gy>(P)wexx=Pc*6M42)N2@2?%}>nrDajZw>*(N!V|`m<@OsK>tag{FAo$|N3SQ ztfkX0H8J-yjl2`!_i`;>4}l{nCu@#0q}9S9%R!5Z%giikla;h6OQvS+Wd(+oj2?JY>k zsB6sp0e9m98`Y&5S;sZGKtJ#Z{!k4}C4K?BM+!=YlnK+gzlu(*_~8lpKUkgy!QcE5 zC$sV{I*~n6XBy4cig=aUVv`*ZaUd7Q(ysR+OpM?q?@Cq29Khy7p!WY=wH?9S-v0du%7cPDBjYeS zraD613<1(rNdGxr5E?Gf3rl>`YzRPz?`K5 zZ2fvO+*AanyI-6iHar3LU`y-|Pn-hR{%V8Lp(PW6NrjQcV*77k>UUDK}t+t@#a65_>o?^e6@{l{C=jl%iBp*b&5G6F7&2PUH@evl0X35%xcc=g%N zE_&2)4;TzOz?`{Fp$4>0XO+?cvERTx_ol#{-PoKP z^1H1%OOjoSem$O6x$%M&T8yYLo>Oz`;)06e56Lay)va5>6?Af`2Diw>XYE#$Ib{T{jg3G4NH_wE5( zxpxG@GH;Z6GdTm3avOMgfdX)mY(VT~?sxuM4&DZa1Z-(9FwQ{*smcY=vU=x(*Fr(1 z6i8$faJc)lmW&i+f&dtd&cGs@mo+*ZIxr)20$6J4tS-pt0R|sBlQ|Kx+u!w>- zuq<73XrUq40-zcb;8?@8fDNUg5G#pt#E1WkM}52BZcENx1U%o2!PC{xWt~$(69Dr# Bwf+DA diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/hash_standard_resize_policy.html b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/hash_standard_resize_policy.html deleted file mode 100644 index 8dbc57ce2..000000000 --- a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/hash_standard_resize_policy.html +++ /dev/null @@ -1,795 +0,0 @@ - - - - - - - hash_standard_resize_policy Interface - - - - -
    -

    hash_standard_resize_policy Interface

    - -

    A resize policy which delegates operations to size and - trigger policies.

    - -

    Defined in: hash_policy.hpp

    - -

    Template Parameters

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    ParameterDescriptionDefault Value
    - 
    -class Size_Policy 
-
    -     		-

    Size policy type.

    -     		hash_exponential_size_policy
    - 
    -class Trigger_Policy 
-
    -     		-

    Trigger policy type.

    -     		hash_load_check_resize_trigger
    - 
    -bool External_Size_Access 
-
    -     		-

    Indicates whether physical sizes can be accessed - externally.

    -     		false
    - 
    -typename Size_Type 
-
    -     		-

    Size type.

    -     		size_t
    - -

    Base Classes

    - - - - - - - - - - - - - - - - - - - -
    ClassDerivation Type
    - 
    -Size_Policy
-
    -     		-

    public

    -
    - 
    -Trigger_Policy
-
    -     		-

    public

    -
    - -

    Public Types and - Constants

    - -

    General Definitions

    - - - - - - - - - - - - - - - - - -
    TypeDefinitionDescription
    - 
    -size_type
-
    -     		- 
    -Size_Type
-
    -     		-

    Size type.

    -
    - -

    Policy Definitions

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    TypeDefinitionDescription
    - 
    -trigger_policy
-
    -     		- 
    -Trigger_Policy
-
    -     		-

    Trigger policy type.

    -
    - 
    -size_policy
-
    -     		- 
    -Size_Policy
-
    -     		-

    Size policy type.

    -
    - 
    -external_size_access
-
    -     		- 
    -External_Size_Access
-
    -     		-

    Indicates whether sizes can be accessed - externally.

    -
    - -

    Public Methods

    - -

    Constructors, Destructor, and - Related

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    MethodDescription
    - 
    -  hash_standard_resize_policy
-  ()
-
    -     		-

    Default constructor.

    -
    - 
    -  hash_standard_resize_policy
-  (const Size_Policy &r_size_policy)
-
    -     		-

    constructor taking some policies r_size_policy will be copied by the - Size_Policy - object of this object.

    -
    - 
    -  hash_standard_resize_policy
-  (const Size_Policy &r_size_policy,
-    const Trigger_Policy &r_trigger_policy)
-
    -     		-

    constructor taking some policies. r_size_policy will be copied by the - Size_Policy - object of this object. r_trigger_policy will be copied by - the Trigger_Policy - object of this object.

    -
    - 
    -virtual 
-  ~hash_standard_resize_policy
-  ()
-
    -     		-

    Destructor.

    -
    - 
    -inline void 
-  swap
-  (hash_standard_resize_policy &other)
-
    -     		-

    Swaps content.

    -
    - -

    Policy Access Methods

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    MethodDescription
    - 
    -Size_Policy &
-  get_size_policy
-  ()
-
    -     		-

    Access to the Size_Policy object - used.

    -
    - 
    -const Size_Policy &
-  get_size_policy
-  () const
-
    -     		-

    Const access to the Size_Policy object - used.

    -
    - 
    -Trigger_Policy &
-  get_trigger_policy
-  ()
-
    -     		-

    Access to the Trigger_Policy - object used.

    -
    - 
    -const Trigger_Policy &
-  get_trigger_policy
-  () const
-
    -     		-

    Access to the Trigger_Policy - object used.

    -
    - -

    Size Access Methods

    - -

    These methods are available only if the external size - parameter indicates that external size access is allowed.

    - - - - - - - - - - - - - - - - - - - -
    MethodDescription
    - 
    -inline size_type 
-  get_actual_size
-  () const
-
    -     		-

    Returns the actual size of the container.

    - -

    This method returns the number of entries (used and - unused) in the container. It is different from the - container's size method, which returns the number of used - entries. Calling this method will not compile when - External_Size_Access - == false.

    -
    - 
    -void 
-  resize
-  (size_type suggested_new_size)
-
    -     		-

    Resizes the container to suggested_new_size, a suggested size - (the actual size will be determined by the Size_Policy - object).

    - -

    Calling this method will not compile when External_Size_Access - == false.

    -
    - -

    Protected Methods

    - -

    Insert Search - Notifications.

    - -

    Notifications called during an insert operation.

    - - - - - - - - - - - - - - - - - - - - - - - - - -
    MethodDescription
    - 
    -inline void
-  notify_insert_search_start
-  ()
-
    -     		-

    Notifies a search started.

    -
    - 
    -inline void
-  notify_insert_search_collision
-  ()
-
    -     		-

    Notifies a search encountered a collision.

    -
    - 
    -inline void
-  notify_insert_search_end
-  ()
-
    -     		-

    Notifies a search ended.

    -
    - -

    Find Search - Notifications.

    - -

    Notifications called during a find operation.

    - - - - - - - - - - - - - - - - - - - - - - - - - -
    MethodDescription
    - 
    -inline void
-  notify_find_search_start
-  ()
-
    -     		-

    Notifies a search started.

    -
    - 
    -inline void
-  notify_find_search_collision
-  ()
-
    -     		-

    Notifies a search encountered a collision.

    -
    - 
    -inline void
-  notify_find_search_end
-  ()
-
    -     		-

    Notifies a search ended.

    -
    - -

    Erase Search - Notifications.

    - -

    Notifications called during an insert operation.

    - - - - - - - - - - - - - - - - - - - - - - - - - -
    MethodDescription
    - 
    -inline void
-  notify_erase_search_start
-  ()
-
    -     		-

    Notifies a search started.

    -
    - 
    -inline void
-  notify_erase_search_collision
-  ()
-
    -     		-

    Notifies a search encountered a collision.

    -
    - 
    -inline void
-  notify_erase_search_end
-  ()
-
    -     		-

    Notifies a search ended.

    -
    - -

    Content Change - Notifications

    - -

    Notifications called when the content of the table changes - in a way that can affect the resize policy.

    - - - - - - - - - - - - - - - - - - - - - - - - - -
    MethodDescription
    - 
    -inline void
-  notify_inserted
-  (size_type num_e)
-
    -     		-

    Notifies an element was inserted.

    -
    - 
    -inline void
-  notify_erased
-  (size_type num_e)
-
    -     		-

    Notifies an element was erased.

    -
    - 
    -void 
-  notify_cleared
-  ()
-
    -     		-

    Notifies the table was cleared.

    -
    - -

    Size Change - Notifications

    - -

    Notifications called when the table changes size.

    - - - - - - - - - - - - - -
    MethodDescription
    - 
    -void
-  notify_resized
-  (size_type new_size)
-
    -     		-

    Notifies the table was resized to new_size.

    -
    - -

    Queries

    - -

    Called to query whether/how to resize.

    - - - - - - - - - - - - - - - - - - - -
    MethodDescription
    - 
    -inline bool
-  is_resize_needed
-  () const
-
    -     		-

    Queries whether a resize is needed.

    -
    - 
    -size_type
-  get_new_size
-  (size_type size, 
-    size_type num_used_e) const
-
    -     		-

    Queries what the new size should be, when the container - is resized naturally. The current size of the container - is size, and the number - of used entries within the container is num_used_e.

    -
    - -

    Private Methods

    - -

    Overrides

    - - - - - - - - - - - - - -
    MethodDescription
    - 
    -virtual void
-  do_resize
-  (size_type new_size)
-
    -     		-

    Resizes to new_size.

    -
    -
    - - diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/hash_text_find_find_timing_test.html b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/hash_text_find_find_timing_test.html deleted file mode 100644 index 60c30fd34..000000000 --- a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/hash_text_find_find_timing_test.html +++ /dev/null @@ -1,164 +0,0 @@ - - - - - -Hash Text Find Timing Test - - - -
    -

    Hash-Based Text find Find Timing Test

    -

    Description

    -

    This test inserts a number of values with keys from an - arbitrary text ([ wickland96thirty ]) into - a container, then performs a series of finds using - find . It measures the average time for find - as a function of the number of values inserted.

    -

    (The test was executed with text_find_timing_test - thirty_years_among_the_dead_preproc.txt 200 200 2100)

    -

    Purpose

    -

    The test checks the effect of different range-hashing - functions, trigger policies, and cache-hashing policies (see - Design::Associative - Containers::Associative Containers::Hash-Based Containers::Hash - Policies and Design::Associative - Containers::Hash-Based Containers::Resize Policies ).

    -

    Results

    -

    Figures NCCG, NCCM - and NCCL show the results for the native - and collision-chaining types in g++, msvc++, and - local, - respetively.

    -
    -
    -
    -
    -
    no image
    NCCG: Native and collision-chaining hash text find timing test using find - g++

    In the above figure, the names in the legends have the following meaning:

    -
      -
    1. -n_hash_map_ncah- -std::tr1::unordered_map with cache_hash_code = false
      2. -
    2. -cc_hash_mod_prime_nea_lc_1div8_1div1_nsth_map- -cc_hash_table -with Comb_Hash_Fn = direct_mod_range_hashing -, and Resize_Policy = hash_standard_resize_policy - with Size_Policy = hash_prime_size_policy -, and Trigger_Policy = hash_load_check_resize_trigger - with αmin = 1/8 and αmax = 1/1
      3. -
    3. -cc_hash_mask_exp_nea_lc_1div8_1div2_sth_map- -cc_hash_table -with Comb_Hash_Fn = direct_mask_range_hashing -, and Resize_Policy = hash_standard_resize_policy - with Size_Policy = hash_exponential_size_policy -, and Trigger_Policy = hash_load_check_resize_trigger - with αmin = 1/8 and αmax = 1/2
      4. -
    4. -cc_hash_mask_exp_nea_lc_1div8_1div1_nsth_map- -cc_hash_table -with Comb_Hash_Fn = direct_mask_range_hashing -, and Resize_Policy = hash_standard_resize_policy - with Size_Policy = hash_exponential_size_policy -, and Trigger_Policy = hash_load_check_resize_trigger - with αmin = 1/8 and αmax = 1/1
      5. -
    5. -cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_map- -cc_hash_table -with Comb_Hash_Fn = direct_mask_range_hashing -, and Resize_Policy = hash_standard_resize_policy - with Size_Policy = hash_exponential_size_policy -, and Trigger_Policy = hash_load_check_resize_trigger - with αmin = 1/8 and αmax = 1/2
      6. -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    no image
    NCCM: Native and collision-chaining hash text find timing test using find - msvc++

    In the above figure, the names in the legends have the following meaning:

    -
      -
    1. -n_hash_map_ncah- -stdext::hash_map
      2. -
    2. -cc_hash_mod_prime_nea_lc_1div8_1div1_nsth_map- -cc_hash_table -with Comb_Hash_Fn = direct_mod_range_hashing -, and Resize_Policy = hash_standard_resize_policy - with Size_Policy = hash_prime_size_policy -, and Trigger_Policy = hash_load_check_resize_trigger - with αmin = 1/8 and αmax = 1/1
      3. -
    3. -cc_hash_mask_exp_nea_lc_1div8_1div1_nsth_map- -cc_hash_table -with Comb_Hash_Fn = direct_mask_range_hashing -, and Resize_Policy = hash_standard_resize_policy - with Size_Policy = hash_exponential_size_policy -, and Trigger_Policy = hash_load_check_resize_trigger - with αmin = 1/8 and αmax = 1/1
      4. -
    4. -cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_map- -cc_hash_table -with Comb_Hash_Fn = direct_mask_range_hashing -, and Resize_Policy = hash_standard_resize_policy - with Size_Policy = hash_exponential_size_policy -, and Trigger_Policy = hash_load_check_resize_trigger - with αmin = 1/8 and αmax = 1/2
      5. -
    5. -cc_hash_mask_exp_nea_lc_1div8_1div2_sth_map- -cc_hash_table -with Comb_Hash_Fn = direct_mask_range_hashing -, and Resize_Policy = hash_standard_resize_policy - with Size_Policy = hash_exponential_size_policy -, and Trigger_Policy = hash_load_check_resize_trigger - with αmin = 1/8 and αmax = 1/2
      6. -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    no image
    NCCL: Native and collision-chaining hash text find timing test using find - local
    -
    -
    -
    -
    -

    Observations

    -

    In this setting, the range-hashing scheme (See Design::Associative - Containers::Hash-Based Containers::Hash Policies ) affects - performance more than other policies. As Figure NCCG shows, containers using mod-based - range-hashing (including the native hash-based container, which - is currently hard-wired to this scheme) have lower performance - than those using mask-based range-hashing. A modulo-based - range-hashing scheme's main benefit is that it takes into - account all hash-value bits. Standard string hash-functions are - designed to create hash values that are nearly-uniform as is [ - knuth98sorting - ].

    -

    Trigger policies (see Design::Associative - Containers::Hash-Based Containers::Resize Policies ), - i.e. the load-checks constants, affect performance to a - lesser extent.

    -

    Perhaps surprisingly, storing the hash value alongside each - entry affects performance only marginally, at least in - pb_ds 's implementation. (Unfortunately, it was not - possible to run the tests with std::tr1::unordered_map - 's cache_hash_code = true , as it appeared to - malfuntion.)

    -

    Observations::Hash-Based - Containers' Policies summarizes some observations on - hash-based containers' policies.

    -
    - - diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/hash_zlob_random_int_find_find_timing_test.html b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/hash_zlob_random_int_find_find_timing_test.html deleted file mode 100644 index bfbb3b086..000000000 --- a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/hash_zlob_random_int_find_find_timing_test.html +++ /dev/null @@ -1,163 +0,0 @@ - - - - - -Hash Skewed Distribution Memory Use Test - - - -
    -

    Hash-Based Skewed-Distribution Random-Integer find - Find Timing Test

    -

    Description

    -

    This test inserts a number of values with a markedly - non-uniform i.i.d. integer keys into a container, then performs - a series of finds using find . It measures the average - time for find as a function of the number of values in - the containers. The keys are generated as follows. First, a - uniform integer is created; it is then shifted left 8 bits.

    -

    (The test was executed with hash_zlob_random_int_find_timing_test - 200 200 2100)

    -

    Purpose

    -

    The test checks the effect of different range-hashing - functions and trigger policies (see Design::Associative - Containers::Hash-Based Containers::Hash Policies and - Design::Associative - Containers::Hash-Based Containers::Resize Policies).

    -

    Results

    -

    Figures NHG, NHM, and - NHL show the results for various hash-based - associative-containers in g++, MSVC++, and - local, - respectively.

    -
    -
    -
    -
    -
    no image
    NHG: Skewed-distribution random int find timing test using find - g++

    In the above figure, the names in the legends have the following meaning:

    -
      -
    1. -cc_hash_mask_exp_nea_lc_1div8_1div1_nsth_map- -cc_hash_table -with Comb_Hash_Fn = direct_mask_range_hashing -, and Resize_Policy = hash_standard_resize_policy - with Size_Policy = hash_exponential_size_policy -, and Trigger_Policy = hash_load_check_resize_trigger - with αmin = 1/8 and αmax = 1/1
      2. -
    2. -gp_hash_mod_quadp_prime_nea_lc_1div8_1div2_nsth_map- -gp_hash_table - with Comb_Hash_Fn = direct_mod_range_hashing -, Resize_Policy = hash_standard_resize_policy - with Size_Policy = hash_prime_size_policy -, and Trigger_Policy = hash_load_check_resize_trigger - with αmin = 1/8 and αmax = 1/2, and Probe_Fn = quadratic_probe_fn -
      3. -
    3. -n_hash_map_ncah- -std::tr1::unordered_map with cache_hash_code = false
      4. -
    4. -cc_hash_mod_prime_nea_lc_1div8_1div1_nsth_map- -cc_hash_table -with Comb_Hash_Fn = direct_mod_range_hashing -, and Resize_Policy = hash_standard_resize_policy - with Size_Policy = hash_prime_size_policy -, and Trigger_Policy = hash_load_check_resize_trigger - with αmin = 1/8 and αmax = 1/1
      5. -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    no image
    NHM: Skewed-distribution random int find timing test using find - msvc++

    In the above figure, the names in the legends have the following meaning:

    -
      -
    1. -n_hash_map_ncah- -stdext::hash_map
      2. -
    2. -cc_hash_mask_exp_nea_lc_1div8_1div1_nsth_map- -cc_hash_table -with Comb_Hash_Fn = direct_mask_range_hashing -, and Resize_Policy = hash_standard_resize_policy - with Size_Policy = hash_exponential_size_policy -, and Trigger_Policy = hash_load_check_resize_trigger - with αmin = 1/8 and αmax = 1/1
      3. -
    3. -gp_hash_mod_quadp_prime_nea_lc_1div8_1div2_nsth_map- -gp_hash_table - with Comb_Hash_Fn = direct_mod_range_hashing -, Resize_Policy = hash_standard_resize_policy - with Size_Policy = hash_prime_size_policy -, and Trigger_Policy = hash_load_check_resize_trigger - with αmin = 1/8 and αmax = 1/2, and Probe_Fn = quadratic_probe_fn -
      4. -
    4. -cc_hash_mod_prime_nea_lc_1div8_1div1_nsth_map- -cc_hash_table -with Comb_Hash_Fn = direct_mod_range_hashing -, and Resize_Policy = hash_standard_resize_policy - with Size_Policy = hash_prime_size_policy -, and Trigger_Policy = hash_load_check_resize_trigger - with αmin = 1/8 and αmax = 1/1
      5. -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    no image
    NHL: Skewed-distribution random int find timing test using find - local
    -
    -
    -
    -
    -

    Observations

    -

    In this setting, the keys' distribution is so skewed that - the unerlying hash-table type affects performance marginally. - (This is in contrast with Hash-Based Text - find Find Timing Test , Hash-Based - Random-Integer find Find Timing Test , Hash-Based - Random-Integer Subscript Find Timing Test and Hash-Based - Random-Integer Subscript Insert Timing Test .)

    -

    The range-hashing scheme affects performance dramatically. A - mask-based range-hashing scheme effectively maps all values - into the same bucket. Access degenerates into a search within - an unordered linked-list. In Figures NHG and - NHM , it should be noted that - std::tr1::unordered_map and stdext::hash_map - are hard-wired currently to mod-based and mask-based schemes, - respectively.

    -

    When observing the settings of this test, it is apparent - that the keys' distribution is far from natural. One might ask - if the test is not contrived to show that, in some cases, - mod-based range hashing does better than mask-based range - hashing. This is, in fact just the case. We did not encounter a - more natural case in which mod-based range hashing is better. - In our opnion, real-life key distributions are handled better - with an appropriate hash function and a mask-based - range-hashing function. (shift_mask.cc - shows an example of handling this a-priori known skewed - distribution with a mask-based range-hashing function). If hash - performance is bad, a Χ2 test can be used - to check how to transform it into a more uniform - distribution.

    -

    For this reason, pb_ds's default range-hashing - function is mask-based.

    -

    Observations::Hash-Based - Container Types summarizes some observations on hash-based - containers; Observations::Hash-Based - Containers' Policies summarizes some observations on - hash-based containers' policies.

    -
    - - diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/hash_zlob_random_int_find_timing_test_gcc.png b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/hash_zlob_random_int_find_timing_test_gcc.png deleted file mode 100644 index 8d170db1a2aede74640d042caba4082ba914b545..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 6910 zcmcgxXH-+~lfHBaU4sQ_VxdV5f*=rr6j31&2~|KqLI)8k3Duw|O;Bo3Aku^YMp_gQ z_=$8vF*E@I1*8|HDN?dG?w&3GvtRbh-jn2>nRn)y=b5?5Iq#bol&KLfL>K}90I%_7 zeKP=HMgRa4j*|uS$Rvh(0RRhtx@K+wng9R;01N;S0DuYrbcO|k0Wb^zBLFZe0HZS& zF)#pw0WbsrLj^E&Ml1ma5HJ9N01&7EfzC*!!T>4;pb`Ko6`;~VB!CVB=oo-b0O(YJ z4jLdf2n}L^$zU{{QHOD1U@!s1YiMFIv!AixMz7=g|p z1;$b_Fe(8?rNXFmkRzB1qhnxn0*p?D(ZQ-9YY+@14YCAjfoou45F3OBvA|?HLlDCT zF9HTb#bD?RePCJ8A`mbHDuzI3$OTz|i&O%JO2ts=pn8xL7>l73Fmx)04$1@j0n!As z!FGW9K@y-skTnPfk_K6Vp&$>iFo+F8gIIJ%=NQYN4PI0NfzD_os1Ga)T2v~5N(cK2 z$^}_~iv&8AKnME>b{cE|$O{Yy8x5)jTM709qzPt&?EpD}fz(#`lz_Or4rPCP${5yUIi@y_P%=7P%7^MF8oiX0Otz>Zg z+a1QV{|aVM{;Pp8{J*pq3jS6Cp~1%ioD$ePP}AR1f1kwv_YW6bs3=&J>&|6se*oY< z#CS8&#>4kOr}#Yst9v(mG53NT@45g6H&7BrZodBa{GIQ*-?=AoLHWFbl1h4D))4?W ziZ#|pm0Ok@TX8$73e?8T+5He-7N0OD%#O>UR*Qp`_1$RE z=fdaLC7W8WTUdIorH-w7+Yu%z-GkP2p6zwUz4rv@a>Q+6+2 zc@>S%IB=KmU%kB3cpWpon;A6I6t}kT5?;WK+>2Vc&9YsBRasGN?6H@+zBiYPC4Z`T z?OjwsvhgIp4=ky-)6c5I|6ZCr@sr6pE#uO6^iR}qhtJdcldZ%hG3DCkvFn;>Xg+*| zgL}VG!FfykMozFp@$j-23*|HOXfqid?B;Y+q)AkdrvYm>G$u%48!dyx_@+5q)^OJ- zTE1@Ep}ar0YNI+@;L<*YyPXV|4KZ3sLHFfEu5IMt+|%Ev3&JdT6^tO}_jyJ}-}93sY*eBbVW_x?vpGp&EKaOq{QU6!N=sXeX#=z5}}ZuL*sSY*wO)UeZE9grKLccIAH%p`i4$^;R(V9ZM122b{Cc zb8FBU9|`_bqteN+1?Omy4CAgwQfcXs!gRH*cb%{Fc-?Z;__^8dJ(XwX zjbR=7lgA-0E)HYoH=dGe%TKc}RaL|FI)vkf+75qPdX5q*dU5(0(pHGKNGC?=FB z{i5ij6UnjHmYy3>C5p$39qlQVn9KhnyRD=vZ~o<>2$7xb>EhWtPBM;>nVjx^!-_23 zk$5v3aw##N$zyl)TenyMNn-zgY{`1mdsAoXDl=(Que{W*+_Yb-*pqkn5G7uu&OP>V z-&FdE3|Exl%LU#{PSo?PhKUN+BJ}m7gYjjio9FJe%xbkRD-b=%_mp!fr3MO`}X6C8870PwAGK#pmu_=4Z1pG8k>vInpXU|gHc3J$Rsp;3Jk#k1n_QfsRY9EG zgQlpy4!-9OgPbT^WD|RHPzUpXhf#)|h~|vL&nB+pW3RU_{E?;zSGS3_*4v^V+N<*oT6rli@Kp1X(^+{FD|R$A zb8IQf5WY}a*mNU-fSIf+*M5#zvjns6Ff6+!3WTN9=%FenAqy`5N!LHr)??UrPohy z%hr}!DqTUeTKL&*egdjTjmmedloW+$0=%j8ZJ3~&I_vIB3SKOwn}!l07X8=nv*Gu7 zKGDm0I#|&o_XJy=nwOS6?*@*@tcq|xD0%^x7RX%JJU1^H-|~1^W7S`+tM#@Vt7{56 z$;S0U3iJPZWR9NnQK0<B_r)=TIhRy=jL+H2(k%3!~T}5ps+(aq+j=r(MJeQm=Tn#mdd12yKKVp zL3BlS-p{Jf;8>h;jgt}0-Fmz5{?{k77SLVTFF&G$ZXPdN0WY^xuN)iM{Sv|*aRF&; zgYIiN+v`#Hyrn;;=#h5Sc2(%TODX`{Q;p&_4fm=m+Tp12Fy|8OqScR(D+ZtSXdHtE zH+RF-z0Lp-$-@;%s{E*daX|u}({O?J$!|2g~NNalkUgSw*|(^}{`cCrxS~YtHUn7t5xOASzo+H!<71&F7+F zM9QWhyxJN1@eH-Nsb6ZKn2hW!CWo@^a3|rox6smps3LyCe$eE@6=N}?5t4Lq(s5tv zDrz7YS(GO|pZ~qk5FZmMDYU7|-kXdo?(M47MDWhVw_JwO)4X~tRy6vN3NpH7y| z8RGy!h?&XSfix!R8&|;GNYv^&P>*Cyk@=h3B0aCd-)HMV<|v5J8#nk*C1B=PE{f7piJE)-ULlm0Z|RfzEgjCBp)7W_=Dq`^^DKSpL*(juAz3 z>#(b9GZOai0Wu@gg(c}+m+%i z3G7^ff5|H={&lsu>cJxsZH<&-nH>4f5?QJ4@VUHeAM%ItS8TNhd7p+aQYN6AuMVoN z4t_I2(Mqyp=6nB;jY(auQTU!6{{!DAe?BGx5Y6e{kWWzWcF=3O!~NbP+Avz22@0KE zn+dSn9())*Q;9%G?PWC-LmVD?UWKDj8I4_Ux7_>^L?Do_vh0vr0J8p*wf`}`)5xb8 zVB7hPch}Q1QElRYtaApFnC7b0?px?06c9*ski!=H3uZQr2X^R@``vuHC!jNTXGtUl zFDp1I>0>cjRYr&SLI9#Oh&mt~9Rgjw= z$z})Z9MZ2Vec-!GQRZ=RXSX zkQy(-X9vsYJ!+}HwL|J{t+#ZQ6B{uEmhO7oVTe>$upC+)DZ^X5c%8}yg{ zM31Jz=@0OV!$wOqADxAvN+$S#z77}fOCn*(`R)^w{^eAM?sLKFJNdm{=bLUA%$T8` z|H8N2I*)_TURYRKUWotgqXzQ}%tHRDk*K&_)Cg1J<$mv1QQ0$=t#n-}4x3a=e7#|; z{*suzbvRGr14(Ck;qcKL2<^G#@afut)m2;g6U&zGZ_WpsP>-im<7c+j$7hnmFRoo) z`Z2LJofT(df2ZwrvOm@v&75exyj^b7E%Wwo+*vZntibfujwrHpq2ElU4K4v5|3T+@&b!BHHxGH_9zLAFib`s>98ILH+Ja(YD-9+TaJ~J^CGv6HUy3yv~NS0R6vKeeF%KmtyAnljX znHSw^_wqc^=Uhv*t~vXJ8a&M#eI=;3SmE_SfTCB8r>#6`C$>}jnnltJhSNenOdtKziw(TwHjoJACIJ%LhsE! z;qdA7uM4sE_ohYRUxzPl%1Za8j>A{v=0`;XD&Itx>^}=1wd`Bz)mZ$M-Ti82!J1xG zM$}(#pS#gGixmBEK`=;rt|9=Ld&%51r#2wM1a309B|`Un{Z7f*@}P#vEv|lPgztBT z3naR4G=SvwPvQ$d>kDK{x~Y9cbWvUQQ8^ut2&rgU2d|h4CisD}rETV?!3aNKbZQl6 zPtaf&UCU_HXzOAR#VkF0kZ$5%x78c+Q`u=1XR#pI9aJ*9r+MN>TqtcVoLW7E3FHsS$Y$uLdCCbheRF1uoO-R-Ea=T%v{7ey&K;d(Uc!v8_;UEzAov)a&}V4S-c~b zhZmLf;jZSi%W9nguUdi&%K>)-wY{D3HO%SGF?@@I95TkY;830;k?;td-LW9;dD1c1 zWSIwT+(zvyd+C$jNe*bztY0pHszI{g&3 zut~XVi^oHhr?fbY%Ads-OQ85d#8f-438#D%i!vk_N8POoBeT1SOLO)`;sM^UvN%UE zR{Kb0&OXjE4o4p5pT|yaE~dr4%!vgKMV)uo{b--8;Kt3vjG_I@wmN!xkW%sWKHr^H zYabbIv3ce>pPb}#!N^V!}KV1_iMqJIFpB*P2b_D4X+^0MNGbHP|J z>P@|HCw}hqle8L*BZ_uaTiO~qs`C#*$fjC9vozthg{OojI*cQ7Lutelk}Cc37>$!L z*az}l<0BRemT{_J(4tQ+*MH}EOE zNZH9pM0|Em%BcP!c)Qv#F~DqtfYlT${m>>+9-5^BR!yu7IZy44ka8~Bi7x)&GN?{C z(;>zCXWEO0mP4jGNYDtj^`4daAQkuvA%pY$G!BW~*_@pVM=$dE-|z?F9h>B0qdhD< zja{G5oQ^qa{cuXSONzJi&^GC$@TuN?Ke52}k`XXn`XqTO8!dorFL|fNKUMBZ3)R3i zRbzhuAttzQYe)5K@WEe%41NwY9isdr@eVSzq=6E6+@=%Tt##n~5U;D1X1QZV3=lk* zC$Gdw!9zxwqasBxk%nJKLyv>K{ZbbeJHi|#5TC5z2##!>gGsnuoYhStLV$RG4?Gt6 zSBIhg0r48;pJTTS1pD6f&ic6sX|>cVq^$_dg21;z03x5>IB0Vs*l?& z`{L*MegJgo=t}Gl)}XVZ?@5dA!qbek^a`FL|2Thk-T3yctz%k}CcQcmxu5b+yVU-9 zJ^Si_DosbS-1DvPmcITo$p^wO{goAcKIsgsEU2~oGFe6B zn4Z{BnnT+US$HD<cz% z^Fg!!_f`BmUoowdUk8PPMDW1^QoR3ifW$*0J}bYhOksbLAdE!N!|x>SA69&wdFj`C zmnG)#9aKYj73}!vi%dSD+uNvrY#*Ho+^&~(+1jk1LwfvFRCx63W-6EYx3%H!1_#Q* z7({b&_l;$*M@>R;z@XpgRGnd4^O}8XxmH90kN>1%f>8Dy$}3`APF?94gS_Hwq$yK1 z=B2!C46fX$cAQ)Y9q?8RClo?iHCZ9Gr$3GO5A@m4EcDpXsNC#uT%mm(Rhj#D1^!B~ z{UoBxCq^bYmX+ePD|NX&;Gbqwq`f0|-A&@I(X9opO z7H0Ex<>xE22`#^*X=}@R%W!UT{EsuZ)&xtm7~5{vzF#nRBM($na@fAwf0q=r-S$nM z*@Z|Htl1`Ijak-L!ufm!rCHb#+N&+gzBK&FI{4hqs`ap|?=>Dz34Se65|4XjpFxNm zF(z2q{v>9rY~{ZJPcmSKm7uCN+A^i%GV{mAh{Tgi#*W?XE1nJgHTj9YGs&Tax?p_q zXgtowtZ%#~gTR%Ml@e2(O6o3pb%t%>OT+fXohB+P)wEN8?8+c!Ah{^}^w2<)O67#L zBBrE}*^^fE>YDb7wP)EQ6w-IdX6fWW|MTi09Ou@iD{uV2OPw~GwNGh+)V^!ot;*K# z9-)nI_fxeD6}p9@EPs&~!~-e%S1D|tJAUsz~zpKCWEi;RnQF=mE~Mtk*q zq%Cvt$?dq<;-1haozGMsjb_T*(eUBRL=fC$gRTOL2SlPi!{x4UD8{~2Wnx*o3rb^sfbFiL>P^nbj?xHx&){4VJYoN*1(;_9k8I8ah}`5#uuT3OC& zGjdIfkoT*wwycO7s_*F3g?oQH^xUD+-A%XGqZM~`5zq&iWx}TFN`GF!pZ0cEwog_& zcRoH6#p+Jie%n~esU0feeZ&OGtu(zBICJjy$ANFlEMU^i{VTF=Bj}A{)BS;-v#y$j zUHubJcRQ1`V#99B^0HmGYCb;PG)J4d>6Iq#e3p00YDde4M35 a1C}!wqQ?>QO(n)Z2gU}b`mgnF;r|V`r1JIv diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/hash_zlob_random_int_find_timing_test_local.png b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/hash_zlob_random_int_find_timing_test_local.png deleted file mode 100644 index 0be2f00fa63e49b970f46ac8a2c4e0e99cb917b9..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 8436 zcmch6XH-*B({2(%mm-KD9qAyT2BcXcf)wdZr6Uk&p@Vcnk*X+4iy%diB7{yrYCsT# z(4{3JNH0>P6NKD@_xtmH>)t=#UF)8;IE&dc^UO2P>~P3Far(OI40N1yAP|T_Q$y7d z1cIPIAaETG1+c;zbpZ_mQGoQdjnx1X1cHG;2oMNZ!-GKNGYbX-!4M!A8U(|GVB|9= z0tP}LKnOGlfd?VTXR&A)2#o-t(I7M)geIS*;$a{>0)$6{@OTiO3?PBXFc295BBMcM zJctY!05$*(U;)WMH2JK~*@b|?&@dPt1|y%91uO&thCss*co>3w#sYAn5im3whQ`Ct zZL2=ZBfKv}>-qY-F40!=<^7hnN6@n{4dkHC|G?g3IjEP{+iknspI&>o-% zKoiIYYPpcU&CjV|MhS-{C~90I`~%!fCjb$FeN}dpr?PO{_Vv7?>C3QU>=|-t%t^A zZxD!{*WAaGt%c*cXapm@wW4F^6=qTxF#ok^?I7$ z`->nDkGrPoU1R^u_4nqf`4Y@(k5gJtd<%aCXTI9;ysf)bkkiz5m6Brjx0U5bbW?{> zlRyUqBp9I#o|%H9P;4~J6%a7Qlpl_xgVH<-2Z1G-`E4j6(9-{jbB6vrL-PTG1>$yZ znU7&mO9_XhSz?#3v8VY~y4kfkwR>`lX*%KBs>6x%Au0X&RtSZzsz)20I9v6S^Wi6_ zQwfh$7OogaoXW{G2hrbx|3g~vYnE%Yn|@L!EpIrDD{pA$rg{3pR)!4%z`tYX8CdgW z{T+T(1QE0pj`pk;oaL)XQ@6_4+ZUZ1+T3@=akU?x7OxRcjgUAUb;H+H_b;Y$?Z6Dd zbz94u`MnbUY}p^B#an(I+ZiHpCWtw+N!^By9Vmy7@jL&0`R$cz)~eI=Op>ul`H0!3 zZdI!Q(Z9gi7s{~@C-@&8{5d-IQ9PHIxmqy2{KJjsCk82BaxqH~=aFBKR2ar(eX>sH zy1+2_0G?Oh#x_$L$Wg}L$jWjl!fD~p^z-l8hBh!6)SK6j$I1)nQk$&;BonX(a5HifuVeuEkJ1@4HD(I3(_|Uu1tV7}yrcjksp{!_(-;;mI|mPCL@WtnoaWlLOMk z_aIE_u2H+vUP1h|VsY4_{A#hn5&9P4=5MQl?kn6-fBB5l`nTtC`B0iIgxM$`^pNg$ z-zpO%n1W#qxPy`Vw{P&{x<+bF&+b^@9y7AMoDGHq%l4fG$TA#+KI6wxkAwrRrQz*= zE{Tw3z$MXlaF+XYI00}y9e#P1D*(fu4BerC9*T9mtG=}YL|xd9LVZm5xycAUvUruSeJM)KbDB^l|4ZEl@M*-K)ss5!Azy)U1lDRi; zd_2jLbB*WerKCtqedCJ#(h>NwA8WT=O1{G-&5T6Y!wR-%^38y{8W7{ft2*O$Cjy;_ zG8@SatA@>!je3Z&T+wvhd+d4kfkMF>6Y-5HUCRR|?e&xM+q>5T?*)AI$^0CFsaFnA zUDNx;FyPQol z>Y4J#(nLfe*VO2}f=ls%RxOkdw$%a^RWOcs69=*lW+>RX!2p+q(VhbsN7 zf}~z{LkeMyvb>s~0-=&ve~%$-!0agVvL78puZG7{J>;+>MdsR7=8!C|KxlT|vW)M2 zpLIW*0Z5ar_B>B*c?b71n{!b!$$z=`)Sp`qlZ+mHE;`8mqN@>2+Ido593reM(r!2` zF#3?Hsc^3lE;>)Qz&EE;TMmWXRG(tmGQr%Tg!;dEhs33gwy@A_35^ko+84eP&BEva z1A#Oye&>}j9%Q{P84en-9lM`mnDA~q$aYN+49-$1?`M4=(EP|b)O=mCZROF^!IB-- zVx!9#(%%%)7r^!~F;odReYF@;TOQ@7G***!V+CV6*rnD%5t@Thu=X5hb9}YZWE562 zQu)=l7{6SaHk8^J9hJ)KC@DQiG@-m5)FtzhpGkGz=gRmhzQ;|;O@qhj6mIT$zSh!c zhT>GD92j%lNF~DIMQ{CR!Q6dImfJr~EsR|jE=<@aUT9m3ve)gZDzWMH$vi#rF!!YW zXla<^yLdP3k|E7z+uK4r#UZdMt zS0g(ejQ2|*>oBIk-o%JZ|6NPVvXy#E)GI7o+WW#oo$#=X=2sI%UovQ@KYWpHN1%FT zmwzYSl7f#9RJ(RAEQyEe=g93y2KK(F@~0Rw087wYR1+2VwQ%ahc;$DZ${1W-+0EFQ zL<*69hqtNUsh^1ru+F?icJd62WPKlTdC04p!|*kuzfzj##5R425T94H@B%X3xGfxQ zPPwB>ydhgV$VPLbsGybZW@K{*k}r|4%!s+eq$Qf~SEJ*Nwa<&9I=S@Y20wIJa8IQ~ znwCJ=jaeO^q1%eC9ZYiMS~L#u&4<^VUd~~CGiM)ye#pPe{^dRG=Qb4$Ap$~i%BokK znUoNrtMQJHM6XHt;UEbF(cU(SOBuYhn--x-dy8hPjuZAtc3FlNnm#*z(Y#2m=Ja|x zTRz2CF!Fm~vvtUZB&IZIS%wbEu@sN+qx_T-S`<>9Lzn1kDNo&SHLlGJgur9Aivf36LMSOASrC3OPrM?0j0_hkKCwFU9Ow` z&d$l4Q{a)iM>4W@grk%@Gm!3g_MTHg>kV?}NZY_-{o~yyFb28%x`d#feHy*4z!Ego zi_D4{sc(AePDNZuL7Vv~if7kU+O_X3IC6oP7QC2CqtBm*F{I=nBboYp7jT#eRs^Sn zIuYtc#UUtKH|MKz9l^P(MuhZB1bXmUg^J>3waeJviMvqi4y9ofN;8%s@}W+-ZQMg^ zQ(qYctVvaD)F+j94I|8QoqxN1t{d|FQs&xeJ1xZbCr`1-c|w_&a7W5aqVlP^C*Sfb z26fuE1~wC=85X13UtMGAimc5&#mF3gROO^rjgOtSVxEXRD~bJV(yELFU_DvzQCFNL z`uSe)TAZNGjX=_V<#~MOo`Zan-$L3#LtG9n|0e3hHXz3{Fbd1B(i~}*^}2*htc~jT zoFy4ac3%zJ>ubR=?p%YWnRnt{r#3Jxy2#F7^B3Kk{`_jD{_TkHE74!_Yu)&6%DvmA zV=p27y4RlJ=Qqld#j%O-wc)c>U1M7J#|#uFe^@aQ)>XXBBo|OQ>vqAHxSZCD9x=8B z4(lgBE2PT6V3jbP879@<@MQTKa3!RGAsF26KA8+XsSR)Bc1ex&8=;5NoXACt)1n>J z506Z)?vB%yv3&KtF-LXcNe{qAKjhT~q9ch^^KtubIjzzDxgY>Xxar0WgJ`wdhi3NW za^cy=*^QU`RynN&{_jD#tyq6^84i-mi!@pQfZ-vn-W@?sk_+ReKenJhRyx#_(-c<| zGfwNY@?yDa&1)=+ZFiivtz`z0YL_(7E9^@czZFP-w)BnWv|yL(Ltle}k9c>kCMB;D zW!E!fVE_-x{;l{WwH{gA3L_*bey67p6C2eLtMprnlZ* z{l_(W7S#-2{@p`Qted5&@=_OF)T!AQb0+`ZN}9Vhm)JdHD#t9fb3!SUo*X<@qV6kiYoIAil+Bm7B|;XwW*L-rZqa53Q|O zYv+URq|AjTKrH;x6~6XGeF9;u~rf^G`p zPK-mQm}PgLNHSja)HKz4=T$6l!GMq>jS0ET+k%guDbLnEKS< zhRaT2MVIo{3*bGDWrU>Q5lB_wvO|)a{ znD6~4KwXwvFqU5@i94a>{d=qA4ylQYXX>saeX*-i`H@(u&bd&>Q`l;)i<0`2-1Xk6 zZE@l$A}!Bw+)BJl_Zae5W;FCoEBlUmwx4Kn31*_Fp4bzu9bA=e@U0iS`Q+{5FF`t3 zC$CaXI}v90XZAd=Qt6eTTiYbz90wuF8K)1*E13J}Dxwiut+)pAyQKAaaDD9kQ6I(9Th3Cr5O`nFzn z+3u-mUX9gEo5IW@DTh7m@)a4|yV=$yid>>ljrcL6d(KULZ%h%vdaaB03fpxLxrKj7 z>Do9w>+sahwbO3&P8dm8kw*_fF?56T0a({Z8p5%>-NK)hvgUH?35%24Zl^;CFUN)X ztm}j(eL<4TLsb7v80S05Z3~I1OURz|{mjOaJh4|uj9l|p-@B+2Cw$~;SQdtK1Xu|t8r1#Y%z7};zr}plA zkc?McGzhcizT`dj;?(RS{{uG`dMPR}HV^%w<_gYll~(^{0VPcq(|>+R=ay)L!R_3d zWrk0mFbcqP6s%G&XI>LKfd0kL82=Q2(p*s2+H!3{n{Ou6v=-f?VHQhFo|z1W)s3(bzJ(W z#+?<1tts)N2+|~#9F}n-s{;~uvtL!kZ}tq`_}}>d*X7&a>dgfG`pn3`KTY9YpTd5K z;m|dv5sUvUZ@{{%?fiWA!i%0vzfm_E4YH!!g`8Nc)Bp0rQO_yvkp{vg>OIbUgS6t@ z9K&IZ=e}HEI=6C%VgxP=q63ahhI2p$&;L;EZ%c5zJf!}Z4flq0T%~fiVd9O>4G*{Y ziQ~P=tV1F5TE1eOp4o)M-KM-eVkkCDpF}Gw3O{G(LA}3i%dsUL$ZkV=F>~8LghXVW zk&RtfFwr6~{?JyTOjpDQI#}doCcZat=E)~t=%dxIb#q{}j{#p9E)&_aGW9CIuXO2E z=6k0O!4uOWdr#EsM?%QDQWU|nRlL%mm}-|<&Z1-A|+b)=Y? zAn(c@b#I7;`N&#%+;9UAZ}`m_s_js5}p@C>!cahLO!lb*ENx z^6P~Uiz7T#xb!K&WAHr%5%IcmkWTr%ebiIW(Vm@16liS*Pq~?TvWVnnCc*wEr-T2; zbH!><+_8Oie<;z#JS;}~TC~C6*Xh|e*JW!J(ehFe>8L{5!BfQOo1hoO3)6~e2Q{y& z3=3!>K9>vgXKW$d!BUDZ*8KWCr+ajF=asuZ0-m{oMWUYd#eI{@(QUW5L&v}qru zsFqnadQLpz1|lMYcaPanX0d=>`2(_uB>j)WP*)lgoMzkFHQ_wF}`|U-4AG zKG;@uM^{!`XLtX2t9X;nmvpfD#BiN|=i|Dqg{4CXB?(rjt~*__N4{Jg%J}8y>4Z*T{bMN!Hgax=}I`r_!n~%Ix_nuEqo78@4 z6^dPKZ+h>AT{>_La|#;d69%BGbzl8$sa*H@=2Y2#aht{NW;#u#Y)6(_BUhho_;%}+ zG?V$ePJzG0C2&r(*(9In=Zg9)SeC(%zndqgcYnX?D^6K-k_2_gQd<*v8G{*4?|$50 zNg|35G)%;ad{uPwO2B!hi78}8A#01TbRiz+m#OtLbK4~EU06hA=!=%?A|Bn`GOS2J zxv~9~I`0I@93M+46<)Me-i&#jZD9RnzS;hGw|nUPLoE~`G7jgdem;kH`1q^Bs^8s5 zD-O5RVEuui0E)xJJ<4U(^}kbSdSdZjKgK(4y>-YnR3tdyB}_8b{hEEuy9+r-uDkCa zLw3!#hT2_`d5_geiCN5f-RJAWK}*xwJIulJK??f|Sl7}K z!SR;tRmm;_>R4}1ASrsH+VPo{x7$m#D+SPV(P;0i_K7sSQFeEQBV%%u5o!bO)56|F z=GGSV__6)`b+)+mhQ~X_TZZzOD3Vwb$6TB0OoQ?U<*WT;-c+?Z@LVUN-6)+xS7oa3 zcA9Mxw-{{+XsWn=i1$;%xniVmKf#}?_4DmbL6fMz+Q(i!=#$;<5Fa}vlXja}I$Not zo1yy5XZq~Ud=pZtrPE&9*q_&$=cs>fXGL&(uzbo6ybu@u)jqn@D@UjaQaWBErnHK12mIGxVRISuGg| z-tTMZa&hMkljJ`J^+b(xWyEG*W*aBIHbkw9eOBLT!Qf9NLQRI8`!lpv!7S;#jqUJ& zsjd4|5xXgOAuZ&uz=eAUkkYC;x9ZIRz6z zI~ZnlGg5&dRCw`xQ5y!WGOxzBZOv98GCrn*E;6glMRAiF0oY^^UW!R%SVwh)$W zozS9C{YghPZR4B!b18U`UHW5gcAd%nN%@`tYpP{cH@|_;D=wbymO@~YgE3Fqt?7g5 z7JlF6Q+YQ@_XGB}-Nnf|RoWhYx#;WN1UL489PIuW zX7Xyo?N1vRyDMNaarWXWf()F4Ye_NbzVr&U&ZPBfeZEbd)1X3M3!Sgg75S~ zdRyw;G-RmCs_GIeq2CSY1Jv1O^p0mC;6&S*ERgTb)K}J&j>tNCzM_xKzHgcTFkG<> zWrb=?ns*7oMV*f|6Dbb?a(r5F9=&jut8aQM-6s#mjz-;Q^8Wr*x(%i~*sfrxCx3tV zbiZ?fh>D!1;#Qq`rdf!u0l$Z$&0QKT=fgP(=Asc8{guBWv{%zSGty?>Hf}-dCvFY> zFs+&1?+j?Rsmsb(uU9X8h4FURF4SJOs)*~0`|&#~;g-H~(AwfekKSD{JJR)rM79-eXVC*}Ya8&=fd3Ya$KcD4UfYAphy zpOgZf&kN7YEd$%}<$v3bLYCr3q0h}R*y>A=;G4*&FzBKGqiV&>BS!AOqy-0l zT+j?2@$2uWYIf;5sov?$1^?LRj6Gj&tU2_wtP=<#2t`Q;L23709hrLXo6y|I?HVE6 zgmj75joItU>v$||ngaSLBNbZYX7P0FDLb-5D%@qg|Hwyo69!&bQA0gMcAN+Pkf1;= zBf6qOGPsf(vtp3UdrZtWNW!IPMV1-Ay^NRjs$3q&PT2RIO%d;E-nIpRt+40Qrko0c z+ORQKee|>Zt{>*GdJWzG(Wa~1ypG>yj%MuHNj(?+hI2t`lM>>Zy#MpT`(}?uP#8go zYIP_Jw1#4-FxavJ{kIoy!!e-hkO@Ae`hYyx^B{c3OhfIy-^+``9{6U+Zvug+5?DBv zEDUpXVrGm<3_H2rk3rN8uawxV_W_T(kw!|6%=7Pkk5$2@mHUgplW}DMvWu6UP#%d` zcl4F&y!DNcarOw~9Q#?;CIs)*AO4^%jFt;Xg8gzaj}J<&t%IXdFwK^c4^U)3^XI+J z7=2>A`Bl^YNR0*c(vaXdVHj z6liO?7}$0^KnHO9!|md3t6P7h|K$vu(lM`VRi)R_)YPQn!U6x8OMw>iWPP2Jf%f&w z?XWSXd{YsDO#wK|ChJT{>a6a(RB3ZcfhG7SwH6%0%P9~EmN_H_+Ju)0G$8; diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/hash_zlob_random_int_find_timing_test_msvc.png b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/hash_zlob_random_int_find_timing_test_msvc.png deleted file mode 100644 index 874e7a780e66b2e2765c51cdb856daf45bf504c6..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 7204 zcmch6c{J4F`}PoHX@roGoh(_0k$q{BohUom8M~5wUk1r8g|Uq^LbkFbM2Lu)$QmJA zcCs_Jc|ZF8-gAEMKfm|9|Gb|w^Eu~!p8LM;>$>havpn<6;GPBz^>u0x2t=c$dG`Sb zM2Y}`NP;OZ0V_9CLp?yCOCSSXBQ+odf#4tz5(GknKsXSHcoD(jAUF~PM}y!v5S)0i ziG+iYNDvYYLgGM3;zceR4niYAXfz0o1EGl*r8qbUhXmo!ARG>aBLYYuA{<0Sf{17k z5eFgy0e}ra16V*YkWIYkb8#Wza5Nl_gTsjzZGi}hgd@>#Bo2-wUa$Z*(MUKN4M*eP zXyOGaAQy*(AJ7(v&}bwYheQ)E!O&l7D!y$1*Ks`VT$VC#-NFokN1mppJ z05pMWzz#q^Kmt$*um->Y(f~^!72p9h2CxBW0E>9x+{HE!0~ZdBCSDi`=mXjU5e|pO z5dmKTxd01b6HUaSiGYuQ(|`d0FCZN-8c+*Z3HSlf1gZf$08W5lKq0^y00T$^l>jY( z2hbS62B3)-Bf7{2wt*P9h`_`EBLRItTOh&_i5CO>H~tG2|0a4d&woR@Aob7pi}C)m z@`B?(cP^&=Pw)lhe;O`^|Bu#%f`6R=XyD}lObIX#(Dbj>zgOb__nT92C_B)U>anJ| z4+wPm>cx{}a4P&1Smg9oGxIfkg!B!td*TFAGc@4RaCzk8>*Mgm^|3FPti&xbm}HiJ z{xuK?iqX1@Fbd4uuv#0zazXy|kA0Q4RXK0~9tsM|w+pDRaxJ$kt*_&tnlUHaloGtx zKs`||o}dA_HZCq&Te>s~7-i2TDA@uDgmec4CJ6$eA{8SMw>kbV+d?o+khnS%_@yaH z9qE6Sx1}KL#(CnRCma7eNHWWfH;8z<(a$Vh=lD<7=*+X^>^k9+^uoPwD(&N1p-}0U!>z5J9m^+w z@jsL4O{(?oN>j3Nj7roV$+9!&qN#M2SZX>(vb_l!2R|o_{hC)o8AVZot$IjZU0R;| zSLNonh*_$iC0+)9BW*R;ZS`_rv>R}I1R>jO%SP*PM{!7>0j~p*FP~$sh0rb+fazwiK*Wq zPyafp1sAtDY}wL@er;M+PLYwMETyV~GzmVpuq8^d(ZLodS+sJti!97Doo2S@~8t3{&t8stvU6Jn!tOuJ@ z8qYD4{B9}296@~H*1qe{Wn?^3PnA+z`ZVT`xLCINh$>FeQOJOFq?hAFHS#Qbzr@2j z^_IzYkb++`L`%WZxc;k^oPT+9{s;L(ORL{RW!%%m-Y5EUJKB>&zHiMP-90J^iU(qx zek^+pb}dV1Q<$V9NuJLic-n8*mTJOVBC~Z#Hz@WjX=&^!*%r&wr1;#0r@EzodGXa* zp;J^c>o1SB=9wy|H0(T>94#I98#L&w@8Kbq;#lz-Yf!b%F|GFRF5wjuscKvDdZZ-G zPI89~Me9ub$9V5#y&SnN+4_}Xam}k&!p$R;ZF8acWBF~ZvQb&f-Dm{g{EFG#Y%7T# zDye37aT!TZYaC)(M4nS|XUs+9LBE?HS`&PBM3=(1-NQL&T2ph&9%>|2P_=EXs~-A| zSjki4w|Bd?`QQmPWk^{~D%si}J2r2g22Sm3jMCu+syFaY{Y?j1VQ1#VnlLmCx&iII1J|YPrtUR62gQ zciC=toAzld`kJ|6g61D#s0z`S+?i181%`%nc55=Q(@1_)B!9oj&taCj?Bdfm zJ&%U9T3-z$aZ8GLuv<&zwxjtv63sd(D;$4l zH%toMgFsmJEY&!4GF4-wnT$1I2?&d_kNn3jf%n(UJrvm%ja7ZCUN)MlFsS%mdZbW? z96<57*2fl?c_|hZ498B_#@gk6y9Vi1FXV84Fjn|6Wy_ z3mx2{eD*8u<_qhr4P0_FJuFgi;T(5(d<2Q zG;qt)*XDRd34W=?JA7<}QjRbf7C{adTXRqxGbZe6edA?p=W+@@tj&%iC7?QfAOgIV z`!9u2cM-4)^a*wb=~8zp&k%bAlvojJb1t;tKUF=v!y?HB?qFkbW(5mW9eZ0L?OY2) z=(&oZ-1jB#Lj74;j2WTVHO5S$REln?7RXTU;wl8K!YBhJV7Gy9hX3ScfewZND&IO!*ou z>CmYt&-I=_#~lcR3Z{0rMA*-Y+-0@oaSI8gNn=%BQ?`2Xb%ArzCkDSy$~R#6wa-q| z#0|{bP@mA8MeHN#34tuPkgRfi>Uwfh$yLaXQvb~Z0n!Rg=E~pxpoqFx^-Qj%N?wcb zQ-7Arn9|Kl$E#HM=_*Kd%Z#p5+Jt*qHC{t$ zWZ#oC_jh|?ib%D}5`PGzj7;iz{eEf5r`F0O#m{9Uw0Tbt3ibkycddCK#Zo8G)Oh{h8ggV_C@BMXdG8%=jKGJgv zy|gjvYMaJPVmMw^!a6|?CeVF&v7}U2M-ADT={1Ox`Qh(KhEn_}^UC57{(AW^@lKw_Rmk90Vb&!ZLnYX3b)2zk zG(w=@r}H7~Y<}uqSkk{X9jd#Iv{|||w(Ea-O9LS=&DonMN`XopCEX#@WpJg+#Le~J zhT_;n&H{_Wwyaa=Ex)cgDVM8X3UckPU*=1(57?FGU^Vr5Xp86K#eX$&WV=`~V=ZZW zboGn;GRXN?;3ddJ+fS)Y5K0;*ovh&2q)6~*u<1MEE!x0gG{z!$rn6wjAH^bICd{_K z^gU?SNDh-5O7>ss8W4)Q+l4FtiBEkwEwoa`E2w+@(|vWfZMaRHeVPhpFQJ{SB>RBTur@gAN9ai&9Ie+>?SfRb zE+DV$q*}=E7q*`;R;*m5=-6$yALvc{VK*QT#;@scVfLORS#w)?v<)BoZLKW6f^^2V|4-%(lrYZ|%7(e=!%lQUNw zJSz??D4xaHDz7-vAFPOUPtUm++Qe^BcnUj()z<&ef^JiwuXU`Ur_)4p#-K}GM zcTKccAdGHalc6%M{I;^|VMEuEAG1p0F{(a+o@c>>f2<3%4q2stqv3s|cYD`>|4zE) zQwjg)0puYv;_Dd0o5kgFvg%0(l(Z=2t5YQ4A8jt3zpK`S9q86xPgmInF-EMT*;MY) zTj`N(4$Mx!Hq$nR+pcqWEzMyOoc5uK2x$1ST@|WxRXe;=gMRNOiI0p*#f=>8`=y=~ z(JD^1C#X?)GV|u5L>LnaU%0P1?*}<%40Aha)J>hMQ!j6Ny2|G}@}=a+@b{RPVD1#v@T9!p(2GmnwBscUG8a^G*8T65g>K>2>ox?6M11Vft=w*~KkuN?E2TB_#g zZ1P%jwlw~Z1pTa?!Hf4qA9nR5OP@-x2KRT$B~4XhhazGNL+a-Gh5Ne>Fg<0j6R9S) zmtrBu&;XOVh5j`t*||}7IdGS1OT4(ZyI-7X*VNuJbIGEw$&G z+imlix}?)UPhAt@O9~o7#qLSZIPoSL+U$F@&FDK!s_ZLXZ+ut}F;uZ=Y*})=bY-Qe zz5A#(W%bh$!|rhH%O8h07yep)Yv)U1X#Hb{)7c>VP~vbcOj4I>U!F~ZfUhBmNKs*j z^5+dYjx zDY9(f``#$~U_9JuWnw&1E@gqQJx4iljdtgD(5u+(Z%1$JrDybiJXMM)f*Prt&Rg*K z)wBN%)VHCi@OdBHbbah;1lxChja#e5IHZmp)dUTfo~*`RUU9R~imu^@ zti~zpM64CQWw$tE*|T!jKP5qlJ@$3{v$>wAoY->3{`2!HEv_X!^YwJrmhEm1)X!?{ zn#6Md$p^0B{d&`BR+(z9 zs68D#^h@33q+lmtSsCK(WdIA^+f@J zFsU0^%eR6>z#L!+MRQTD!kyT_#j{t@L2qaKqD?hTi=PJs$~N3!oX-9@}AwvvK_NPj3Gu7^M8|I_>FoQ-pn^T9)^Y@3dw_<`D zJ7Z4dg0=etl-_LU;2s&zhO<&vH#31@M^HXBDc@ewrY`Ngu!Dg8#&Y)z_kH`f27zIf zOW?b1Df3E3!ON2-7iHH?G7GcwMN_?_;P@eU`7osD@2U)@xw|c3H|hK0GrgM>2#nDcvYH26%nqOgjGyaN=W-M)++VUnf3zgqSs4ni80(C%oUW<|d61r*iW z9w2R_W=cY!dq*Zj)juA}ZnZFnh*VLt%f~Yp8?b_-Zad8;XH>mPe5eSbD}}kqFAVv{ zVlxC&_zb+w^4kR?4AKx(Oi?O-?7B*KzHu@#TC*^+^plesNB+2l2kf{@>{TYwHR|vY0b+hEt}NwGOAt2mwM-gkuIGdYkn-R zd82OGg)pKQXm=9T`*my$l#Vb5Wv_&-B*X1c<`o=)!Hi+g%~*D08grMP)U2kHMPzp< zGYd<{jyGK;M{rfa6x=yt1!d@*V3cI`mrH8H6IVvP2UFNGZzs)4x_EF*+4V)K$`GLvhZHqq*9n6GMcCs#dP0O4@-1q9_tH*ZKnpdo@C4>&XVa&We zIlE?@p>Yz=`^PAyX8i8~zF)voGfHKB_E#eMcXHe$T0A&Y;9VU7izxg)Q;-L?ybaSAYjlUv2u?uj?JzD#fNX?uqcd5^;^5{x|wL${4AmA^JRP z_FpP8w50oF`qkf)F|uS)O{CSbD>$2e^6QZ-sI3?G0xrJc!yM=ec2}=_f|Bk1k7s!X zOrL(p-%h8ucD6xA<2te(B>OcE18%7_^f||2jMx>gb9e!NG zx2DR{Tv2?l zzLc3nywhcpG21RKdA+-LlgdgoShTn7>CA=IuLR!MKXN)1o{?;N?j+crgrKz$bnbs( z@b!@oU&!+&K8921i;09+!S=q!88;QC`T7i^IZ>L9@(%+Z*9u(2K|9~YM!Ew~1DsyL z#(lMg5t5$|vK~9N70S#tnc^o~S2GCppJOz@kYL`bkP+NQxiZ@3L?_VkKMBc`txF}l z?xGA^GgCJlfN3C>K#syV?|x!*p$oBKrM@_fcNQp)Y^OoqCW-|B2hvgPGh1=Drj?%cyexzb*uF~P?} z;7|WKkzH;nW#}_UBbc2(mF?4^YX@TSHRj!#V-K0Ajh)h(iq|a}Zs2)45txAcngjJd zNgsBELVIgiZcv_g9_%dXNSDfs)D~>e&Ijt);`4#cdscN2izm4`&k-?0KH*ABrN9l=wt-WoNkwzl6C!)(5k|CV3iW;Y)RTk<#uf+`0|I&cD)(+% z=@fVBiMHVgL#d*UBZm+VZITHEkn;n`p*IN1>`^qj%aNUd(A^YPH+3aC!y$yfNq%y=paSEgCND<{M&AuyH`TNTD5WjwG=GO*9Yko7<@xR!Y)E}W$kzke_q z?6v>G#DEg_Frm6q;Ev(!u}&0PXS;qM>#|Bc`7q&8rGUEe?D6HOT%GO8{mxRMhY>g5 z`QB`OSKy*|_Mgm2VWDc$z+3-0`ey$~AYD5Gezyxf-X$O1xfzWxnpwPD@rRxi72k$u zHp7=tg6X4j#oy)V(?g0#Wo&FkF+9+_V6WEOcLP9Hp#Qh?^#9|y{Y9)RoqhIb0LHVY ze_EF6joo=m{L4H46&;M`s!YXWS_vL(l`?hpMWStmY!LgL)CPO@L}}c~j*Ewzxl$xT z?x(Cn751r}4F~>P`4dR@lc1lhPYxm9%-4B!Tw#I~Lm%dIM(g)JFth#{Gt;`{ xojvBaC%q8wM_*_6@Mg@EBB=Af|C4Y^Q8mgno6m~lx%huYOYPp>synvP{|gqwYsmlr diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/index.html b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/index.html deleted file mode 100644 index 4c73c2e91..000000000 --- a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/index.html +++ /dev/null @@ -1,146 +0,0 @@ - - - - - - - Policy-Based Data Structures - - - - -
    -

    Policy-Based Data Structures

    - -
    Ami Tavory and Vladimir Dreizin, IBM Haifa Research - Laboratories, and Benjamin Kosnik, Red Hat
    - -
    pbassoc@gmail.com
    - -

    This is a library of policy-based elementary - data structures: associative containers and priority queues. It - is designed for high-performance, flexibility, semantic safety, - and conformance to the corresponding containers in std - and std::tr1 (except for some points where it differs by - design).

    - -

    The documentation is organized as follows:

    - -
      -
    1. - Introductory - -
        -
      1. Introduction
        2. - -
      2. Motivation
        3. - -
      3. Usage - Prerequisites
        4. -
      -
      2. - -
    2. - Interface - -
        -
      1. Short Tutorial
        2. - -
      2. Concepts
        3. - -
      3. Specifics
        4. -
      -
      3. - -
    3. - Design - -
        -
      1. - Associative Containers - -
          -
        1. Data-Structure - Genericity and Interface
          2. - -
        2. Tree-Based - Containers
          3. - -
        3. Trie-Based - Containers
          4. - -
        4. Hash-Based - Containers
          5. - -
        5. List-Based - Containers
          6. -
        -
        2. - -
      2. Priority Queues
        3. -
      -
      4. - -
    4. - Examples - -
        -
      1. Associative - Containers
        2. - -
      2. Priority Queues
        3. -
      -
      5. - -
    5. - Tests - -
        -
      1. - Associative Containers - -
          -
        1. Regression - Tests
          2. - -
        2. Performance - Tests
          3. -
        -
        2. - -
      2. - Priority Queues - -
          -
        1. Regression - Tests
          2. - -
        2. Performance - Tests
          3. -
        -
        3. -
      -
      6. - -
    6. - Misc. - -
        -
      1. Acknowledgments
        2. - -
      2. Contact
        3. - -
      3. Disclaimer and - Copyright
        4. - -
      4. References
        5. -
      -
      7. -
    -
    - - diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/insert_error.html b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/insert_error.html deleted file mode 100644 index 37a89aaf9..000000000 --- a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/insert_error.html +++ /dev/null @@ -1,53 +0,0 @@ - - - - - - -insert_error Interface - - - - -
    -

    insert_error Interface

    - -

    An entry cannot be inserted into a container object for logical -reasons (not, e.g., if memory is unavailable, in which case the -allocator's exception will be thrown).

    - -

    This exception may be thrown, e.g., when a probe sequence in - a probing hash table does not encounter any free positions, - even though free positions are available.

    - -

    Defined in: exception.hpp

    - -

    Base Classes

    - - - - - - - - - - - - - -
    ClassDerivation Type
    - 
    -insert_error
-
    -     		-

    public

    -
    -
    - - diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/insert_resize_sequence_diagram1.png b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/insert_resize_sequence_diagram1.png deleted file mode 100644 index f64764ec931c93f57928adaf846bf83ea509894f..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 25834 zcmeFZXIN9+);1a-B1j3?0FltK&_Pfk6cI$EiqdPOC|yC2UTl#j(wl%vliooC?e{(B`*D7u$;z5*&Nb#3_qfMBroV=oBF%wg2VgK5 zjnZX#O&E-f9|j|Bq96sIcrX&&!5Str znyN6EI}Z%z`w#{rfRB79VK8SQ7;M@U29t<^!5D5ouegeW!OU+d$zQncYCM;4;mL75 zms~NS-eCTGV-F$HkYL-iIOAry81${jB2SR{`;2w(lQfY%V7BIDB)7T!4xeU4&gp3O zIZaj>UHt4F?;c4oiY_>|9buE~bhR~d7HhVrC|t$|NJHh=v1mj2FYqTtbP zz0k9*RTGkDubT`%3EIL9lsO0%T!4|%`NH6AFcJ!Cby;LRISGaA&yR#qe#+Q;N+G|# z2cOU9D#?-j@dH`Y!=$dgCwr$3|M5{ivi|tb+kwkD=}o0McIc|)%#D^}W8vObl+cPS^3sSQi z%M)iEhTgibOnb~%r6;K;q8j&+js9)?2ZtD2v0Ui0_FrP!CZdwH>wbJGU*4EVLL`c? z$o-nQA0GwvcXVMcLS}1WWu~Vj#bK~w1wYlvcUg$ykMV@~{QOX}?;h-5`!Q&fwz@Rd zWYd#N6E9Nr$NKHvMxWY%?7Rd&KlhrN8HLM zV-}A0sp?+ezD`b_Owy~nj1P?{DiS>>`@(^gkkmWxv$N^7Cg({Z`$C44%&qtFiqLua zJVbsimJlx`Z>$JInAuZbgdvz8i&pJj5`$zOSI>UUUGx=Kz-2XxRuVdxa)<<#eMsQg zyb264z{Ij&j_nY*SIl<7XBN?x=gxDNdcH*55GCa3& zKfbL&k=3jC#|?}34;S+v3Q?ADgDaIa&J2XZkfkSNX)(2v@W;zSshRtP++w5$mj~y) zb)rvU+-w<<;sh?Lb1)R2X}h8l6M}i4WP%(UJ1~#t`l=ts1rPPKE`CKz`Ek#Zle#i? znlS>C6?#6kkCaFcR>e%x&^(b<{P@hA`+IEZsC5_*a~0BPiVix1{Yy}){8wF_-LEdZU_$} zX6fXWmQ;jJH$7d*S4q=YFhM{2e^OXtLi6KnIsJw3eK8D+1G3=O#` zyTvGwxJcdMxgNI|p7^xqX#r`&+h(6Vue~OY_P)0DSe@%2kS)kmBv{g>5O$`O%|n#p8`?yuI>|Wp5cLH-xaV9zWh|av%6ZRu&e!^GKq9 zp$v74>V?uBvQmqC2I5$3DO^mqC=%)7>iSyg)rOO&XZBPX(YF1t(RoLOUhir9k46`l zIxpmjwK|8tJ!+nGJ`Y*f+_G~(vnGrH}HQxt!g=1VD+;UTZNelcRCI{|O? z{*3rT{V6n|p{j!Ir3~42)^^XAo%t`gGJH?#+T{^^LvqFN@RCfHyH0y?O}~QZ>|-(C zT=Rwe+z$l%VZ2b^B`vWtp<6ofrqTx1%Zd(G-h|mg|L?(eHN~vF9;3L(_XnE8%;|P<(B-!iu~>Px4%zMAq6X?=0TW10Ht6-K-+gNO3MZ z!hKm*_~X_5{Rrfj%6s#`-#*~?7n4%)A_AG&=dDEL zj`pe*s zPN!ufS=rIONx-6CeksEu_=qaa83g|m)zb)@&W`@clDH|I_@V7rZ;ZhnS-I=Z79CQna+hzIF=+&s5 zmgO2cT-q^lN)i+wW&OhorFbEyyE8h=Eoqqff(^4nN;2KO6F2P&tsMJ5JsVtl9aa4{ z<>Hra++fY?ivmU!DHm<8-3$0kePhPFRNRs*%R1`*KpwA$L!p=;UiE~2_~WE|NA>zP zI9?43kB=^T9y)sG;LC-4r3n8Ea;9X!jj8l-fQV#~oKgLwL~bA()0Y%AEi>ja5MU>u zwK~zT+Pf3DX+pmff1N0q8MT_V^QbdWzn7~Va^*bKg~6D<6AFfSJ96=f5RVw+UP4yO zNfXZ;HKX_>g5JvM_+Dm}x}CNUhMyi6i#*}4>&w(_!4`LJ`5bpNN)o zX|F{C4N}{P#yS_HXTBz6a=j=);0&*5PA=U5N4N?5%Ibj|XLGGWa$Nf~_}>&RtJ`Z| zTNsKb>OY*`=AmIN737k3CC@(5szFhtwtK$nzqRmccF9t=k4FOEyon5Lu5)431?k{eE;tw+}Sb&_gRe1=uSW_LEb>vv=Z<`*?RDi43-pWA7l zdmK5RacKd%<~!5}d1+Ew z$Bs5gc2EU>I(AOB(oP0Fmv#i~FYPKues~<5d@0|V^;vO<`l^16GZJT$PPV@ROHMx2 z&(hZEpb(MbmqWqhcG5mnI zgP-IffNpQzJ>KgNL*ghIg4v(3`*};*dc5nu)Z>E1VCL$BlUG5goVyreR(8S{W7ifC zMfWjWwgxF4-y%)KciM^cM5|3_ohY;FE1>~#jd5-bTsGJCjA8&xsr02hGsSn67mA1( zf=YmMTWRkh)?Fwx><1tb*%{itpMU*iwc+mg{9Hsz@0M#|LdI9LWb$Zj0)Q&eUo|jM zwKun@{irGNV`w7=EVU}D@(owr$DO(B>|fD!(dWY9i}@-C-U+egi~3cgR00iVkP0vN z&*W_iBm*Ghhz+lIQ9g(m2xeBC1At%vgKV$|Fnu8L2tWI?6W|xN7fT74(QtKXChGmW zPQeiXt#I@|0py+O^Q`y(BG_=%r7Wrce;+GRd`0`LV|-l2M^@_?Ot!|))-dH`MTy-z zQ|dm)ZsNw1rhw(HNUdFLB_RYTjdZHZ5Jw&$mSi{?+2L&YPh~fdtHV3QVV{NlJ_|nN zU%YqLe0J{ntlir`yRdWeoypcWhUO(timkpRV&AhvFM_Ib4a+qzagg1-C-T0!^oIG)IeA~%lcW+hcYi#*5^D}+WkDn8rZL9?-NQjh1n-+S zDL7WJ%VbLBAH(2<+(P#;7EK)8wF~*zx%>|Wz>r5Xzi@$Mj}b&lqDn2cLzMdl45WO% z9N`>rHVt6hsY!=ib=}kCsbxW;r(v%75C+V1djf1A88i2j&j1cJy{be>N_UI1)?JtR z<&XJM^kD2AIDF_ET7{HCmW>VE*{gjqAFtxi=nKYs@iB#hgyObQ;m&zq%t~7f@&K1F z=7{cf&HFHTKSfYJQaq{cW|7`NEzcGJG+)07;}=1)GFp&+lS0S0vsi_G#GAi*DJsH@cq=#b_biW-kR-D1CdM4V>N|A2$_)jM2IBAdQ~152oXl=7zjil(Yd^?&eP_a&f2O`5 zCx5n|1czOEO_uyCqh&*a=^M8+GXBiB{ZL>sZe4y?e`T3;Az)4N#?7gJ-b5A&mKQZ$ zdlJg;p^Kh?6fjW7Nd&yU-H+H1;PntBnkSa~Y@?(F=-D;SkR*sn+zU_({SIC5bINU< z>TMBENGKMnE|CPN1OU?^M`~}4jxP$eic-vicR4_E3pQeP&Q#h@kw3dAO|1sJ1KGstjrMC5DU`1nk443wi zP~fisTL@u5DDN)72>RFjd$fgOPTTJ90UH9I+ZnY&&6R0MuC% zyq`0nBd^~xr)f=>jK$H>@ztut!pKN%*OeOkYo;ufZDGCQMxV)l+0h8xaZQLRGB(^h z?pdsUW1HemKC|B`w-}~K zrO2Qw%7)!qyhQ?iG2&I+p-YjXYeHoe+PVW}wloT4fBQjL?RBZ2P;e$AB@5g(IV|@>8*^WiZj7ar^zzj#(px&yg*O zFAg33Id2k*C$c|~QExAcp0{OiS-(D3x+s`aU7Ev$0maRt3n1?UDU5 z>y7H(2i^5UQSb^7hbu%!0TE`p1fEsM%Xn$LCH`!{fHyvw)obD1{+cz9nzcCxpG}O+ z*4OXp+73w!?ie^C*R(DRTB4&-I0u*_yoQd-Frx60AMko$cJ3Y+xl` z+z3AnXIt2TB8>&gzBU$_|))>K2jqk|z}O&;>RD7rMEb_>o0?DhkvFQzW*Jk!OWydrSkD83L0 zA>jP>KKTZSpKsmIgMM+HA0NPwQHm^#`+iw66qy#S)#`s4;P(qKL{lI&xQ zDt5x`*BzIDYfR0(oSFdKZ5=g*hFdGk5%=FOWB)6#~!rqQB5@V(PCradt+@j$Zoc(^Mo=Q}Ln#T6Cc zJe?pfX`yDm^YtrwVq${lq@tptdk(|?{rmfur@OPX-avnf5p8S~}Y#c2(E zR85ldz_~}Hv)x+lH!NMLoe~H1l!4?WS`v!cU4n72pR8$B$Y40ksM}nwhL8yHF|4dv zsY)@cO*;5a?-Esa^h@jbeT!sSRo5%?lQTW|;#Mc?zJC2m-jh++e%acrXcl!Jk=B>7 zq`7#jaL6LviABBo_x#oWfGV4+dWX#B*w%VjnV% zo2k#&T+aIi1J5D%m&ATE-m~sHg64?vi|$Q0Y_Un!g-f0Zn!N|YhqU1H${zSE+A=A} zQ0w$*9hzBwy9)1{gE@RTG+Hlh7c@BrlGoD|qvGb;ZJ2}Xrh6RMu-&1-*937!XR}vN zS{3EH7rf-Wswr!xW#o8GkyeQKfkhHLkjuVFR#G}f0Oq5R?u$rEmu~@V1-JJJ6GhfU z9uzpUg;R#7PY3dNtqBEAVQ$s%Q}vw=wFzIl;bKA3V-#H+dEP*C$xlz#Kh$~dm06(X z(P8rBvgVE15|$e?w;kU^j`z%7ZONXYVR1VkO+ItIhSsIAL@%y-Z3OLgh({WL40d3r zURMLwgcxX@?)TphcB{XF5KRwVyPnt5eP9GR&ajlt;Qw@}68If8_kVyysy?-1QvAwR{>Dy9J?ZSdO!(?2m&R0U?^fJqT2*u7Rt^3ZnBgK$+ecN}Jl5SJ0duU8(? z%Uw6^tYnrW?(LkX=P7efxX%xqiLt9^m$w;ET!ykK-w-HmqQxu?FexAroOOR`JANufZr=n?DT|Gv-1$>goS z>QDFQM+t_m76|iFZ-t+(r(+jVB?SS{hk&0t)6n`F@}YPI7{Wslm$+q*u$~V*bBCQS z-WN5C%P{~omUb^w3ccBK*;Vk0c0k%uWrilV6tABJK$^h0Kv=QydbW>!CPXNd9p+~R z{PIwDQ{Lrig?GcuqB$9jx0-l-pG6v(6h45#OF{gs+9b$LMN3h7E$e7FG~N}DA2fx& z;e4SmiI83&88ETiS#{Vc9n-rc3fZCsc=92y%BR)%&z~~#76x|gy}VY3s_SAwMC_Fv z2^6eepDk*W-d-PViWZznH;!J+JFN!=iQYuny9k?r=wjQp{kqK)PW=9MCS>|@Y=`|o zl?w&JbZdfS#Z42L6@3qR*_*+w2^uFaLr@0%s&mj(Y^GzUdVV8ADKWjxZJ!^HpEF^M z-z`zP6QDeb%cgJy@AjQ#SKZn}{t*V0y~kqmyu}7a(K*ysU@apQq3;nl_&HJ8>j%S4 z|Ac6fQPr})CvDRp6ycpne?!Fpvg{lORh646h<#u~9^gBD3e?B!0GhYq>>_%hvL!{I z`ql#IqVyBGqzX#>o=xQ{ul`l^^`pmO1AM-qkT~%fS5{J95Gz%vpu7Uw0BOVgy#R9K6;J9r$lg_%kMgeXxrJP<*nXO7x`Qg%Og-Ty=MXre4YdsNko- z%?(Ou!2rzLJ*=n+!8qTnr>7g)KtstH8wcbtyQ7=NZWLT*jebIRGS0X4Sc0TN`ejEb zbiWa3{JRpU8=a}t|6MR(*yiwF)@%;)u78#asj}$JtS{zk%b)R;1r@mZY%noW$j36U z{Jx^(AQKWKMQVHcE9FDkBNB_GfBcyhcAQbQvT}{ zI0;2Ds1s)gYpks;=Kp9uM@s6jD8xeoXQKmrKvebQ@3trMMnLbM<(^PFZ+suXnYhWd zntuGZ)wuzHPC{5^>=TIAxc;<~cc4C0SEpc8L}Wghce5>Vj;Z1Ptxl>(`bxFKgN1_V zvY7gsE}Gr47)btXA%vBLeB>6hvk^@li?DOh*|Z7XFbO-C6Df^CeW~H3dZjAZHCo{t z)`VNseE=xi*p66|nI3+`b3;*-ts}QtEpS2GV7CyNaGWY1v1)2+#o4JfKf=gOhQrow zg@_xFFLw)y;nGY5L8&0Ap`igMYp~*c1Vbrb6y4c*ZRS0Lt7ixembU$Mu}ObA18-d& zCesp^H!n=maTOOTiED2Uy+5Nv8GO$gW0QU`L)>1C7BR`GBRlh+I%6DtsWwE@Y_r>> zw_v)5(BZBAZtdJn;l-$_6F++C7xN2vWp}{iQ9zsd^NH_hLb#yA=hM;Ib=u{{4Ts;Y ze&qL*YR*&ES3d7oa%MxfvE2;k-tKLne+{nWkHQ|i6_O&aZB8Z{tzU*rBg-*ixm7Xx zpeMhj7~jcNpWXU6Q|(BfWcSyhUXi8xmXtG&%#r$W@8iyCkLvVbgM7IyIIk<4@MrbE zq>M6I5M$3OC<*FN??Z8X`$cIyfDCRlF$%L$@zf?D57kIrd>4d&m1EX&+R0N$+-x0n zJ?@$9zKdf`=(z&kMCq+yp}wY_Wx$7GhzQ)OLj9-7suyxM&KR+f7tsv~}?q$caQS53|-aj9&H)6NrX-)SVS zP6BWPg=#>auVBSgt}|o^F(DFebysDc#nMR85(h(jNUbU< zUUvWL(X$u{&ybnhR!S-iP9?WL-q3x|q;L`n%;$lhcYOW+dcz3AdW5f0P?o(F>;2(- zTb4AB=kH)q3z$hY=UgHC-SkQqpbIl&C@O;o0fXHEgN@!!*V+9N`Ur9iWXl_#;_;~= z%JLM4Rd*xut7}~6p-Y^hg!8=c%ZaIU^~5K1y^*lC&f&=84ImsI;(=(>l{apipKf~G zkC0}a2nicbPjT&)#-9`C1F^++O6fRhC?&{;^}d#-zZy6(I{Pwi6M;YsB(c+f;(THA zR3s-|JtW zb6LIDzk*V}Lq3@K0R87v%R?UXUNZ*6gfT&%^1nw+)nC#2h=E}&aPIZx7mj)z`Yg3s zaWrF~?rvvHYh2PcJ{{11Ezj3~n&xK3*`OB1W895F|F3|kE@H-qb_7inO~a6a^k(1D$Oy1o#Q|4bLO;DNjl?A|DawxU zBkQ@q3X=YF1Oq|KdN*=E7O>AHWk=}%;WZ7vq>JD+z80WoM8r_+8rm}ia6?J@ z5#k4R_WM6_92n9OsP13=@KP=Oqv4EDX&%;4@k1pSJwtXfNpzWKa{b#d(^blMX6YQ}`}8El8Cm_EtudQyV=BCrMI^4WMVj2N z>koWW^nXlthNww4GpK7<6cICOh*sI1L4G0tt+Tz4e0iTz#>#y>*eq1sF#GOEORh4Z zB2@p=Y1@#yDScHX*UzxLPSR&CVz9OibuMW=e%VMD?jK7} zCY3QpC=$2<2eFi^o}29SHJ>>q^VX;72sGh~_;@TXD4w?YWbf@m$Mx zROfhJxf)G9fU96Q$bMN&?fULYC$(7?@iVIz$5uX>Qd_Y$%fj@-)pz>^^b32xtLR`SSl z7sW*(dG2I*k$0*puyosAlKy^Hr~8|Y)hB_V{?j^I94)6-Iz#MoF>dKD7m7*?OFFP! z$tHf?Hbsqb7&qOT`hL6+vr7hZTc;q9tL@@)5JQjbyxH(YrZHJIU3VERH<~Znd~VpD zIgT!y%Zrc36;_y9*7VE8IinNJIV|D_4ad+q!;wj3LhS|TcwEG<7hNQRs?2JZk$N_5 zy+jGtt~lJXrvKhq`fl!V=JHT=G%+N; zC+FLCce{rg9A&HSdmI@K9GCEn8jg-a4T`U-*JcOEy#{>bzDJF0GtramQby#yDh#`E z`jtnF4`s-aOCdJ;8}L;%3oImkyhBGSA((4i<-YdA$b&=Q35&ho4DSHIBNGm;k9ueA zb7a*=;}Ej`Jh@*a9G_qbbR2K*jMiUa$6{l|cjHF8RC9IRdAqNR`Nb%IZKNNBULtjF ziGT&she$4|SqDJL(S{|Eg4fq?%%kN?)&cDCC7UKOys@%GP^C6v#$p*p$x9tQ>z9KnjWkcuH2N^pR4 zc0&af(U3|4IO^hC&kjtu3(9G(DdHr&_k>!X0q_;(1?KDv5fBOuSe&rbZb9m@vLVS4 zal2;zWV_ClKAre|s61N(7y3+)#Qa%c0)8MN5f+fbo$GrbUVJ>NJyFU7h;-kSFB0>_ zZJah&=lTQrB@c8^Bd9cQ?YS5*(lQCcprMN!k{E}@(5R)Ab=5P!E)Yj#5eZr}wjpAm z(!G&sFjw1On;omLToz|$^P}Km@#it5Hgi}=gVgNeXoG+`U}^|r#O8Qcd6ez9edZu9 zsTBazFnVn#O%86ai2Fw1IMpr@6=ZHP`rrYX7>+b->ylu0L5@eC4Y6w*P&+0OBBSkT zX3nXFZl*0M~U_ktQRI~i2{%nJT;nlr2A~&C91nET&(xs92TQlsJa$T;C zM2>U3Ms~}}*j)~Iiw+4^J$lQYpS0hmi10F3ro9d}-sDLa26|ru{w(*H93#EjaUd4Wc3IXg5vb&!SbzTg>Ng6W$f`1DA4z0~p6tXrBedJPypFtI2sN4a)eguL$kDeQC6` z>``8PdYsq1w8p*Xt#J?Smk#XPSm*03XuFUf%vrRxw8fGgo?PArj5Fw*9s6(SoF}({ zXWON(J@AuP`$FOyu;LyuT_2)CXDf!rSA=ZLf>T8_Su5wSczj2@+jS%pT?}HZo?Xv# z8xcoZt_A4bW*&Gf<=)iao2tn&cJJ*5(qeiIqa~x8FR-|@?cXQOiL&+3E(Xyl0I(6M zg51c`rx`Lb&D#FO<#AoKi%pOE1(ORav)>kco7AaMZhlYjB5Z3f*Xj#)V>~wYGagYL z)Jjq+bqsND|LPs#o#S<&qn`78k;VC{To+-SXj_N++FiiJ-R1KKdA!PFi154)5uOV2 z__oW1jHQK%uDbM{&$+-ZffyP4x20CW7`uy&10U6_4OrW7g@G?iayrkgIb;j>F7;NZ zpO_u4OW_P?esmx9hz6JBhkS;LEL@=Knh(lAb{HFBW@2X#9^5K?h3J zGrvf=U3g6w0%{J+6D++_T{FmJI)@w2{zyNo4n6sSUab>beSJde;kCTY^?c)bixe^n z6+ho<W_vNjdGQfcd3jt5^mH}L3G;>(cc&_ci9d38BJLaqk@Uc*ee z5o9(R)n_GB`oLE-@a<8V?a}C(tyI)3acy`fTxKI2($)D>|a5b&v6-vLK{9nw7L zEv`*q`jUCWP%_krrpyo2JfOO<(uBca#;%>Z1c(RfOKcUG6_R7Si7*x0?d5S*6QXt6 z1I!VP8=4@gtpHD7anQyg1XCjVY9IU<2>3ieQ}9p7^Z%l718d7Mr3D~@9&+Qm%-0cW z=3k;f9O$J{22O*`0KmrHWW^9X!oE~~m6Z`$Dszzo4m|xnK8aIc!604?Y@|P_vRO$oA8x=?8AOcQ=A)ZGaEL&!$pSop=r8Ah8!55GsG z0O1^96aH)Q#a|@ee~!Z)Jzs0KXKE~q{syjq)b7_K?Sb^g$#zb!i^@OI*Sc}?t0rYo zNUF643mJoqHCo-3*@^$79_BwU(d-F9e#c$^QPIma5F<|8r$KK>?t=RQLnx@gtf8jO__0mK=XT+x4(mXxLq3R_Xi z-BF(pH>9+j6~kS%&RDg!JS zhe|OurTb2=2^o}hKms7^j3j2wJmcu=DkWv-ydxT;>Wa_ds1fn&4{rc)1A{w)_&26W zSzq8M+k%Z_*guH%98<9?wwp(fnp)tJr{6G$J6*QE3to^8R zTefU_dhR$WH?&hSdCH-k0{r)on{L0Lt?>l9Ly(wS?l|@-$Dk|`o}Xi`lrRsf_3Mu4M* z+86*&Neca<;&Qsr?Pc^$lLw*5FgHEBkQYF&c$>@Qz}wsezrAUmvwvh4FZ%I-MoB%upF>e8Rgh3uSNC_7 z{J1eky`O4qC@h(&{VizxMGZ)J|F6v2xAq)(Pj}vQ0?_g^*#^GuZ^XUnaqv9nzDynY z8G=Z_)c#KEEd+Wq`J~nu1dW?5i~dlC$F@!U0%UuE`~ENUbxri%Q`JB7`vXq@m8SXs zrb52^(bVl%DSOp2Q2YP8Y*FdjC+{y?05vQKshy*^%k7JC=Dy?stPu2&|CH$OYxdCm z2nhnvR~aFq{4BIy=>JLHYeHKHyiLC+;5Fj4cKLUXzo>qURB$={f)SuTd;#$F|5jj+ zbT&P_2R#0!6U}44z1UqUmAJg@B<8&`-MxzW3>AGL(gjRknAMT%wx=g*EB}X2iCy1( zV`JlJLrC{J&@&hy<#uI8z^;P<$sO@ARCe3Z$<_7Nh`HIofWgyjrbD|H7z7Zua@#fl z!B83JizdevLoVTdE`xD{QpG$~`=?Kz($do6i((gxZnhN<>sL@(EjD`t0=~xhc|w9! z2rjo+EV<85n%V%-*?nmsSrw}h((mc&Zby>!V@xVa^VOZD&w8RsZ4FcL#t;P@BoBr| zY=ah2!s96XoxmrrD>J_6r>MH;NOiDO3MNsT@nGza-Z%tt0aRuJ$;E=y=M` z-ZG$cNkCv;N6`vaG80yKhCy=qJaZ;Z+rwtX_eM81)zzzeZuvZx2TQ{PmGpLHOudgg zW&6LcdG|?#XGHSfvT|zIWBNc_P?n-f(2^nEu6oAaHyv$f&G$~f%y^8-!6jX%8*A&| zDv?P$4GD?Y^ksR~@a6z5HAMux_s1O6bMpVkxxYQn=Gpn6v z4Q}@jVYytqv$>R%ueoTotXnrxY`>`fRx{;NdRs$6)rFf^TNuWw-AL9n~Wm7R={KV#3aO)N3uSENM8^MF_ z^K0V+E$c1kByaqV&Lh$_Jm>I8uizZ_ z1_MIl;Zq#QqZ$3*50FrJ?l!(0S;(hRvEUcbEIkle4SOJ;4KPG*ed!6HwgwC^5bmn% zf^BQpUdy!Y7=IdGtpE)#?}vG6IhF5w^%V?Ev+Q}30^5%@FyG=2o_J#)ViO|MiyfWP2o?mDw`SaQ6resPvgNF27w^GNl+%6lT0kp zsyTbRtYfm0mLagtzQOS@oP$pHl(~dWRFlO+d?OH^`T9aZ%Ohr_+H*rwx&fTNVau}s z+QB?m`);!OY%Pv8MXxNI?5vn<^e};|L9++QpJu}1WD!Wzn|ILViX)rDJKLk%#U4DwJ@62_O-&TD^0Fbg z(Ql(_-_KEy(w&5Ibz3W?J@p1ys%9t;r^0`$3;dTnBIqjGlj9|(v;HAX188HH%{kY` zmQMyOZ~v|1AQ@IksHK?smmK1s6O?D~oEyId0*GL8xBe;~OS$7O?~JIie0jV$ir&W%-9-Ql%}PVmN3gD?P~=H{_nTx6 zOhE~Ujd=_%_?r?Bdi-|K;rpkiq<>RVu6grD_wPCvEXxfa{~^KsUr-SI+ogykf888Um$41bN zv584Z;NXZ!R;44;qWDWX@U45-Rit*Iznr^->VDkAT$ z@4j)XroYC0C9}WzRo^&$rcoD1SEhl@6xnJFΝA_`2@Aw6you`W?Fk>6CF-T(A)F zd%Ppyn?H4%&4QUe1@^-7&h8vvHiqT+@h>1N-6n3j-*I<8Ee~=|&7*ex4mELvNgab> z2}wzV^3SPk{dq|e@-M#&yT4rRH;b?M{3_y=RgG9~T{}B2!-1g1SrB8X@6H}ud(fc~J89X8AhkLlBr+zy2R7W%C(HE3Swee|=#iPIw{ z=W63Kb1uS^y*a7*rs~IL(_$0y&gbRUre`1aeTwynDLJ#)5tw;;>RC(Af$rp$u_n{B zE2VBHi-c$T#j?cZXle;d$#}VUEfc60)TbVN6zi zwm`ZT+4RblGABg1$A)Io4eJ`4RQky?@9o<9Bo=4+#dd(zDHLpDQuYZdP-qwx2kWIp&w4&9Qwfd4Sh(E4GWRMAcLQivs)HMOEn8p zUD4Q5h46a_=OZKsm%u2g8 zCI5!g&hmx!waa&LfTXGRU7gL@@8@i|#96zHPu6f<0uFbU?v@*K&vhFOh?zGNtwF2QEXis>+N}N>GCpQBbviPCTD})+CR!#pBUosQ4 zo+7&xv|o{6cLuGJerXMcIA*dv*1+oH2^4a~EzqY>z5b0VCm1>>jG1CGt=3;+JwKMJh8wM$eb{8iejs{&=8d zYswYu1Gj?CjhfE~O$bJzT?hISo$92TN7>9hIK~zrEi#1`k0QwZAfzb69f!mnE(Bad zfp`>Bias4kD&iei7$revfD@ns#oNrZ1Hh|Ga&o}00P~L2R9XV>O9F%giQ4|cQ^->8 zlW`Xy-o#A$UqpaC2FNBPUND=_RTsUFJK>Krtssl}gVEML+(Ao@P;LspbpaUSg#)T_ zASy#*FmLJK*;P>0=9)pPT->8#%(Qn$ha_y1*}t*hAcOo@9q=ZGKo=PJqXBfm%YpvB zB13_ToNR8ulK*#_!T%~({Zmh)7mM*vK8~9M9spV(fdMo86KS9u;a9sfGELDkn)qg8 zczd;s5cu8@SmV!=ut4QV12i(>u%BRM?1A7=G;k<|PAohe0OK%DZZ;q&kOA3_SMcv( z?f;YB@qdL%>ujzpQmT1%h;E~RdAs2rT?Lk21=zig(Yk-cbdBG{QrF?tF3|A9p`$RqN+`hfAzBu}jOvn7u91xy;?Ca|Tw78vZ!u`)bj~>|LD3&vms&0||9cMLw59g1ZI^NPY^oja2qf39=0- zuJ6HibsYYr|H(T$wbXe!IZ9J%Dgq;>E)re%h_@$w$mz zAHP$1$rc14Gy40f+Ece=$snfg4NaC5?V=FV9%>*w9Crp zqgg=@t191NQ?y<5oCb4@v=HI0Zn6f|9qMz}nTdB1qLq%J9W(uY-Ibl5&033@R(fwU zd75;gJ}~pI6rg%6YkB}eEn45)2s1I@7$(bPvC}5Hg~|agBn2);njZLE7yCD?O$kc% z~^Oz)QHonj5uUl+un2CH3J?|?@P zzha-=lFM@CR%0#~!HGAMSJP#GZ^e3dR7t)i=teOfxOj3lGj;HBUds=%ES6jKmS@*N z#%+XJ5w=~B+m4+A!Fc9jAZYQEWr7+fMQZInk|JjEK6KB-5LY^m^$jXdYdaU>$gJ{# zez+bF)}0jEKf6sw_&EcE&rAC+tyh_p#McrgE10e&^h@0=m8*|>2s|)2S`WlCsF|;$ zhYBP{_^c=0m7^;arG5L6`v+!=NWU;e(Vas^(eb#6b+)Ly)iE@zH%vsa{x4=ej)J0*DK6;HA^prz6C!nIz)uO;=rk zG4ydTKMjb(uzg*ANrujKvoyn`-^>)Wt-*o%kn|u}n9O@C?JrtP?#0t>7`hJHZ5`hS z^vozPLU9FQj4;5TXCerg^?wk%?e)vwNxWbR4sYnC{d^8+^kO8Spq2JC+j$FACOD4mmRx?u`M=6D zcaI)nAVKg}f8grcJ#6zCe9t$X+GU3>dgo9Vyn7_1w&+&jUgw4{9j zpC!)BKajX9mFyFxz(DvY<|u?xs=%oq_9{lVxGs)g1UYzrxoR3ERA^iqqcHKSQ#wz}IBWQbUSW+4Klf84OOs<2YWlE%mWXX!I>fMu&-`}q> zSlnEZ9qSfzZ2k4&PvHmFLoR1VEJBAh0VY=E2}s(-*(EAzjv#CtJ0-&T6lF?2TL`K& zb#)AdO|HAgm_!$^2Zgfm+@AQWNITvgbVfUQ|!zb$Ki!) zQeKM*RgS+-(n56Fgx9nn(=1CLPbBD@qxd#rA7Ho@uYeLU8`Qr*IQA7i;2LAHdCkm# zIs9Oskv6DF^e5lzw#1gyI3s!dLi%=+di}wNN&3@oW2$ah4cn+js3W(B0?y_+EABlQKxaVO8R@8Jzek-!;v@%ag{) zEzUh4<+)kfH@8*VAYh@-(OqEGXcv#MNlCJ{Q22oTlzE~Lcs~OW>Pp{tWzd7e=X#=o zvwDQfQ08rx@k!j;&Uw=}Ppr+JS^Da#`+YiG68;{FqR~i@xpd)*x8Bj|mn_9k&ec73 zE-dEEQ0NScF;u1U;CsydH3-A~?lRQ;qW|+?gAfe2%>K*}of65$%z=t{pp8go`pkM> zQr4vIp5HF53UF)O?!~)!HuTSU7AmmP{oW_@|Mb|EA^J>d`OIKl=rAowPJP)Ipex8s z^Jh#o@z8xg@pAWc0s7k_p(1c`I#&>aK>;1_a|#s3jr&vpL}Fot7;y>^tCi=`FL~%1 zlo&f**OU*)8*h7tP28Y%slS9Dy zI`a@mU$r*02~Nz3pO=XWf~ay?#Q$mM{9|H{!#G|kyMC!ZDq+rrjuyH6XlFxFMyN}d z*4o82v6=je#-*IQNwZ3&W~@_f)kV^;RclA)kY8>2H9s0{*{-;d=oE3~{d}))iJ3pJ znfdc}(3+oH01nlkFfYLg8)q$JdKk!+m2&Ca4 znrni1!BxMB-M+E$6VCCAmUk+WtmAOfhQR%ll_earw~TWyc+wbQyj3eqvqi%xpc>ID}C-Fjc(8sU^XR?ri@1e|r)5u9-v3ORPks*ALs;JPz zi4T#JnBezP4cyHA@+pM~pG=~o2HVy@JetMoHG*yM7d0=hzo7Jh?m6KF%}i6fQO5?{ zYY4viy5Bp2ji=SCc`F=p`{y0%==lgtc9%-3b97B+02hUOf=cMVYg03`QWnbxK12OP z572p(NF#*D3{5?TY*1L|BdYO@Y`i(%!qJgZ$KHC`qYC6hzVOO$mEt*egifD3x?GD+ zM|Vly0h!y|%3aUrH;8huD~8tXC!IomhCr7a&=&=*Rc?GFH)afe$jIN(&PjVMeBqv4EE1FHTV{sBZu3oFUjxZR|2y#NK~^F@HWpac(uFr%6^~Z^!I{h&+nQl zC(Lbi@9lo(KYPcPXhO)oJA0;3r-|`)o}M+TzFa6fQ4*DxS;h6~QmOln;LGqMg@^5- zfBQ=l9k$xEq+swFq_m{!iG2}^VkHBHC2R350&K5iUQUt3iP1%WD$06LWy(0kP%eXt zL(@PITscB&xoo}aH1!k-YxyW@U!t-WBQeDd_!WE&+Q6CiJuC4S{O#yz*(i}Z>aUqg zhGqb*y*sC1QR(errlo5(1+tqp2E2a8Fi^V23*98P8B2zQ-~OPV0JdGJ%=R)FikU?V z1mbEBt1+-c#&mduERE0x;;&_rMMW%}YDK?nbOgkmA@?TIx|` zp22}!Z5zJx-f*E|5+3POEakDLW(m``@)YXX*{n=^JTf;_fM|=hXlAKIK&Nz8?O~1e z2F0~O9yWZUvM*uKLRpitq%hV(h$4)=jI5O~wp5BN*>_ndWKXiM zSw=E;#@NPl4srFpmf!Q-_v?FqpZoQD_1D$-tmpYT&f_@V@8f-(*W=6TN(c8b?Snud z2QOVbe+2^BbqWF@ucssje{ns!;sX9d=5R&nEF`UoWgPsVuuxD_fIu=s_OBs!gWv2X z7q6&6ATC@Gi04BHWCi@m^E(7`Ul0QMVFZDkK|>%%>|%;EWgrj}!As{Au0AlBjFo$L zL(g%_OmMh@&CV4kUqRrA)^7FMwL9oG^EVpD!C+s8qrKv2M(RC`BD%ZCos60GzOGcK z*f*&lIB9z8p^x#gN3oRj4E{{q$wuBb@$#P!P3gaQn?I0r=6=eLnEA>3#8kuG5k>cx zh<}_adG;5c%Ytk>KOy9^6lou!wSK?+Wn(q+ zIQ{0ykj?89IXt1vyQO{3Zv6yDnlQS%b}leFP9B2_qIiMeAl)CFb5R2V3wNgi6S{Sd z*Hg+tj3Rk+#`Yy|xILjNWfWkJH_!Jhzeu4tgXo#WFHUrDR@LvECvS9;;;dWe{8+Ob zVbCWQ1*)BJHwUd_hN_P#}niFi=EP0yCV$U zohQ3vdmXjzhX39CbITI+G1n{5eaLs0jgOgn+aOhv#_us;k-u=HJN=HpNPp z)Svu>()${r)&fsY{lOuOT)6EqD`-lyU?6+%L!jsSrMlKcjc>cWx+!oGopLMja>=s( z=i^>KF*dg+Dk6R5O3n>pL-9|!qo5G6 zAqq=sGzyyC;~OTejnkC0A4fkt0$25>d8$q^gNU_jDUcvT>e}AB_t4Y7Tn33Q(d(=t zn?z4$Gxua()2JcCGn>)W&p-g7Mb^(ZwtA%kP#`+hPiuiMKR4rhm^Pc*;! znsl%Ob-(iP=c6zNNF+xf1RiJx@oE9LR)6C;pV88Bs}lU1mdow=lUYQ(k;P?7QSf^P zaU)T#aESuhIdUcIGu1Z?LzHf16dm}2@B=XMLjNk1n!t(uvD9$uSC3DmO3{#}VFnSJ zqWk~D1-cqA{M=|g3JQZim?7?sRB}xwU z6Q^8-4F;0jvfc5xF0)BDskZ3qr_N2ysQ20_V0FiwPq(z2fv1JQpjUxVuMm@ajkjGDX>=RsV)wDN4vUN`h9PH8CL zN_g4a`x9BXh|*7~;&puHgHr=#1IUuKcWA-Yq@=EiMvm^Rn@*#gqBDqRZ;#OzHlV~J z6!fk)hJCgkoR)4Jb+Yqq6lh!=519F6ES{TnxjsC*qh9AeO(r+K?&)MJLz&o2*z}b~ zLv=iM`2NUgagVQ4o&9OuC$KM-Tb$4DRm#5`y;`GN2EWwaLypv)d@bmvpLwDl9+Mu5 zmtK>)pxOT3;`8nhLdJZ+>(oy73*SO-r;U|dnR|UJZG&sA#Q1i&#=H{4?N%!1lAaFP zE(e3#rHf*`lVQFGJJy17K5XDFjHOE?wjk%NmAHB3k3@DkcP7TUyG-|&j5WuhSRd!Q zp(n5HJ(z1N7;d{7^wGm(Zns5sy}_&izSrH9JC67ome}R6`t&q;y7TJOlJ7R@yc1;; z1*x(xWSo!b?IQ?MDZcuo0K=xF@S}ZHJ~4Gply>3@Prbs|$bcRPt89sD1Nk_$*0={Hx|uoB zdGUGS#MQgJ$5Qyyl~$j6peJaYudUEAS9V?Zv6mmxI-CI4wVZN)H+^g?4q48 zHgr1}QDr`mH}I{Q*B{GV;1M&Fl0SZU=x|pvf|yf!yaXG9Ci9i#ol#m>q-V+C%>;P(%y8|n8{C{ zOG!{leBTE|rTckOtDYyG>0tlgS{Poqzz>)Hg?XI> zPMw52H+0Aq(|YDdtCd)NCFi$a;~jeTBcbt+ur}#3GSwyDqu>o!T15?rDLTuKF1zH9UehqUJ^F zamTF*A}k_GzjUj7@<m0Fg)J;f2Y(2~| z{Y!!rqhTj^ehfBiX}~aA>(0Iv+cberoLMvU(ARr!+Y^=*2YMeW2fDs!Hjwz*o>FaF zU3u+ZFqjwJ+G(>3cTKxu^ytkhTn|5ged|T+y_5b~F;Ua_w+r~JyfIAhkqg;(J6`iB zeK6~isQ;)ZHn6Yzf@ag>)2r{B&snWz%oPovl3L{GPVWp*JJdh;=_Q_%Pj|qeFIa-r zPNe@?Yu;dFORUztNpXic1YYlr+c7=k&ec4_HEvh18ey8^r>QeVS2-;7u6xw z?karC@F9%-aoK7z$`Pp3qjihkBB9#z(h z&FA}mXwr-Klwfe?yj>dg77jt@d?n}vYR1~Fr}Lv6&)2wh_D}1$jvXS3n}yh$n`h6} ze+XX95btrk*BB$dyI$(MRLf$@Ko=ncPo~@Ow6kJj!R^E{tRmd1%zEAV*t$f9EavOl z(Hp9)@9Cvjs{6HC6=6QX8Y3^_J7RVv?I{ z+GH$U(TsPTtj9hT5vFUZBv+(U%Z94jQtL`;iwANAl=@frP8}%3%^`JH-EvE;Sxod| zT(2%^N1fgidf!2-{~MH;;HIvLJB;nG?1@%&P?FT6?=LXa)K!wxozt{ta(|6YClK3u zI}R~ia4ycM)(#{V-*6s!#kzzLu(DnfsJAK`dW?VIO2}}$rv}5;W3-0Pb@DZS&k2)c zhT$vr!csdXN(R#nN{aeya?j(x9$FE!(n`y-#-0n&Of~fJ2&6f_5zV<1 z(x5SZx2;==Yq5^Qjclj(PJ>K?z1-PL?vrJ@5i8x%$<2umacv`B)Ay~F?({sieSPAG z{cQ*5w|Zd-gQ59KQX(_;_(zvu7cAT1sf9%XeEvT5)tYgJ^rIPdMT9Kg`tg>K#DlNmO(&<0J+Z;7T*FT%V8wRe_QKxkw%jTYUnXW~= zovZ$WtU~4OfrrW}yS^P!?Ox11a&tAPNlQy$pUf2A_v^F_veV3iecS^sb(|RLc6uJc zE#35v3~p^%JLJA{P2|hk#n%J!qn|Skm&O;Oa-q?Os&_YxWVKezpX00fG3InTUo?9( z@vgg|xnWQGftKk$9ojy#_+|{MYjk<9?NMw#U5d+bU+6@M-FRoT{6QGDqfY`hS5^v_ zGuZgA>e@~|`bWz0D#Kg%+E#vqqz`{eJ3nvi?oI6_~gCG7Dx%)`ZyuaOj%gbWc>g5F8; zS~uO~8+15Rs)lk@Uy18dOT1D9&DxKYblgcH>7ywRkN$n$uG)v{vIxf44&RM7i}348 z(tRsBj5+CbfdN*{bTk$Mw_czZB%=gp#SUjS&03a-1VJYN?kS<1#iO~ODoRQq%C4l(21HLgL42B_xa6$(;# zw$If-IaGKrVlJIZasmqF_VIS4mn7s!iAN z78`)iCXYT+m!qoe%;_mvI0Q9e<|zG$KL1LaRFAF=;gz9))4{#BQwPqJqZWr1(>VZ! zIQP9}2?<_cUay6gJd9HHE6A1F`z750I=xoe5?+OR^ve9@SqQA!*bl({fNu>v)aU`{ zqi}xvwmFYd&f9S!3~(Haat@<91STHCv5)%bMSw8qAW~4~g39mxKgYDd4$uu*kO1{( z0Nen0l7zN0wAqRMd2+U(hIa196~AH3%H?IN99ReRj>iMl* zUdiAbaGh=&?F45qbmCkPybnO2B9ZvL6d$(^p$p#m)_=qJik$z(0$#&`r)3ZMwN02r z$VfiXuEYXsM=`k-(E)3*P=r$YZ5G9leBY|MSy>Ox{?G zcdaQ~6P~^2u`nHF@cQ%yaoSa_84kxU z3UlnCc^Ty`&*xi#;^i5_EYNGJDuFTFtfMMmB1=wUx?Um(=IJ>YgBCp5Qq# zl6fg}jE^GG-p9reF8(|ToWN2AMk#ItLE5e!d~a|RmS9om{C8iOu>y69=r~Uhtg1WD z`DZicBxF?eJg?gO&d`_V?BI}htj{$F*~c`Uumcv~=!b$$;ZK%y~Kf!tvc;a*^7VS=q~ zxWB9r5o=Tko!>t>i{N+Jey;>oqcnJfwf1uF=k;*IgV@x`LJzwxnX}m%g3WTH!fqSS zL-+2iig)LY_P`rXPiCd7X^p0%Tjx|3V}m^=_L{ifY`D67&CKxuHmIIesE$tV;(T0` zw_BDT)tRhqs$9ODl)%)6nyOE*_}s^iuFZ{eQ2t!B@@(YeNOW8%t40Q6?i`Ip$lDBq zbe)uIA;I^&U(ZVu zbivb-DF7LASLx>hOszTlWWkN<%?aEyJ>GYe$j$3pL3>OHUXn1~zx}d;l%;>PZJb22Lrw2Y)pccKX zwQ;Q)awT_%s};_H+!OO0J`ODJjUhSY33#3<&%}O^Gzr0PeVRe|pub4*fz_TG$!#MG zmPK<;)Q}{+VM@C!qs9Uh141?kA+}}f__h?C0oUo0vXzvwW4 zMAcEktr_#9ZF|zanP85VZLAvq8SRJQJ2}2hpkh&HL_dFp>P?Ll5@_^t@FwwgS0;2lj@Q`W^Yd)G7)3mD2`Q&lXZ2>(xIw&x$Ll%1rS?4nRE@( zp{5}bq#{w*6@wdqZ`Wwgazn@2MizIA(BbbmkIoL)EKLvOhuc)*?$7h#+sYPEUHc=t zT?;Obce1>ddbng+I%J9Wmo0Rj$I_%{Cz^?(ASxE`&_>v-fOVrqi|S^(**gU z(QKEV$^MEOvD5lZG?P^hA5z`bP&`=<4~@*9(1U2p_?GeK<5_Fb%z`2aV)=`L$P8|L zQOOXu1YXP4c&cLk$@-^e4DP=4LHnTyy?t_sthlJNjP(YYw(pC}j1AsMy$iBBxTb{9 zXr4wE_#`bRMLpN(=YLveykZj~BkEE0V%2mFG3g10+PX*FQiVoUZVDGX@wd^tu-=+3y`5 zlegjOl@W`}89xHUM!gLvnW{PKu6)&6i?OONY`+1%@J(F9^3yAk=>1VbbFTtgX3z0< zEY)^~^v*9kOb?COVZR+ZQ-=3zZ$QC?FH^m0sMwopi-FtUNld`=;aGC1;^Vd+KfLvL zK3|M%MZZ_jYM>9iK{jal1=hmBm5K+RihME_k8a6?={Y%_#eXb41!Zo6)wrS8zxq0| z+V;}VLNyvEyZlBEG}O%1ilSz`lyR=UNsM3n{i;x`jNkpB4ps%9_Da_rYgN7+PyI4V zv7+DhGE!I0rpCo=9#NHWlwRbLIXajiSauKR7g^ANT22aMHCsmcCR|R7vW$LHe<%ot ztAk=x8*l2go)4!J*0Fhk%0*?+2_Kn#YZnQ%3eiRCN`13}K7_VLobadqbRIyqcx%$A z>aZBxyjZ@myXiI6#~yDw*KT~#(~q7TH;5(zV&YBjx573N=8++HF?3-H77@1oeenKO zcdrN!`yU;y%NMTW-z$A<6;XrTvK8*{bHBbvb{x~q*)5~iCD;1F`lax}X#<|FYZWXw2wG9HvfSnVF^v-bbZcaor;A~Ki>l%>Ni~rXTi_R7t%%q z-S0ZQ;L2H)+MFjZeKfc1mWAu1WLaBc<9J~It)|G6(lwhX&;cZMW0#{YM$;fWv+nqh z-k&AI8x*^XeA#XI?Q3+y(_r(CwP|Qw&_~Na;oWME!MvtkQv5z7Ta+Q$VkPQkbxv<> zC3EL^Q-6HS{YzO_^vh&xl{r`31fpt!XyICPh%xkaMRYTgG~7DYe}5|4GYOE_f88w? z(LErpEsw={^q0V7NnV*h5)dP`T_?mTRZ*VH8Bn>knfLkqS$sNzrmeO6ML-HyeFBvG zBjn=Gu^;hDFI}l4zC3y^oNwa%elp4%Ai=Nx0ld8;yC(-T*_m@d641)&32hzw2=^$g z0$4#Z#B)6^#i`$UtixlG03tKgP2n{uVKJ%%e*fCD;f<mxnp?$ z3+C5MaK+^S_0eN?k?SYv3wAw7+pUlz20o40 zxPR_;ilh4B;!}MJGPzxRAOxd3r5K)Cc%vymHbZ+`(v}uPjCn5cVQoSNBX>wr2*4sH zGWfs`q9E1;3j0G_x%Y!)-`|)Vq!_;f7*cF2W+DO8zlCidQRBR?(ZK*v6g{W269e#2 zEXM^w0xbYg{5|yj1OUY`|8W2t->68D>2S)6T|1X@q#7U-d$zxOgZ~!@Wj!lyHcR#+ zg2Vr>S=l%T@DYEHrtj+P`p5Bt(f(I}_7>F7>zOpqZkc#Z>2-lFBRR8M@17sUUawyO z^Z!f|0cfA?+~gl1uw!zKONqgI?ZoRKYm+xZd0q=@J9L>H;`I$g&2I-V^nj%J+N)u> zNn!xg`UM%Hfp;0Ql?Z`qrK*a4`4jUX;|*=yDI)W}1JC9Yqn}T4i=b382 zAwQvb65bs6aS&+?=Zh{k3xB(Ca<960INz!$vXbp3pZ+eod|Sg(q+Y_ezB}yu-*lCf z{D|fh|Hi`jNm0~n)zVVjrX@#*0eL(;BMQ69_82(LLqC@kmD3@I!`K5j6Qy|`cP7*H z0+Sh?hScYramHpJ-bx*}Ewnft#aE?&UCDNQ&nMOpkM{BYv;&ry!gF(v!$K6GY4C~f zmRzIN^`+g^Q}ZAnYbyyZE)r(c%IlDIbS1nT#b`U2RI!VrY(hF8I&{gyg;syG99D>a zb};8_rLwNtyxIxiZKZ!wC&zoG8Wiaobsa=VlfI7Em1J{yVXAcG?pDEXsEtF7tvxn5}69j7(Z zPd$eonkF`x5Mx#jA><5>kg0uoewI^IdS&O6Y%ql?+$1N7j(l@mkW~* zA}kx{Gkg?smH6#~4~(>Cr@QVoN^qR{dZ%B-zpMEPh_t?!OzHqcIYyb|hBm~E9LX!L z7ebB19qtZrfA)2)_^hh||5fJ4`TVTwg+1xQ%FDO1q;5GFn``&djZqVLq48MB5>`_U@g7O}@$wAM0H;q1hkA&IPIm;^PZ~QY5gY zM2W`m#F?m5e67G_KW=E0<5;X^ky48JWF4tU3yALHkGWKVgVUs_yML4IT47O&b7X|z zVE4*ok~UKdw7MaPRZ5B8{@gxtZoqh}AA3y(Jf{~g?XCWVwinZ~Ib&CH7kiL=LApeL z2Y*I0bzX4Rm4w)r+bTdb1W@o4&&qd{gcmOX%&M`v>0DiI(sN|o+N3A~4m}-Yr~ZZO zEl8L(-nyzfh&Wl4vGu6gYEqMBk4jD+rDSlwjD%BLHt;o+A$8-%qUO-uqol ziQJt}y>?x&OA1>6LC^D0SVt7PE~RZ)&HF%;Z$JOAz)TO6Vm+A#n{FmixqQki?F_BS z7~1k#WXA|4axC<_6*0A&(RzHKj6j66#abj#W#tJR-*_EEKNECr9GP2pHV zRfR*NM9GSq#$Iy7M{&jG_0@jcOdkP_D0zu|bmL4kGvCHs;gagc)HHD_Zeuxa@?H=K zNuR^Yn>~p0acd*o5;nbrDW|ekAK2O;5X0rizH<`#BJ>O-L>kN_e=)Q`*(v9q2R*Uw zArsAEMVudZ4_zlNm2FHFPj@Swk^vvdoq~vKCgLXZ2Z-(YrHfW&cq{Yzm21aJyumkG zC?_$SJnA8yH(w2`LEW&`dko$;bMv;U2#ZAR^#Y*Q1K(u<1BsTtZHbxTWMQm;1Dklr z$juwz+Q>>0BPuCN?g+tdBsas%D{)t?KZ(wg%1aU)UU}i!aZNwn-x+Ma)`E`U-0R~TCo zFF$43DHqjgE&hM9*1yo-jGJlpCcWY54ZfNJ&B1NzgZ(q8N~TJSxa^Q0WV?Z2#{1ZR zgHcgm)J^Y5Y5Q@N&;1Y?C61buLy_$Ro-GETmKX$@9IhG?wK_hr$zMA`G=8Zc0Pbn) z+xUk)R{S&V4YK1EcCG|JXteHGbdwB7I~zDP8te~&y#;ZR)q5B1NlzXNB{(P5qNi37D+Re8cFZ8{B>z{j%0ltof?6 z#rMQAmx957>fr{CD`F;N7sG74-viM^vcC>rFtl}U%@9an%v7fV!qh&m(o3PHo#LF( zO{&BKvG|8sA4Ay>jQ}Yxy@-*z{LCE3a*0+AO$H(^FXM z&4u;j&W7nle<^3`iT~6+fqySHqw^s$e^yEAe$PaKgpe)Pa#U%uFxPNa!141nWM}{L zI;20;b&YUW$dpuFuwCS{#rlKtod$br94PGEK3gj(b{N^od$!Lb7+M?{Sr~3?*zmkl zDqQNBPf)sHnN83nq;@SxcDCAmYP5MWrGz+A8*0xp8eGHH-T_atcCv7i!;|ib-oTGOHq-jM~hfvq5poL*~J4TN@)Z68XbCcBl*ux54$uOq4bKc6x z&`mi3IdV8Ix=`Lpr$1|1S&Cc4Z3*!6*xwxAu62f-e;6m(XfN0m~!wG!A2c4Ag#)ITtR=1fVoN z58LmsDsV?3P}_`cMs)|nwzz1=ud0;%)d8aGBqOvlh`=fy{E?H;$zHcpM~Tp%*dEp+HDglcd6j z)ID;2!?lsvA75RPy9QvdQlj%ATWg1z;mmsC83chkTia+1eSZbL_J(w&a?NZlaDsrZ z{|DX1|D;zdq3qoFGPp0pVB|Xm;Mv0g`Uf^HNU0iBUIX($F8*lK&$p3vS)e>8o{JNN z0q9K+P`GA>2oJ>^ZHDwapnN=XF5GE1HQ*;c1M!WC6o3iC)a6ftFtM6INW%;CisRX{ zB)ygg0p)QERyqTi_$Ce@Ckq-_Eg2}bAFW#|U6Lgc?p{a=?Ub;a!I7t@^b|pXII(dm zaRaDr2^&waWMn`xI5Qu&vBoX8{CGKI+I^|GY-6=-V;HufYxsocEIW*BDp4*zCS(x9 z;8E;MOm7L?=b03Iw!EJLcg0QmWOm9&+;t%lOYwt_!J76JF9U$QtC8nDV9Xg?#wD(i zDp?EHWxRawDd!uTG6}ooJrQ7~2!6%vtps|xf^<+X5V>%dh5|RgV!zUM$S>A}<`S3R zB~S_Ddg?pRZj4&eG*o1odzbYRIS zb}?LLK@nvJtyoELaEQuM9r_>Cy4}^m5F=-Q^XdP4`EUW@srp=mZ(dL39=YQe{OgMY-k= zy89lHgkeZDkXjyst3p8qf3pNd$k@_45Hd&_x_>D_0Y4fyV$uAfuheaI4R4Vrs-^|c z&dloqowgeL!o^9#dmv`WT}qef2K70S>xZ{pGmv2dx!>~7hQ%6g3uTb?3~o zV78$~96Z+mzerqPwK()NnGtTSI1b8DJJLsF=kg_S%!rbL#tWIubNsF{4`v39mPj3Z z?rQ|VytjXGaULGJnHo`MEVnp(LI;23eMHEYsRD^`F+tvG-H-LX*5v)A>;7VS0_~ZE z4B@x-!ucIop!O2a6!yZ-&yxw1o&e9}B|S6u7wWiNVgL#1f#0dkDk7EcZXobg@Hc!6 z$+DhZOjhGBs+m^l9K`X0^CQO+2IK6*!-=omCKxQ!O82y(9>V@L}y6 zqR?hi7i*A#u&}~wbGD5&oerRRD;l0Kj=?R~pJ7`-jNYjGc!yuEeeT=Z$CPzt2g&Iv zZoB?^ESB4O)Tp87xgV0rbs+0JyPz}(3tevmsm?*jyQt`4SkxtA;R}zvf+flCn7RP- zDx8nX{3V-u|8b$y*95$5nF{JvH5}mW=FO-sK5^w%)H0u1$hAWw*0*3)Z0--Wk?8yi zl$qgrKmZJuSMZ#c8i;4^kx#kSjXh>a>xtlmr#kC}Ei=pQ;e*W-_RXfd@4NP8d3 zRR{zay1}Wq9z0)rc`rJ5Rzqa+l5J9?jcfShHHxgYYsaT#KJ3afoFSACsrWk$7q4l<5 zAMc!JITCQ1*l1~Uz=FvSZqQ{kGuDS)8-2|3q%afDQ^C;4nfrMyTg5q$@+>_>i%D4tgW1bOXp5+_+hg)QXGgMXGwj)Cn$o!8#dm0w3FtL$k<`XhK4s$!#c{z zXj(#VGXN`J9L#QpuYx9cT%5BZgEUw%DdamLX`H5WbxD}$aobmBvo%2CFj;X!H?p(1 z%!NhN6a@13dv|JYiAqM(GS-AUjkAbNj`$3jG_4g=79em}17{Ih%{NTkcbo=bm6rwQ z4ct#+H|XpJ0a>_MH_-9 zI#bX{tcJ%*D<2@T$!NStnaPLyF~tOcZ4w*z${zYSI|47_2n_<-%rZy{cot;USAI@UX)tSsYWitq-(#(?}Te1DgErM3;Eh}MT_$gBVqpbdSKHO0oIWnO3 zz2+RSL-v_Qi2;`77&96US_&ZZ?gXA_cP5+60l2l`*`1oUr~GN)JPbNX8R$=vnPkxi z75#vs`{#BG-!A}__I~Er?cbi|M&OzXN}4}Zd?i4E=Yoi*+qvebDzMI@96Q2V`Ikq4 z^6#{@lJxuk6-$K*yztiC4q~=d^*ekBSbv-C1YqZZpVPk0u@N%1+6iV5e^z|M`M25$ z;QW75e1ng?*-ijL^q&;pYd8zJ?Cwj{JRE0Vo&mFS|6>u^ju;~!uBm(;2>dm(sB(pY zz+c$t?HY-$CW$dl9$~*uP4FNky8Hj*iSA}=LeQjRahLU`(x!zX)iTwQf%RC00{buB z6#p|t4AAhiZKnSq3yuAeNzyd8C26m*kW+VZYg9O$4o zK}zGj42g3Q+R{|yta2Yo6b(0mByj)Ey}B^2HIWhvwd~dKP_)`X?B-V?s`t-;Fe6l0 z;I^9AyCma^$JK@L;d7NJ#Um#=(wDwpjNshNjM)AK-zbA5jv)iWCg*PLI}S1-N5{q2 zvl+Gl0do;X$7%egRSa$7UDvNU01U{p-x6q-+V8PtAy1qzsJ$zNr)>sYCY6 z>eKujRODHt?%Ow{wzu~j0iaw`^%DSrKAc(`^qRvZ30+58td7&RJ4tPq(ZU$`vg)}!q56*Qj|Db!419SeY2|PB3JpfZ zOH&*Ione`R>@UIQA6lCN_#LU$U!Bv>m@ssls8+N*L9owCXCMQp za{g>}Y2`GE(CLZ$5H^uM**p|=%y{i`i_M3sBwE)kgd0G=U{li~^>8yb1~NYO2?=M=Lq8=pTNrx6OV zcVpMR>D%t}jS||@?X0V9(HyKCgA}QLAEF+p#(`(7NE!Q5qmPjlLRU%EZ5VL|wK1jx zb)9RCBYuTH8UYJ_fpZ3E+IdUw3MMjuZodF>&^UCid}C2<{C1p5xQB78($vrpiI6B; zpS1Ou&>wJF1(j@%jdgueZJUgOpqntjtcg60)Rl2id{|CPNq~XNY=$>zEgl#($H|pB zP50+ob%2Cp7Hs3=zC0R%5z{2aHbFfQ=V}vtA1fIBpujJs_weR6MuKv>S%PTTy4J z6$%>P%(r<(dOo_Kd%y{8wI_jI1VCK?a%Mq6Rh0%Np7~HP))};OHEz{uXAlmbzC=rH z$yT@6kiP`8KkDQ&h%NQv3}U+r?`NI-pX1zLBP|djZZ=T;e+;L8lF5~$-fjvTJ)tR} zK@Z5}^gpQSAw5^j{Ekrw2+SZh>$HOyQVYs2>`yuB#HKW)9Q8*_+&263m+>C^$^QK7 z6#mNoY)c7{x;y=P{}L2Sm$A$#u@_Jm?Wie_8M#uo(SLNA5&Z9_P4~Qa(lH+ZU-odG z2ax1v`n5pXAm~w$`u1;mBSEm{jUH|XN?>mWz!pj}SSNFSF|eP)spFEA6oB0NBL}kk z-DtPdFA5^~f2h&!ck|}&=FNY1^X6}x`fXFcZR&TEIUxQ2S2vme_EW$8)Neoa+fV)W zQ@=M@+1iR{n{NNVe}k3ZvF~^6`*+8_8FIJIpPN>^>(*FUJH%_x#(;^`WKaYxqzI}L zF*KmDnX_{Gj3_*nFSB(rpVV0^)fdb_?J4iG*}ZxZa7N#N1dG(Y%J3ai*(n4x06(jN zN5P(N;t$!}w%fKmt+6 zEYfCC&A~7JV6iB@cvmtC2hQEv+{A-J@6~AvT3S-q%B7={9OvZ0CR)!p-*ZcH!0>C! z^PrFmc9EF`+qfqmvGWuLe5hvwbv7~(pDm?hxr z3$3Ti*0Pk2hW-GXt6V*UZn#0}UOA!F;IIM)KR))Z!HxokH96hvemDV?xDP|LVh@3x zTgFGcBO78#z5WNl{fJmwA{KPS7r89{FeHu|5?kfgTe&Ud;9v)OeTN5Y6J^Adw(>v* zGOb7D^x*!g9Qzv(jNtx^qjxD__}Lm*&jq7_|GW&ZmC2r9RNd)l50m ze{~iy-^eNgdkQuy^P6FGAt~_~Pux2TssUdKH|&LKk3ISGEw;L7#$>D&cb8vHJO_;I zOra5%12;+J=d(?rNyaZWUbO%fO%ugh<77H;P)$amaeSxS?e8|t`h#`;>)vnwz3!~o z+kb8x{S*KBKeEBu|GC4foDz-$>Z;xo?_3jh>YL?XD8c@6;l58EY_Gfjbfx~^LOHik z?JV#Epy0(ENWJ4E*gppVr*K643`t$HNo9Lg0Gir|=Gae11ODa$ib{)>irhPnL=f!r g@MrnL#t}@f{iJ_P+*R;D)qq^Opng8>tdaNs1J#}wcmMzZ diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/insert_resize_sequence_diagram3.png b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/insert_resize_sequence_diagram3.png deleted file mode 100644 index 5535c5fe6038661f5ca70d56269822e83b04457d..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 24542 zcmeHvcU)83wr+qZph!SKP)ewwsemAz1RID_MFB-hKtP%xP3Z)b2qGY;bg&?(bP*|` z8j5rQ=^Z49^j<=FGpOu+_u2cNyU)Gvy!(DX|JiPmtU1?ObIdWnF~;|e08Mq}eR~e= zfj}VpRL-8h0D({(fk4P>smQ@6?ksC=;2$!_3(6-U=?!dS;18(93AGatNLI++b@VRq zH>c^@3u+LE8v+9HxdVZ$fscH?LLknf5Xd)U2t+m#0%5j~EzpvOK#Z=coIY{!w&7$P z>f==vm!-w1T_Q_eZMl_77(Z$qa~f6wy*gt?8ue6rDC@g8y{FfV#dMw;?-!S*V;7=V z9WWMUP&KaOWRqYJjC{&~vHvVEC#z+l!>Nj$kJC_Q%-!loX|xvQHe~okc;W06E{)#$ z=A>ZP+r7MjLT#=L@8h8Jfj~JSWK@a}@)7Dt*f81l|89S(8DIKf&Y+p+=l66zrCTU| z>RqJYe!mQ(MKyp|DpOD18O3Kql&~`(9ZLX&h~~j0>;Jsu14AkHZUQ;v=cLBG9+7y`rX!A#@5=`7a=wN zs&>EK)qe0B(QcY<8%chiV#m?oxVN!Tn%%#>(>?paOgH)pT|F)|<2_~u%G!;*<3z5F zx4V^S5%Df;^J1s-DanXMl7dU!u3&+-zWegf(Pu&o&w zk?A5A++4BYL1Tli`63;?x@VUZ2M5xl!*2H{AqEVyh+zk__OSq-y%+=rwHl6E9mK+u z8hJk?&n{$_Qi;>&4LBZM*87Mx=zxjC9xm=aKraM`KY5+*|8WTK|LKJ-KUf;|JZTnk z87kFYY^N>0nO&H6sKkCO@(v?X)tCNZI&=nY5OCAO4*an1>vbwJCd_N1D2}`?okA}7 zed(3EFm1JCPO|g@qPcPpuztb_A6SZX{vAnXa_wbwWm7S;rLZ=`tBqSc-TZR5wba?* z2<1RyRxp_4BWb0R5ICaj9u?G|E)oM1M_r3J(!FoN*7GfPGSqXfntxPXhZcSF(*Zc* zPQXQXaLrPxv;!xZM~9-11h&+kTzm$7Ako$*3Pv0e@m{s?Ub1kBep_dYpF!i3nfE9F zvvpH^p@ISzdi7l2MaG43T@i(?^yHYFWK$FL&_iT?Gz7P6>d(mI0~7X-4(7BEh9D;< zdP=cck}v2=u@8I|%#&9#BVGBwsnC~V2l06! zc&u8A&Mdm6M!EGx8TL|~p>GT&hI%z~(QUH-p8WF4(0!407p4ffi&n`Ug;72}7W%Ps z5O~{Tma1iN3*!%h{pmF6BLiXCTedb*$$9IUtY7;JoX5Mg65ecf(j!%mSAQBi4KAQ& zri5|%z*tX)yr&DL0~c5`(DX;xoO<0Nw(ec6o>#*b1QW(b83sX+L6#6q6WD1DNj@8y zO%@h)WCM5;g6E@Gv*;Jb$=XyB;JX?0)nrs!BlN%cL}VT;NE*0g+La2dnlSuQ$Zoif zvm5md4qziIqF@XwCh(=lMTJ8idaYx8d9L6c4uUya-dy_cPY~zX5hG<6ui(D)rJ6xs zgil2>=hk$eN@78vJ-j`=d=H!V1m4E2gLkYeN3AJcZH;|;%OcfNzq*u{d$e+bei7dn zk7o>y&47(Z#HF?*MSao=Evp)nM8efA3KvkYv+n6 zak>}ox$tnqv3k0gm=1|>MAn7%F7&>aO)@&tZ@F)N<4DYbF(z?)$-OZd$+^uFS+~?C zOS|B;OL~Hh^my#!sPl1dGNbs0`Uesep2aVXY}31f-s&FB^JrJ4>|o3Z`1WEkAfj)M zpVG=pwFS%m?k$<#Dfop$TQcw`1=ndgpUJVj(ZygrK3Qg8Qx99#V*jj_eJN1jZvUNr z8|gM9%{cSVcl}1E@aYFC%HCOOGg{8c<(g|Ht`h7Ph4*Ao*>&d#&|0l?%C^@TFj{U( z4NC1TGhE(pec|nB{Rb%qLglMlT>1|sw`6l9UY6{R$+2nN$TaUvYRno&rwFBlH`sV| zv?Oc572FoSwWgTpn^Y0e?@!0|JjuM;H9l42d1I9^D+--)n_)}4^ogE#Q*O&devujF zN?{iN(vzaEH!=jry(4g`3hN>PgD{T{dw++!;mEqA(~dVf7G?w^%BRh&;H{R;5)OT%- zoGa68u_!R&8qgv>q}&&h?U?`R!bY_D8g%)ChRvkw+RDaOvy=hvTvIiB^7y}iM~c(+WYUHvw- zzRwNMXbqcnO7E?_Du|V|QD1>3m^UT2Wj(s)d z^+P8%)|4?C@t8ABvE9W}Y%7_5&(FfC>NWg_EhnsB5p}of#tc3pMuOYm$oOG2d?l0c zrfZ!ICqL1%C=G*~k8-1k6XF(49`TRWV>U!lgUzuj$jdE{a&EOurDWXI;aEBst*}&+ z1v_u;BbZ!;N#%9%h=jh-`SKQaUb}YR9d8I9+{egP6KrpJno$*ZeBUz@q^-B6_F)c*t0^YCM zx6W!wY)RkDF@?J*HoDuyR~Csz^@g&0WI7$n7G6;{a!9DcBVP?69N~t^XbYi6a0<#X zTUzik`1%=%Ka&BTDk^3Za!znzvQq*!0b}g=g3 zA2*Li77i=7VEIz6;m$?j%p!YAcCTIKtYTG9|AY$-54T3l-tGXV=v}lhmzk|& zv_Am@lk0;BXY;wt5yRr$^#zaM#=1m|RwtOYB+VQb-;P#e^QYfaq}mj^uBCLbdq$TP zv#k-bQM1ljGS$5E6ac-vVzQjZH$R$(og>n{(`~kLa;~18Op$2u=v&iG_t-V3&FVEZ zY+RkCJ8@*o>!p#sW6v9zmo3-cBkDC~5C!jUuPmYs5u0Cbzk2N=Z{^Jm zlALf{jH#Sv-tAgn&^Ryb-fTwEMXh-u4GC{M9O&3mNd@nSF7HVW_5RS!u=P2okoX$! z7c#|hrs?oY^)pSW(h1nACf8k^je}<%J`qazHin?LT(3GaX!lb4&0P7W?izjk|-9dF5DtD!Lj-Cx^uWgjEUXx*5;lind#vAWVh_r6D5W`E_E`* zFl2^W&DvspnmPON^L16j8HrWZ{*+wA(YGz`4s25rv1o~StgFkM72q+yd2$)YM7$Hi7x{i#y|^u9ZdyYMjw9}rbjq$+>D%3n~q)QrH+CvX@ zO8^j0UcSi-Jw_iH3&YWk zf(US9pv+H|GuUhvU7^{c6%O$EswP0`sVr8qzNIoCM#*-hfGc$dftW~g&r)RE5CH3O zulUc9q6>HF*9WVOXV7&R6EHHko*vo(8<(d9{|O4(y$8IKU1ub&fDk3;L-`51k18NQ zU&435YA>UEb7s-KQBBYJ!3t>DOZfSK2!{rY*wPw)k{X`$^q!J1m|7=Nnu=UzJ04ic zjAd#wV1>8E9X#R&9%m7%EKcNu>56t>*fFEZlco5Qf|E8%X z!eGQ<)TXIE<9&rTd4&#t#c`iEpzLiq?<|d6@F_e3q`R%GX z_F?0FNUKDI$Aba<`|e5e?5Mp@Ifl!>8!ii(4s8+{^dj^Xf~mSkmS-iihwDLl2#i%> z7maZeR8Ph{TH0UX1o_1lXt;yJ*%eXGq#3kZl0YSAX$?J3JDE;!=gS~6 zjVIvsbbe-|p#hl`{B@Yzk6+`e@j9+ z@q;kFA?UzPnn)4k1;GB={WIxB_f;KuC9tc0B;x3Ne0%}AK0&|lXWoqSQylOIa^hEZ z(otl)faCGyKD0CFQ#r7YZ<)7WN!3Xiad4d!=)*#wwA39%%Lnf7y2=T`3_@Qe4bs#K z4B!`H^An1<*TJ50hQ$?8vmbo5{}GdC&;b5TNv}LoRZP6;-dUf=JSJ@cGBC0?f-v2p zZ&XNCczHSFESljw6+UVoX$cYoG3xPP304_BSvZlZ34$cE_=n}C01um&fdTLIjM#2) z+3#l@z%zmo|CY6ohWiNYh&zy;I@95Fovhd>m*Vk}!8f`UV3pqjD+@HCAx~u!n^S$n zN2RI8Cm_7W0unFYI9HEI6Z7Zvf3W3NdJnxt$(L)8#TL3VRE7MdHD#xLd;%e@iQG~8 zl<*|}pufEH<>P<3rMQu*8uS(SfE9C_$3@Nq%b2roO;PW~7J01BZEg_p!(N-~uKV+a zR=!k+gIwLh)T0ej7L6qq80ieP;>t<#i{W(UI2OGxT-;6P73SW0e!DHoBeQ!a1G~T@ z$`2<5*Qh;~5$YbYn!1udeoV?7=3X0gu}kJW@^F4ZN@f?_^->_kj`5eOkUK7-i}TIg zO$pU?&Z|lhlg9b5`Mr~~XjQkLJ0eNdI2~DMqa$ng)vGpRw`1EF8rb^BT5uA3y)WC&%~i=(7_>3I}pA4qt& zGfvc*BffszNe`3ph&sa&8euYNlDktzM%L#Bxu||5$rahi2R$OE!wu9k59T-pW>;O* zOVgRXT9H$l47c28l0`*}nc?CD7OEn8fG*%Ge&YFN?KR3inJ2_C=EyuJEk3d- zh@sgPYAZ&tZUPOID?zdIbzwC@kMuX$GBt>W~2(F6p+1 zrBoGcfI5krH157&15+bLzJ$)8#%O(rIrm2IT5E>a;<(Y4tbPrhzhVxs z{WoeyFiiZ4$C;G-vhnmDk)B3#eMRmGI?F35C2J|Dt$EZ|Q9rRLVf_og_iBW9r#P2{ zpQ15%WK6imR}*lzEY~IT!Tx-&S4l6azuKy66qWKWE)&4ho~2c35gB#FSLaPI4P%O^U=KFgYD17KE9CXy8-Tc1W><02E*UR$HhfC4aGUMZX!Y2aDs+ z8V4Cw&?$f(X>YmR-6_wk{D)Ev7J{^4n_AejQ~#MkugPR?AIpZ!XQ)1_mrfPs>K(QU z30vXR{EygStNrZu$(u)U`}fByu+`T78yxVY$f)b5{{RM@q3|S_iAmr}W&q!v!8(74 zaFxx43PpYmAFF7OKqL*_zwKRG5--C{0y`m9;r^ip zD=MDxvAXcEF3k_t!ch5_P=t8sFO7*Fo|Jsg^S)gI2WQg6e==P6 zq)T?^S7)s|ijz=KLUSuhS2#E1r}%sLbA1O;V5UI)0OA4i9oH=YpgkjF)6ZHRguEAo z0R`eOcKtjX=rlnTB`EOxHybPfp_;RW(%u~-eG0saw&p*8p@}Q^Tdi`g9?f8{Ac7-{ z>$|J;*$d?qjRklj7JYCRfD+=%E$!QwVG6?WJH#3S_V;3LOchqp9C7H67=XPDJLVS| z$&Iuzp+-w*bCuSJ#atBoRL$@-8j>^*Z#N3bRb|RaC$8RSS1W*6{B@_d~^%z?f_#-3%DHH03b8H*yU#tpDg0{t=kI z`^}DiM5Vu-&$mFJIaPQ4H#=ekwg_U$zi*tlHj|typeAFjJd1>K+MoUIvACbs=0fIw##1lGyaaQ2tvsIWV;^YCEnG;+SRrH8NYX9ZI z@Gqf^KQ|H*Xn6?C=kJ8WVn48|Xhq#=osJ=*R~GAkrZoL4i}fpuCA{`M?eza?7E6f+2}XFeXiH*xr$i0`nGw z{PWrGkB;y2oH3`1scdkQf1Qz_N5+^>aodNN!GsIYi?}}d;ST;Fopju_>~s>n;pDMg z3zxdlBO2k@iG8X4#5{yH8uxJS=tT1L#klT_bF6l4aYj!43+T3<)cBYW5-0n)9H%2q zSRs0Vak5I*V`9|!28l5OD9ta3w$CSkPS$cGs!Jnv0Bj5xJ{*A%5(Vj(gU-@D< zpX~J;IBoNi?V;rbJDs%5Klfnx;N~@Bb0Ync=M6drX3?wPf*$k0^&h`Mb0T0HV#P{dA5?d_vw1Ae{qr1D(x%FY$02<#my_v zox6I5=0+*(n8y9G*pEr#ue6#n%SH&JcbNf%r zORe3HzEOPEIK{~I4}6Wtc+r2I-6qUyKiyYUVKO_J+dt)k3m?pKxESet@=yS%wC-PN z=pDk#^5D9F5-jDOG$(>A+sOPwU0`pa>wF@Y>Bv19v3s(VfC5I@$`%dE5UrCgxE~CK z1LUJLQANd|`WFx;%_)ii1q;dFe3_Zl=jz_4Nbp#~zU9f-FHXk&(}5 zLntt&0g&G;L19`=4i!X8&P0EE;VV7Ph-oBT6U4Dei|`bN{4E7+(R7Z_Q(yT=)8WApw+tIyVgdq4WvJl)viMzi}yl)vf<4q>BIb zb?fr0GJv@yrQ_CL=<1k0PF$X5=4j1c4tWxX^xj;rAYv6PJ9)d%VkwrvmjT5k8}P_U z)D4V}a8+%DNP@iUF&#IN$h7WUJ7$i@#5Ygkz-a9uho_nKgY6ga1>xlbE-2CpB zIzOtNuk1!LdkaIk0*7H!`>5?o)4eXh$qVy9b4jGJlFU`Fw~2GaRAUW3NnM5qO{+(3o(Nfb4iDe`DfT1vUAx+R*m)5S zXlqc{!-9*+2JcwR7PxBG-n?#G09E`b5|tDXh84|(vH1+$@5OYlnU7aKU|r%ZGLign z%V{E@$bIf}BD?W{`YR-gmsm*85s~wl7jsqr3bS@Wa3bCH^28Jbn8Z-y4$Lkm~Qc*S*3v93_Qy8Z5kaOy$Pq ztK~5r_@eU;TGbsdbqJO{&iUcuQltTQMR>F#kf~~95BiG=++S zadP4vJ*f`(YrgdaubM`w(mF`~P0O`R!fdfOL8s18O5eQ1a1qVC5R0Lp!J9x!*#w@UbA{O-MD%isL!6Pc_9|^s%pWnQ-Y@o zn#(9-Tr6p(TIIhHu9>4Iu375psI_dZd{a2-p=al0!AeSg04fgYeJ(q%*BqJOK;*uS>P)(-Fty^zFvL9HAcU7Z7P~QwwT)<{fcs`=1SbV_(?xC z`A!-+%CxsuRwya+Tf6|jANxTL`JC&();~3V4FS6m?Y!y~?{PFS+-FRsmiU^Z2Qu-Y zv{~)r1?EY+IPVK>QuK|sd^Pm-TA9UG(WVEwf)2vl{4eC1ZYvzd+WcQ|K`?Odo^3ue zIG1<$%rj^+=@!5c`;oPi<^_CJ_1_pmHvwC%a!@^EhY$~eSF!=ru*Q%noU{7jinqr* z5S#2YpeTiq*Sp`Q4SgmE0K=2gTm7CEMtE=H(vhGyVBnNvY0zDmlhAdPMmC=gl~nH? z-Wi}Jri5|y09*vxL*PSOrFPAr7e^l5Bm<|`E^hd2>)K{ zAEVFIkLp%Yk>eTLitOAvvJhGYq$pc`0|3`7aL*)cttL>mR&6X`J=h-G$o-@YhlxiP zS8^NcewErf{vbbVaO+0YW7AZd=IKJJjuM;IxmppF*H$J!|CZlgpeu<5JDcE}v@AV~ zE^2DBSAyD5q`Io<#dt4y9GBGzCc(jD7|A8!*=Ny&W0!!{d?z@?a$q7vj5uh%tvpVD zVLtNpT+lENU1s=M-CHHWGMZ|RQLO(UHtBp&s%zxwJoROG7uTEDtRu6*;Ed=5ujkK6 z9)E?Pw+TRhlP>lD38&6~LqwElm->rT_ls2b-%`q4pZD0>^h_HVZ_j{(UNHLeK&@NU z-JB^5D5k<$S;1Af-=CNB7=|xF`&wTwBIFRR$E6&{jHN7=tmlHg6dh^C z2Am9=E2kx!3S7b?BzjYv4-H=Wzy`qtkm6GL6ErY#x>r$(bD(LBT~KFyXwlb@cc;wN zKgJWQ<=h?Ykz!;H!sdIX(mhah9QC$B+SgrfE*7|lJE$>Ox*@D1yOPL=;o-?@;jnp3 zXQf`(mGg$57IDFugw+!^WZ+yR=Z&HRr|Rqd(m+j|*-X$Z;H+E5g6z1hfn%qWi_BPc`Ipn9D;pA$#Y6hsyISUM)gM}GwON`uUmWZz_Vag%fee}R&a84(%YN$*~p5iE7fdAM>P$}?)I zAXs^*-TgBD+RZRl$1*4OB6dP>Rs7XrWL<857`@YZ3pEdxu`ci2kiJEkn8P^J&mD=lG``#IBZg#G>BPpn!xOJ zTz^$~>|vj5K7&i@bi`_M`-Y14C!?%%HBo2JV=r8;HLHxOhUdy%w=Oa4OSvy+d9Uy& zP|JEEbxCx*&*Ok(-Su5PcV<${YDmsrH)3CCQf-@%i{addnRWNLv6S8Q)(uydOEK+$ z0os00ZI}ui->}~?^=jo~nk@UuY7;a@Z!C@(n$(|2`m}xnJ=V^(>~9+&OhALJHHZ9p zcIVf5RmvO(^iS35zq!q}$TGUGvF#YsSD=Z?ZY)fsR zv5HZV+wnqXMou~mkc=E9MSI^F^*7z1&Gnt0*T>$+o>FovbjaH%a2#z=290RGHoeHT z>!)o>J^~#Al7V`@_8o+v9#UH76}gpBiV1n=z}6x1zHGPeOIJm(zWKbKKNDt-Q5!*y zRG5VX%8kUta_q(o9!ApFwoEZES)cX2&KgU)5e8%M^CGp^$kKe(8tALpG$WK|V^6pPZ1Z{)82oT9y1sKn=XZiS2iotUOSP?eywUgqw2#SyQg} z45hdIcw3qVYGWZKqxkJskyugQL3${usgq=g{Kg6ofWO}bk1agL$h!3UWqsWh(-oGM z8uXU$43N-Qh3-=hJgG-|ltiF{`5{mRz|OmILMkn@3b<%K3VA~rTAI!qx#3QCsGx6v zv3^cXnhN5R4&6Zxv-WQSGQdXh8ER)*!ka zIS}Wk`#^%qEP3d}&v7wj;2J-A?jL|0Y;B*$`mp|B?;u*y9h`5Dz~o(x@3RD)BnfewyyPZGL(T>`*vsyeeZ`=)55vd|i2f zREMIqaes6W2QpK+3T|6@pmyakUoW-M)%;E9yA9^Ku~33|Q5SemU3#@I5a6xpNjB(o zERZl54>D9ygP$eofErU@DZoM=)Cz7-;1=b-yJs@bNLvw7rpK$R@39?oXCr7k*d@Hw z;^hehuk+3ciJNU@c*)ocr|gD^Xv7GN*cumV+4XQKGd+g8s@tG30i_Y`qI8ViK6Nak zqij^N=t7X?4C1;-bkaV2Rk&n#!-Guy2THQhk9jV<4>%5-zo3Xw+!~NvORWS5?OH&a zBLOTkU$w6?HLU4r29x)MMv1u24&B8uEQ`7Lutp3sMpqppnq+i~rFY7UjIF7(#l!@| zqc|udye~6YU!U$0oj@B%9Wic}h&O=P?w4EciZ!E_o%<4E^%zs>Z{TE4W@8J*yKv!Ge^ z2=FkyJrg0{8wJ!U1iB--FU{2p^*=fn;Stwec5alfe)n-tJ=w)EYH@9|jJ!()ZidZk zbMs+K*<*NGi8O1eOH+*vaS^H@k)^iQsnSorP$WA&HAl7BlD-GbBGi1AE*$7o)VTK@ z*^Pl&lf5410!AYf_T@_RW~k9jUm;bU;mu?dkpeN<)ft17Yw;5S0WlW~Qu~f?kRL|* zb$-tBgQd&QpC8*mH*WZZM|+uhep|bJ+q`MQpj|5YaXR(9g5)&!gV7!;IrUeH*lY*r zImu_{2vA?!eK@=dTdj$B=7Us)-J}g9WJi({N;&c>~s*%;F;kwh(rzG=4@d4;Ti>IH%J5HyRW!9P`;lJ*yx z41w=Xz}bt#fV3`uz>&lcYkI8TpXxXxd} z4_E`89lhql6V?}!Q5!46A(LBu9;6Cap3(qFe!E&Z2My>*wVHH%Ku%0Y$_$8wb_ zFmxR}rR=3qbUVsIz!Gfey@9;-s$$`Ldm1yKJQO-FFbL$!R)^@llGA}OF0N9l%5N6! zSa--Yo*bBn;5CfcXP||SKF{$xEb|AkQ_<@ z^lu9XEsRvv?4B(F57u?c)*!a1Lwb^au z_*GOe4+yY5$#K0miVRQfBBx_f2YbFDGw9@9WGaoc8|FLL2Vg1+;F@-mC(3|a$@hTa zs|xV33~cp3|Mn>*g>)E*CGAc?vC~58XAWO96ohe{iqSv@_rtx#g8)OJtcm8gpoCZS z4BULV{}4-SUj25U&UTAtffggPKeNl|@Bv3Q8B_n#&p;lpUHdVAR`nyc$Zhc(Xodk| z(54>Lz5ImDtLCWT*h8S_1~Ml|G=3HEX$WCB&|r6XH)) zq7DFumi4j4&XW`ze{q7s3D>`68wrkpuxX@|4EVLA*obl?7`)U;o2$KIEl zDG>CvdF8}lqXXDcI)x`^e>&E?^Dsfsa5&RJ6wdjSTk-hovxGLF;ivw$6bHVaK{#>H zTdV0u#^(V=`~Qx1PN4C5WbfzlsmxZ-SHBa_T%sp6GpYzN-q~7;Mqq0df4NS%v$gy| z9KLT@+4?6O;QSN;VkQxpuHRyJG}v1Bm8L^GTWf(2z)73 zF82hxd@bw+`_3+BQ345xAb8pjZXigm{I9x|E!bzphqEwm^V6UKKSbq>`swtO#=idt Dx$?qM diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/interface.html b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/interface.html deleted file mode 100644 index a48a8bbad..000000000 --- a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/interface.html +++ /dev/null @@ -1,446 +0,0 @@ - - - - - - -Interface - - - - -
    -

    Interface Specifics

    - -

    Following are the library's interface specifics. Short Tutorial is a short tutorial, and - Concepts describes some - concepts.

    -
    - -

    Namespace

    - -

    All code is enclosed in namespace pb_ds. Nested within - this is namespace detail, which contains the parts of this - library that are considered implementation details.

    -
    - -

    Containers

    - -

    Associative Containers

    - -
      -
    1. container_base - - abstract base class for associative containers.
      2. - -
    2. Hash-based: - -
        -
      1. basic_hash_table - - abstract base class for hash-based - containers
        2. - -
      2. cc_hash_table - - concrete collision-chaining hash-based - containers
        3. - -
      3. gp_hash_table - - concrete (general) probing hash-based - containers
        4. -
      -
      3. - -
    3. Tree-based: - -
        -
      1. basic_tree - - abstract base class for tree and trie based - containers
        2. - -
      2. tree - - concrete base class for tree-based - containers
        3. - -
      3. trie - - concrete base class for trie-based - containers
        4. -
      -
      4. - -
    4. List-based: - -
        -
      1. list_update - - singly-linked list with update-policy container
        2. -
      -
      5. -
    - -

    Priority - Queues

    - -
      -
    1. priority_queue - - priority queue
      2. -
    -
    - -

    Container Tags and - Traits

    - -

    Container Tags

    - -

    Common

    - -
      -
    1. container_tag - - base class for data structure tags
      2. -
    - -

    Associative-Containers

    - -
      -
    1. associative_container_tag - - base class for associative-container data structure tags
      2. - -
    2. basic_hash_tag - - base class for hash-based structure tags
      3. - -
    3. cc_hash_tag - - collision-chaining hash structure tag
      4. - -
    4. gp_hash_tag - - (general) probing hash structure tag
      5. - -
    5. basic_tree_tag - - base class for tree-like structure tags
      6. - -
    6. tree_tag - - base class for tree structure tags
      7. - -
    7. rb_tree_tag - - red-black tree structure tag/li>
      8. - -
    8. splay_tree_tag - - splay tree structure tag
      9. - -
    9. ov_tree_tag - - ordered-vector tree structure tag
      10. - -
    10. trie_tag - - trie structure tag
      11. - -
    11. pat_trie_tag - - PATRICIA trie structure tag
      12. - -
    12. list_update_tag - list - (with updates) structure tag
      13. -
    - -

    Priority-Queues

    - -
      -
    1. priority_queue_tag - base - class for priority-queue data structure tags
      2. - -
    2. pairing_heap_tag - - pairing-heap structure tag.
      3. - -
    3. binomial_heap_tag - - binomial-heap structure tag
      4. - -
    4. rc_binomial_heap_tag - - redundant-counter binomial-heap (i.e., a heap where - binomial trees form a sequence that is similar to a - de-amortized bit-addition algorithm) structure tag
      5. - -
    5. binary_heap_tag - - binary heap (based on an array or an array of nodes) - structure tag
      6. - -
    6. thin_heap_tag - thin - heap (an alternative [kt99fat_heaps] to - Fibonacci heap) data structure tag.
      7. -
    - -

    Invalidation-Guarantee - Tags

    - -
      -
    1. basic_invalidation_guarantee - - weakest invalidation guarantee
      2. - -
    2. point_invalidation_guarantee - - stronger invalidation guarantee
      3. - -
    3. range_invalidation_guarantee - - strongest invalidation guarantee
      4. -
    - -

    Container - Traits

    - -
      -
    1. container_traits - - traits for determining underlying data structure - properties
      2. -
    -
    - -

    Container Policy Classes

    - -

    Hash Policies

    - -

    Hash and Probe Policies

    - -
      -
    1. Hash Functions: - -
        -
      1. null_hash_fn - - type indicating one-step range-hashing
        2. -
      -
      2. - -
    2. Range-Hashing Functions: - -
        -
      1. Sample - range-hashing function - interface required of a - range-hashing functor
        2. - -
      2. direct_mask_range_hashing - - (bit) mask-based range hashing functor
        3. - -
      3. direct_mod_range_hashing - - modulo-based range hashing functor
        4. -
      -
      3. - -
    3. Probe Functions: - -
        -
      1. Sample probe - function - interface required of a probe functor
        2. - -
      2. null_probe_fn - type - indicating one-step ranged-probe
        3. - -
      3. linear_probe_fn - - linear-probe functor
        4. - -
      4. quadratic_probe_fn- - quadratic-probe functor
        5. -
      -
      4. - -
    4. Ranged-Hash Functions: - -
        -
      1. Sample - ranged-hash function - interface required of a - ranged-hash functor
        2. -
      -
      5. - -
    5. Ranged-Probe Functions: - -
        -
      1. Sample - ranged-probe function - interface required of a - ranged-probe functor
        2. -
      -
      6. -
    - -

    Resize Policies

    -
      -
    1. Resize Policies: - -
        -
      1. Sample resize - policy - interface required of a resize policy
        2. - -
      2. hash_standard_resize_policy - - standard resize policy
        3. -
      -
      2. - -
    2. Size Policies: - -
        -
      1. Sample size - policy - interface required of a size policy
        2. - -
      2. hash_exponential_size_policy - - exponential size policy (typically used with (bit) mask - range-hashing)
        3. - -
      3. hash_prime_size_policy - - prime size policy (typically used with modulo - range-hashing)
        4. -
      -
      3. - -
    3. Trigger Policies: - -
        -
      1. Sample trigger - policy - interface required of a trigger policy
        2. - -
      2. hash_load_check_resize_trigger - - trigger policy based on load checks
        3. - -
      3. cc_hash_max_collision_check_resize_trigger - - trigger policy based on collision checks
        4. -
      -
      4. -
    - -

    Tree Policies

    - -

    Tree Node-Update Policies

    - - -
      -
    1. Sample node -updater policy - interface required of a tree -node-updating functor
      2. - -
    2. null_tree_node_update -- null policy indicating no updates are required
      3. - -
    3. tree_order_statistics_node_update -- updater enabling order statistics queries
      4. -
    - -

    Trie Policies

    - - -

    Trie Element-Access Traits

    - -
      -
    1. Sample - element-access traits - interface required of - element-access traits
      2. - -
    2. string_trie_e_access_traits - - String element-access traits
      3. -
    - -

    Trie Node-Update Policies

    - - -
      -
    1. Sample node -updater policy - interface required of a trie node -updater
      2. - -
    2. null_trie_node_update -- null policy indicating no updates are required
      3. - -
    3. trie_prefix_search_node_update -- updater enabling prefix searches
      4. - -
    4. trie_order_statistics_node_update -- updater enabling order statistics queries
      5. -
    - -

    List Policies

    - -

    List Update Policies

    - - -
      -
    1. Sample list update - policy - interface required of a list update policy
      2. - -
    2. move_to_front_lu_policy - - move-to-front update algorithm
      3. - -
    3. counter_lu_policy - - counter update algorithm
      4. -
    - -

    Mapped-Type Policies

    - - -
      -
    1. null_mapped_type - data - policy indicating that a container is a "set"
      2. -
    -
    - -

    Exceptions

    - - -
      -
    1. container_error - - base class for all policy-based data structure errors
      2. - -
    2. insert_error
      3. - -
    3. join_error
      4. - -
    4. resize_error
      5. -
    - -
    - - diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/introduction.html b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/introduction.html deleted file mode 100644 index b3ccbd76a..000000000 --- a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/introduction.html +++ /dev/null @@ -1,120 +0,0 @@ - - - - - - - Introduction - - - - -
    -

    Introduction

    - -

    This section describes what problems the library attempts to - solve. Motivation describes the - reasons we think it solves these problems better than similar - libraries.

    - -

    Associative Containers

    - -
      -
    1. Associative containers depend on their policies to a very - large extent. Implicitly hard-wiring policies can hamper their - performance and limit their functionality. An efficient - hash-based container, for example, requires policies for - testing key equivalence, hashing keys, translating hash - values into positions within the hash table, and determining - when and how to resize the table internally. A tree-based - container can efficiently support order statistics, - i.e., the ability to query what is the order of each - key within the sequence of keys in the container, but only if - the container is supplied with a policy to internally update - meta-data. There are many other such examples.

      2. - -
    2. Ideally, all associative containers would share the same - interface. Unfortunately, underlying data structures and - mapping semantics differentiate between different containers. - For example, suppose one writes a generic function - manipulating an associative container Cntnr: - 
      -template<typename Cntnr>
-  void
-  some_op_sequence(Cntnr& r_cnt)
-  {
-    ...
-  }
-
      - -then what can one assume about Cntnr? The answer -varies according to its underlying data structure. If the -underlying data structure of Cntnr is based on a tree or -trie, then the order of elements is well defined; otherwise, it is -not, in general. If the underlying data structure of Cntnr -is based on a collision-chaining hash table, then modifying -r_Cntnr will not invalidate its iterators' order; if the -underlying data structure is a probing hash table, then this is not -the case. If the underlying data structure is based on a tree or -trie, then r_cnt can efficiently be split; otherwise, it -cannot, in general. If the underlying data structure is a red-black -tree, then splitting r_cnt is exception-free; if it is an -ordered-vector tree, exceptions can be thrown. -

      3. -
    - -

    Priority Queues

    - -

    Priority queues are useful when one needs to efficiently - access a minimum (or maximum) value as the set of values - changes.

    - -
      -
    1. Most useful data structures for priority queues have a - relatively simple structure, as they are geared toward - relatively simple requirements. Unfortunately, these structures - do not support access to an arbitrary value, which turns out to - be necessary in many algorithms. Say, decreasing an arbitrary - value in a graph algorithm. Therefore, some extra mechanism is - necessary and must be invented for accessing arbitrary - values. There are at least two alternatives: embedding an - associative container in a priority queue, or allowing - cross-referencing through iterators. The first solution adds - significant overhead; the second solution requires a precise - definition of iterator invalidation. Which is the next - point...

      2. - -
    2. Priority queues, like hash-based containers, store values in - an order that is meaningless and undefined externally. For - example, a push operation can internally reorganize the - values. Because of this characteristic, describing a priority - queues' iterator is difficult: on one hand, the values to which - iterators point can remain valid, but on the other, the logical - order of iterators can change unpredictably.

      3. - -
    3. Roughly speaking, any element that is both inserted to a - priority queue (e.g., through push) and removed - from it (e.g., through pop), incurs a - logarithmic overhead (in the amortized sense). Different - underlying data structures place the actual cost differently: - some are optimized for amortized complexity, whereas others - guarantee that specific operations only have a constant - cost. One underlying data structure might be chosen if modifying - a value is frequent (Dijkstra's shortest-path algorithm), - whereas a different one might be chosen - otherwise. Unfortunately, an array-based binary heap - an - underlying data structure that optimizes (in the amortized - sense) push and pop operations, differs from - the others in terms of its invalidation guarantees. Other design - decisions also impact the cost and placement of the overhead, at - the expense of more difference in the the kinds of operations - that the underlying data structure can support. These - differences pose a challenge when creating a uniform interface - for priority queues.

      4. -
    -
    - - diff --git a/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/invalidation_guarantee_cd.png b/l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/doc/html/ext/pb_ds/invalidation_guarantee_cd.png deleted file mode 100644 index 1f9d1243c6a3f44738f275d382f3db7fa6348a67..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 8331 zcmeHtc{tSX_xBiYHG~-zMU1g$D^WgKVh~DXUsFtFUs`0ZVOmV6lw7)d@1GfSzwi5;bD#Bf&Re+2NqsI30S*)j z#dZAHQ8N^ZRUZESg+aroSf=JF_+s%f)7M57Gz*Tw55z^wNDGB}5w&fN#0I|!=Z={f zp-@4RC{*Z8I0#Fj-%%)E1r%!B5rtAsK%sVBOnGgp4qMreAJwu5I5YVrvrzE!V$JO1 zvJj$-<@4|-&)?I`xE(yQF5m7A2pO5h!7_5&- zC<=`sY<{#$&6uv=7Zv@lg|$_s<2(QN_5$rt>S?y}jDL0$LPO^jg8xklSGJvHlw^(G zFZVBEKhjWG<~kp!=pSAMN8vDg1?^vlX~Af9&m~adKTkK0(}=z8C8)QhN|1paAQ9y-bD_L zK7^T}3B=SA9YtC2$~-Y7^(H(q1B+JAi_&=hXa{^h)H_qfiT4Yv6D6430D-h@IT6Y2 z{iGdQ{B?{UEdOzYJp#KTckRck2PkZ7Sdb1`z4*bdg0m`k$-6?sUgYInZ_ntKkLcK;*Lm+q{cASDp7TA-~iO}9j@Z>%@Q@6R?2TpdVKoV#ck z)HT5IVA2S0b@TGspvLWLA)WTKN0dadYCAHJ75oRu+CxUDewCsm}jDO71 zpY_4TW#HUE1L;M;zUXQ`%ZASqM?dB*&|Yd+ydQHS z+Rn^=d-uxOu)f0}O+{j>;L}T2q;%_@tPmmIWVa~oceDiF@LH|UB$2G1bLWQ=1snRK z2L@8-OVzMy>6yGZR|*R2k-6)DI=%-Z$#yyZZP+J@|i7bj&-8yv6L_s!?oGXHDbelyp>+8Lkv09kLnFdo&SyK2K0 z&k}6=q{m`cd1Q56V(JE*WhgIy9xKUCHpCA6&+hwmL7dH3Mg-r^BOKe<_h2fI@pI^6D&I3QGrtd&m)h%K8%YC*bl`BA zN5IaV)6RJhs9e<&d}gsvqwV-?d6W5rx=h*|+$9F0>-MhPPHT>_6ken;TC?`QV0*&Q z4l9XQH(wl#u(7TE-YmmRrRHD%D2lO9MPbW>wuy(6yQ&9`b>aeX(l!kS0e{)=TCQxi5Q1oE23xK6rj7F~mxBu(ED<=oaTK z)#bRxz6W;gU1()^%ZQ_6GpKm0v%J_nufC|9N~fmkwAdp(5M(`Lw+wMM^Q$D?>^Itj z0nc2GR_qn0vgMz|2$E;w^?bWx8S}J3(Xp#eR`mlp)Vmt*nsghq>{PIg9g3BQV+0Bk z$IYjDhe%mOF>E7|nn`WGVlEYz!>3Y(;d@Qkijc)=oukpA-0U}BJ`S#pHL#|%45a_GS$n5( z&$*EybI=rn$l&@(yo7C(8VhuOpbdHc+7%=D5rc2sJDRaJ-^h5|)6#{pj5%5?#g3aI z%hUf)T7HKq9wDt1?$WpZmak@b82f0B{H@;DIErfI;v|li-_cK!_t*C>7i&$TP8P5* zr4y)L+184>{mN+drVV0-2;{O%=i*cjtVg-#OC3iU$ak?ZmoOIKm@>pEF$6o274@7L zO6_LF9E6;DsQnJze1PP&r0<6@l&E1mjaKBQa3BFTZ11n#>?d7YFy+O}K>eVE!NtRp zKKjY1=S^N$CfTJlA>TSOri zg-teSIQ%b-Eb&~YE`HRv1d$-K3W(M)1l;wQ&t_=!RWUW>DP&#q2J6kB0>E}o3W+Wm@Z95}X#QSl5e`|KoeudOd|nS3Jm%T=Q&E5g z>4D19GZB6V>KC!UaewvNm~qIjT!(cIUZ{Z?njlnl+H(wrjHw8mA8Afit6r|%PhKkj zdTn*GbbaU3?Xat#71SU`2ql&yg9<-38RT?nZp=mnFHMys=QKg7rs#tDL_H-%LTiTE zhe%!J{?mglSAC`;_g4k{{Lwwki1<_KL6q?qeC#ZUGtYYlEg>3jRqWX*xj;*F8|Qe%Vw7jakrzQrThLL1^7Z$-K;q^%3tp5!^vRp*2CXbTk@sP~UOr zR4qd={Lp6^c90+tWC>hr(nC?U;g+kh*0urPNtvz=A?u55XYIBFFen4F`muf277eYD zL+fCZ4}Emp)Ws#x#q5^jSQdo5wiHd=1Sjj@#_Nj~x|jvMnn0TiLY7!GW{rx%7VU!l zzOa9hyB_w(fg~sD6R9Y43AmNr<612gr3XywH8=?J*n?5`9r(sWbd&|jtW+h8k)J0* zsgtEkGWr?*KxBzK7fYFhP+(4Ha)7!IgSuTn-4j4!LMU1ojgbRaj*C_TR_-8C$+5^A zzzVQR&)ZrZ6y+6=wLe=Y7FuHk?DMY}q=6Oz2VI!9yhoe{BGW=v!e}Ny5BgUfUP5RM z+_b3~tkwx6I@QEA5uA-dC{f-&SA+5|xBU!mWH@->bKG^ih<2$N{Iu zV$^xM_5&FD+LtRx>4S%TYIzz6-8hu$RZW!v!r#EXQ^7>}KqBA&7#TyL#h|dK44Tyu zTn^Z?LsXs{SV;n_9lPLGBcMQ^aQ-M1`V=H#`X}i?QJMp&t-8`$1zib5D*bJ)VLa2} zQe>z{R0s@PK5Z1L51Xf1CN^&3EstFW0vRw(! zg3zJhdp$9qJL*^sY9j|1UPgj|NYFIx7p_YKXsqL(1A4p%O#QZ?F~yLiOZr4sz>a1h zkhID?Se}msZxva57+56(D8sm8jq%_DL3a=r9X4Ze68OAICk;OjJ zq6qC8&{#cU!GgvJ0@ELy2+kEMokyk49N6&*2xNA7L?o0b4_?9Nb_rN11FPh+01QC^ zESh|xDFDHBae$PuC+l}m)&SrDE;3ALQ6CI+I;%&wRT@tim}GZ&|lRnTcKzr z=6@^4P>G*G%+HgSy?&Uh^B?|7zxK1+e;+b}TW)mNn41}3OnUkxLJ%i_98x&f>%@SB zt?oNgyDYZTKRoS`utn~Hx6;|rMz|TG*CVb|C*IJz?cNPV{^=knlI#H)%H46D4_|uy z@u0)HHGy5y+I{*N94y#&nS|hNXPFC~ri(wKz@82*mc8PzEXn*7WJWjo6P4KzZ00vB zqKLd`e2%5U65m_;Sbo-cw=kHeIxV;CI4m2{pDaH1O#TyOCn0pRF@eGq8ARPA*Ktbz zwpZIJ{f;8Y!JZ*UtS>!;m z#2Y~cga7>kq105-p=-!x^j74mizXjN5#L`?VXtI`^}Fcsu19+-UXlN zM;#Zpx~GWfu8V9H)7;$`en3TzTt!}2?TbiPkxh~QF?!!IF?zc0{Z-Q`ti!ugjEiF= z#)FlqR>oX2NkAg8sc22r;M>!<_=A_%T!Weg!kT5y+Bhr9JVxX_g*C}*3uA5eQd>vg zCQs#+9J2nZ>>=SS1R;4Wlxl=H?MBB-(0;KV8j`G#S|gl{9@PD%RdIXul2l8gS?H(N zgU)~Y49wA#skf0?`cAcpXNhv#tLq|1ThghwV#IO-c&eSh@5V6(eQ%z?%F4c7-+s_r zuh(!|;ckptJwwb1==IqF;XC>6?dIzkc~x}%#$U~Bc6Lz1CPbo4#ynxP0-`U z3s~Cb@3iFO_m!1Tl}lHuUA{;@-Lvm9-YSXb+~EA%hj?X?@~pckj@*55)O?VknyAr3>$@%PTHjJ9!FUAryuW?E0v!hvy5gb$R+EXHBn%)^ypW zcD?u)-S)s=C!lcbgaGG|IEO1cOz9BLSy`vGKb^a<^hPSoe-7)<^;^|?L!e`Xzk}30 zeBoNG|Ge?_;r9a$XxXotk>6F8XQrvVJWafFYG-&}=RI`eRBAdfoHOkzkX7sxWN%BZ zNZvnq@|pk6ptp~Sd-$SFKkX{2%M-1S577u*XtrB*Tl6ZjI@<|&BpkBFQIjx{i?--o zO_RpIJDldd$%|{H_od@kxacG1X%G6xna+BiI)GESKwz$jPGZ03=H8Z-8@aYdD^=Fy z36JG3g++~(?P!L@yzg!66!P#ymekdFgC`BI!M-xK+peR~zoBOQ*n%Vx`YAm}_t4{R zdKH!2tKUUA0I0^8(28tk(H>ffxMy;{uVK|cX#BsYvj6XMF_fg2^7&Fu%;HUSaWMjg zRnvXHim?!xnJoQE9@2KypcGd9dfvdzi?AU3HfLZ+t}fU{9!<*8T&XwSSbnEjP?F)h ziN5_HUHb)z?0}-L-QQOkthw6VLf)89uMV8wLfC}1N>JpB!eq8m3NUX;U8CtCWEfsm zZ!8u%kXM|nOQg2|Dh~LaM(u{O-nx%+m~(Ywb(+C|4I#D0`e!HU2F?HrZUcn7`9T~2 zv^qtdGx9LWvG7b~5a9b=4p%R&&_p*8^CE~6l&7nWqSzvH3V8uG6?^@i^Uo>3e6Cdv zFodUvcvwvVdklk?N#(jQm2_{AhnTSo#EU=qoRw0A;f$)9^Qq5kd0^vk&58>h3@GVm z6>EDG@dh&3>#=MJ$L{vID+Ee!4iMV_i;U&nIf|kfAmrr%s{eFftfLM#GI^up{1asi zfaG{Mzpupx0nJ3!yk|6@YVzFF$3Jc5F*d+?0HKrt=PdvLUhJ{;6=}tSl*aolH$53J zT{q8vG=ln{R^oqJiT}7(qAa||zhDpM>Ri24OWKheqkAdBB430or_ehj3iUB!t|un z3IPd6=E0ubZXyba0HN+Q5RrYyYgiYfuauu=(#Pl}98502-^o_8#a@8Fy_T{+{_srJ z+ao5ANJ2~Z(3JmnjRYY7Gtu6q9!%vgbSqLhw48oz?ziYhHLN9*8wZn8z1m#QJ-$_Q z9{4NDu=12`BL5SgCjGpaPnn%Eo_|3p^|s4zr2`%Mmvp_NA};~2JH@yJLjat5P6Twk zct0iR`0FnPUd$^@yIYfC&_NjG^7beL9r|jUs~_Dc>+S}D3 zEb&VAK9x)R0)0!lTZuMP5^AVlh`@(tx?AyqPuh-((4z6jQZV+>p0kL)u1uiAoHEYp?pD65tY?QY1OP6XrHG@P*xuF2x>y^z3yW8`sS}f|TVU{R z{2WkyJu*Mq@@+#!EB=Y9e
    -

    gp_hash_table Interface

    - -

    A concrete general-probing hash-based associative - container.

    - -

    Defined in: assoc_container.hpp

    - -

    Template Parameters

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    ParameterDescriptionDefault Value
    - 
    -typename Key
-
    -     		-

    Key type.

    -     		-
    - 
    -typename Mapped
-
    -     		-

    Mapped type.

    -     		-
    - 
    -class Hash_Fn 
-
    -     		-

    Hash functor.

    -     		- 
    -__gnu_cxx::hash<Key>
-
    if using gcc; - 
    -stdext::hash_value<Key>
-
    if using Visual C++ .net -
    - 
    -class Eq_Fn 
-
    -     		-

    Equivalence functor.

    -     		- 
    -std::equal_to<Key>
-
    -
    - 
    -class Comb_Probe_Fn 
-
    -     		-

    Combining probe functor.

    - -

    If Hash_Fn is - null_hash_fn, and Probe_Fn is null_probe_fn, then this is the - ranged-probe functor; otherwise, this is the - range-hashing functor.

    - -

    (See Design::Hash-Based - Containers::Hash Policies.)

    -     		direct_mask_range_hashing
    - 
    -class Probe_Fn 
-
    -     		-

    Probe functor.

    -     		- If Comb_Probe_Fn - is direct_mask_range_hashing, then - 
    -linear_probe_fn<
-  typename Comb_Probe_Fn::size_type>
-
    otherwise, - 
    -quadratic_probe_fn<
-  typename Comb_Probe_Fn::size_type>
-
    -
    - 
    -class Resize_Policy 
-
    -     		-

    Resize policy.

    -     		- If Comb_Probe_Fn - is direct_mask_range_hashing, - then - 
    -hash_standard_resize_policy<
-  hash_exponential_size_policy<
-    typename Comb_Probe_Fn::size_type>,
-  hash_load_check_resize_trigger<
-    typename Comb_Probe_Fn::size_type>,
-  false,
-  typename Comb_Probe_Fn::size_type>
-
    otherwise, - 
    -hash_standard_resize_policy<
-  hash_exponential_size_policy<
-    typename Comb_Probe_Fn::size_type>,
-  hash_load_check_resize_trigger<
-    typename Comb_Probe_Fn::size_type>,
-  false,
-  typename Comb_Probe_Fn::size_type>
-
    -
    - 
    -bool Store_Hash 
-
    -     		-

    Indicates whether the hash value will be stored along - with each key.

    - -

    If hash_fn is null_hash_fn, then the container - will not compile if this value is - true

    -     		- 
    -false
-
    -
    - 
    -class Allocator 
-
    -     		-

    Allocator type.

    -     		- 
    -std::allocator<char>
-
    -
    - -

    Base Classes

    - - - - - - - - - - - - - -
    ClassDerivation Type
    - 
    -basic_hash_table
-
    -     		-

    public

    -
    - -

    Public Types and - Constants

    - -

    Policy Definitions

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    TypeDefinitionDescription
    - 
    -hash_fn
-
    -     		- 
    -Hash_Fn
-
    -     		-

    Hash functor type.

    -
    - 
    -eq_fn
-
    -     		- 
    -Eq_Fn
-
    -     		-

    Equivalence functor type.

    -
    - 
    -comb_probe_fn
-
    -     		- 
    -Comb_Probe_Fn
-
    -     		-

    Combining probe functor type.

    -
    - 
    -probe_fn
-
    -     		- 
    -Probe_Fn
-
    -     		-

    Probe functor type.

    -
    - 
    -resize_policy
-
    -     		- 
    -Resize_Policy
-
    -     		-

    Resize policy type.

    -
    - -

    Public Methods

    - -

    Constructors, Destructor, and - Related

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    MethodDescription
    - 
    -  gp_hash_table
-  ()
-
    -     		-

    Default constructor.

    -
    - 
    -  gp_hash_table
-  (const hash_fn &r_hash_fn)
-
    -     		-

    Constructor taking some policy objects. r_hash_fn will be copied by the - hash_fn object of - the container object.

    -
    - 
    -  gp_hash_table
-  (const hash_fn &r_hash_fn, 
-    const eq_fn &r_eq_fn)
-
    -     		-

    Constructor taking some policy objects. r_hash_fn will be copied by the - hash_fn object of - the container object, and r_eq_fn will be copied by the - eq_fn object of the - container object.

    -
    - 
    -  gp_hash_table
-  (const hash_fn &r_hash_fn, 
-    const eq_fn &r_eq_fn, 
-    const comb_probe_fn &r_comb_probe_fn)
-
    -     		-

    Constructor taking some policy objects. r_hash_fn will be copied by the - hash_fn object of - the container object, r_eq_fn will be copied by the - eq_fn object of the - container object, and r_comb_probe_fn will be copied by - the comb_probe_fn - object of the container object.

    -
    - 
    -  gp_hash_table
-  (const hash_fn &r_hash_fn, 
-    const eq_fn &r_eq_fn, 
-    const comb_probe_fn &r_comb_probe_fn,
-    const probe_fn &r_probe_fn)
-
    -     		-

    Constructor taking some policy objects. r_hash_fn will be copied by the - hash_fn object of - the container object, r_eq_fn will be copied by the - eq_fn object of the - container object, r_comb_probe_fn will be copied by - the comb_probe_fn - object of the container object, and r_probe_fn will be copied by the - probe_fn object - of the container object.

    -
    - 
    -  gp_hash_table
-  (const hash_fn &r_hash_fn, 
-    const eq_fn &r_eq_fn, 
-    const comb_probe_fn &r_comb_probe_fn, 
-    const probe_fn &r_probe_fn,
-    const resize_policy &r_resize_policy)
-
    -     		-

    Constructor taking some policy objects. r_hash_fn will be copied by the - hash_fn object of - the container object, r_eq_fn will be copied by the - eq_fn object of the - container object, r_comb_probe_fn will be copied by - the comb_probe_fn - object of the container object, r_probe_fn will be copied by the - probe_fn object - of the container object, and r_resize_policy will be copied by - the Resize_Policy - object of the container object.

    -
    - 
    -template<
-    class It>
-  gp_hash_table
-  (It first_it, 
-    It last_it)
-
    -     		-

    Constructor taking iterators to a range of - value_types. The value_types between first_it and last_it will be inserted into the - container object.

    -
    - 
    -template<
-    class It>
-  gp_hash_table
-  (It first_it, 
-    It last_it,
-    const hash_fn &r_hash_fn)
-
    -     		-

    Constructor taking iterators to a range of value_types - and some policy objects. The value_types between - first_it and - last_it will be inserted - into the container object. r_hash_fn will be copied by the - hash_fn object of - the container object.

    -
    - 
    -template<
-    class It>
-  gp_hash_table
-  (It first_it, 
-    It last_it,
-    const hash_fn &r_hash_fn, 
-    const eq_fn &r_eq_fn)
-
    -     		-

    Constructor taking iterators to a range of value_types - and some policy objects. The value_types between - first_it and - last_it will be inserted - into the container object. r_hash_fn will be copied by the - hash_fn object of - the container object, and r_eq_fn will be copied by the - eq_fn object of the - container object.

    -
    - 
    -template<
-    class It>
-  gp_hash_table
-  (It first_it, 
-    It last_it,
-    const hash_fn &r_hash_fn, 
-    const eq_fn &r_eq_fn, 
-    const comb_probe_fn &r_comb_probe_fn)
-
    -     		-

    Constructor taking iterators to a range of value_types - and some policy objects. The value_types between - first_it and - last_it will be inserted - into the container object. r_hash_fn will be copied by the - hash_fn object of - the container object, r_eq_fn will be copied by the - eq_fn object of the - container object, and r_comb_probe_fn will be copied by - the comb_probe_fn - object of the container object.

    -
    - 
    -template<
-    class It>
-  gp_hash_table
-  (It first_it, 
-    It last_it,
-    const hash_fn &r_hash_fn, 
-    const eq_fn &r_eq_fn, 
-    const comb_probe_fn &r_comb_probe_fn,
-    const probe_fn &r_probe_fn)
-
    -     		-

    Constructor taking iterators to a range of value_types - and some policy objects. The value_types between - first_it and - last_it will be inserted - into the container object. r_hash_fn will be copied by the - hash_fn object of - the container object, r_eq_fn will be copied by the - eq_fn object of the - container object, r_comb_probe_fn will be copied by - the comb_probe_fn - object of the container object, and r_probe_fn will be copied by the - probe_fn object - of the container object.

    -
    - 
    -template<
-    class It>
-  gp_hash_table
-  (It first_it, 
-    It last_it,
-    const hash_fn &r_hash_fn, 
-    const eq_fn &r_eq_fn, 
-    const comb_probe_fn &r_comb_probe_fn, 
-    const probe_fn &r_probe_fn,      
-    const resize_policy &r_resize_policy)
-
    -     		-

    Constructor taking iterators to a range of value_types - and some policy objects. The value_types between - first_it and - last_it will be inserted - into the container object. r_hash_fn will be copied by the - hash_fn object of - the container object, r_eq_fn will be copied by the - eq_fn object of the - container object, r_comb_probe_fn will be copied by - the comb_probe_fn - object of the container object, r_probe_fn will be copied by the - probe_fn object - of the container object, and r_resize_policy will be copied by - the resize_policy - object of the container object.

    -
    - 
    -  gp_hash_table
-  (const gp_hash_table &other)
-
    -     		-

    Copy constructor.

    -
    - 
    -virtual 
-  ~gp_hash_table
-  ()
-
    -     		-

    Destructor.

    -
    - 
    -gp_hash_table &
-  operator=
-  (const gp_hash_table &other)
-
    -     		-

    Assignment operator.

    -
    - 
    -void
-  swap
-  (gp_hash_table &other)
-
    -     		-

    Swaps content.

    -
    - -

    Policy Access Methods

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    MethodDescription
    - 
    -comb_probe_fn &
-  get_comb_probe_fn
-  ()
-
    -     		-

    Access to the comb_probe_fn - object.

    -
    - 
    -const comb_probe_fn &
-  get_comb_probe_fn
-  () const
-
    -     		-

    Const access to the comb_probe_fn - object.

    -
    - 
    -probe_fn &
-  get_probe_fn
-  ()
-
    -     		-

    Access to the probe_fn object.

    -
    - 
    -const probe_fn &
-  get_probe_fn
-  () const
-
    -     		-

    Const access to the probe_fn object.

    -
    -