https://bugs.kde.org/show_bug.cgi?id=455168

            Bug ID: 455168
           Summary: want/need more 'const' in Valgrind source code
           Product: valgrind
           Version: 3.20 GIT
          Platform: Other
                OS: Linux
            Status: REPORTED
          Severity: normal
          Priority: NOR
         Component: memcheck
          Assignee: jsew...@acm.org
          Reporter: jrei...@bitwagon.com
  Target Milestone: ---

Created attachment 149626
  --> https://bugs.kde.org/attachment.cgi?id=149626&action=edit
Patch to add 'const' to many "HChar *" declarations.

SUMMARY
***
I found 120 regions in 32 Valgrind source code files
where 'const' was omitted:
   git diff master --stat | wc -l;  git diff master | grep -c '@@'
and that was just by hunting near instances of "HChar *"
which often should be "HChar const *".
See the attached patch.

The problems are exacerbated (or perhaps caused) by oversights
(or errors) in the Standard for C language stdlib.  For instance:

       int execve(const char *pathname, char *const argv[],
                  char *const envp[]);

should be

       int execve(const char *pathname, char const *const argv[],
                  char const *const envp[]);

Note the added 'const' in the declaration of the second and third
parameters.  When 'execve' fails, then control returns to the program
(which often is a shell!) and the program is going to assume
that the operating system has not scribbled on the characters
in the argument or environment strings.  But only the revised
declaration states that property explicitly.

A similar bug in the Standard is:

       long strtol(const char *nptr, char **endptr, int base);

which should be

       long strtol(const char *nptr, char const **endptr, int base);

If endptr is not NULL, then upon return from strtol
*endptr designates a substring of nptr.  The characters of nptr
are const (both the application programmer and strtol are not allowed
to write them), so therefore the characters of *endptr also must be 'const'.

Confimation of this problem can be seen in the source code to strtol:
===== glibc-2.29-32-g6d8eaf4a25/stdlib/strtol_l.c
INT
INTERNAL (__strtol_l) (const STRING_TYPE *nptr, STRING_TYPE **endptr,
               int base, int group, locale_t loc)
-----
  /* Store in ENDPTR the address of one character
     past the last character we converted.  */
  if (endptr != NULL)
    *endptr = (STRING_TYPE *) s;
-----
  const STRING_TYPE *save, *end;
-----
    *endptr = (STRING_TYPE *) &save[-1];
-----
    /*  There was no number to convert.  */
    *endptr = (STRING_TYPE *) nptr;
=====
where "gcc -Wcast-qual" will complain about 'const' being elided.
***


STEPS TO REPRODUCE
1.  Compile both  3aee8a29447ea14108eb5d4ab3c1f7677767296a and the patch using
"gcc -Wcast-qual" and compare.
2. 
3. 

OBSERVED RESULT
No differences except -Wcast-qual complaints due to external requirements
(Standard declarations.)
Therefore the added 'const' should have been used.

EXPECTED RESULT


SOFTWARE/OS VERSIONS
Windows: 
macOS: 
Linux/KDE Plasma:  Fedora 34
(available in About System)
KDE Plasma Version: 
KDE Frameworks Version: 
Qt Version: 

ADDITIONAL INFORMATION
gcc (GCC) 11.3.1 20220421 (Red Hat 11.3.1-2)

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to