Wformat-security and string literal
Following code generate a _dubious_ warning message:
int main(void) {
const char * const literal = "xxx";
fprintf(stderr, literal);
return 0;
}
cc -Wall -Wformat-security -o main main.c
main.c: In function `main':
main.c:9: warning: format not a string literal and no format arguments
check_format_info() in gcc/c-format.c doesn't check if the format
argument is a _pointer_ to a string literal.
best regards
HGN
Re: Wformat-security and string literal
* Joe Buck | 2005-10-17 09:28:51 [-0700]: >If we go down that route, the option would only work correctly if >optimization is enabled, because you expect gcc to trace the source >of pointers, and see what the pointers point to, and check the original >strings for format characters. ACK - gcc behave correctly if optimization is enabled. To my mind: a pointer who points to a string literal is also a string literal. The generated string is stored in the .rodata section, on either side (-O0, -O2). The generated code is the same, but the warning messages differ! HGN
Re: Shared libraries
* Softish soft | 2005-11-02 08:31:05 [+]: >What I mean with shared library is that I build a library that somehow can >dynamically be called over an ethernet cable. That's a feature that you don't want! This implied many technics that are not the tenor of gcc or another compiler! Upper technics like corba or rpc(3) offer such features. >Maybe theres an option to specify IP address to the dynamically linked >library. gcc is a compiler suite - nothing more and nothing less! HGN -- Artificial intelligence has the same relation to intelligence as artificial flowers have to flowers. -- David Parnas
Re: sizeof((..))
On Mon, 31 Jan 2011 09:19:07 +, Jonathan Wakely wrote: > The code is wrong. sizeof expects either an expression, or a > parenthesized type-id. (long) is not a type-id so ((long)) is not a > parenthesized type-id, therefore it must be interpreted as an > expression, but it's not a valid expression either. In sense of 6.5.3.4 - the sizeof operator where nearly every value is allowed? Why not a parenthesized parenthesized type-id? HGN
Re: Will GCC eventually support SSE2 or SSE4.1?
* Jonathan Wakely via Gcc | 2023-05-26 08:30:06 [+0100]: >On Fri, 26 May 2023, 08:01 Andrew Pinski via Gcc, wrote: > >> > GCC 13.3: gcc -m32 -O3 demo.c >> > >> > NOTE: -mtune=native is the default! >> >> You need to use -march=native and not -mtune=native to turn on >> the architecture features. > >Yes this is just user error. You didn't use the right options to say you >want SSE2. GCC supports it fine already. > >This is also the wrong mailing list for this kind of question, please use >gcc-h...@gcc.gnu.org for this kind of thing, thanks. Correct, that was also my first thought - but: this mistake has been repeated again and again for decades. Here specifically Stefan Kanthak realized that something is wrong - in many cases simply mtune=native is used and the error is not realized. Maybe we should think about how you can support the users better? Maybe by an explicit hint in the documentation or by a info message at execution time. And for such discussions this is the right mailing list! ;-) Hagen
