Re: Naming flag for specifying the output file name for Binary Module Interface files
Hi David, > I think Nathan might've been asking not only about what currently happens, but what we think should happen? Yes. > Is that consistent with `-o`? (I assume so, but don't know - I guess there aren't many cases where `-o` is unused (maybe `-fsyntax-only`), so that behavior might be a bit less well specified) `-o` wouldn't emit a warning if it is not used. (with `-fsyntax-only` for example). Since we want to make the behavior of `-fmodule-output` to be consistent with `-o`. I've changed the behavior in https://reviews.llvm.org/D140001. > This seems surprising/possibly wrong to me - do we have precedent from other flags to draw from? I feel it makes sense since `-fmodule-output=` will provide more information than `-fmodule-output`. So it is naturally to me that `-fmodule-output=` has higher priority. For examples, I don't enumerate all the flags but I find the following cases in minutes: - `-fpack-struct=` has higher priority than `-fpack-struct`. - `-fsave-optimization-record=` has higher priority than `-fsave-optimization-record=`. - `-ftime-report=` has higher priority than `-ftime-report`. - `-ftime-trace=` has higher priority than `-ftime-trace`. So I think the bahavior should be correct. Thanks, Chuanqi -- From:David Blaikie Send Time:2022年12月13日(星期二) 23:56 To:chuanqi.xcq Cc:Iain Sandoe ; GCC Development ; Nathan Sidwell ; Jonathan Wakely ; ben.boeckel Subject:Re: Naming flag for specifying the output file name for Binary Module Interface files I think Nathan might've been asking not only about what currently happens, but what we think should happen? On Mon, Dec 12, 2022 at 7:11 PM chuanqi.xcq wrote: > > Hi Nathan, > > > 1) Are these flags silently ignored, if no module output is to be > > generated? Or is some kind of diagnostic generated? > > Currently, clang will generate the unused-command-line-argument warning for > this case: > > ``` > argument unused during compilation: '-fmodule-output' > [-Wunused-command-line-argument] > ``` Is that consistent with `-o`? (I assume so, but don't know - I guess there aren't many cases where `-o` is unused (maybe `-fsyntax-only`), so that behavior might be a bit less well specified) > > 2) what happens if you specify both -- do you get two outputs, a > > diagnostic, or > is one silently selected? > > If someone specify both `-fmodule-output` and `-fmodule-output=/path`, > the `-fmodule-output=/path` will be selected always no matter what the order > is. This seems surprising/possibly wrong to me - do we have precedent from other flags to draw from? > And if multiple `-fmodule-output=/path` are specified, the last one will be > selected. > > > 3) What is the behaviour if compilation fails? Does nothing happen to the > > file > indicated (potentially leaving an older version there), or does the equivalent > of 'rm -f $MODULE.pcm' happen? > > The module file will be deleted. The behavior is the same with `-o`. > > Thanks, > Chuanqi > > > -- > From:Nathan Sidwell > Send Time:2022年12月12日(星期一) 22:30 > To:Iain Sandoe ; GCC Development > Cc:Nathan Sidwell ; Jonathan Wakely > ; David Blaikie ; ben.boeckel > ; chuanqi.xcq > Subject:Re: Naming flag for specifying the output file name for Binary Module > Interface files > > On 12/9/22 12:33, Iain Sandoe wrote: > > Hello all. > > > >> On 9 Dec 2022, at 01:58, chuanqi.xcq wrote: > >> > >> It looks like `-fmodule-file` is better from the discussion. So let's take > >> it. Thanks for everyone here > > > > So FAOD (after this discussion) Chuanqi's current patchset implements the > > following in clang: > > > > -fmodule-output > > > > - this causes the BMI to be saved in the CWG with the basename of the > > source file and a suffix of .pcm. > > > > -fmodule-output= > > > > - this causes the BMI to be saved at the path specified. > > > > 1) Are these flags silently ignored, if no module output is to be generated? > Or > is some kind of diagnostic generated? > > 2) what happens if you specify both -- do you get two outputs, a diagnostic, > or > is one silently selected? > > 3) What is the behaviour if compilation fails? Does nothing happen to the file > indicated (potentially leaving an older version there), or does the equivalent > of 'rm -f $MODULE.pcm' happen? > > nathan > > -- > Nathan Sidwell > >
Re: Possible regression in DF analysis
I have update the fix to this one: diff --git a/gcc/df-core.cc b/gcc/df-core.cc index a901b84878f..cc6383990a1 100644 --- a/gcc/df-core.cc +++ b/gcc/df-core.cc @@ -1437,7 +1437,16 @@ df_analyze_loop (class loop *loop) df_set_blocks (blocks); BITMAP_FREE (blocks); - df_analyze_1 (); + /* Iterate over loop's exit edges and add theirs destinations BB + indexes. */ + struct loop_exit *exit; + for (exit = loop->exits->next; exit->e; exit = exit->next) +bitmap_set_bit (df->blocks_to_analyze, exit->e->dest->index); + + if (dump_file) +debug_bitmap_file (dump_file, df->blocks_to_analyze); + + df_analyze (); } I still need to validate it for x86 Best, Claudiu On Tue, Dec 13, 2022 at 7:38 PM Claudiu Zissulescu Ianculescu wrote: > > > > > Maybe you want to iterate over the loops exit edges and include their > > destination block instead? > > > > This is better approach, let me try it and I will be back to you. > > Thanks, > Claudiu
Re: Possible regression in DF analysis
On Wed, Dec 14, 2022 at 11:37 AM Claudiu Zissulescu Ianculescu wrote: > > I have update the fix to this one: > > diff --git a/gcc/df-core.cc b/gcc/df-core.cc > index a901b84878f..cc6383990a1 100644 > --- a/gcc/df-core.cc > +++ b/gcc/df-core.cc > @@ -1437,7 +1437,16 @@ df_analyze_loop (class loop *loop) >df_set_blocks (blocks); >BITMAP_FREE (blocks); > > - df_analyze_1 (); > + /* Iterate over loop's exit edges and add theirs destinations BB > + indexes. */ > + struct loop_exit *exit; > + for (exit = loop->exits->next; exit->e; exit = exit->next) > +bitmap_set_bit (df->blocks_to_analyze, exit->e->dest->index); I think you want to adjust the local 'blocks' bitmap passed to df_set_blocks. There's also the issue that the computed postorder doesn't include the new blocks and thus the computation will likely be invalid? > + > + if (dump_file) > +debug_bitmap_file (dump_file, df->blocks_to_analyze); > + > + df_analyze (); > } > > I still need to validate it for x86 > > Best, > Claudiu > > On Tue, Dec 13, 2022 at 7:38 PM Claudiu Zissulescu Ianculescu > wrote: > > > > > > > > Maybe you want to iterate over the loops exit edges and include their > > > destination block instead? > > > > > > > This is better approach, let me try it and I will be back to you. > > > > Thanks, > > Claudiu
Re: Possible regression in DF analysis
Hi Richard, Sorry for my misunderstanding. I am calling the df_analyze() instead of df_analyze1() at the end. Shouldn't df_analyze take care and compute the correct postorder (df-core.cc:1273) ? Thank you, Claudiu On Wed, Dec 14, 2022 at 1:06 PM Richard Biener wrote: > > On Wed, Dec 14, 2022 at 11:37 AM Claudiu Zissulescu Ianculescu > wrote: > > > > I have update the fix to this one: > > > > diff --git a/gcc/df-core.cc b/gcc/df-core.cc > > index a901b84878f..cc6383990a1 100644 > > --- a/gcc/df-core.cc > > +++ b/gcc/df-core.cc > > @@ -1437,7 +1437,16 @@ df_analyze_loop (class loop *loop) > >df_set_blocks (blocks); > >BITMAP_FREE (blocks); > > > > - df_analyze_1 (); > > + /* Iterate over loop's exit edges and add theirs destinations BB > > + indexes. */ > > + struct loop_exit *exit; > > + for (exit = loop->exits->next; exit->e; exit = exit->next) > > +bitmap_set_bit (df->blocks_to_analyze, exit->e->dest->index); > > I think you want to adjust the local 'blocks' bitmap passed to df_set_blocks. > There's also the issue that the computed postorder doesn't include the new > blocks and thus the computation will likely be invalid? > > > + > > + if (dump_file) > > +debug_bitmap_file (dump_file, df->blocks_to_analyze); > > + > > + df_analyze (); > > } > > > > I still need to validate it for x86 > > > > Best, > > Claudiu > > > > On Tue, Dec 13, 2022 at 7:38 PM Claudiu Zissulescu Ianculescu > > wrote: > > > > > > > > > > > Maybe you want to iterate over the loops exit edges and include their > > > > destination block instead? > > > > > > > > > > This is better approach, let me try it and I will be back to you. > > > > > > Thanks, > > > Claudiu
Re: Possible regression in DF analysis
On Wed, Dec 14, 2022 at 12:30 PM Claudiu Zissulescu Ianculescu wrote: > > Hi Richard, > > Sorry for my misunderstanding. I am calling the df_analyze() instead > of df_analyze1() at the end. Shouldn't df_analyze take care and > compute the correct postorder (df-core.cc:1273) ? The point of df_analyze_loop is to be more efficient than doing a full df_analyze (but of course that's only so in a limited way, still ...) > Thank you, > Claudiu > > On Wed, Dec 14, 2022 at 1:06 PM Richard Biener > wrote: > > > > On Wed, Dec 14, 2022 at 11:37 AM Claudiu Zissulescu Ianculescu > > wrote: > > > > > > I have update the fix to this one: > > > > > > diff --git a/gcc/df-core.cc b/gcc/df-core.cc > > > index a901b84878f..cc6383990a1 100644 > > > --- a/gcc/df-core.cc > > > +++ b/gcc/df-core.cc > > > @@ -1437,7 +1437,16 @@ df_analyze_loop (class loop *loop) > > >df_set_blocks (blocks); > > >BITMAP_FREE (blocks); > > > > > > - df_analyze_1 (); > > > + /* Iterate over loop's exit edges and add theirs destinations BB > > > + indexes. */ > > > + struct loop_exit *exit; > > > + for (exit = loop->exits->next; exit->e; exit = exit->next) > > > +bitmap_set_bit (df->blocks_to_analyze, exit->e->dest->index); > > > > I think you want to adjust the local 'blocks' bitmap passed to > > df_set_blocks. > > There's also the issue that the computed postorder doesn't include the new > > blocks and thus the computation will likely be invalid? > > > > > + > > > + if (dump_file) > > > +debug_bitmap_file (dump_file, df->blocks_to_analyze); > > > + > > > + df_analyze (); > > > } > > > > > > I still need to validate it for x86 > > > > > > Best, > > > Claudiu > > > > > > On Tue, Dec 13, 2022 at 7:38 PM Claudiu Zissulescu Ianculescu > > > wrote: > > > > > > > > > > > > > > Maybe you want to iterate over the loops exit edges and include their > > > > > destination block instead? > > > > > > > > > > > > > This is better approach, let me try it and I will be back to you. > > > > > > > > Thanks, > > > > Claudiu
[RISC-V] [SIG-toolchain] Meeting will be canceled (Dec 15, 2022)
Hi all, Tomorrow's meeting will be canceled, since there was few new topics to discuss. The next RISC-V GNU Toolchain meeting is collecting. Please let me know if you have any topics want to discuss in the next meeting. Best Regards, Jiawei
Energy Exchange 2022 Attendees
Hi, Would you be interested in obtaining the Energy Exchange 2022 attendance database? Facility managers, Fleet managers, Water managers, State resource managers, City planners, Procurement officers, Building commissioners, Project implementation specialists, Energy auditors, Compliance managers, financial managers, Attorneys, Engineers, and more are among the attendees. Please express your thoughts with me so that I can provide you more detailed information. Sincere regards, Laura Prickett | Associate for Business Development Note: You were specifically sent this email based upon your company profile. If you do not wish to hear from you further, please reply with "REMOVE".
Contribution
Hello all, As I mentioned before, I don't have much time to contribute. So is there any way I can contribute some medium project I can work on but myself in the long run? I loved this community, I contributed before so can you suggest some work for me? Mohamed
Possible dead code in file lra-spills.cc
At line 276, lra_assert (spill_class != NO_REGS); would trigger whenever execution reached here with spill_class equal to NO_REGS. Seems to me that would never happen. Because one of the conditions in the if statement right above it (line 265) catches spill_class == NO_REGS and causes the rest of the for loop to be skipped by executing continue in the consequent of the if. So lra_assert never sees spill_class == NO_REGS. That makes line 276 dead code, right? Thanks. GT.
Re: Naming flag for specifying the output file name for Binary Module Interface files
On Wed, Dec 14, 2022 at 1:56 AM chuanqi.xcq wrote: > > Hi David, > > > I think Nathan might've been asking not only about what currently > happens, but what we think should happen? > > Yes. > > > Is that consistent with `-o`? (I assume so, but don't know - I guess > there aren't many cases where `-o` is unused (maybe `-fsyntax-only`), > so that behavior might be a bit less well specified) > > `-o` wouldn't emit a warning if it is not used. (with `-fsyntax-only` for > example). > Since we want to make the behavior of `-fmodule-output` to be consistent with > `-o`. > I've changed the behavior in https://reviews.llvm.org/D140001. > > > This seems surprising/possibly wrong to me - do we have precedent from > other flags to draw from? > > I feel it makes sense since `-fmodule-output=` will provide more information > than `-fmodule-output`. > So it is naturally to me that `-fmodule-output=` has higher priority. > > For examples, I don't enumerate all the flags but I find the following cases > in minutes: > - `-fpack-struct=` has higher priority than `-fpack-struct`. > - `-fsave-optimization-record=` has higher priority than > `-fsave-optimization-record=`. > - `-ftime-report=` has higher priority than `-ftime-report`. > - `-ftime-trace=` has higher priority than `-ftime-trace`. > > So I think the bahavior should be correct. Fair enough - thanks for the references! Nathan - is that consistent with your preference/understanding/experience? > > Thanks, > Chuanqi > > > -- > From:David Blaikie > Send Time:2022年12月13日(星期二) 23:56 > To:chuanqi.xcq > Cc:Iain Sandoe ; GCC Development ; Nathan > Sidwell ; Jonathan Wakely ; > ben.boeckel > Subject:Re: Naming flag for specifying the output file name for Binary Module > Interface files > > I think Nathan might've been asking not only about what currently > happens, but what we think should happen? > > On Mon, Dec 12, 2022 at 7:11 PM chuanqi.xcq > wrote: > > > > Hi Nathan, > > > > > 1) Are these flags silently ignored, if no module output is to be > > > generated? Or is some kind of diagnostic generated? > > > > Currently, clang will generate the unused-command-line-argument warning for > > this case: > > > > ``` > > argument unused during compilation: '-fmodule-output' > > [-Wunused-command-line-argument] > > ``` > > Is that consistent with `-o`? (I assume so, but don't know - I guess > there aren't many cases where `-o` is unused (maybe `-fsyntax-only`), > so that behavior might be a bit less well specified) > > > > 2) what happens if you specify both -- do you get two outputs, a > > > diagnostic, or > > is one silently selected? > > > > If someone specify both `-fmodule-output` and `-fmodule-output=/path`, > > the `-fmodule-output=/path` will be selected always no matter what the > > order is. > > This seems surprising/possibly wrong to me - do we have precedent from > other flags to draw from? > > > And if multiple `-fmodule-output=/path` are specified, the last one will be > > selected. > > > > > 3) What is the behaviour if compilation fails? Does nothing happen to > > > the file > > indicated (potentially leaving an older version there), or does the > > equivalent > > of 'rm -f $MODULE.pcm' happen? > > > > The module file will be deleted. The behavior is the same with `-o`. > > > > Thanks, > > Chuanqi > > > > > > -- > > From:Nathan Sidwell > > Send Time:2022年12月12日(星期一) 22:30 > > To:Iain Sandoe ; GCC Development > > Cc:Nathan Sidwell ; Jonathan Wakely > > ; David Blaikie ; ben.boeckel > > ; chuanqi.xcq > > Subject:Re: Naming flag for specifying the output file name for Binary > > Module Interface files > > > > On 12/9/22 12:33, Iain Sandoe wrote: > > > Hello all. > > > > > >> On 9 Dec 2022, at 01:58, chuanqi.xcq wrote: > > >> > > >> It looks like `-fmodule-file` is better from the discussion. So let's > > >> take it. Thanks for everyone here > > > > > > So FAOD (after this discussion) Chuanqi's current patchset implements the > > > following in clang: > > > > > > -fmodule-output > > > > > >- this causes the BMI to be saved in the CWG with the basename of the > > > source file and a suffix of .pcm. > > > > > > -fmodule-output= > > > > > > - this causes the BMI to be saved at the path specified. > > > > > > > 1) Are these flags silently ignored, if no module output is to be > > generated? Or > > is some kind of diagnostic generated? > > > > 2) what happens if you specify both -- do you get two outputs, a > > diagnostic, or > > is one silently selected? > > > > 3) What is the behaviour if compilation fails? Does nothing happen to the > > file > > indicated (potentially leaving an older version there), or does the > > equivalent > > of 'rm -f $MODULE.pcm' happen? > > > > nathan > > > > -- > > Nathan Sidwell > > > > > >
Re: Possible dead code in file lra-spills.cc
> Am 14.12.2022 um 18:28 schrieb G.T. via Gcc : > > At line 276, lra_assert (spill_class != NO_REGS); would trigger > whenever execution reached here with spill_class equal to NO_REGS. > Seems to me that would never happen. Because one of the conditions in > the if statement right above it (line 265) catches spill_class == > NO_REGS and causes the rest of the for loop to be skipped by executing > continue in the consequent of the if. So lra_assert never sees > spill_class == NO_REGS. That makes line 276 dead code, right? Sometimes this serves as documentation to make the code more obvious to read. Depends on the distance of the redundant check. Richard > Thanks. > GT.
Re: Naming flag for specifying the output file name for Binary Module Interface files
I'm missing something from this discussion. IIUC the claim is that these 2 new
options -fmodule-output{,=NAME} are for build systems that want to specify the
module output file.
But how do they specify the mapping from module/header-unit name to CMI, so that
imports work?
Is this really a clang-specific mechanism, as it has no module mapper ATM
(IIUC)?
nathan
--
Nathan Sidwell
[-Wstringop-overflow=] strncat(3)
Hi,
I was rewriting the strncat(3) manual page, and when I tried to compile the
example program, I got a surprise from the compiler.
Here goes the page:
strncat(3) Library Functions Manual strncat(3)
NAME
strncat - concatenate a null‐padded character sequence into a
string
LIBRARY
Standard C library (libc, -lc)
SYNOPSIS
#include
char *strncat(char *restrict dst, const char src[restrict .sz],
size_t sz);
DESCRIPTION
This function catenates the input character sequence contained in
a null‐padded fixed‐width buffer, into a string at the buffer
pointed to by dst. The programmer is responsible for allocating a
buffer large enough, that is, strlen(dst) + strnlen(src, sz) + 1.
An implementation of this function might be:
char *
strncat(char *restrict dst, const char *restrict src, size_t sz)
{
int len;
char *end;
len = strnlen(src, sz);
end = dst + strlen(dst);
end = mempcpy(end, src, len);
*end = '\0';
return dst;
}
RETURN VALUE
strncat() returns dest.
ATTRIBUTES
[...]
STANDARDS
POSIX.1‐2001, POSIX.1‐2008, C89, C99, SVr4, 4.3BSD.
CAVEATS
The name of this function is confusing. This function has no re‐
lation with strncpy(3).
If the destination buffer is not large enough, the behavior is un‐
defined. See _FORTIFY_SOURCE in feature_test_macros(7).
BUGS
This function can be very inefficient. Read about Shlemiel
the painter ⟨https://www.joelonsoftware.com/2001/12/11/
back-to-basics/⟩.
EXAMPLES
#include
#include
#include
int
main(void)
{
charbuf[BUFSIZ];
size_t len;
buf[0] = '\0'; // There’s no ’cpy’ function to this ’cat’.
strncat(buf, "Hello ", 6);
strncat(buf, "world", 42); // Padding null bytes ignored.
strncat(buf, "!", 1);
len = strlen(buf);
printf("[len = %zu]: <%s>\n", len, buf);
exit(EXIT_SUCCESS);
}
SEE ALSO
string(3), string_copy(3)
Linux man‐pages (unreleased) (date) strncat(3)
And when you compile that, you get:
$ cc -Wall -Wextra ./strncat.c
./strncat.c: In function ‘main’:
./strncat.c:12:12: warning: ‘strncat’ specified bound 6 equals source length
[-Wstringop-overflow=]
12 |strncat(buf, "Hello ", 6);
|^
./strncat.c:14:12: warning: ‘strncat’ specified bound 1 equals source length
[-Wstringop-overflow=]
14 |strncat(buf, "!", 1);
|^~~~
So, what? Where's the problem? This function does exactly that: "take an
unterminated character sequence and catenate it to an existing string". Clang
seems to be fine with the code.
Cheers,
Alex
--
Re: [-Wstringop-overflow=] strncat(3)
On 12/14/22 23:45, Alejandro Colomar wrote:
Hi,
I was rewriting the strncat(3) manual page, and when I tried to compile the
example program, I got a surprise from the compiler.
Here goes the page:
strncat(3) Library Functions Manual strncat(3)
NAME
strncat - concatenate a null‐padded character sequence into a
string
LIBRARY
Standard C library (libc, -lc)
SYNOPSIS
#include
char *strncat(char *restrict dst, const char src[restrict .sz],
size_t sz);
DESCRIPTION
This function catenates the input character sequence contained in
a null‐padded fixed‐width buffer, into a string at the buffer
pointed to by dst. The programmer is responsible for allocating a
buffer large enough, that is, strlen(dst) + strnlen(src, sz) + 1.
An implementation of this function might be:
char *
strncat(char *restrict dst, const char *restrict src, size_t sz)
{
int len;
char *end;
len = strnlen(src, sz);
end = dst + strlen(dst);
end = mempcpy(end, src, len);
*end = '\0';
return dst;
}
RETURN VALUE
strncat() returns dest.
ATTRIBUTES
[...]
STANDARDS
POSIX.1‐2001, POSIX.1‐2008, C89, C99, SVr4, 4.3BSD.
CAVEATS
The name of this function is confusing. This function has no re‐
lation with strncpy(3).
If the destination buffer is not large enough, the behavior is un‐
defined. See _FORTIFY_SOURCE in feature_test_macros(7).
BUGS
This function can be very inefficient. Read about Shlemiel
the painter ⟨https://www.joelonsoftware.com/2001/12/11/
back-to-basics/⟩.
EXAMPLES
#include
#include
#include
int
main(void)
{
char buf[BUFSIZ];
size_t len;
buf[0] = '\0'; // There’s no ’cpy’ function to this ’cat’.
strncat(buf, "Hello ", 6);
strncat(buf, "world", 42); // Padding null bytes ignored.
strncat(buf, "!", 1);
len = strlen(buf);
printf("[len = %zu]: <%s>\n", len, buf);
exit(EXIT_SUCCESS);
}
SEE ALSO
string(3), string_copy(3)
Linux man‐pages (unreleased) (date) strncat(3)
And when you compile that, you get:
$ cc -Wall -Wextra ./strncat.c
./strncat.c: In function ‘main’:
./strncat.c:12:12: warning: ‘strncat’ specified bound 6 equals source length
[-Wstringop-overflow=]
12 | strncat(buf, "Hello ", 6);
| ^
./strncat.c:14:12: warning: ‘strncat’ specified bound 1 equals source length
[-Wstringop-overflow=]
14 | strncat(buf, "!", 1);
| ^~~~
So, what? Where's the problem? This function does exactly that: "take an
unterminated character sequence and catenate it to an existing string". Clang
seems to be fine with the code.
Maybe it's saying that I should be using strncat(buf, "!"); because the length
is useless?
Cheers,
Alex
--
Re: [-Wstringop-overflow=] strncat(3)
On 12/14/22 23:51, Alejandro Colomar wrote:
On 12/14/22 23:45, Alejandro Colomar wrote:
Hi,
I was rewriting the strncat(3) manual page, and when I tried to compile the
example program, I got a surprise from the compiler.
Here goes the page:
strncat(3) Library Functions Manual strncat(3)
NAME
strncat - concatenate a null‐padded character sequence into a
string
LIBRARY
Standard C library (libc, -lc)
SYNOPSIS
#include
char *strncat(char *restrict dst, const char src[restrict .sz],
size_t sz);
DESCRIPTION
This function catenates the input character sequence contained in
a null‐padded fixed‐width buffer, into a string at the buffer
pointed to by dst. The programmer is responsible for allocating a
buffer large enough, that is, strlen(dst) + strnlen(src, sz) + 1.
An implementation of this function might be:
char *
strncat(char *restrict dst, const char *restrict src, size_t sz)
{
int len;
char *end;
len = strnlen(src, sz);
end = dst + strlen(dst);
end = mempcpy(end, src, len);
*end = '\0';
return dst;
}
RETURN VALUE
strncat() returns dest.
ATTRIBUTES
[...]
STANDARDS
POSIX.1‐2001, POSIX.1‐2008, C89, C99, SVr4, 4.3BSD.
CAVEATS
The name of this function is confusing. This function has no re‐
lation with strncpy(3).
If the destination buffer is not large enough, the behavior is un‐
defined. See _FORTIFY_SOURCE in feature_test_macros(7).
BUGS
This function can be very inefficient. Read about Shlemiel
the painter ⟨https://www.joelonsoftware.com/2001/12/11/
back-to-basics/⟩.
EXAMPLES
#include
#include
#include
int
main(void)
{
char buf[BUFSIZ];
size_t len;
buf[0] = '\0'; // There’s no ’cpy’ function to this ’cat’.
strncat(buf, "Hello ", 6);
strncat(buf, "world", 42); // Padding null bytes ignored.
strncat(buf, "!", 1);
len = strlen(buf);
printf("[len = %zu]: <%s>\n", len, buf);
exit(EXIT_SUCCESS);
}
SEE ALSO
string(3), string_copy(3)
Linux man‐pages (unreleased) (date) strncat(3)
And when you compile that, you get:
$ cc -Wall -Wextra ./strncat.c
./strncat.c: In function ‘main’:
./strncat.c:12:12: warning: ‘strncat’ specified bound 6 equals source length
[-Wstringop-overflow=]
12 | strncat(buf, "Hello ", 6);
| ^
./strncat.c:14:12: warning: ‘strncat’ specified bound 1 equals source length
[-Wstringop-overflow=]
14 | strncat(buf, "!", 1);
| ^~~~
So, what? Where's the problem? This function does exactly that: "take an
unterminated character sequence and catenate it to an existing string". Clang
seems to be fine with the code.
Maybe it's saying that I should be using strncat(buf, "!"); because the length
oops; of course, I meant strcat().
is useless?
Cheers,
Alex
--
Re: [-Wstringop-overflow=] strncat(3)
On Wed, Dec 14, 2022 at 2:46 PM Alejandro Colomar via Libc-alpha
wrote:
>
> Hi,
>
> I was rewriting the strncat(3) manual page, and when I tried to compile the
> example program, I got a surprise from the compiler.
>
> Here goes the page:
>
>
>strncat(3) Library Functions Manual strncat(3)
>
>NAME
> strncat - concatenate a null‐padded character sequence into a
> string
>
>LIBRARY
> Standard C library (libc, -lc)
>
>SYNOPSIS
> #include
>
> char *strncat(char *restrict dst, const char src[restrict .sz],
> size_t sz);
>
>DESCRIPTION
> This function catenates the input character sequence contained in
> a null‐padded fixed‐width buffer, into a string at the buffer
> pointed to by dst. The programmer is responsible for allocating a
> buffer large enough, that is, strlen(dst) + strnlen(src, sz) + 1.
>
> An implementation of this function might be:
>
> char *
> strncat(char *restrict dst, const char *restrict src, size_t sz)
> {
> int len;
> char *end;
>
> len = strnlen(src, sz);
> end = dst + strlen(dst);
> end = mempcpy(end, src, len);
> *end = '\0';
>
> return dst;
> }
>
>RETURN VALUE
> strncat() returns dest.
>
>ATTRIBUTES
> [...]
>
>STANDARDS
> POSIX.1‐2001, POSIX.1‐2008, C89, C99, SVr4, 4.3BSD.
>
>CAVEATS
> The name of this function is confusing. This function has no re‐
> lation with strncpy(3).
>
> If the destination buffer is not large enough, the behavior is un‐
> defined. See _FORTIFY_SOURCE in feature_test_macros(7).
>
>BUGS
> This function can be very inefficient. Read about Shlemiel
> the painter ⟨https://www.joelonsoftware.com/2001/12/11/
> back-to-basics/⟩.
>
>EXAMPLES
> #include
> #include
> #include
>
> int
> main(void)
> {
> charbuf[BUFSIZ];
> size_t len;
>
> buf[0] = '\0'; // There’s no ’cpy’ function to this ’cat’.
> strncat(buf, "Hello ", 6);
> strncat(buf, "world", 42); // Padding null bytes ignored.
> strncat(buf, "!", 1);
> len = strlen(buf);
> printf("[len = %zu]: <%s>\n", len, buf);
>
> exit(EXIT_SUCCESS);
> }
>
>SEE ALSO
> string(3), string_copy(3)
>
>Linux man‐pages (unreleased) (date) strncat(3)
>
>
> And when you compile that, you get:
>
> $ cc -Wall -Wextra ./strncat.c
> ./strncat.c: In function ‘main’:
> ./strncat.c:12:12: warning: ‘strncat’ specified bound 6 equals source length
> [-Wstringop-overflow=]
> 12 |strncat(buf, "Hello ", 6);
>|^
> ./strncat.c:14:12: warning: ‘strncat’ specified bound 1 equals source length
> [-Wstringop-overflow=]
> 14 |strncat(buf, "!", 1);
>|^~~~
>
>
> So, what? Where's the problem? This function does exactly that: "take an
> unterminated character sequence and catenate it to an existing string". Clang
> seems to be fine with the code.
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83404 and the
background of why the warning was added here:
https://www.us-cert.gov/bsi/articles/knowledge/coding-practices/strncpy-and-strncat.
Thanks,
Andrew Pinski
>
> Cheers,
>
> Alex
>
>
> --
>
Re: [-Wstringop-overflow=] strncat(3)
[CC += groff]
Hi Andrew,
On 12/14/22 23:57, Andrew Pinski wrote:
On Wed, Dec 14, 2022 at 2:46 PM Alejandro Colomar via Libc-alpha
wrote:
Hi,
I was rewriting the strncat(3) manual page, and when I tried to compile the
example program, I got a surprise from the compiler.
Here goes the page:
strncat(3) Library Functions Manual strncat(3)
NAME
strncat - concatenate a null‐padded character sequence into a
string
LIBRARY
Standard C library (libc, -lc)
SYNOPSIS
#include
char *strncat(char *restrict dst, const char src[restrict .sz],
size_t sz);
DESCRIPTION
This function catenates the input character sequence contained in
a null‐padded fixed‐width buffer, into a string at the buffer
pointed to by dst. The programmer is responsible for allocating a
buffer large enough, that is, strlen(dst) + strnlen(src, sz) + 1.
An implementation of this function might be:
char *
strncat(char *restrict dst, const char *restrict src, size_t sz)
{
int len;
char *end;
len = strnlen(src, sz);
end = dst + strlen(dst);
end = mempcpy(end, src, len);
*end = '\0';
return dst;
}
RETURN VALUE
strncat() returns dest.
ATTRIBUTES
[...]
STANDARDS
POSIX.1‐2001, POSIX.1‐2008, C89, C99, SVr4, 4.3BSD.
CAVEATS
The name of this function is confusing. This function has no re‐
lation with strncpy(3).
If the destination buffer is not large enough, the behavior is un‐
defined. See _FORTIFY_SOURCE in feature_test_macros(7).
BUGS
This function can be very inefficient. Read about Shlemiel
the painter ⟨https://www.joelonsoftware.com/2001/12/11/
back-to-basics/⟩.
EXAMPLES
#include
#include
#include
int
main(void)
{
charbuf[BUFSIZ];
size_t len;
buf[0] = '\0'; // There’s no ’cpy’ function to this ’cat’.
strncat(buf, "Hello ", 6);
strncat(buf, "world", 42); // Padding null bytes ignored.
strncat(buf, "!", 1);
len = strlen(buf);
printf("[len = %zu]: <%s>\n", len, buf);
exit(EXIT_SUCCESS);
}
SEE ALSO
string(3), string_copy(3)
Linux man‐pages (unreleased) (date) strncat(3)
And when you compile that, you get:
$ cc -Wall -Wextra ./strncat.c
./strncat.c: In function ‘main’:
./strncat.c:12:12: warning: ‘strncat’ specified bound 6 equals source length
[-Wstringop-overflow=]
12 |strncat(buf, "Hello ", 6);
|^
./strncat.c:14:12: warning: ‘strncat’ specified bound 1 equals source length
[-Wstringop-overflow=]
14 |strncat(buf, "!", 1);
|^~~~
So, what? Where's the problem? This function does exactly that: "take an
unterminated character sequence and catenate it to an existing string". Clang
seems to be fine with the code.
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83404 and the
background of why the warning was added here:
https://www.us-cert.gov/bsi/articles/knowledge/coding-practices/strncpy-and-strncat.
This document is bogus, since it's puting strncpy(3) and strncat(3) in the same
sack, when they're in reality two completely different beasts. I'll quote below
some paragraphs of some new page I'm writing, which will show why.
The rationale behind GCC's warning is also fundamentally wrong. Martin was
wrong when he claimed that the right call for strncat(3) is the remaining space
in the destination.
I admit that I didn't know what strncat(3) was useful for, and believed that it
was simply a broken-by-design function until very recently (this week, more or
less). And to be honest, I still believe it's broken by design; it's just that
it can be repurposed for a reasonable new purpose (which I found while digging
in groff's source code; that's why the CC).
First I'll show an example program that I added to the strncat(3) manual page
last week, which is based on the groff code that used it:
#include
#include
#include
#define nitems(arr) (sizeof((arr)) / sizeof((arr)[0]))
int
main(void)
{
char pre[4] = "pre.";
char *post = ".post";
char *src = "some_long_body.post";
char dest[100];
dest[0] = '\0';
strncat(dest, pre, nitems(pre));
strncat(dest, src, strlen(src) - strl
Re: Naming flag for specifying the output file name for Binary Module Interface files
Hi Nathan,
> But how do they specify the mapping from module/header-unit name to CMI, so
> that
> imports work?
>
> Is this really a clang-specific mechanism, as it has no module mapper ATM
> (IIUC)?
Yes, clang doesn't have a module mapper. And I remember Iain said he want to
introduce these options in GCC.
Thanks,
Chuanqi
--
From:Nathan Sidwell
Send Time:2022年12月15日(星期四) 06:29
To:David Blaikie ; chuanqi.xcq
Cc:Iain Sandoe ; GCC Development ; Nathan
Sidwell ; Jonathan Wakely ;
ben.boeckel
Subject:Re: Naming flag for specifying the output file name for Binary Module
Interface files
I'm missing something from this discussion. IIUC the claim is that these 2 new
options -fmodule-output{,=NAME} are for build systems that want to specify the
module output file.
But how do they specify the mapping from module/header-unit name to CMI, so
that
imports work?
Is this really a clang-specific mechanism, as it has no module mapper ATM
(IIUC)?
nathan
--
Nathan Sidwell
Why does filing a bug report have to be so damn hard?
Seriously? You UNIX folks are completely clueless about usability! It would have been far easier to supply a built-in or separate utility to automatically collect all the pertinent source files with the option of mailing them to you. It also wouldn't be half as backward if you didn't make me read a tome's worth of hostile verbiage telling me what you want and don't want while wading through irrelevant instructions with hyperlinking hell because you can't be bothered with the effort of separating the different programming languages. If you UNIX folks could have it your way, we'd all still be typing on teleprinters and staring at green monitors getting carpal tunnel syndrome because you can't be bothered with usability. Let me remind you that it was Apple, the evil proprietary monster, who had the consideration to make their products usable by people with disabilities. Their biggest mistake was to adopt UNIX, which would've been the biggest productivity-killing malware ever created if it wasn't for Git.
Re: Naming flag for specifying the output file name for Binary Module Interface files
> On 15 Dec 2022, at 05:58, chuanqi.xcq wrote:
>
> Hi Nathan,
>
> > But how do they specify the mapping from module/header-unit name to CMI, so
> > that
> > imports work?
> >
> > Is this really a clang-specific mechanism, as it has no module mapper ATM
> > (IIUC)?
>
> Yes, clang doesn't have a module mapper. And I remember Iain said he want to
> introduce these options in GCC.
To clarify:
* I have patches for clang that implements the P1184 interface which would
allow a ‘module mapper’ to be used to discover module name <-> pathname
pairings.
* The demand for the command line options we are discussing here is coming
from build systems folks who want to be able to specify everything on the
command line (i.e. from my understanding they do not want to use a module
mapper, but prefer dependency scanning).
So I think the two aspects are somewhat independent, I would expect the same
build systems folks to want to be able to specify everything on the GCC command
line too.
thanks,
Iain
>
> Thanks,
>
> Chuanqi
>
> --
> From:Nathan Sidwell
> Send Time:2022年12月15日(星期四) 06:29
> To:David Blaikie ; chuanqi.xcq
>
> Cc:Iain Sandoe ; GCC Development ; Nathan
> Sidwell ; Jonathan Wakely ;
> ben.boeckel
> Subject:Re: Naming flag for specifying the output file name for Binary Module
> Interface files
>
> I'm missing something from this discussion. IIUC the claim is that these 2
> new
> options -fmodule-output{,=NAME} are for build systems that want to specify
> the
> module output file.
>
> But how do they specify the mapping from module/header-unit name to CMI, so
> that
> imports work?
>
> Is this really a clang-specific mechanism, as it has no module mapper ATM
> (IIUC)?
>
> nathan
> --
> Nathan Sidwell
>
