C++ Logo

std-proposals

Advanced search

Re: Fixing C-style arrays

From: Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]>
Date: Thu, 12 Mar 2020 19:48:05 -0400
On Thu, Mar 12, 2020 at 5:40 PM Maciej Cencora via Std-Proposals <
std-proposals_at_[hidden]> wrote:

>
> I propose to deprecate in C++23:
> 1) mixed pointer and array comparisons:
> int a[2]; int b[2];
> a == &b[0];
>

Okay... but why "mixed"? Why not just deprecate *all* relational/equality
operators where either side (or both) is an array?

    bool one(const char *p) { return *p == "hello"*; } // definitely a bug
    bool two(int x, int y) { int a[2] = {x,y}; int b[2] = {3,4}; return (*a
== b*); } // definitely a bug
    const char *three(const char *p) { static const char arr[] = "hello";
return (*p == arr*) ? nullptr : arr; } // not a bug, but perhaps
expendable if its sacrifice buys us something good

GCC, Clang, and MSVC all warn on `one`.
Clang warns twice on `two`, even going so far as to claim that comparison
between two arrays is already deprecated(!).
Nobody warns on `three`.



> 2) array decl in func parameters:
> void foo(int a[2]);
>

Sadly, you can't do this. It's true that nobody should ever write what you
have there <https://lkml.org/lkml/2015/9/3/428>; but there's simply too
much code out there of the form

    int main(int argc, char *argv[])

to ever permit a general deprecation of the notation.
Vendors could certainly start warning on it, though.

Does clang-tidy support a check for "misleading array syntax in parameter
declaration"?

–Arthur

Received on 2020-03-12 18:51:05