xref: /linux/Documentation/translations/sp_SP/process/deprecated.rst (revision 1ac731c529cd4d6adbce134754b51ff7d822b145)
1*456ef6b0SCarlos Bilbao.. include:: ../disclaimer-sp.rst
2*456ef6b0SCarlos Bilbao
3*456ef6b0SCarlos Bilbao:Original: :ref:`Documentation/process/deprecated.rst <deprecated>`
4*456ef6b0SCarlos Bilbao:Translator: Sergio Gonzalez <sergio.collado@gmail.com>
5*456ef6b0SCarlos Bilbao
6*456ef6b0SCarlos Bilbao.. _sp_deprecated:
7*456ef6b0SCarlos Bilbao
8*456ef6b0SCarlos Bilbao============================================================================
9*456ef6b0SCarlos BilbaoInterfaces obsoletos, Características del lenguaje, Atributos y Convenciones
10*456ef6b0SCarlos Bilbao============================================================================
11*456ef6b0SCarlos Bilbao
12*456ef6b0SCarlos BilbaoEn un mundo perfecto, sería posible convertir todas las instancias de
13*456ef6b0SCarlos Bilbaoalguna API obsoleta en una nueva API y quitar la API anterior en un
14*456ef6b0SCarlos Bilbaoúnico ciclo de desarrollo. Desafortunadamente, debido al tamaño del kernel,
15*456ef6b0SCarlos Bilbaola jerarquía de mantenimiento, y el tiempo, no siempre es posible hacer
16*456ef6b0SCarlos Bilbaoestos cambios de una única vez. Esto significa que las nuevas instancias
17*456ef6b0SCarlos Bilbaohan de ir creándose en el kernel, mientras que las antiguas se quitan,
18*456ef6b0SCarlos Bilbaohaciendo que la cantidad de trabajo para limpiar las APIs crezca. Para
19*456ef6b0SCarlos Bilbaoinformar a los desarrolladores sobre qué ha sido declarado obsoleto y por
20*456ef6b0SCarlos Bilbaoqué, ha sido creada esta lista como un lugar donde indicar cuando los usos
21*456ef6b0SCarlos Bilbaoobsoletos son propuestos para incluir en el kernel.
22*456ef6b0SCarlos Bilbao
23*456ef6b0SCarlos Bilbao__deprecated
24*456ef6b0SCarlos Bilbao------------
25*456ef6b0SCarlos BilbaoMientras que este atributo señala visualmente que un interface ha sido
26*456ef6b0SCarlos Bilbaodeclarado obsoleto, este `no produce más avisos durante las compilaciones
27*456ef6b0SCarlos Bilbao<https://git.kernel.org/linus/771c035372a036f83353eef46dbb829780330234>`_
28*456ef6b0SCarlos Bilbaoporque uno de los objetivos del kernel es que compile sin avisos, y
29*456ef6b0SCarlos Bilbaonadie ha hecho nada para quitar estos interfaces obsoletos. Mientras
30*456ef6b0SCarlos Bilbaoque usar `__deprecated` es sencillo para anotar una API obsoleta en
31*456ef6b0SCarlos Bilbaoun archivo de cabecera, no es la solución completa. Dichos interfaces
32*456ef6b0SCarlos Bilbaodeben o bien ser quitados por completo, o añadidos a este archivo para
33*456ef6b0SCarlos Bilbaodesanimar a otros a usarla en el futuro.
34*456ef6b0SCarlos Bilbao
35*456ef6b0SCarlos BilbaoBUG() y BUG_ON()
36*456ef6b0SCarlos Bilbao----------------
37*456ef6b0SCarlos BilbaoUse WARN() y WARN_ON() en su lugar, y gestione las condiciones de error
38*456ef6b0SCarlos Bilbao"imposibles" tan elegantemente como se pueda. Mientras que la familia de
39*456ef6b0SCarlos Bilbaofunciones BUG() fueron originalmente diseñadas para actuar como una
40*456ef6b0SCarlos Bilbao"situación imposible", confirmar y disponer de un hilo del kernel de forma
41*456ef6b0SCarlos Bilbao"segura", estas funciones han resultado ser demasiado arriesgadas. (e.g.
42*456ef6b0SCarlos Bilbao"¿en qué orden se necesitan liberar los locks? ¿Se han restaurado sus
43*456ef6b0SCarlos Bilbaoestados?). La popular función BUG() desestabilizará el sistema o lo romperá
44*456ef6b0SCarlos Bilbaototalmente, lo cual hace imposible depurarlo o incluso generar reportes de
45*456ef6b0SCarlos Bilbaocrash. Linus tiene una `opinión muy fuerte
46*456ef6b0SCarlos Bilbao<https://lore.kernel.org/lkml/CA+55aFy6jNLsywVYdGp83AMrXBo_P-pkjkphPGrO=82SPKCpLQ@mail.gmail.com/>`_
47*456ef6b0SCarlos Bilbaoy sentimientos `sobre esto
48*456ef6b0SCarlos Bilbao<https://lore.kernel.org/lkml/CAHk-=whDHsbK3HTOpTF=ue_o04onRwTEaK_ZoJp_fjbqq4+=Jw@mail.gmail.com/>`_.
49*456ef6b0SCarlos Bilbao
50*456ef6b0SCarlos BilbaoNótese que la familia de funciones WARN() únicamente debería ser usada
51*456ef6b0SCarlos Bilbaoen situaciones que se "esperan no sean alcanzables". Si se quiere
52*456ef6b0SCarlos Bilbaoavisar sobre situaciones "alcanzables pero no deseadas", úsese la familia
53*456ef6b0SCarlos Bilbaode funciones pr_warn(). Los responsables del sistema pueden haber definido
54*456ef6b0SCarlos Bilbao*panic_on_warn* sysctl para asegurarse que sus sistemas no continúan
55*456ef6b0SCarlos Bilbaoejecutándose en presencia del condiciones "no alcanzables". (Por ejemplo,
56*456ef6b0SCarlos Bilbaovéase commits como `este
57*456ef6b0SCarlos Bilbao<https://git.kernel.org/linus/d4689846881d160a4d12a514e991a740bcb5d65a>`_.)
58*456ef6b0SCarlos Bilbao
59*456ef6b0SCarlos BilbaoOperaciones aritméticas en los argumentos de reserva de memoria
60*456ef6b0SCarlos Bilbao---------------------------------------------------------------
61*456ef6b0SCarlos BilbaoLos cálculos dinámicos de tamaño (especialmente multiplicaciones) no
62*456ef6b0SCarlos Bilbaodeberían realizarse en los argumentos de reserva de memoria (o similares)
63*456ef6b0SCarlos Bilbaodebido al riesgo de desbordamiento. Esto puede llevar a valores rotando y
64*456ef6b0SCarlos Bilbaoque se realicen reservas de memoria menores que las que se esperaban. El
65*456ef6b0SCarlos Bilbaouso de esas reservas puede llevar a desbordamientos en el 'heap' de memoria
66*456ef6b0SCarlos Bilbaoy otros funcionamientos incorrectos. (Una excepción a esto son los valores
67*456ef6b0SCarlos Bilbaoliterales donde el compilador si puede avisar si estos puede desbordarse.
68*456ef6b0SCarlos BilbaoDe todos modos, el método recomendado en estos caso es reescribir el código
69*456ef6b0SCarlos Bilbaocomo se sugiere a continuación para evitar las operaciones aritméticas en
70*456ef6b0SCarlos Bilbaola reserva de memoria.)
71*456ef6b0SCarlos Bilbao
72*456ef6b0SCarlos BilbaoPor ejemplo, no utilice `count * size`` como argumento, como en::
73*456ef6b0SCarlos Bilbao
74*456ef6b0SCarlos Bilbao    foo = kmalloc(count * size, GFP_KERNEL);
75*456ef6b0SCarlos Bilbao
76*456ef6b0SCarlos BilbaoEn vez de eso, utilice la reserva con dos argumentos::
77*456ef6b0SCarlos Bilbao
78*456ef6b0SCarlos Bilbao    	foo = kmalloc_array(count, size, GFP_KERNEL);
79*456ef6b0SCarlos Bilbao
80*456ef6b0SCarlos BilbaoEspecíficamente, kmalloc() puede ser sustituido con kmalloc_array(),
81*456ef6b0SCarlos Bilbaokzalloc() puede ser sustituido con kcalloc().
82*456ef6b0SCarlos Bilbao
83*456ef6b0SCarlos BilbaoSi no existen funciones con dos argumentos, utilice las funciones que se
84*456ef6b0SCarlos Bilbaosaturan, en caso de desbordamiento::
85*456ef6b0SCarlos Bilbao
86*456ef6b0SCarlos Bilbao    	bar = vmalloc(array_size(count, size));
87*456ef6b0SCarlos Bilbao
88*456ef6b0SCarlos BilbaoOtro caso común a evitar es calcular el tamaño de una estructura com
89*456ef6b0SCarlos Bilbaola suma de otras estructuras, como en::
90*456ef6b0SCarlos Bilbao
91*456ef6b0SCarlos Bilbao    header = kzalloc(sizeof(*header) + count * sizeof(*header->item),
92*456ef6b0SCarlos Bilbao   		  GFP_KERNEL);
93*456ef6b0SCarlos Bilbao
94*456ef6b0SCarlos BilbaoEn vez de eso emplee::
95*456ef6b0SCarlos Bilbao
96*456ef6b0SCarlos Bilbao    header = kzalloc(struct_size(header, item, count), GFP_KERNEL);
97*456ef6b0SCarlos Bilbao
98*456ef6b0SCarlos Bilbao.. note:: Si se usa struct_size() en una estructura que contiene un elemento
99*456ef6b0SCarlos Bilbao    	de longitud cero o un array de un único elemento como un array miembro,
100*456ef6b0SCarlos Bilbao    	por favor reescribir ese uso y cambiar a un `miembro array flexible
101*456ef6b0SCarlos Bilbao    	<#zero-length-and-one-element-arrays>`_
102*456ef6b0SCarlos Bilbao
103*456ef6b0SCarlos Bilbao
104*456ef6b0SCarlos BilbaoPara otros cálculos, por favor use las funciones de ayuda: size_mul(),
105*456ef6b0SCarlos Bilbaosize_add(), and size_sub(). Por ejemplo, en el caso de::
106*456ef6b0SCarlos Bilbao
107*456ef6b0SCarlos Bilbao    foo = krealloc(current_size + chunk_size * (count - 3), GFP_KERNEL);
108*456ef6b0SCarlos Bilbao
109*456ef6b0SCarlos BilbaoRe-escríbase, como::
110*456ef6b0SCarlos Bilbao
111*456ef6b0SCarlos Bilbao    foo = krealloc(size_add(current_size,
112*456ef6b0SCarlos Bilbao   			 size_mul(chunk_size,
113*456ef6b0SCarlos Bilbao   				  size_sub(count, 3))), GFP_KERNEL);
114*456ef6b0SCarlos Bilbao
115*456ef6b0SCarlos BilbaoPara más detalles, mire también array3_size() y flex_array_size(),
116*456ef6b0SCarlos Bilbaocomo también la familia de funciones relacionadas check_mul_overflow(),
117*456ef6b0SCarlos Bilbaocheck_add_overflow(), check_sub_overflow(), y check_shl_overflow().
118*456ef6b0SCarlos Bilbao
119*456ef6b0SCarlos Bilbao
120*456ef6b0SCarlos Bilbaosimple_strtol(), simple_strtoll(), simple_strtoul(), simple_strtoull()
121*456ef6b0SCarlos Bilbao----------------------------------------------------------------------
122*456ef6b0SCarlos BilbaoLas funciones: simple_strtol(), simple_strtoll(), simple_strtoul(), y
123*456ef6b0SCarlos Bilbaosimple_strtoull() explícitamente ignoran los desbordamientos, lo que puede
124*456ef6b0SCarlos Bilbaollevar a resultados inesperados por las funciones que las llaman. Las
125*456ef6b0SCarlos Bilbaofunciones respectivas kstrtol(), kstrtoll(), kstrtoul(), y kstrtoull()
126*456ef6b0SCarlos Bilbaotienden a ser reemplazos correctos, aunque nótese que necesitarán que la
127*456ef6b0SCarlos Bilbaocadena de caracteres termine en NUL o en el carácter de línea nueva.
128*456ef6b0SCarlos Bilbao
129*456ef6b0SCarlos Bilbao
130*456ef6b0SCarlos Bilbaostrcpy()
131*456ef6b0SCarlos Bilbao--------
132*456ef6b0SCarlos Bilbaostrcpy() no realiza verificaciones de los límites del buffer de destino.
133*456ef6b0SCarlos BilbaoEsto puede resultar en desbordamientos lineals más allá del fin del buffer,
134*456ef6b0SCarlos Bilbaocausando todo tipo de errores. Mientras `CONFIG_FORTIFY_SOURCE=y` otras
135*456ef6b0SCarlos Bilbaovarias opciones de compilación reducen el riesgo de usar esta función, no
136*456ef6b0SCarlos Bilbaohay ninguna buena razón para añadir nuevos usos de esta. El remplazo seguro
137*456ef6b0SCarlos Bilbaoes la función strscpy(), aunque se ha de tener cuidado con cualquier caso
138*456ef6b0SCarlos Bilbaoen el el valor retornado por strcpy() sea usado, ya que strscpy() no
139*456ef6b0SCarlos Bilbaodevuelve un puntero a el destino, sino el número de caracteres no nulos
140*456ef6b0SCarlos Bilbaocompilados (o el valor negativo de errno cuando se trunca la cadena de
141*456ef6b0SCarlos Bilbaocaracteres).
142*456ef6b0SCarlos Bilbao
143*456ef6b0SCarlos Bilbaostrncpy() en cadenas de caracteres terminadas en NUL
144*456ef6b0SCarlos Bilbao----------------------------------------------------
145*456ef6b0SCarlos BilbaoEl uso de strncpy() no garantiza que el buffer de destino esté terminado en
146*456ef6b0SCarlos BilbaoNUL. Esto puede causar varios errores de desbordamiento en lectura y otros
147*456ef6b0SCarlos Bilbaotipos de funcionamiento erróneo debido a que falta la terminación en NUL.
148*456ef6b0SCarlos BilbaoEsta función también termina la cadena de caracteres en NUL en el buffer de
149*456ef6b0SCarlos Bilbaodestino si la cadena de origen es más corta que el buffer de destino, lo
150*456ef6b0SCarlos Bilbaocual puede ser una penalización innecesaria para funciones usen esta
151*456ef6b0SCarlos Bilbaofunción con cadenas de caracteres que sí están terminadas en NUL.
152*456ef6b0SCarlos Bilbao
153*456ef6b0SCarlos BilbaoCuando se necesita que la cadena de destino sea terminada en NUL,
154*456ef6b0SCarlos Bilbaoel mejor reemplazo es usar la función strscpy(), aunque se ha de tener
155*456ef6b0SCarlos Bilbaocuidado en los casos en los que el valor de strncpy() fuera usado, ya que
156*456ef6b0SCarlos Bilbaostrscpy() no devuelve un puntero al destino, sino el número de
157*456ef6b0SCarlos Bilbaocaracteres no nulos copiados (o el valor negativo de errno cuando se trunca
158*456ef6b0SCarlos Bilbaola cadena de caracteres). Cualquier caso restante que necesitase todavía
159*456ef6b0SCarlos Bilbaoser terminado en el caracter nulo, debería usar strscpy_pad().
160*456ef6b0SCarlos Bilbao
161*456ef6b0SCarlos BilbaoSi una función usa cadenas de caracteres que no necesitan terminar en NUL,
162*456ef6b0SCarlos Bilbaodebería usarse strtomem(), y el destino debería señalarse con el atributo
163*456ef6b0SCarlos Bilbao`__nonstring
164*456ef6b0SCarlos Bilbao<https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html>`_
165*456ef6b0SCarlos Bilbaopara evitar avisos futuros en el compilador. Para casos que todavía
166*456ef6b0SCarlos Bilbaonecesitan cadenas de caracteres que se rellenen al final con el
167*456ef6b0SCarlos Bilbaocaracter NUL, usar strtomem_pad().
168*456ef6b0SCarlos Bilbao
169*456ef6b0SCarlos Bilbaostrlcpy()
170*456ef6b0SCarlos Bilbao---------
171*456ef6b0SCarlos Bilbaostrlcpy() primero lee por completo el buffer de origen (ya que el valor
172*456ef6b0SCarlos Bilbaodevuelto intenta ser el mismo que el de strlen()). Esta lectura puede
173*456ef6b0SCarlos Bilbaosobrepasar el límite de tamaño del destino. Esto ineficiente y puede causar
174*456ef6b0SCarlos Bilbaodesbordamientos de lectura si la cadena de origen no está terminada en el
175*456ef6b0SCarlos Bilbaocarácter NUL. El reemplazo seguro de esta función es strscpy(), pero se ha
176*456ef6b0SCarlos Bilbaode tener cuidado que en los casos en lso que se usase el valor devuelto de
177*456ef6b0SCarlos Bilbaostrlcpy(), ya que strscpy() devolverá valores negativos de erno cuando se
178*456ef6b0SCarlos Bilbaoproduzcan truncados.
179*456ef6b0SCarlos Bilbao
180*456ef6b0SCarlos BilbaoEspecificación de formato %p
181*456ef6b0SCarlos Bilbao----------------------------
182*456ef6b0SCarlos BilbaoTradicionalmente,el uso de "%p" en el formato de cadenas de caracteres
183*456ef6b0SCarlos Bilbaoresultaría en exponer esas direcciones en dmesg, proc, sysfs, etc. En vez
184*456ef6b0SCarlos Bilbaode dejar que sean una vulnerabilidad, todos los "%p" que se usan en el
185*456ef6b0SCarlos Bilbaokernel se imprimen como un hash, haciéndolos efectivamente inutilizables
186*456ef6b0SCarlos Bilbaopara usarlos como direcciones de memoria. Nuevos usos de "%p" no deberían
187*456ef6b0SCarlos Bilbaoser añadidos al kernel. Para textos de direcciones, usar "%pS" es
188*456ef6b0SCarlos Bilbaomejor, ya que resulta en el nombre del símbolo. Para prácticamente el
189*456ef6b0SCarlos Bilbaoresto de casos, mejor no usar "%p" en absoluto.
190*456ef6b0SCarlos Bilbao
191*456ef6b0SCarlos BilbaoParafraseando las actuales `direcciones de Linus <https://lore.kernel.org/lkml/CA+55aFwQEd_d40g4mUCSsVRZzrFPUJt74vc6PPpb675hYNXcKw@mail.gmail.com/>`_:
192*456ef6b0SCarlos Bilbao
193*456ef6b0SCarlos Bilbao- Si el valor "hasheado" "%p" no tienen ninguna finalidad, preguntarse si el
194*456ef6b0SCarlos Bilbao  puntero es realmente importante. ¿Quizás se podría quitar totalmente?
195*456ef6b0SCarlos Bilbao- Si realmente se piensa que el valor del puntero es importante, ¿porqué
196*456ef6b0SCarlos Bilbao  algún estado del sistema o nivel de privilegio de usuario es considerado
197*456ef6b0SCarlos Bilbao  "especial"? Si piensa que puede justificarse (en comentarios y mensajes
198*456ef6b0SCarlos Bilbao  del commit), de forma suficiente como para pasar el escrutinio de Linux,
199*456ef6b0SCarlos Bilbao  quizás pueda usar el "%p", a la vez que se asegura que tiene los permisos
200*456ef6b0SCarlos Bilbao  correspondientes.
201*456ef6b0SCarlos Bilbao
202*456ef6b0SCarlos BilbaoSi está depurando algo donde el "%p" hasheado está causando problemas,
203*456ef6b0SCarlos Bilbaose puede arrancar temporalmente con la opción de depuración "`no_hash_pointers
204*456ef6b0SCarlos Bilbao<https://git.kernel.org/linus/5ead723a20e0447bc7db33dc3070b420e5f80aa6>`_".
205*456ef6b0SCarlos Bilbao
206*456ef6b0SCarlos Bilbao
207*456ef6b0SCarlos BilbaoArrays de longitud variable (VLAs)
208*456ef6b0SCarlos Bilbao----------------------------------
209*456ef6b0SCarlos BilbaoUsando VLA en la pila (stack) produce un código mucho peor que los arrays
210*456ef6b0SCarlos Bilbaode tamaño estático. Mientras que estos errores no triviales de `rendimiento
211*456ef6b0SCarlos Bilbao<https://git.kernel.org/linus/02361bc77888>`_  son razón suficiente
212*456ef6b0SCarlos Bilbaopara no usar VLAs, esto además son un riesgo de seguridad. El crecimiento
213*456ef6b0SCarlos Bilbaodinámico del array en la pila, puede exceder la memoria restante en
214*456ef6b0SCarlos Bilbaoel segmento de la pila. Esto podría llevara a un fallo, posible sobre-escritura
215*456ef6b0SCarlos Bilbaode contenido al final de la pila (cuando se construye sin
216*456ef6b0SCarlos Bilbao`CONFIG_THREAD_INFO_IN_TASK=y`), o sobre-escritura de la memoria adyacente
217*456ef6b0SCarlos Bilbaoa la pila (cuando se construye sin `CONFIG_VMAP_STACK=y`).
218*456ef6b0SCarlos Bilbao
219*456ef6b0SCarlos Bilbao
220*456ef6b0SCarlos BilbaoSwitch case fall-through implícito
221*456ef6b0SCarlos Bilbao----------------------------------
222*456ef6b0SCarlos BilbaoEl lenguaje C permite a las sentencias 'switch' saltar de un caso al
223*456ef6b0SCarlos Bilbaosiguiente caso cuando la sentencia de ruptura "break" no aparece al final
224*456ef6b0SCarlos Bilbaodel caso. Esto, introduce ambigüedad en el código, ya que no siempre está
225*456ef6b0SCarlos Bilbaoclaro si el 'break' que falta es intencionado o un olvido. Por ejemplo, no
226*456ef6b0SCarlos Bilbaoes obvio solamente mirando al código si `STATE_ONE` está escrito para
227*456ef6b0SCarlos Bilbaointencionadamente saltar en `STATE_TWO`::
228*456ef6b0SCarlos Bilbao
229*456ef6b0SCarlos Bilbao    switch (value) {
230*456ef6b0SCarlos Bilbao    case STATE_ONE:
231*456ef6b0SCarlos Bilbao   	 do_something();
232*456ef6b0SCarlos Bilbao    case STATE_TWO:
233*456ef6b0SCarlos Bilbao   	 do_other();
234*456ef6b0SCarlos Bilbao   	 break;
235*456ef6b0SCarlos Bilbao    default:
236*456ef6b0SCarlos Bilbao   	 WARN("unknown state");
237*456ef6b0SCarlos Bilbao    }
238*456ef6b0SCarlos Bilbao
239*456ef6b0SCarlos BilbaoYa que ha habido una larga lista de defectos `debidos a declaraciones de "break"
240*456ef6b0SCarlos Bilbaoque faltan <https://cwe.mitre.org/data/definitions/484.html>`_, no se
241*456ef6b0SCarlos Bilbaopermiten 'fall-through' implícitos. Para identificar 'fall-through'
242*456ef6b0SCarlos Bilbaointencionados, se ha adoptado la pseudo-palabra-clave macro "falltrhrough",
243*456ef6b0SCarlos Bilbaoque expande las extensiones de gcc `__attribute__((__fallthrough__))
244*456ef6b0SCarlos Bilbao<https://gcc.gnu.org/onlinedocs/gcc/Statement-Attributes.html>`_.
245*456ef6b0SCarlos Bilbao(Cuando la sintaxis de C17/c18 `[[fallthrough]]` sea más comúnmente
246*456ef6b0SCarlos Bilbaosoportadas por los compiladores de C, analizadores estáticos, e IDEs,
247*456ef6b0SCarlos Bilbaose puede cambiar a usar esa sintaxis para esa pseudo-palabra-clave.
248*456ef6b0SCarlos Bilbao
249*456ef6b0SCarlos BilbaoTodos los bloques switch/case deben acabar en uno de:
250*456ef6b0SCarlos Bilbao
251*456ef6b0SCarlos Bilbao* break;
252*456ef6b0SCarlos Bilbao* fallthrough;
253*456ef6b0SCarlos Bilbao* continue;
254*456ef6b0SCarlos Bilbao* goto <label>;
255*456ef6b0SCarlos Bilbao* return [expression];
256*456ef6b0SCarlos Bilbao
257*456ef6b0SCarlos Bilbao
258*456ef6b0SCarlos BilbaoArrays de longitud cero y un elemento
259*456ef6b0SCarlos Bilbao-------------------------------------
260*456ef6b0SCarlos BilbaoHay una necesidad habitual en el kernel de proveer una forma para declarar
261*456ef6b0SCarlos Bilbaoun grupo de elementos consecutivos de tamaño dinámico en una estructura.
262*456ef6b0SCarlos BilbaoEl código del kernel debería usar siempre `"miembros array flexible" <https://en.wikipedia.org/wiki/Flexible_array_member>`_
263*456ef6b0SCarlos Bilbaoen estos casos. El estilo anterior de arrays de un elemento o de longitud
264*456ef6b0SCarlos Bilbaocero, no deben usarse más.
265*456ef6b0SCarlos Bilbao
266*456ef6b0SCarlos BilbaoEn el código C más antiguo, los elementos finales de tamaño dinámico se
267*456ef6b0SCarlos Bilbaoobtenían especificando un array de un elemento al final de una estructura::
268*456ef6b0SCarlos Bilbao
269*456ef6b0SCarlos Bilbao    	struct something {
270*456ef6b0SCarlos Bilbao            	size_t count;
271*456ef6b0SCarlos Bilbao            	struct foo items[1];
272*456ef6b0SCarlos Bilbao    	};
273*456ef6b0SCarlos Bilbao
274*456ef6b0SCarlos BilbaoEn código C más antiguo, elementos seguidos de tamaño dinámico eran creados
275*456ef6b0SCarlos Bilbaoespecificando una array de un único elemento al final de una estructura::
276*456ef6b0SCarlos Bilbao
277*456ef6b0SCarlos Bilbao    	struct something {
278*456ef6b0SCarlos Bilbao            	size_t count;
279*456ef6b0SCarlos Bilbao            	struct foo items[1];
280*456ef6b0SCarlos Bilbao    	};
281*456ef6b0SCarlos Bilbao
282*456ef6b0SCarlos BilbaoEsto llevó a resultados incorrectos en los cálculos de tamaño mediante
283*456ef6b0SCarlos Bilbaosizeof() (el cual hubiera necesitado eliminar el tamaño del último elemento
284*456ef6b0SCarlos Bilbaopara tener un tamaño correcto de la "cabecera"). Una `extensión de GNU C
285*456ef6b0SCarlos Bilbao<https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html>`_ se empezó a usar
286*456ef6b0SCarlos Bilbaopara permitir los arrays de longitud cero, para evitar estos tipos de
287*456ef6b0SCarlos Bilbaoproblemas de tamaño::
288*456ef6b0SCarlos Bilbao
289*456ef6b0SCarlos Bilbao    	struct something {
290*456ef6b0SCarlos Bilbao            	size_t count;
291*456ef6b0SCarlos Bilbao            	struct foo items[0];
292*456ef6b0SCarlos Bilbao    	};
293*456ef6b0SCarlos Bilbao
294*456ef6b0SCarlos BilbaoPero esto llevó a otros problemas, y no solucionó algunos otros problemas
295*456ef6b0SCarlos Bilbaocompartidos por ambos estilos, como no ser capaz de detectar cuando ese array
296*456ef6b0SCarlos Bilbaoaccidentalmente _no_ es usado al final de la estructura (lo que podía pasar
297*456ef6b0SCarlos Bilbaodirectamente, o cuando dicha estructura era usada en uniones, estructuras
298*456ef6b0SCarlos Bilbaode estructuras, etc).
299*456ef6b0SCarlos Bilbao
300*456ef6b0SCarlos BilbaoC99 introdujo "los arrays miembros flexibles", los cuales carecen de un
301*456ef6b0SCarlos Bilbaotamaño numérico en su declaración del array::
302*456ef6b0SCarlos Bilbao
303*456ef6b0SCarlos Bilbao    	struct something {
304*456ef6b0SCarlos Bilbao            	size_t count;
305*456ef6b0SCarlos Bilbao            	struct foo items[];
306*456ef6b0SCarlos Bilbao    	};
307*456ef6b0SCarlos Bilbao
308*456ef6b0SCarlos BilbaoEsta es la forma en la que el kernel espera que se declaren los elementos
309*456ef6b0SCarlos Bilbaode tamaño dinámico concatenados. Esto permite al compilador generar
310*456ef6b0SCarlos Bilbaoerrores, cuando el array flexible no es declarado en el último lugar de la
311*456ef6b0SCarlos Bilbaoestructura, lo que ayuda a prevenir errores en él código del tipo
312*456ef6b0SCarlos Bilbao`comportamiento indefinido <https://git.kernel.org/linus/76497732932f15e7323dc805e8ea8dc11bb587cf>`_.
313*456ef6b0SCarlos BilbaoEsto también permite al compilador analizar correctamente los tamaños de
314*456ef6b0SCarlos Bilbaolos arrays (via sizeof(), `CONFIG_FORTIFY_SOURCE`, y `CONFIG_UBSAN_BOUNDS`).
315*456ef6b0SCarlos BilbaoPor ejemplo, si no hay un mecanismo que avise que el siguiente uso de
316*456ef6b0SCarlos Bilbaosizeof() en un array de longitud cero, siempre resulta en cero::
317*456ef6b0SCarlos Bilbao
318*456ef6b0SCarlos Bilbao        struct something {
319*456ef6b0SCarlos Bilbao                size_t count;
320*456ef6b0SCarlos Bilbao                struct foo items[0];
321*456ef6b0SCarlos Bilbao        };
322*456ef6b0SCarlos Bilbao
323*456ef6b0SCarlos Bilbao        struct something *instance;
324*456ef6b0SCarlos Bilbao
325*456ef6b0SCarlos Bilbao        instance = kmalloc(struct_size(instance, items, count), GFP_KERNEL);
326*456ef6b0SCarlos Bilbao        instance->count = count;
327*456ef6b0SCarlos Bilbao
328*456ef6b0SCarlos Bilbao        size = sizeof(instance->items) * instance->count;
329*456ef6b0SCarlos Bilbao        memcpy(instance->items, source, size);
330*456ef6b0SCarlos Bilbao
331*456ef6b0SCarlos BilbaoEn la última línea del código anterior, ``zero`` vale ``cero``, cuando uno
332*456ef6b0SCarlos Bilbaopodría esperar que representa el tamaño total en bytes de la memoria dinámica
333*456ef6b0SCarlos Bilbaoreservada para el array consecutivo ``items``. Aquí hay un par de ejemplos
334*456ef6b0SCarlos Bilbaomás sobre este tema:  `link 1
335*456ef6b0SCarlos Bilbao<https://git.kernel.org/linus/f2cd32a443da694ac4e28fbf4ac6f9d5cc63a539>`_,
336*456ef6b0SCarlos Bilbao`link 2
337*456ef6b0SCarlos Bilbao<https://git.kernel.org/linus/ab91c2a89f86be2898cee208d492816ec238b2cf>`_.
338*456ef6b0SCarlos BilbaoSin embargo, los array de miembros flexibles tienen un type incompleto, y
339*456ef6b0SCarlos Bilbaono se ha de aplicar el operador sizeof()<https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html>`_,
340*456ef6b0SCarlos Bilbaoasí cualquier mal uso de dichos operadores será detectado inmediatamente en
341*456ef6b0SCarlos Bilbaoel momento de compilación.
342*456ef6b0SCarlos Bilbao
343*456ef6b0SCarlos BilbaoCon respecto a los arrays de un único elemento, se ha de ser consciente de
344*456ef6b0SCarlos Bilbaoque dichos arrays ocupan al menos tanto espacio como un único objeto del
345*456ef6b0SCarlos Bilbaotipo https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html>`_, de ahí que
346*456ef6b0SCarlos Bilbaoestos contribuyan al tamaño de la estructura que los contiene. Esto es
347*456ef6b0SCarlos Bilbaoproclive a errores cada vez que se quiere calcular el tamaño total de la
348*456ef6b0SCarlos Bilbaomemoria dinámica para reservar una estructura que contenga un array de este
349*456ef6b0SCarlos Bilbaotipo como su miembro::
350*456ef6b0SCarlos Bilbao
351*456ef6b0SCarlos Bilbao        struct something {
352*456ef6b0SCarlos Bilbao                size_t count;
353*456ef6b0SCarlos Bilbao                struct foo items[1];
354*456ef6b0SCarlos Bilbao        };
355*456ef6b0SCarlos Bilbao
356*456ef6b0SCarlos Bilbao        struct something *instance;
357*456ef6b0SCarlos Bilbao
358*456ef6b0SCarlos Bilbao        instance = kmalloc(struct_size(instance, items, count - 1), GFP_KERNEL);
359*456ef6b0SCarlos Bilbao        instance->count = count;
360*456ef6b0SCarlos Bilbao
361*456ef6b0SCarlos Bilbao        size = sizeof(instance->items) * instance->count;
362*456ef6b0SCarlos Bilbao        memcpy(instance->items, source, size);
363*456ef6b0SCarlos Bilbao
364*456ef6b0SCarlos BilbaoEn el ejemplo anterior, hemos de recordar calcular ``count - 1``, cuando se
365*456ef6b0SCarlos Bilbaousa la función de ayuda struct_size(), de otro modo estaríamos
366*456ef6b0SCarlos Bilbao--desintencionadamente--reservando memoria para un  ``items`` de más. La
367*456ef6b0SCarlos Bilbaoforma más clara y menos proclive a errores es implementar esto mediante el
368*456ef6b0SCarlos Bilbaouso de `array miembro flexible`, junto con las funciones de ayuda:
369*456ef6b0SCarlos Bilbaostruct_size() y flex_array_size()::
370*456ef6b0SCarlos Bilbao
371*456ef6b0SCarlos Bilbao        struct something {
372*456ef6b0SCarlos Bilbao                size_t count;
373*456ef6b0SCarlos Bilbao                struct foo items[];
374*456ef6b0SCarlos Bilbao        };
375*456ef6b0SCarlos Bilbao
376*456ef6b0SCarlos Bilbao        struct something *instance;
377*456ef6b0SCarlos Bilbao
378*456ef6b0SCarlos Bilbao        instance = kmalloc(struct_size(instance, items, count), GFP_KERNEL);
379*456ef6b0SCarlos Bilbao        instance->count = count;
380*456ef6b0SCarlos Bilbao
381*456ef6b0SCarlos Bilbao        memcpy(instance->items, source, flex_array_size(instance, items, instance->count));
382