René Scharfe writes:
> I wonder when we can begin to target C99 in git's source, though. :)
Let's get the ball rolling by starting to use some of the useful
features like designated initializers, perhaps, in a small, critical
and reasonably stable part of the system that anybody must compile,
le
Am 09.07.2017 um 14:37 schrieb Andreas Schwab:
On Jul 09 2017, René Scharfe wrote:
[2] http://pubs.opengroup.org/onlinepubs/009695399/functions/memchr.html
You are using an old revision.
OK, the final draft of C11 [3] says "The implementation shall behave as
if it reads the characters sequ
On Jul 09 2017, René Scharfe wrote:
> [2] http://pubs.opengroup.org/onlinepubs/009695399/functions/memchr.html
You are using an old revision.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something compl
Am 08.07.2017 um 15:38 schrieb Andreas Schwab:
On Jul 08 2017, René Scharfe wrote:
Am 08.07.2017 um 13:08 schrieb Andreas Schwab:
On Jul 08 2017, René Scharfe wrote:
Avoid running over the end of another -- a C string whose length we
don't know -- by using strcmp(3) instead of memcmp(3) fo
Am 09.07.2017 um 00:29 schrieb Junio C Hamano:
René Scharfe writes:
Am 08.07.2017 um 13:08 schrieb Ramsay Jones:
On 08/07/17 09:58, René Scharfe wrote:
Avoid running over the end of another -- a C string whose length we
don't know -- by using strcmp(3) instead of memcmp(3) for comparing it
w
René Scharfe writes:
> Am 08.07.2017 um 13:08 schrieb Ramsay Jones:
>> On 08/07/17 09:58, René Scharfe wrote:
>>> Avoid running over the end of another -- a C string whose length we
>>> don't know -- by using strcmp(3) instead of memcmp(3) for comparing it
>>> with another C string.
>>
>> I had t
On Jul 08 2017, René Scharfe wrote:
> Am 08.07.2017 um 13:08 schrieb Andreas Schwab:
>> On Jul 08 2017, René Scharfe wrote:
>>
>>> Avoid running over the end of another -- a C string whose length we
>>> don't know -- by using strcmp(3) instead of memcmp(3) for comparing it
>>> with another C str
Am 08.07.2017 um 13:08 schrieb Ramsay Jones:
On 08/07/17 09:58, René Scharfe wrote:
Avoid running over the end of another -- a C string whose length we
don't know -- by using strcmp(3) instead of memcmp(3) for comparing it
with another C string.
I had to read this twice, along with the patch t
Am 08.07.2017 um 13:08 schrieb Andreas Schwab:
On Jul 08 2017, René Scharfe wrote:
Avoid running over the end of another -- a C string whose length we
don't know -- by using strcmp(3) instead of memcmp(3) for comparing it
with another C string.
That's not a good justification for the change,
On 08/07/17 09:58, René Scharfe wrote:
> Avoid running over the end of another -- a C string whose length we
> don't know -- by using strcmp(3) instead of memcmp(3) for comparing it
> with another C string.
I had to read this twice, along with the patch text, before this
made any sense. ;-) The
On Jul 08 2017, René Scharfe wrote:
> Avoid running over the end of another -- a C string whose length we
> don't know -- by using strcmp(3) instead of memcmp(3) for comparing it
> with another C string.
That's not a good justification for the change, since memcmp never reads
past the differing
Avoid running over the end of another -- a C string whose length we
don't know -- by using strcmp(3) instead of memcmp(3) for comparing it
with another C string.
Signed-off-by: Rene Scharfe
---
apply.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/apply.c b/apply.c
index
12 matches
Mail list logo