This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Add a character size parameter to c_strlen/get_range_strlen


On 08/25/2018 11:44 PM, Jeff Law wrote:
On 08/21/2018 10:35 AM, Martin Sebor wrote:
On 08/21/2018 09:59 AM, Jeff Law wrote:
On 08/21/2018 09:57 AM, Martin Sebor wrote:
On 08/21/2018 02:59 AM, Richard Biener wrote:
On Tue, 21 Aug 2018, Bernd Edlinger wrote:

gcc -S -O2 -Wall -Wformat-overflow -ftrack-macro-expansion=0
-fshort-wchar builtin-sprintf-warn-20.c
builtin-sprintf-warn-20.c: In function 'test':
builtin-sprintf-warn-20.c:19:39: warning: hex escape sequence out of
range
19 |     ? (char*)L"\x4142\x4344" : (char*)L"\x41424344\x45464748";
    |                                       ^~~~~~~~~~~~~~~~~~~~~~~

Hmm, this test might create some noise on short-wchar targets.

I would prefer a warning here, about the wrong type of the parameter.
The buffer overflow is only a secondary thing.

For constant objects like those, the GIMPLE type is still guaranteed
to be reliable,
right?

TREE_TYPE of tcc_declaration and tcc_constant trees should more-or-less
(minus qualifications not affecting semantics) be those set by
frontends.

A warning for these cases should be relatively  straightforward
to add to the sprintf pass.  It would require c_strlen() to return
the type of the string argument to the caller.  That way sprintf's
format_string() function could compare the string type to the
expected type of the directive.
Umm, why would c_strlen need to return that?  We should be able to get
to it directly from the argument?!?  What am I missing here?

The sprintf pass sees the type of the argument.  In the literal
case above the cast is folded away and so sprintf does see
the type of the argument.  In more interesting cases like
the one below it sees the type of the argument (i.e., wchar_t*)
but c_strlen() has the smarts to get at the underlying object:

  const char a[] = "1234";

  int f (int i)
  {
    __WCHAR_TYPE__ *p = a;

    return __builtin_snprintf (0, 0, "%ls", &p[i]);
Presumably it'd have to be bubbled up from string_constant, right?

Yes, string_constant() returns the string to c_strlen() which
would then return it to the caller, as n the prototype patch
here:

  https://gcc.gnu.org/ml/gcc-patches/2018-08/msg01321.html

Martin


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]