- Overflow issue - 8 Updates
| Juha Nieminen <nospam@thanks.invalid>: May 07 06:12AM > errors, which means that sometimes they reflect a serious problem, and > sometimes they don't. Each warning should be considered on a case by > case basis, to decide whether or not the warning is justified. I once encountered a project where the author(s) had taken the "must compile without warnings" way too seriously. Not only was the compiler option -Werror used (obviously) in addition to your standard -Wall -Wextra -pedantic, but the author(s) had gone the extra mile of wading through gcc's documentation and turned on every single warning flag that was not already turned on by those generic options. Problem was, when I tried to compile the project with whaver version of gcc happened to be installed in my system at the time, those additional super-pedantic warning flags (that are not turned on by -Wall nor -Wextra) were causing warnings *from the standard library headers*. Which of course stopped the project from compiling because of -Werror. There are policies and there's taking policies too far. |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: May 07 08:52AM +0200 On 07.05.2020 08:12, Juha Nieminen wrote: > super-pedantic warning flags (that are not turned on by -Wall nor > -Wextra) were causing warnings *from the standard library headers*. > Which of course stopped the project from compiling because of -Werror. Modern compilers have ways to suppress warnings from system headers. --- For (modern) g++ that's the default, and you have to explicitly enable warnings from system headers if you're interested in them: <url: https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wsystem-headers> « -Wsystem-headers Print warning messages for constructs found in system header files. Warnings from system headers are normally suppressed, on the assumption that they usually do not indicate real problems and would only make the compiler output harder to read. Using this command-line option tells GCC to emit warnings from system headers as if they occurred in user code. However, note that using -Wall in conjunction with this option does not warn about unknown pragmas in system headers—for that, -Wunknown-pragmas must also be used. » To designate a directory as containing system headers, <url: https://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html#Directory-Options> « The -isystem and -idirafter options also mark the directory as a system directory, so that it gets the same special treatment that is applied to the standard system directories. » --- Visual C++ only recently gained the ability to let the user differentiate between system headers and headers in general. As of Visual C++ 2019 it's still an experimental feature. I.e., the details may possibly still change. In typical Microsoft fashion it's done via an excessively verbose COBOL like syntax with no reasonable defaults, no doubt either designed to look impressive to some non-technical MS manager, or designed by such. [In the Windows Cmd interpreter:] « > cl /? 2>&1 | find /i "external" /FC use full pathnames in diagnostics /H<num> max external name length /external:I <path> - location of external headers /external:env:<var> - environment variable with locations of external headers /external:anglebrackets - treat all headers included via <> as external /external:W<n> - warning level for external headers /external:templates[-] - evaluate warning level across template instantiation chain » Some explanation and background: <url: https://devblogs.microsoft.com/cppblog/broken-warnings-theory/>. > There are policies and there's taking policies too far. Yes, agreed. :) - Alf |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: May 07 11:37AM +0200 On 05.05.2020 11:08, jacobnavia wrote: > WHAT? > Can you specify a little bit more? A reference? Some proof? > Thanks in advance Thread started in 2016: <url: https://www.reddit.com/r/cpp/comments/4ibauu/visual_studio_adding_telemetry_function_calls_to/> « Visual Studio adding telemetry function calls to binary? [–]spongo2MSVC Dev Manager 86 points 3 years ago hi everyone. This is Steve Carroll, the dev manager for the Visual C++ team. Tl;dr: thanks folks for the feedback. Our team will be removing this from our static libs in Update 3. Our intent was benign – our desire was to build a framework that will help investigate performance problems and » Thread started in 2018, about editor and IDE: <url: https://www.reddit.com/r/privacy/comments/80d8wu/just_realised_that_visual_studio_code_sends/> « Just realised that Visual Studio Code sends telemetry data do Microsoft by default. Here how to disable it. (self.privacy) submitted 2 years ago by misterolupo As a reminder, if you are a programmer using VS Studio, you can disable the telemetry by entering these entries in your user settings: { "telemetry.enableCrashReporter": false, "telemetry.enableTelemetry": false } Using a FOSS alternative would be better, but I thought this might be useful to somebody out there. --- [–]slayerizer 10 points 2 years ago The .NET core runtime also sends telemetry to Microsoft by default. If you create a project with it, you need to disable that also. » There was a recent (two or three months ago) thread about telemetry, or at least the functions for telemetry, discovered in an executable generated by Visual C++ 2019. Simple googling didn't find it now. - Alf |
| Manfred <noname@add.invalid>: May 07 01:00PM +0200 On 5/7/2020 11:37 AM, Alf P. Steinbach wrote: > at least the functions for telemetry, discovered in an executable > generated by Visual C++ 2019. Simple googling didn't find it now. > - Alf I honestly thought this was a joke. It's scary indeed, thanks for sharing. |
| David Brown <david.brown@hesbynett.no>: May 07 01:25PM +0200 On 06/05/2020 22:06, Keith Thompson wrote: > if you need to support multiple implementations, for example if you need > your code to build correctly on, say, Linux and Windows. It can be > simpler to follow a rule than to decide when it's ok to add exceptions. I agree with this approach. Compilers vary significantly in how they handle warnings, especially when left in defaults or general "-Wall" settings. My preference is to be explicit about the warnings used - usually as flags in a Makefile. But on occasions where I know some code will trigger warnings that I normally prefer to have on, I use explicit pragmas in the code. (The same applies to any specific optimisation settings, such as if I am working with third-party code that does silly things with pointer casts and needs "-fno-strict-alias" for gcc.) Warnings are primarily of importance while developing code, rather than for building it on different systems. So even for portable code it is usually fine to have gcc-specific warning flags and pragmas if you are using gcc as your main development compiler, and say that for building on other tools you turn off warnings. |
| David Brown <david.brown@hesbynett.no>: May 07 02:52PM +0200 On 07/05/2020 00:46, James Kuyper wrote: > I've usually seen the policy of treating all warnings as errors promoted > as an essential best-practice, without any acknowledgment that the bad > taste of some compiler writers could make such a policy problematic. You can't base "best practice" on whatever a compiler chooses by default or in common flag groups (like "-Wall"). But you /can/ have it based on your company or project specific choice of warnings. Static analysis is, IMHO, an important part of any serious development practice. It needs to be considered and used sensibly and appropriately, not as in a shotgun "enable everything" way. |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: May 07 08:46AM -0700 > On 06/05/2020 22:06, Keith Thompson wrote: [...] > optimisation settings, such as if I am working with third-party code > that does silly things with pointer casts and needs > "-fno-strict-alias" for gcc.) Sure, but I was thinking primarily about writing the code so it doesn't trigger the warning in the first place rather than using a compiler-specific pragma. For example, if this: unsigned x = 42; x = -x; triggers a warning because I used unary "-" on an unsigned type, I might change it to: x = UINT_MAX-x+1; (Depending on the context, that might even be clearer.) > it is usually fine to have gcc-specific warning flags and pragmas if > you are using gcc as your main development compiler, and say that for > building on other tools you turn off warnings. The most common case where I've run into this at work is when I've added a temporary function while debugging and then commented out a call to it, causing a (fatal) warning that the function is unused. It's easy enough to comment out the function definition and rebuild. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for Philips Healthcare void Void(void) { Void(); } /* The recursive call of the void */ |
| David Brown <david.brown@hesbynett.no>: May 07 08:20PM +0200 On 07/05/2020 17:46, Keith Thompson wrote: > change it to: > x = UINT_MAX-x+1; > (Depending on the context, that might even be clearer.) I'd say write the code in the clearest way. I am a big fan of warnings in compilers, and use them a lot - but if a warning means you have to write code in an awkward way, then this must be balanced carefully against the warnings use in preventing accidental mistakes. If you think you are likely to make mistakes that are caught by this warning, then it is worth enabling it even if it means occasionally writing awkward looking code (or warning disables) for the rare occasions when you need it. If you don't see it as a likely cause of mistakes and regularly want to negate unsigned types, then disable the warning completely. > added a temporary function while debugging and then commented out a > call to it, causing a (fatal) warning that the function is unused. > It's easy enough to comment out the function definition and rebuild. Yes. Or add "__attribute__((unused))" to the function (for gcc - other compilers are likely to have their own methods). |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment