On 8/20/18 4:49 PM, Joseph Myers wrote:
> On Mon, 20 Aug 2018, Jeff Law wrote:
>
>>> If you do that, probably you want to move
>>> fortran/trans-types.c:get_typenode_from_name (which converts the strings
>>> used in target macros such as WCHAR_TYPE to the corresponding types) into
>>> generic c
On 08/28/18 11:25, Bernd Edlinger wrote:
> On 08/28/18 04:55, Jeff Law wrote:
>> On 08/23/2018 08:48 AM, Bernd Edlinger wrote:
>>> On 08/23/18 16:24, Jeff Law wrote:
>
> Yes, and which one was the earlier, more controversial patch from me?
https://gcc.gnu.org/ml/gcc-patches/2018-0
On 08/28/18 04:55, Jeff Law wrote:
> On 08/23/2018 08:48 AM, Bernd Edlinger wrote:
>> On 08/23/18 16:24, Jeff Law wrote:
Yes, and which one was the earlier, more controversial patch from me?
>>>
>>> https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01800.html
>>>
>>>
>>> Which is the issue I'
On 08/23/2018 08:48 AM, Bernd Edlinger wrote:
> On 08/23/18 16:24, Jeff Law wrote:
>>>
>>> Yes, and which one was the earlier, more controversial patch from me?
>>
>> https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01800.html
>>
>>
>> Which is the issue I'm working through right now :-)
>>
>
> Okay,
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
On 08/26/18 07:47, Jeff Law wrote:
> On 08/21/2018 11:49 AM, Martin Sebor wrote:
>> On 08/21/2018 09:44 AM, Joseph Myers wrote:
>>> On Tue, 21 Aug 2018, Martin Sebor wrote:
>>>
Sure, but the only valid argument to %ls is wchar_t*. Passing
it something else is undefined.
>>>
>>> Well, (wc
On 08/26/18 07:44, 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 -Wa
On 08/23/2018 08:48 AM, Bernd Edlinger wrote:
> On 08/23/18 16:24, Jeff Law wrote:
>>>
>>> Yes, and which one was the earlier, more controversial patch from me?
>>
>> https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01800.html
>>
>>
>> Which is the issue I'm working through right now :-)
>>
>
> Okay,
On 08/21/2018 11:49 AM, Martin Sebor wrote:
> On 08/21/2018 09:44 AM, Joseph Myers wrote:
>> On Tue, 21 Aug 2018, Martin Sebor wrote:
>>
>>> Sure, but the only valid argument to %ls is wchar_t*. Passing
>>> it something else is undefined.
>>
>> Well, (wchar_t *)"something\0\0\0\0" would be OK give
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-expansio
On 08/23/18 16:24, Jeff Law wrote:
>>
>> Yes, and which one was the earlier, more controversial patch from me?
>
> https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01800.html
>
>
> Which is the issue I'm working through right now :-)
>
Okay, please note that a re-based patch is here:
https://gcc
On 08/22/2018 11:40 PM, Bernd Edlinger wrote:
> On 08/23/18 01:36, Jeff Law wrote:
>> On 08/22/2018 05:22 PM, Bernd Edlinger wrote:
>>> On 08/23/18 00:50, Jeff Law wrote:
On 08/22/2018 02:14 AM, Richard Biener wrote:
> On Wed, 22 Aug 2018, Bernd Edlinger wrote:
>
>> On 08/22/18 09:
On 08/23/2018 04:21 AM, Bernd Edlinger wrote:
> On 08/22/18 10:14, Richard Biener wrote:
>> On Wed, 22 Aug 2018, Bernd Edlinger wrote:
>>
>>> On 08/22/18 09:26, Richard Biener wrote:
On Wed, 22 Aug 2018, Bernd Edlinger wrote:
> On 08/21/18 10:59, Richard Biener wrote:
>> On Tue, 2
On 08/22/18 10:14, Richard Biener wrote:
> On Wed, 22 Aug 2018, Bernd Edlinger wrote:
>
>> On 08/22/18 09:26, Richard Biener wrote:
>>> On Wed, 22 Aug 2018, Bernd Edlinger wrote:
>>>
On 08/21/18 10:59, Richard Biener wrote:
> On Tue, 21 Aug 2018, Bernd Edlinger wrote:
>
>> gcc -S
On 08/23/18 00:50, Jeff Law wrote:
> On 08/22/2018 02:14 AM, Richard Biener wrote:
>> On Wed, 22 Aug 2018, Bernd Edlinger wrote:
>>
>>> On 08/22/18 09:26, Richard Biener wrote:
On Wed, 22 Aug 2018, Bernd Edlinger wrote:
> On 08/21/18 10:59, Richard Biener wrote:
>> On Tue, 21 Aug
On 08/23/18 01:36, Jeff Law wrote:
> On 08/22/2018 05:22 PM, Bernd Edlinger wrote:
>> On 08/23/18 00:50, Jeff Law wrote:
>>> On 08/22/2018 02:14 AM, Richard Biener wrote:
On Wed, 22 Aug 2018, Bernd Edlinger wrote:
> On 08/22/18 09:26, Richard Biener wrote:
>> On Wed, 22 Aug 2018,
On 08/22/2018 05:22 PM, Bernd Edlinger wrote:
> On 08/23/18 00:50, Jeff Law wrote:
>> On 08/22/2018 02:14 AM, Richard Biener wrote:
>>> On Wed, 22 Aug 2018, Bernd Edlinger wrote:
>>>
On 08/22/18 09:26, Richard Biener wrote:
> On Wed, 22 Aug 2018, Bernd Edlinger wrote:
>
>> On 08/21
On 08/23/18 00:50, Jeff Law wrote:
> On 08/22/2018 02:14 AM, Richard Biener wrote:
>> On Wed, 22 Aug 2018, Bernd Edlinger wrote:
>>
>>> On 08/22/18 09:26, Richard Biener wrote:
On Wed, 22 Aug 2018, Bernd Edlinger wrote:
> On 08/21/18 10:59, Richard Biener wrote:
>> On Tue, 21 Aug
On 08/22/2018 02:14 AM, Richard Biener wrote:
> On Wed, 22 Aug 2018, Bernd Edlinger wrote:
>
>> On 08/22/18 09:26, Richard Biener wrote:
>>> On Wed, 22 Aug 2018, Bernd Edlinger wrote:
>>>
On 08/21/18 10:59, Richard Biener wrote:
> On Tue, 21 Aug 2018, Bernd Edlinger wrote:
>
>> gc
On Wed, 22 Aug 2018, Bernd Edlinger wrote:
> On 08/22/18 09:26, Richard Biener wrote:
> > On Wed, 22 Aug 2018, Bernd Edlinger wrote:
> >
> >> On 08/21/18 10:59, Richard Biener wrote:
> >>> On Tue, 21 Aug 2018, Bernd Edlinger wrote:
> >>>
> gcc -S -O2 -Wall -Wformat-overflow -ftrack-macro-exp
On 08/22/18 09:26, Richard Biener wrote:
> On Wed, 22 Aug 2018, Bernd Edlinger wrote:
>
>> On 08/21/18 10:59, 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
>>>
On Wed, 22 Aug 2018, Bernd Edlinger wrote:
> On 08/21/18 10:59, 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 'tes
On 08/21/18 10:59, 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 esc
On 08/21/2018 03:44 PM, Joseph Myers wrote:
On Tue, 21 Aug 2018, Martin Sebor wrote:
On 08/21/2018 09:44 AM, Joseph Myers wrote:
On Tue, 21 Aug 2018, Martin Sebor wrote:
Sure, but the only valid argument to %ls is wchar_t*. Passing
it something else is undefined.
Well, (wchar_t *)"somethi
On 08/21/2018 10:46 AM, Martin Sebor wrote:
> On 08/21/2018 09:56 AM, Jeff Law wrote:
>> On 08/21/2018 09:37 AM, Martin Sebor wrote:
>>> On 08/21/2018 05:50 AM, Joseph Myers wrote:
On Tue, 21 Aug 2018, Martin Sebor wrote:
> I still believe it would be simpler, more robust, and safe
>>
On Tue, 21 Aug 2018, Martin Sebor wrote:
> On 08/21/2018 09:44 AM, Joseph Myers wrote:
> > On Tue, 21 Aug 2018, Martin Sebor wrote:
> >
> > > Sure, but the only valid argument to %ls is wchar_t*. Passing
> > > it something else is undefined.
> >
> > Well, (wchar_t *)"something\0\0\0\0" would be
On 08/21/2018 09:44 AM, Joseph Myers wrote:
On Tue, 21 Aug 2018, Martin Sebor wrote:
Sure, but the only valid argument to %ls is wchar_t*. Passing
it something else is undefined.
Well, (wchar_t *)"something\0\0\0\0" would be OK given
-fno-strict-aliasing and if you know the alignment is OK.
On 08/21/2018 09:56 AM, Jeff Law wrote:
On 08/21/2018 09:37 AM, Martin Sebor wrote:
On 08/21/2018 05:50 AM, Joseph Myers wrote:
On Tue, 21 Aug 2018, Martin Sebor wrote:
I still believe it would be simpler, more robust, and safe
to pass in a flag to either count bytes (the default, for
all cal
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-war
On 08/21/2018 09:27 AM, Jeff Law wrote:
On 08/20/2018 11:17 PM, Bernd Edlinger wrote:
On 08/21/18 01:23, Martin Sebor wrote:
On 08/20/2018 04:17 PM, Jeff Law wrote:
On 08/18/2018 11:38 AM, Martin Sebor wrote:
On 08/17/2018 09:32 PM, Jeff Law wrote:
On 08/17/2018 02:17 PM, Martin Sebor 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'
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 sequ
On 08/21/2018 09:37 AM, Martin Sebor wrote:
> On 08/21/2018 05:50 AM, Joseph Myers wrote:
>> On Tue, 21 Aug 2018, Martin Sebor wrote:
>>
>>> I still believe it would be simpler, more robust, and safe
>>> to pass in a flag to either count bytes (the default, for
>>> all callers except sprintf %ls),
On Tue, 21 Aug 2018, Martin Sebor wrote:
> Sure, but the only valid argument to %ls is wchar_t*. Passing
> it something else is undefined.
Well, (wchar_t *)"something\0\0\0\0" would be OK given
-fno-strict-aliasing and if you know the alignment is OK. Do we have that
information about the typ
On 08/21/2018 05:50 AM, Joseph Myers wrote:
On Tue, 21 Aug 2018, Martin Sebor wrote:
I still believe it would be simpler, more robust, and safe
to pass in a flag to either count bytes (the default, for
all callers except sprintf %ls), or elements of the string
type (for sprintf %ls).
But the
On 08/20/2018 11:17 PM, Bernd Edlinger wrote:
> On 08/21/18 01:23, Martin Sebor wrote:
>> On 08/20/2018 04:17 PM, Jeff Law wrote:
>>> On 08/18/2018 11:38 AM, Martin Sebor wrote:
On 08/17/2018 09:32 PM, Jeff Law wrote:
> On 08/17/2018 02:17 PM, Martin Sebor wrote:
>> On 08/17/2018 12:44
On 08/20/2018 05:23 PM, Martin Sebor wrote:
>> And I think you're hitting on some of issues already raised in the
>> thread.
>>
>> In this specific case though ISTM 4 is the right answer. We casted to a
>> char *, so that's what we should be counting. Or am I missing
>> something? Also note that
On Tue, 21 Aug 2018, Martin Sebor wrote:
> I still believe it would be simpler, more robust, and safe
> to pass in a flag to either count bytes (the default, for
> all callers except sprintf %ls), or elements of the string
> type (for sprintf %ls).
But the correct thing to count for sprintf %ls i
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"\
On 08/21/18 01:23, Martin Sebor wrote:
> On 08/20/2018 04:17 PM, Jeff Law wrote:
>> On 08/18/2018 11:38 AM, Martin Sebor wrote:
>>> On 08/17/2018 09:32 PM, Jeff Law wrote:
On 08/17/2018 02:17 PM, Martin Sebor wrote:
> On 08/17/2018 12:44 PM, Bernd Edlinger wrote:
>> On 08/17/18 20:23,
On 08/21/18 01:23, Martin Sebor wrote:
> On 08/20/2018 04:17 PM, Jeff Law wrote:
>> On 08/18/2018 11:38 AM, Martin Sebor wrote:
>>> On 08/17/2018 09:32 PM, Jeff Law wrote:
On 08/17/2018 02:17 PM, Martin Sebor wrote:
> On 08/17/2018 12:44 PM, Bernd Edlinger wrote:
>> On 08/17/18 20:23,
On 08/20/2018 04:22 PM, Jeff Law wrote:
On 08/20/2018 04:16 PM, Joseph Myers wrote:
On Fri, 17 Aug 2018, Jeff Law wrote:
WCHAR_TYPE_SIZE is wrong because it doesn't account for flag_short_wchar.
As far as I can see only ada/gcc-interface/targtyps.c uses WCHAR_TYPE_SIZE
now. TYPE_PRECISION (wc
On 08/20/2018 04:17 PM, Jeff Law wrote:
On 08/18/2018 11:38 AM, Martin Sebor wrote:
On 08/17/2018 09:32 PM, Jeff Law wrote:
On 08/17/2018 02:17 PM, Martin Sebor wrote:
On 08/17/2018 12:44 PM, Bernd Edlinger wrote:
On 08/17/18 20:23, Martin Sebor wrote:
On 08/17/2018 06:14 AM, Joseph Myers wr
On 08/18/18 20:01, Martin Sebor wrote:
> On 08/17/2018 05:01 PM, Bernd Edlinger wrote:
>> On 08/17/18 22:17, Martin Sebor wrote:
>>> On 08/17/2018 12:44 PM, Bernd Edlinger wrote:
On 08/17/18 20:23, Martin Sebor wrote:
> On 08/17/2018 06:14 AM, Joseph Myers wrote:
>> On Fri, 17 Aug 2018
On 08/21/18 00:49, Joseph Myers wrote:
> On Mon, 20 Aug 2018, Jeff Law wrote:
>
>>> If you do that, probably you want to move
>>> fortran/trans-types.c:get_typenode_from_name (which converts the strings
>>> used in target macros such as WCHAR_TYPE to the corresponding types) into
>>> generic code.
On Mon, 20 Aug 2018, Jeff Law wrote:
> > If you do that, probably you want to move
> > fortran/trans-types.c:get_typenode_from_name (which converts the strings
> > used in target macros such as WCHAR_TYPE to the corresponding types) into
> > generic code.
> I think we ultimately have to go down
On 08/21/18 00:22, Jeff Law wrote:
> On 08/20/2018 04:16 PM, Joseph Myers wrote:
>> On Fri, 17 Aug 2018, Jeff Law wrote:
>>
WCHAR_TYPE_SIZE is wrong because it doesn't account for flag_short_wchar.
As far as I can see only ada/gcc-interface/targtyps.c uses WCHAR_TYPE_SIZE
now. TYPE_
On 08/20/2018 04:16 PM, Joseph Myers wrote:
> On Fri, 17 Aug 2018, Jeff Law wrote:
>
>>> WCHAR_TYPE_SIZE is wrong because it doesn't account for flag_short_wchar.
>>> As far as I can see only ada/gcc-interface/targtyps.c uses WCHAR_TYPE_SIZE
>>> now. TYPE_PRECISION (wchar_type_node) / BITS_PER
On 08/18/2018 11:38 AM, Martin Sebor wrote:
> On 08/17/2018 09:32 PM, Jeff Law wrote:
>> On 08/17/2018 02:17 PM, Martin Sebor wrote:
>>> On 08/17/2018 12:44 PM, Bernd Edlinger wrote:
On 08/17/18 20:23, Martin Sebor wrote:
> On 08/17/2018 06:14 AM, Joseph Myers wrote:
>> On Fri, 17 Aug
On Fri, 17 Aug 2018, Jeff Law wrote:
> > WCHAR_TYPE_SIZE is wrong because it doesn't account for flag_short_wchar.
> > As far as I can see only ada/gcc-interface/targtyps.c uses WCHAR_TYPE_SIZE
> > now. TYPE_PRECISION (wchar_type_node) / BITS_PER_UNIT is what should be
> > used.
> But that's
On 08/17/2018 05:01 PM, Bernd Edlinger wrote:
On 08/17/18 22:17, Martin Sebor wrote:
On 08/17/2018 12:44 PM, Bernd Edlinger wrote:
On 08/17/18 20:23, Martin Sebor wrote:
On 08/17/2018 06:14 AM, Joseph Myers wrote:
On Fri, 17 Aug 2018, Jeff Law wrote:
On 08/16/2018 05:01 PM, Joseph Myers wro
On 08/17/2018 09:32 PM, Jeff Law wrote:
On 08/17/2018 02:17 PM, Martin Sebor wrote:
On 08/17/2018 12:44 PM, Bernd Edlinger wrote:
On 08/17/18 20:23, Martin Sebor wrote:
On 08/17/2018 06:14 AM, Joseph Myers wrote:
On Fri, 17 Aug 2018, Jeff Law wrote:
On 08/16/2018 05:01 PM, Joseph Myers wrot
On 08/17/2018 06:14 AM, Joseph Myers wrote:
> On Fri, 17 Aug 2018, Jeff Law wrote:
>
>> On 08/16/2018 05:01 PM, Joseph Myers wrote:
>>> On Thu, 16 Aug 2018, Jeff Law wrote:
>>>
restores previous behavior. The sprintf bits want to count element
sized chunks, which for wchars is 4 bytes (
On 08/17/2018 02:17 PM, Martin Sebor wrote:
> On 08/17/2018 12:44 PM, Bernd Edlinger wrote:
>> On 08/17/18 20:23, Martin Sebor wrote:
>>> On 08/17/2018 06:14 AM, Joseph Myers wrote:
On Fri, 17 Aug 2018, Jeff Law wrote:
> On 08/16/2018 05:01 PM, Joseph Myers wrote:
>> On Thu, 16 Au
On 08/17/2018 12:44 PM, Bernd Edlinger wrote:
> On 08/17/18 20:23, Martin Sebor wrote:
>> On 08/17/2018 06:14 AM, Joseph Myers wrote:
>>> On Fri, 17 Aug 2018, Jeff Law wrote:
>>>
On 08/16/2018 05:01 PM, Joseph Myers wrote:
> On Thu, 16 Aug 2018, Jeff Law wrote:
>
>> restores previo
On 08/17/2018 12:23 PM, Martin Sebor wrote:
> On 08/17/2018 06:14 AM, Joseph Myers wrote:
>> On Fri, 17 Aug 2018, Jeff Law wrote:
>>
>>> On 08/16/2018 05:01 PM, Joseph Myers wrote:
On Thu, 16 Aug 2018, Jeff Law wrote:
> restores previous behavior. The sprintf bits want to count eleme
On 08/17/18 22:17, Martin Sebor wrote:
> On 08/17/2018 12:44 PM, Bernd Edlinger wrote:
>> On 08/17/18 20:23, Martin Sebor wrote:
>>> On 08/17/2018 06:14 AM, Joseph Myers wrote:
On Fri, 17 Aug 2018, Jeff Law wrote:
> On 08/16/2018 05:01 PM, Joseph Myers wrote:
>> On Thu, 16 Aug 201
On 08/17/2018 12:44 PM, Bernd Edlinger wrote:
On 08/17/18 20:23, Martin Sebor wrote:
On 08/17/2018 06:14 AM, Joseph Myers wrote:
On Fri, 17 Aug 2018, Jeff Law wrote:
On 08/16/2018 05:01 PM, Joseph Myers wrote:
On Thu, 16 Aug 2018, Jeff Law wrote:
restores previous behavior. The sprintf bi
On 08/17/18 20:23, Martin Sebor wrote:
> On 08/17/2018 06:14 AM, Joseph Myers wrote:
>> On Fri, 17 Aug 2018, Jeff Law wrote:
>>
>>> On 08/16/2018 05:01 PM, Joseph Myers wrote:
On Thu, 16 Aug 2018, Jeff Law wrote:
> restores previous behavior. The sprintf bits want to count element
>>
On 08/17/2018 06:14 AM, Joseph Myers wrote:
On Fri, 17 Aug 2018, Jeff Law wrote:
On 08/16/2018 05:01 PM, Joseph Myers wrote:
On Thu, 16 Aug 2018, Jeff Law wrote:
restores previous behavior. The sprintf bits want to count element
sized chunks, which for wchars is 4 bytes (that count will the
On Fri, 17 Aug 2018, Jeff Law wrote:
> On 08/16/2018 05:01 PM, Joseph Myers wrote:
> > On Thu, 16 Aug 2018, Jeff Law wrote:
> >
> >> restores previous behavior. The sprintf bits want to count element
> >> sized chunks, which for wchars is 4 bytes (that count will then be
> >
> >>/* Compute
On 08/16/2018 05:01 PM, Joseph Myers wrote:
> On Thu, 16 Aug 2018, Jeff Law wrote:
>
>> restores previous behavior. The sprintf bits want to count element
>> sized chunks, which for wchars is 4 bytes (that count will then be
>
>>/* Compute the range the argument's length can be in. */
>> -
On Thu, 16 Aug 2018, Jeff Law wrote:
> restores previous behavior. The sprintf bits want to count element
> sized chunks, which for wchars is 4 bytes (that count will then be
>/* Compute the range the argument's length can be in. */
> - fmtresult slen = get_string_length (arg);
> + int co
On 08/14/2018 04:25 AM, Bernd Edlinger wrote:
> 2018-08-14 Bernd Edlinger
>
> * builtins.c (c_strlen): Add new parameter eltsize.
> * builtins.h (c_strlen): Adjust prototype.
> * expr.c (string_constant): Add new parameter mem_size.
> * expr.h (string_constant): Adjust p
On 08/16/18 23:27, Jeff Law wrote:
> On 08/16/2018 12:47 PM, Bernd Edlinger wrote:
>
> Parameterizing the function to return either the number of
> bytes or the number of elements makes sense as an enhancement.
> It makes less sense (and could be the source of bugs) to let
> caller
On 08/16/2018 12:47 PM, Bernd Edlinger wrote:
Parameterizing the function to return either the number of
bytes or the number of elements makes sense as an enhancement.
It makes less sense (and could be the source of bugs) to let
callers pass in anything else. A boolean flag to
On 08/16/18 19:35, Jeff Law wrote:
> On 08/15/2018 12:51 PM, Bernd Edlinger wrote:
> [ snip -- comment attribution is likely lost... ]
>
>
> 2018-08-14 Bernd Edlinger
>
> * builtins.c (c_strlen): Add new parameter eltsize.
> * builtins.h (c_strlen): Adjust prototyp
On 08/15/2018 12:51 PM, Bernd Edlinger wrote:
[ snip -- comment attribution is likely lost... ]
2018-08-14 Bernd Edlinger
* builtins.c (c_strlen): Add new parameter eltsize.
* builtins.h (c_strlen): Adjust prototype.
* expr.c (string_constant): Add new
On 08/15/18 20:18, Martin Sebor wrote:
> On 08/15/2018 10:25 AM, Jeff Law wrote:
>> On 08/14/2018 04:25 AM, Bernd Edlinger wrote:
>>> Hi,
>>>
>>> this patch is a follow-up to my patch here:
>>> https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01800.html
>>>
>>> Since most calls of c_strlen and get_ran
Ignore this prior message from me I'm off-base here...
On 08/15/2018 12:13 PM, Jeff Law wrote:
> On 08/15/2018 10:38 AM, Bernd Edlinger wrote:
>> On 08/15/18 18:25, Jeff Law wrote:
>>> On 08/14/2018 04:25 AM, Bernd Edlinger wrote:
Hi,
this patch is a follow-up to my patch here
On 08/15/18 20:13, Jeff Law wrote:
> On 08/15/2018 10:38 AM, Bernd Edlinger wrote:
>> On 08/15/18 18:25, Jeff Law wrote:
>>> On 08/14/2018 04:25 AM, Bernd Edlinger wrote:
Hi,
this patch is a follow-up to my patch here:
https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01800.html
>>>
On 08/15/2018 10:25 AM, Jeff Law wrote:
On 08/14/2018 04:25 AM, Bernd Edlinger wrote:
Hi,
this patch is a follow-up to my patch here:
https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01800.html
Since most calls of c_strlen and get_range_strlen expect
a string length in bytes of a zero-terminated
On 08/15/2018 10:38 AM, Bernd Edlinger wrote:
> On 08/15/18 18:25, Jeff Law wrote:
>> On 08/14/2018 04:25 AM, Bernd Edlinger wrote:
>>> Hi,
>>>
>>> this patch is a follow-up to my patch here:
>>> https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01800.html
>>>
>>> Since most calls of c_strlen and get_r
On 08/15/18 18:25, Jeff Law wrote:
> On 08/14/2018 04:25 AM, Bernd Edlinger wrote:
>> Hi,
>>
>> this patch is a follow-up to my patch here:
>> https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01800.html
>>
>> Since most calls of c_strlen and get_range_strlen expect
>> a string length in bytes of a zer
Standard procedure in this kind of situation where we have two patches
that are handling the same issue is to bake them off and choose one
based on the technical merits. To that end...
It would be helpful if you could compare/contrast your patch to Bernd's.
ie, are there cases that will be hand
On 08/14/2018 04:25 AM, Bernd Edlinger wrote:
> Hi,
>
> this patch is a follow-up to my patch here:
> https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01800.html
>
> Since most calls of c_strlen and get_range_strlen expect
> a string length in bytes of a zero-terminated string, there is
> a need for
On 08/15/2018 08:03 AM, Bernd Edlinger wrote:
>
> But must admit, that I have sometimes the impression of being ignored,
> for instance what I wrote in response to Martin's patch here:
> https://gcc.gnu.org/ml/gcc-patches/2018-08/msg00184.html
> ... and already earlier here:
> https://gcc.gnu.org/
On 08/15/18 07:12, Jeff Law wrote:
> On 08/14/2018 08:08 AM, Martin Sebor wrote:
>> On 08/14/2018 04:25 AM, Bernd Edlinger wrote:
>>> Hi,
>>>
>>> this patch is a follow-up to my patch here:
>>> https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01800.html
>>
>> As I said multiple times, this patch is re
On 08/14/2018 08:08 AM, Martin Sebor wrote:
> On 08/14/2018 04:25 AM, Bernd Edlinger wrote:
>> Hi,
>>
>> this patch is a follow-up to my patch here:
>> https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01800.html
>
> As I said multiple times, this patch is redundant -- the issue
> is fixed by the solu
On 08/14/2018 04:25 AM, Bernd Edlinger wrote:
Hi,
this patch is a follow-up to my patch here:
https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01800.html
As I said multiple times, this patch is redundant -- the issue
is fixed by the solution I posted back in July:
https://gcc.gnu.org/ml/gcc-pa
Hi,
this patch is a follow-up to my patch here:
https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01800.html
Since most calls of c_strlen and get_range_strlen expect
a string length in bytes of a zero-terminated string, there is
a need for a new parameter eltsize, which is per default 1,
but can be u
81 matches
Mail list logo
