lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] [lmi-commits] master 98a3720 2/6: Explicitly qualify std::size


From: Greg Chicares
Subject: Re: [lmi] [lmi-commits] master 98a3720 2/6: Explicitly qualify std::size_t
Date: Wed, 17 Feb 2021 12:59:13 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0

On 2/17/21 11:11 AM, Vadim Zeitlin wrote:
> On Tue, 16 Feb 2021 20:11:38 -0500 (EST) Greg Chicares 
> <gchicares@sbcglobal.net> wrote:
> 
> GC> branch: master
> GC> commit 98a3720daf8758b11cc14433e2ba88df80fc7475
> GC> Author: Gregory W. Chicares <gchicares@sbcglobal.net>
> GC> Commit: Gregory W. Chicares <gchicares@sbcglobal.net>
> GC> 
> GC>     Explicitly qualify std::size_t
> 
>  Sorry for missing these occurrences of unqualified size_t.

We both did--they occurred in only two files, one of which ('unwind.cpp')
I added quite recently.

> Should we
> (meaning I) add a coding rules check for this, i.e. verify that size_t is
> always preceded by "std::" in all C++ files?
> 
>  Please let me know if you think this would be useful

No, I don't think so. Reasons, in order of increasing importance:

- It causes no immediate palpable harm, though of course a different
compiler, or a new version of the same compiler, may reject it.

- False positives occur with almost any automated coding rule. I fixed
these yesterday because of a periodic manual check using this command:

  grep -h ^ *.?pp | sed -nf check_std_names.sed 2>&1 |sed -e's/^ *//' 
-e'/^\//d' -e'/^#/d' |sort -u |less -SN

which has sixty-nine false positives for common words like "exit" and
"log". To automate that, we'd want to write rules to filter out those
sixty-nine cases. Even doing that just for 'size_t' would call for
filtering out
  unwind.cpp:#include <cstddef>                      // size_t
  check_std_names.sed:/[^:A-Za-z_]size_t[^A-Za-z_]/p
and I'm not sure that's worth the time.

- Isn't it virtually always better to use 'int' instead of 'size_t'
these days? If so, then it's virtually always a mistake to write
'size_t' at all. We've mostly replaced it with 'int' already, so
the remaining occurrences are a code smell. For example, this
declaration looks like a mistake:

// ABI:
extern "C" char* __cxa_demangle
    (char const * mangled_name  // mangled name, NUL-terminated
    ,char       * output_buffer // just use 0
    ,std::size_t* length        // just use 0
    ,int        * status        // zero --> success
    );

If we need a prototype for that, we should include some header.
But AFAICS gcc doesn't require a prototype for __cxa_demangle
because it's built in. I think I wrote that only as documentation,
so it should be in a comment.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]