From nobody Sat Apr 11 14:24:21 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8A775C678D5 for ; Tue, 7 Mar 2023 13:46:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230255AbjCGNqX (ORCPT ); Tue, 7 Mar 2023 08:46:23 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45442 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229767AbjCGNqB (ORCPT ); Tue, 7 Mar 2023 08:46:01 -0500 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on2080.outbound.protection.outlook.com [40.107.92.80]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 937CC52F7B; Tue, 7 Mar 2023 05:45:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=i4E0yot6Prdk7PpRbjNkTPHIlbqJe71xOH7IuifbmEYMMJIt2ck8AQjVZiDNUI7iS0pkaEALn9D/zH4dSmXXOZvoMaeS9dRqDmANIADCP2Aq7s1trVFDyFni6Jx+d1DHWEGSpVGDTbnbDJ8WjDGabUBzhSZup9h8M0YhFjZcvT5aFnmgu5mMW+Tb0FGKV98hrMV7/Io7KLqOYpUk12jLrKduBajo0nmnW7Mu+h+/Hq4XdY/dgu5faMr4//zX3XKDQWgDCe0wQZsGwHwFXR3S9jhi735uNvVS/FvA3rVC/PTgX5avciNK3nlDmDyMLqfDnCu3dT/YuPsSEe9zDjDNiQ== 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=yJWEj3hjDnPe65iOjnLh7VgkaSVLEFJha2qS1Gs9wX0=; b=gTbvsr/EOL5opPSLoq06sqkWvEXVJauzN4pCslwocsy6JwP7xfPb7J+9E7cjHaoLGerVU065e8lEZUN6RqCoC2j5V4/jFYELR6X89AdD6szdDIt5E438axOEtW3y6fLKxk8YKP69OEMP6VgOmMVmQKST9GVj8747+1oBx5ll8ON7yfK1y+AscfjywDePIStS9kDFbrqO4A2PSt/p3PYkskDrYnuxbFvwiW5pMXcE2G64TuEGRC7ry2k8H6cufRRCYYbXcoP4yk4OlhHJNHsgxVr7KAZi9ZUYEKw7n8u679jCOlIOFGsGgzdTFaTUNzvd/BvxZwCbXQNyQtXt8cBaKQ== 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=yJWEj3hjDnPe65iOjnLh7VgkaSVLEFJha2qS1Gs9wX0=; b=x+JajhQBPYxfA0j/zLLcM9xuhTkfIyPP2fiu2vA+7nhYd5CccJOYQ6MYwf4mWTv/OHj1ag+GF72qvGeUlvkZw9i7wlSkfky4iMsFA/JHsGMv11U+cx1wue/cwukaXf1iS6BR5qNY0aZeQtse64vWdLdbi/3lktYJl14+aT99Ruw= Received: from DM6PR13CA0035.namprd13.prod.outlook.com (2603:10b6:5:bc::48) by CH3PR12MB8305.namprd12.prod.outlook.com (2603:10b6:610:12e::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6156.29; Tue, 7 Mar 2023 13:45:09 +0000 Received: from DS1PEPF0000B074.namprd05.prod.outlook.com (2603:10b6:5:bc:cafe::cf) by DM6PR13CA0035.outlook.office365.com (2603:10b6:5:bc::48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6178.16 via Frontend Transport; Tue, 7 Mar 2023 13:45:09 +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 DS1PEPF0000B074.mail.protection.outlook.com (10.167.17.5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.6178.13 via Frontend Transport; Tue, 7 Mar 2023 13:45:09 +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; Tue, 7 Mar 2023 07:45:08 -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; Tue, 7 Mar 2023 07:45:07 -0600 From: Carlos Bilbao To: CC: , , , , Carlos Bilbao Subject: [PATCH v2] docs/sp_SP: Add translation of process/deprecated Date: Tue, 7 Mar 2023 07:45:02 -0600 Message-ID: <20230307134502.625671-1-carlos.bilbao@amd.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS1PEPF0000B074:EE_|CH3PR12MB8305:EE_ X-MS-Office365-Filtering-Correlation-Id: 303176ad-905a-44a0-7aa8-08db1f122acd X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: YGjhhP8KKMo6LHaGFnRtGLqfMZ2Y9iVBKriYWNyfDGGHH9deX6wd00q2/Sp2+wu6vFdRYQdhiKY/6hsasQLlh+2kKw6z+oBejWblb9HmCuK0vAKOtZAFl7eOmaqXDHDAj8Awqw62me5l8tj4AMQFgoEEDLARRxB5tfBi+z+037mtyTFvgWnkElA6MibBQ8grf6e1/HTOkLpRr/hsMoOYkctmy/GzJ+IcshuTI8SFVPBVJdQ7kzYOGpm667g1MOG4vs0ALOxrTivJOGbqbmYrwOq5dZSLTsSqci/plfgiuheAQycDWv48sLQamm5wuugzOdIkoCJtkDDQxTSIfJq13jYkCkPcrP2nWO32B0DwsiCrAFJurqIbySurveE4MFMrDmUy7FE7X4bLdnTPZo4wsoIYXXihQg7gjQEuzRV1NFcHkIVWHdHdrsFIvU2FiiysYlfZsTf5RI1gLZ3AUEDK8V/mkP28UJKWoXyYomkcQ1BBdroPJE+oD1mqFvuT+WWklZxN6NHgXJ2cOVxKK4kTm1OC4dhPB8mpBOPwCMXNyTf58U/L7K2QNIZYURt3GF2658RblwS1x3VMivIJzAYtQK3mRMGiJBxDVPzEuMX8FmLA/aFDRjUvA9YhcuBdV80iC27d0mmw8tRPm0bz4KmFok3iTDAQLWcCRykUMdpY22OYGjCrsp836d6Ge/pwGeLzb2buyH5n4eLpfziTdvJ/MwKlwXvbXpulcRihlNRxzXNvmavYs4q1ftWPtJZNTxFDfyFb3VGOOZ0e1zvBn+IVrA== 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)(136003)(376002)(346002)(39860400002)(396003)(451199018)(46966006)(40470700004)(36840700001)(82740400003)(36860700001)(81166007)(86362001)(356005)(36756003)(8676002)(44832011)(30864003)(5660300002)(2906002)(4326008)(6916009)(8936002)(70206006)(70586007)(41300700001)(82310400005)(2616005)(40460700003)(336012)(26005)(40480700001)(186003)(83380400001)(426003)(47076005)(478600001)(54906003)(316002)(6666004)(1076003)(7696005)(966005)(36900700001);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Mar 2023 13:45:09.0257 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 303176ad-905a-44a0-7aa8-08db1f122acd 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: DS1PEPF0000B074.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB8305 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Sergio Gonzalez Translate Documentation/process/deprecated.rst into Spanish. Co-developed-by: Carlos Bilbao Signed-off-by: Sergio Gonzalez Signed-off-by: Carlos Bilbao --- Changes since v1: - Change commit message to avoid confusion - Add From: tag for ma --- .../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/Docu= mentation/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: + +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D +Interfaces obsoletos, Caracter=C3=ADsticas del lenguaje, Atributos y Conve= nciones +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D + +En un mundo perfecto, ser=C3=ADa posible convertir todas las instancias de +alguna API obsoleta en una nueva API y quitar la API anterior en un +=C3=BAnico ciclo de desarrollo. Desafortunadamente, debido al tama=C3=B1o = del kernel, +la jerarqu=C3=ADa de mantenimiento, y el tiempo, no siempre es posible hac= er +estos cambios de una =C3=BAnica vez. Esto significa que las nuevas instanc= ias +han de ir cre=C3=A1ndose 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=C3=A9 ha sido declarado obsoleto y= por +qu=C3=A9, 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=C3=B1ala visualmente que un interface ha sido +declarado obsoleto, este `no produce m=C3=A1s avisos durante las compilaci= ones +`_ +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=C3=B3n completa. Dichos interfaces +deben o bien ser quitados por completo, o a=C3=B1adidos 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=C3=B1adas para actuar como una +"situaci=C3=B3n imposible", confirmar y disponer de un hilo del kernel de = forma +"segura", estas funciones han resultado ser demasiado arriesgadas. (e.g. +"=C2=BFen qu=C3=A9 orden se necesitan liberar los locks? =C2=BFSe han rest= aurado sus +estados?). La popular funci=C3=B3n BUG() desestabilizar=C3=A1 el sistema o= lo romper=C3=A1 +totalmente, lo cual hace imposible depurarlo o incluso generar reportes de +crash. Linus tiene una `opini=C3=B3n muy fuerte +`_ +y sentimientos `sobre esto +`_. + +N=C3=B3tese que la familia de funciones WARN() =C3=BAnicamente deber=C3=AD= a ser usada +en situaciones que se "esperan no sean alcanzables". Si se quiere +avisar sobre situaciones "alcanzables pero no deseadas", =C3=BAsese la fam= ilia +de funciones pr_warn(). Los responsables del sistema pueden haber definido +*panic_on_warn* sysctl para asegurarse que sus sistemas no contin=C3=BAan +ejecut=C3=A1ndose en presencia del condiciones "no alcanzables". (Por ejem= plo, +v=C3=A9ase commits como `este +`_.) + +Operaciones aritm=C3=A9ticas en los argumentos de reserva de memoria +--------------------------------------------------------------- +Los c=C3=A1lculos din=C3=A1micos de tama=C3=B1o (especialmente multiplicac= iones) no +deber=C3=ADan realizarse en los argumentos de reserva de memoria (o simila= res) +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=C3=B3n a esto son los va= lores +literales donde el compilador si puede avisar si estos puede desbordarse. +De todos modos, el m=C3=A9todo recomendado en estos caso es reescribir el = c=C3=B3digo +como se sugiere a continuaci=C3=B3n para evitar las operaciones aritm=C3= =A9ticas en +la reserva de memoria.) + +Por ejemplo, no utilice `count * size`` como argumento, como en:: + + foo =3D kmalloc(count * size, GFP_KERNEL); + +En vez de eso, utilice la reserva con dos argumentos:: + + foo =3D kmalloc_array(count, size, GFP_KERNEL); + +Espec=C3=ADficamente, 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 =3D vmalloc(array_size(count, size)); + +Otro caso com=C3=BAn a evitar es calcular el tama=C3=B1o de una estructura= com +la suma de otras estructuras, como en:: + + header =3D kzalloc(sizeof(*header) + count * sizeof(*header->item), + GFP_KERNEL); + +En vez de eso emplee:: + + header =3D kzalloc(struct_size(header, item, count), GFP_KERNEL); + +.. note:: Si se usa struct_size() en una estructura que contiene un elemen= to + de longitud cero o un array de un =C3=BAnico elemento como un array m= iembro, + por favor reescribir ese uso y cambiar a un `miembro array flexible + <#zero-length-and-one-element-arrays>`_ + + +Para otros c=C3=A1lculos, por favor use las funciones de ayuda: size_mul(), +size_add(), and size_sub(). Por ejemplo, en el caso de:: + + foo =3D krealloc(current_size + chunk_size * (count - 3), GFP_KERNEL); + +Re-escr=C3=ADbase, como:: + + foo =3D krealloc(size_add(current_size, + size_mul(chunk_size, + size_sub(count, 3))), GFP_KERNEL); + +Para m=C3=A1s detalles, mire tambi=C3=A9n array3_size() y flex_array_size(= ), +como tambi=C3=A9n 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=C3=ADcitamente 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=C3=B3tese que necesitar=C3=A1= n que la +cadena de caracteres termine en NUL o en el car=C3=A1cter de l=C3=ADnea nu= eva. + + +strcpy() +-------- +strcpy() no realiza verificaciones de los l=C3=ADmites del buffer de desti= no. +Esto puede resultar en desbordamientos lineals m=C3=A1s all=C3=A1 del fin = del buffer, +causando todo tipo de errores. Mientras `CONFIG_FORTIFY_SOURCE=3Dy` otras +varias opciones de compilaci=C3=B3n reducen el riesgo de usar esta funci= =C3=B3n, no +hay ninguna buena raz=C3=B3n para a=C3=B1adir nuevos usos de esta. El remp= lazo seguro +es la funci=C3=B3n 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=C3=BAmero de caracteres no nul= os +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=C3=A9 termin= ado en +NUL. Esto puede causar varios errores de desbordamiento en lectura y otros +tipos de funcionamiento err=C3=B3neo debido a que falta la terminaci=C3=B3= n en NUL. +Esta funci=C3=B3n tambi=C3=A9n termina la cadena de caracteres en NUL en e= l buffer de +destino si la cadena de origen es m=C3=A1s corta que el buffer de destino,= lo +cual puede ser una penalizaci=C3=B3n innecesaria para funciones usen esta +funci=C3=B3n con cadenas de caracteres que s=C3=AD est=C3=A1n terminadas e= n NUL. + +Cuando se necesita que la cadena de destino sea terminada en NUL, +el mejor reemplazo es usar la funci=C3=B3n 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=C3=BAmero de +caracteres no nulos copiados (o el valor negativo de errno cuando se trunca +la cadena de caracteres). Cualquier caso restante que necesitase todav=C3= =ADa +ser terminado en el caracter nulo, deber=C3=ADa usar strscpy_pad(). + +Si una funci=C3=B3n usa cadenas de caracteres que no necesitan terminar en= NUL, +deber=C3=ADa usarse strtomem(), y el destino deber=C3=ADa se=C3=B1alarse c= on el atributo +`__nonstring +`_ +para evitar avisos futuros en el compilador. Para casos que todav=C3=ADa +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=C3=ADmite de tama=C3=B1o del destino. Esto ineficiente y p= uede causar +desbordamientos de lectura si la cadena de origen no est=C3=A1 terminada e= n el +car=C3=A1cter NUL. El reemplazo seguro de esta funci=C3=B3n 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=C3=A1 valores negativos de erno cuand= o se +produzcan truncados. + +Especificaci=C3=B3n de formato %p +---------------------------- +Tradicionalmente,el uso de "%p" en el formato de cadenas de caracteres +resultar=C3=ADa 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=C3=A9ndolos efectivamente inutilizab= les +para usarlos como direcciones de memoria. Nuevos usos de "%p" no deber=C3= =ADan +ser a=C3=B1adidos al kernel. Para textos de direcciones, usar "%pS" es +mejor, ya que resulta en el nombre del s=C3=ADmbolo. Para pr=C3=A1cticamen= te 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. =C2=BFQuiz=C3=A1s se podr=C3=ADa quitar= totalmente? +- Si realmente se piensa que el valor del puntero es importante, =C2=BFpor= qu=C3=A9 + alg=C3=BAn estado del sistema o nivel de privilegio de usuario es consid= erado + "especial"? Si piensa que puede justificarse (en comentarios y mensajes + del commit), de forma suficiente como para pasar el escrutinio de Linux, + quiz=C3=A1s pueda usar el "%p", a la vez que se asegura que tiene los pe= rmisos + correspondientes. + +Si est=C3=A1 depurando algo donde el "%p" hasheado est=C3=A1 causando prob= lemas, +se puede arrancar temporalmente con la opci=C3=B3n de depuraci=C3=B3n "`no= _hash_pointers +`_". + + +Arrays de longitud variable (VLAs) +---------------------------------- +Usando VLA en la pila (stack) produce un c=C3=B3digo mucho peor que los ar= rays +de tama=C3=B1o est=C3=A1tico. Mientras que estos errores no triviales de `= rendimiento +`_ son raz=C3=B3n suficiente +para no usar VLAs, esto adem=C3=A1s son un riesgo de seguridad. El crecimi= ento +din=C3=A1mico del array en la pila, puede exceder la memoria restante en +el segmento de la pila. Esto podr=C3=ADa llevara a un fallo, posible sobre= -escritura +de contenido al final de la pila (cuando se construye sin +`CONFIG_THREAD_INFO_IN_TASK=3Dy`), o sobre-escritura de la memoria adyacen= te +a la pila (cuando se construye sin `CONFIG_VMAP_STACK=3Dy`). + + +Switch case fall-through impl=C3=ADcito +---------------------------------- +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=C3=BCedad en el c=C3=B3digo, ya que no sie= mpre est=C3=A1 +claro si el 'break' que falta es intencionado o un olvido. Por ejemplo, no +es obvio solamente mirando al c=C3=B3digo si `STATE_ONE` est=C3=A1 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=C3=ADcitos. 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=C3=A1s com=C3=BAnme= nte +soportadas por los compiladores de C, analizadores est=C3=A1ticos, 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