diff options
Diffstat (limited to 'Documentation/process/deprecated.rst')
| -rw-r--r-- | Documentation/process/deprecated.rst | 24 |
1 files changed, 3 insertions, 21 deletions
diff --git a/Documentation/process/deprecated.rst b/Documentation/process/deprecated.rst index 918e32d76fc4..ff71d802b53d 100644 --- a/Documentation/process/deprecated.rst +++ b/Documentation/process/deprecated.rst @@ -51,24 +51,6 @@ to make sure their systems do not continue running in the face of "unreachable" conditions. (For example, see commits like `this one <https://git.kernel.org/linus/d4689846881d160a4d12a514e991a740bcb5d65a>`_.) -uninitialized_var() -------------------- -For any compiler warnings about uninitialized variables, just add -an initializer. Using the uninitialized_var() macro (or similar -warning-silencing tricks) is dangerous as it papers over `real bugs -<https://lore.kernel.org/lkml/20200603174714.192027-1-glider@google.com/>`_ -(or can in the future), and suppresses unrelated compiler warnings -(e.g. "unused variable"). If the compiler thinks it is uninitialized, -either simply initialize the variable or make compiler changes. Keep in -mind that in most cases, if an initialization is obviously redundant, -the compiler's dead-store elimination pass will make sure there are no -needless variable writes. - -As Linus has said, this macro -`must <https://lore.kernel.org/lkml/CA+55aFw+Vbj0i=1TGqCR5vQkCzWJ0QxK6CernOU6eedsudAixw@mail.gmail.com/>`_ -`be <https://lore.kernel.org/lkml/CA+55aFwgbgqhbp1fkxvRKEpzyR5J8n1vKT1VZdz9knmPuXhOeg@mail.gmail.com/>`_ -`removed <https://lore.kernel.org/lkml/CA+55aFz2500WfbKXAx8s67wrm9=yVJu65TpLgN_ybYNv0VEOKA@mail.gmail.com/>`_. - open-coded arithmetic in allocator arguments -------------------------------------------- Dynamic size calculations (especially multiplication) should not be @@ -322,7 +304,8 @@ to allocate for a structure containing an array of this kind as a member:: In the example above, we had to remember to calculate ``count - 1`` when using the struct_size() helper, otherwise we would have --unintentionally-- allocated memory for one too many ``items`` objects. The cleanest and least error-prone way -to implement this is through the use of a `flexible array member`:: +to implement this is through the use of a `flexible array member`, together with +struct_size() and flex_array_size() helpers:: struct something { size_t count; @@ -334,5 +317,4 @@ to implement this is through the use of a `flexible array member`:: instance = kmalloc(struct_size(instance, items, count), GFP_KERNEL); instance->count = count; - size = sizeof(instance->items[0]) * instance->count; - memcpy(instance->items, source, size); + memcpy(instance->items, source, flex_array_size(instance, items, instance->count)); |