From patchwork Fri Mar 10 16:36:51 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Carlos Bilbao X-Patchwork-Id: 67556 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:5915:0:0:0:0:0 with SMTP id v21csp975145wrd; Fri, 10 Mar 2023 08:42:03 -0800 (PST) X-Google-Smtp-Source: AK7set/XOls0iN/zq2lLMHnDW7cGErzINIjKEwL1ZGwnPHPgnk2chmRBzkJpXhxIRX0H5rSfoYAE X-Received: by 2002:a17:90b:4c89:b0:234:bff5:97d6 with SMTP id my9-20020a17090b4c8900b00234bff597d6mr26155066pjb.46.1678466523230; Fri, 10 Mar 2023 08:42:03 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1678466523; cv=pass; d=google.com; s=arc-20160816; b=R8SZ9Rc+oRZYlQ6MhWQ+Oo4i1rK2wbJNF0AgFZZ9IidKglMhAuL0mPD7JlPTEy0+N1 nR1aWAc9alOlHwMPEs1XTIDyQ+4e0NDA/Qs7LG+ZDsbflgT0C3rkiMwzNZI8RvZntraN OPeL8vjfoWftSD/6HOSFqw8WHQIGm/0TN3Up93vDKPX9/9Hez2paejgo+x2TNuf4SZsp mV9gKRGp9q10x1Cy+y8Z1YjUdxMTFsMyHGGv5xlDkGaT2NpxkP7bCnT2337ZCt0eklK0 k3IcT9TbpAdFVka4XFZTvZwycmfVHyxs+AqP2mOpvbziW2jtTY2j+LDVDwOlhXPZRteF xYEQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=kvVqLMj11O1RfinK9+986ppF2hYHU3O3AS3dCwqnPjg=; b=alWJ1dHXHYOroqWYpuOvn7iVFkylDXpoJX9ncNQhvz8Zp/IIjrZopLludTKf84i12L WNOO7d8H//8OMzZkpcUNra7MOB1UC+g5wZqjErwhwIDb4LPzyHrt+L7svvkwCzA3b/WU LUaBILYWgZV4982UCoFvZGJW7tIeeBSjisquQRFN6MvvI6Z8+z7uaqS3wa9wpj5aCZgS R+90g81HyG0eFnE6APQMZ5uuwLwlpL5Mab6rsCPNMNHSFi3tkzsrk4fP5QbL31Bcaga9 Ac95BxHhhvv9AnDV36RcE6svTsFj8qzDW4PF+y6pUHI/Clxzzcx+aSla3oRqUqhgSu36 D11Q== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@amd.com header.s=selector1 header.b=AFbIzzpn; arc=pass (i=1 spf=pass spfdomain=amd.com dmarc=pass fromdomain=amd.com); spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=amd.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id oo2-20020a17090b1c8200b00233fe9ab99bsi207893pjb.130.2023.03.10.08.41.50; Fri, 10 Mar 2023 08:42:03 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@amd.com header.s=selector1 header.b=AFbIzzpn; arc=pass (i=1 spf=pass spfdomain=amd.com dmarc=pass fromdomain=amd.com); spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=amd.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229613AbjCJQkb (ORCPT + 99 others); Fri, 10 Mar 2023 11:40:31 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43248 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231167AbjCJQkE (ORCPT ); Fri, 10 Mar 2023 11:40:04 -0500 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2065.outbound.protection.outlook.com [40.107.220.65]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6415D12E160; Fri, 10 Mar 2023 08:37:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QhNdG6P8SjTxTPJhc9w7U9I9VfoQz5e0fPNDnROF8TIQbRF5hV5CIQJIvTn897ygRKU9OYG5NNen7TVcYehSkw52x6ytMuKufCdpE8/6mVlV6XsC0l3uZbvEOHfbRnbnFKQA1ejN+XgcA1OZBhsuGP3bYTnMqokXAyG6pYVlKlIDy8d8AliDDL7vhGKUXkOwcN92JaHSYYAFDvBi2B8Uy0cIhKkQXJWjJeL3H8b3sX4Ha3fWlHHuSlUldD9QW19KcVexpYlmRdEifzCG0eSFI0fkQAk1SGBdvz2nd69dpSPCosIiUr2ROqvUPzlY1Xe3sVj7MkIzV+rDu3ieyROvJw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=kvVqLMj11O1RfinK9+986ppF2hYHU3O3AS3dCwqnPjg=; b=CT1SNuk33L3nWOIkcg0vU51+En2Hv0tsKmdJZXoiE02okqxn3y/Nsr052XC//F8vJ3helDxgFkT8xjGG+EDyx+00HxBiPygCJKOruHZwyi0jwqw2N48Gh3wfW9BwqqKum+GMGzBaXnsoyMUplCjd8V8YeTNIjMx03Nm3rhtDAnbcMyHOS/pAPrzCQofzuj+dbuB+0C9wEnBE+gzrUN5tM7nUIOUTd61ODSsFK02tVNbvxu0LcxuNeKyPIamSB3rXoW25906fMj5D0F2Yrmz0uSO0nRF0aDVUdsfTPj/TRnHYK/KehN5tdO/vbSZHJuVibq2qnNHvYi+xyNBGGS9cmA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lwn.net smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kvVqLMj11O1RfinK9+986ppF2hYHU3O3AS3dCwqnPjg=; b=AFbIzzpn3x8TO8BGlRGDFeL7aT440V5Quh6n0xcI1h1qFMmI4aOySjEiQcXEiyasM9FBpoDonPuXnxvrAEB/UIu//Yq8jcJXWMi4ONYe+cMbhmhIM4aedrY+zfXJuAPpDAmNJN6BJMK5huwKy2iNN5mVi5u+JEISHf1MnYIC2Qk= Received: from BN9PR03CA0504.namprd03.prod.outlook.com (2603:10b6:408:130::29) by DM4PR12MB5328.namprd12.prod.outlook.com (2603:10b6:5:39f::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6178.20; Fri, 10 Mar 2023 16:36:54 +0000 Received: from BN8NAM11FT013.eop-nam11.prod.protection.outlook.com (2603:10b6:408:130:cafe::cc) by BN9PR03CA0504.outlook.office365.com (2603:10b6:408:130::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6178.19 via Frontend Transport; Fri, 10 Mar 2023 16:36:54 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C Received: from SATLEXMB03.amd.com (165.204.84.17) by BN8NAM11FT013.mail.protection.outlook.com (10.13.176.182) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.6178.21 via Frontend Transport; Fri, 10 Mar 2023 16:36:53 +0000 Received: from SATLEXMB03.amd.com (10.181.40.144) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.34; Fri, 10 Mar 2023 10:36:52 -0600 Received: from iron-maiden.amd.com (10.180.168.240) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server id 15.1.2375.34 via Frontend Transport; Fri, 10 Mar 2023 10:36:51 -0600 From: Carlos Bilbao To: CC: , , , , Carlos Bilbao Subject: [PATCH v3] docs/sp_SP: Add translation of process/deprecated Date: Fri, 10 Mar 2023 10:36:51 -0600 Message-ID: <20230310163651.2500175-1-carlos.bilbao@amd.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230307134502.625671-1-carlos.bilbao@amd.com> References: <20230307134502.625671-1-carlos.bilbao@amd.com> MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN8NAM11FT013:EE_|DM4PR12MB5328:EE_ X-MS-Office365-Filtering-Correlation-Id: e770884a-4ea9-4d10-42b7-08db2185a841 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: g2DhZleiUQJOKUisTzMmjPvG/kBgNkdHqTHCHwsqrWMXHWHaWHTX0/7AURvn0TXCxlwRvPF7sg77EwrTDm83DGZu1U6MaaW7V7R+PlTkNnEmD2nibSQ5wRNnLdcLfOrXAVZBRMi+dq9oJASqHZ9LfPF4TfbHfirmVqT7PZzO7u4eEw2yupqW57OjE3kaxT+Dzf2xqgtVWQjmwMMw47aQyHZU6PgPApIdgx17aQTidLxv6lThVGy0Ys4tiqs05cPII9CIq6C4ZC/tm54uTWguTHvKmtNfATYCQlxZJTejnAMwpT301JfvolM/is1bAtXMP6LQYmMSGMToKouRdmsthaWDPcWn/gcqRuIKNaWcnHan5r+Fiaw1NiooAOB8+vJc2T7dsFE/R7lGZo+AO6oERngJG2wOPisJATP000haf8V7tk8PD9CDpKCmoKIIxK5Y1VqcXbRbqABVEN/Ry0phg+XHlDIgXjK5xpHkz6eogcqODlxedaQ4VfMgYHBTO0YnsC/nKzrRykBoXbu32xKPp8W9Z1homkDLWIAUg5kHNZ2jubqdFKayPQIVXYlK94KZHnJuu9WxpdpQgS9yutRsRuKPxYhkWUv1n3kZ6UnBt3m3zQcwOvOsAQyn8PujPzLTivF3Qxxt1GTIgcQuRH8uunVgQReGD8wr6te/YyHFld+Fh2ThYREIkZJMPN1SAvlBs1JPD643WIaSR7CqfVKa4kVEbZWDejvXQrcnuiFUV0wV8gpn1EumR9hF1qGfnB2SXKukcXFdT+u7FhWl4A2chQ== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:es;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB03.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230025)(4636009)(396003)(136003)(39860400002)(376002)(346002)(451199018)(36840700001)(46966006)(40470700004)(2906002)(81166007)(82740400003)(83380400001)(44832011)(36756003)(30864003)(40460700003)(5660300002)(40480700001)(8936002)(41300700001)(70206006)(356005)(8676002)(4326008)(6916009)(36860700001)(316002)(86362001)(54906003)(70586007)(478600001)(7696005)(82310400005)(47076005)(426003)(336012)(2616005)(186003)(26005)(1076003)(966005)(36900700001);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Mar 2023 16:36:53.9804 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: e770884a-4ea9-4d10-42b7-08db2185a841 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB03.amd.com] X-MS-Exchange-CrossTenant-AuthSource: BN8NAM11FT013.eop-nam11.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB5328 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FORGED_SPF_HELO, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_NONE, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1759718196892353968?= X-GMAIL-MSGID: =?utf-8?q?1759999712980414025?= Translate Documentation/process/deprecated.rst into Spanish. Co-developed-by: Sergio Gonzalez Signed-off-by: Sergio Gonzalez Signed-off-by: Carlos Bilbao --- Changes since v2: - Change SoB chain, remove From: tag Changes since v1: - Change commit message to avoid confusion - Add From: tag --- .../translations/sp_SP/process/deprecated.rst | 381 ++++++++++++++++++ .../translations/sp_SP/process/index.rst | 1 + 2 files changed, 382 insertions(+) create mode 100644 Documentation/translations/sp_SP/process/deprecated.rst diff --git a/Documentation/translations/sp_SP/process/deprecated.rst b/Documentation/translations/sp_SP/process/deprecated.rst new file mode 100644 index 000000000000..d52120e0d753 --- /dev/null +++ b/Documentation/translations/sp_SP/process/deprecated.rst @@ -0,0 +1,381 @@ +.. include:: ../disclaimer-sp.rst + +:Original: :ref:`Documentation/process/deprecated.rst ` +:Translator: Sergio Gonzalez + +.. _sp_deprecated: + +============================================================================ +Interfaces obsoletos, Características del lenguaje, Atributos y Convenciones +============================================================================ + +En un mundo perfecto, sería posible convertir todas las instancias de +alguna API obsoleta en una nueva API y quitar la API anterior en un +único ciclo de desarrollo. Desafortunadamente, debido al tamaño del kernel, +la jerarquía de mantenimiento, y el tiempo, no siempre es posible hacer +estos cambios de una única vez. Esto significa que las nuevas instancias +han de ir creándose en el kernel, mientras que las antiguas se quitan, +haciendo que la cantidad de trabajo para limpiar las APIs crezca. Para +informar a los desarrolladores sobre qué ha sido declarado obsoleto y por +qué, ha sido creada esta lista como un lugar donde indicar cuando los usos +obsoletos son propuestos para incluir en el kernel. + +__deprecated +------------ +Mientras que este atributo señala visualmente que un interface ha sido +declarado obsoleto, este `no produce más avisos durante las compilaciones +`_ +porque uno de los objetivos del kernel es que compile sin avisos, y +nadie ha hecho nada para quitar estos interfaces obsoletos. Mientras +que usar `__deprecated` es sencillo para anotar una API obsoleta en +un archivo de cabecera, no es la solución completa. Dichos interfaces +deben o bien ser quitados por completo, o añadidos a este archivo para +desanimar a otros a usarla en el futuro. + +BUG() y BUG_ON() +---------------- +Use WARN() y WARN_ON() en su lugar, y gestione las condiciones de error +"imposibles" tan elegantemente como se pueda. Mientras que la familia de +funciones BUG() fueron originalmente diseñadas para actuar como una +"situación imposible", confirmar y disponer de un hilo del kernel de forma +"segura", estas funciones han resultado ser demasiado arriesgadas. (e.g. +"¿en qué orden se necesitan liberar los locks? ¿Se han restaurado sus +estados?). La popular función BUG() desestabilizará el sistema o lo romperá +totalmente, lo cual hace imposible depurarlo o incluso generar reportes de +crash. Linus tiene una `opinión muy fuerte +`_ +y sentimientos `sobre esto +`_. + +Nótese que la familia de funciones WARN() únicamente debería ser usada +en situaciones que se "esperan no sean alcanzables". Si se quiere +avisar sobre situaciones "alcanzables pero no deseadas", úsese la familia +de funciones pr_warn(). Los responsables del sistema pueden haber definido +*panic_on_warn* sysctl para asegurarse que sus sistemas no continúan +ejecutándose en presencia del condiciones "no alcanzables". (Por ejemplo, +véase commits como `este +`_.) + +Operaciones aritméticas en los argumentos de reserva de memoria +--------------------------------------------------------------- +Los cálculos dinámicos de tamaño (especialmente multiplicaciones) no +deberían realizarse en los argumentos de reserva de memoria (o similares) +debido al riesgo de desbordamiento. Esto puede llevar a valores rotando y +que se realicen reservas de memoria menores que las que se esperaban. El +uso de esas reservas puede llevar a desbordamientos en el 'heap' de memoria +y otros funcionamientos incorrectos. (Una excepción a esto son los valores +literales donde el compilador si puede avisar si estos puede desbordarse. +De todos modos, el método recomendado en estos caso es reescribir el código +como se sugiere a continuación para evitar las operaciones aritméticas en +la reserva de memoria.) + +Por ejemplo, no utilice `count * size`` como argumento, como en:: + + foo = kmalloc(count * size, GFP_KERNEL); + +En vez de eso, utilice la reserva con dos argumentos:: + + foo = kmalloc_array(count, size, GFP_KERNEL); + +Específicamente, kmalloc() puede ser sustituido con kmalloc_array(), +kzalloc() puede ser sustituido con kcalloc(). + +Si no existen funciones con dos argumentos, utilice las funciones que se +saturan, en caso de desbordamiento:: + + bar = vmalloc(array_size(count, size)); + +Otro caso común a evitar es calcular el tamaño de una estructura com +la suma de otras estructuras, como en:: + + header = kzalloc(sizeof(*header) + count * sizeof(*header->item), + GFP_KERNEL); + +En vez de eso emplee:: + + header = kzalloc(struct_size(header, item, count), GFP_KERNEL); + +.. note:: Si se usa struct_size() en una estructura que contiene un elemento + de longitud cero o un array de un único elemento como un array miembro, + por favor reescribir ese uso y cambiar a un `miembro array flexible + <#zero-length-and-one-element-arrays>`_ + + +Para otros cálculos, por favor use las funciones de ayuda: size_mul(), +size_add(), and size_sub(). Por ejemplo, en el caso de:: + + foo = krealloc(current_size + chunk_size * (count - 3), GFP_KERNEL); + +Re-escríbase, como:: + + foo = krealloc(size_add(current_size, + size_mul(chunk_size, + size_sub(count, 3))), GFP_KERNEL); + +Para más detalles, mire también array3_size() y flex_array_size(), +como también la familia de funciones relacionadas check_mul_overflow(), +check_add_overflow(), check_sub_overflow(), y check_shl_overflow(). + + +simple_strtol(), simple_strtoll(), simple_strtoul(), simple_strtoull() +---------------------------------------------------------------------- +Las funciones: simple_strtol(), simple_strtoll(), simple_strtoul(), y +simple_strtoull() explícitamente ignoran los desbordamientos, lo que puede +llevar a resultados inesperados por las funciones que las llaman. Las +funciones respectivas kstrtol(), kstrtoll(), kstrtoul(), y kstrtoull() +tienden a ser reemplazos correctos, aunque nótese que necesitarán que la +cadena de caracteres termine en NUL o en el carácter de línea nueva. + + +strcpy() +-------- +strcpy() no realiza verificaciones de los límites del buffer de destino. +Esto puede resultar en desbordamientos lineals más allá del fin del buffer, +causando todo tipo de errores. Mientras `CONFIG_FORTIFY_SOURCE=y` otras +varias opciones de compilación reducen el riesgo de usar esta función, no +hay ninguna buena razón para añadir nuevos usos de esta. El remplazo seguro +es la función strscpy(), aunque se ha de tener cuidado con cualquier caso +en el el valor retornado por strcpy() sea usado, ya que strscpy() no +devuelve un puntero a el destino, sino el número de caracteres no nulos +compilados (o el valor negativo de errno cuando se trunca la cadena de +caracteres). + +strncpy() en cadenas de caracteres terminadas en NUL +---------------------------------------------------- +El uso de strncpy() no garantiza que el buffer de destino esté terminado en +NUL. Esto puede causar varios errores de desbordamiento en lectura y otros +tipos de funcionamiento erróneo debido a que falta la terminación en NUL. +Esta función también termina la cadena de caracteres en NUL en el buffer de +destino si la cadena de origen es más corta que el buffer de destino, lo +cual puede ser una penalización innecesaria para funciones usen esta +función con cadenas de caracteres que sí están terminadas en NUL. + +Cuando se necesita que la cadena de destino sea terminada en NUL, +el mejor reemplazo es usar la función strscpy(), aunque se ha de tener +cuidado en los casos en los que el valor de strncpy() fuera usado, ya que +strscpy() no devuelve un puntero al destino, sino el número de +caracteres no nulos copiados (o el valor negativo de errno cuando se trunca +la cadena de caracteres). Cualquier caso restante que necesitase todavía +ser terminado en el caracter nulo, debería usar strscpy_pad(). + +Si una función usa cadenas de caracteres que no necesitan terminar en NUL, +debería usarse strtomem(), y el destino debería señalarse con el atributo +`__nonstring +`_ +para evitar avisos futuros en el compilador. Para casos que todavía +necesitan cadenas de caracteres que se rellenen al final con el +caracter NUL, usar strtomem_pad(). + +strlcpy() +--------- +strlcpy() primero lee por completo el buffer de origen (ya que el valor +devuelto intenta ser el mismo que el de strlen()). Esta lectura puede +sobrepasar el límite de tamaño del destino. Esto ineficiente y puede causar +desbordamientos de lectura si la cadena de origen no está terminada en el +carácter NUL. El reemplazo seguro de esta función es strscpy(), pero se ha +de tener cuidado que en los casos en lso que se usase el valor devuelto de +strlcpy(), ya que strscpy() devolverá valores negativos de erno cuando se +produzcan truncados. + +Especificación de formato %p +---------------------------- +Tradicionalmente,el uso de "%p" en el formato de cadenas de caracteres +resultaría en exponer esas direcciones en dmesg, proc, sysfs, etc. En vez +de dejar que sean una vulnerabilidad, todos los "%p" que se usan en el +kernel se imprimen como un hash, haciéndolos efectivamente inutilizables +para usarlos como direcciones de memoria. Nuevos usos de "%p" no deberían +ser añadidos al kernel. Para textos de direcciones, usar "%pS" es +mejor, ya que resulta en el nombre del símbolo. Para prácticamente el +resto de casos, mejor no usar "%p" en absoluto. + +Parafraseando las actuales `direcciones de Linus `_: + +- Si el valor "hasheado" "%p" no tienen ninguna finalidad, preguntarse si el + puntero es realmente importante. ¿Quizás se podría quitar totalmente? +- Si realmente se piensa que el valor del puntero es importante, ¿porqué + algún estado del sistema o nivel de privilegio de usuario es considerado + "especial"? Si piensa que puede justificarse (en comentarios y mensajes + del commit), de forma suficiente como para pasar el escrutinio de Linux, + quizás pueda usar el "%p", a la vez que se asegura que tiene los permisos + correspondientes. + +Si está depurando algo donde el "%p" hasheado está causando problemas, +se puede arrancar temporalmente con la opción de depuración "`no_hash_pointers +`_". + + +Arrays de longitud variable (VLAs) +---------------------------------- +Usando VLA en la pila (stack) produce un código mucho peor que los arrays +de tamaño estático. Mientras que estos errores no triviales de `rendimiento +`_ son razón suficiente +para no usar VLAs, esto además son un riesgo de seguridad. El crecimiento +dinámico del array en la pila, puede exceder la memoria restante en +el segmento de la pila. Esto podría llevara a un fallo, posible sobre-escritura +de contenido al final de la pila (cuando se construye sin +`CONFIG_THREAD_INFO_IN_TASK=y`), o sobre-escritura de la memoria adyacente +a la pila (cuando se construye sin `CONFIG_VMAP_STACK=y`). + + +Switch case fall-through implícito +---------------------------------- +El lenguaje C permite a las sentencias 'switch' saltar de un caso al +siguiente caso cuando la sentencia de ruptura "break" no aparece al final +del caso. Esto, introduce ambigüedad en el código, ya que no siempre está +claro si el 'break' que falta es intencionado o un olvido. Por ejemplo, no +es obvio solamente mirando al código si `STATE_ONE` está escrito para +intencionadamente saltar en `STATE_TWO`:: + + switch (value) { + case STATE_ONE: + do_something(); + case STATE_TWO: + do_other(); + break; + default: + WARN("unknown state"); + } + +Ya que ha habido una larga lista de defectos `debidos a declaraciones de "break" +que faltan `_, no se +permiten 'fall-through' implícitos. Para identificar 'fall-through' +intencionados, se ha adoptado la pseudo-palabra-clave macro "falltrhrough", +que expande las extensiones de gcc `__attribute__((__fallthrough__)) +`_. +(Cuando la sintaxis de C17/c18 `[[fallthrough]]` sea más comúnmente +soportadas por los compiladores de C, analizadores estáticos, e IDEs, +se puede cambiar a usar esa sintaxis para esa pseudo-palabra-clave. + +Todos los bloques switch/case deben acabar en uno de: + +* break; +* fallthrough; +* continue; +* goto