I have some legacy code that has got conditional preprocessing e.g. #ifdef and #else where I have found the use of __attribute__ macro. I have done a quick research and found out that it is specific to GNU compilers. I have to use this legacy code in Visual Studio 2010 using MSVC10 compiler and apparently it is complaining everywhere it sees attribute((unused)) even though it is protected by #ifndef and #ifdefs. An example is:
#ifdef __tone_z__
static const char *mcr_inf
#else
static char *mcr_inf
#endif
#ifndef _WINDOWS
__attribute__(( unused )) % this is causing all the problem!!
#endif
= "#(#) bla bla copyright bla";
#ifdef __tone_z__
static const char *mcr_info_2a353_id[2]
#else
static char *mcr_info_2a353_id[2]
#endif
__attribute__(( unused )) = { "my long copyright info!" } ;
I am really struggling to understand if it is very poorly planned code or is it just my misunderstanding. How do I avoid the usual compiler and linker errors with this __attribute__() directive? I have started to get C2061 errors (missing identifiers/unknown). I have got all necessary header files and nothing is missing, may be except GNU compiler (which I don't want!!).
Also, it seems that the end of line character ; is also being messed up when I take to code in windows....argh....I mean the UNIX end-of-line and Windows EOL how can I use this code without modifying the body....I can define in my property sheet about the _WINDOWS thingy, but cannot automatically adjust the EOL character recognition.
ANy help is appreciated!
Thanks.
My best guess is that _WINDOWS is, in fact, not defined by your compiler, and so use of __attibute__ is not protected.
In my opinion, the best way to protect against attributes is to define a macro like this:
#define __attribute__(A) /* do nothing */
That should simply remove all __attribute__ instances from the code.
In fact, most code that has been written to be portable has this:
#ifdef _GNUC
#define ATTR_UNUSED __attribute__((unused))
#else
#define ATTR_UNUSED
#endif
static TONE_Z_CONST char *integ_func ATTR_UNUSED = "my copyright info";
(Other __tone_z__ conditional removed for clarity only.)
Related
I'm aware of many similar questions on this site. I really like the solution mention in the following link:
https://stackoverflow.com/a/25021520/884553
with some modification, you can include text file at compile time, for example:
constexpr const char* s =
#include "file.txt"
BUT to make this work you have to add string literal prefix and suffix to your original file, for example
R"(
This is the original content,
and I don't want this file to be modified. but i
don't know how to do it.
)";
My question is: is there a way to make this work but not modifying file.txt?
(I know I can use command line tools to make a copy, prepend and append to the copy, remove the copy after compile. I'm looking for a more elegant solution than this. hopefully no need of other tools)
Here's what I've tried (but not working):
#include <iostream>
int main() {
constexpr const char* s =
#include "bra.txt" // R"(
#include "file.txt" //original file without R"( and )";
#include "ket.txt" // )";
std::cout << s << "\n";
return 0;
}
/opt/gcc8/bin/g++ -std=c++1z a.cpp
In file included from a.cpp:5:
bra.txt:1:1: error: unterminated raw string
R"(
^
a.cpp: In function ‘int main()’:
a.cpp:4:27: error: expected primary-expression at end of input
constexpr const char* s =
^
a.cpp:4:27: error: expected ‘}’ at end of input
a.cpp:3:12: note: to match this ‘{’
int main() {
^
No, this cannot be done.
There is a c++2a proposal to allow inclusion of such resources at compile time called std::embed.
The motivation part of ths p1040r1 proposal:
Motivation
Every C and C++ programmer -- at some point -- attempts to #include large chunks of non-C++ data into their code. Of course, #include expects the format of the data to be source code, and thusly the program fails with spectacular lexer errors. Thusly, many different tools and practices were adapted to handle this, as far back as 1995 with the xxd tool. Many industries need such functionality, including (but hardly limited to):
Financial Development
representing coefficients and numeric constants for performance-critical algorithms;
Game Development
assets that do not change at runtime, such as icons, fixed textures and other data
Shader and scripting code;
Embedded Development
storing large chunks of binary, such as firmware, in a well-compressed format
placing data in memory on chips and systems that do not have an operating system or file system;
Application Development
compressed binary blobs representing data
non-C++ script code that is not changed at runtime; and
Server Development
configuration parameters which are known at build-time and are baked in to set limits and give compile-time information to tweak performance under certain loads
SSL/TLS Certificates hard-coded into your executable (requiring a rebuild and potential authorization before deploying new certificates).
In the pursuit of this goal, these tools have proven to have inadequacies and contribute poorly to the C++ development cycle as it continues to scale up for larger and better low-end devices and high-performance machines, bogging developers down with menial build tasks and trying to cover-up disappointing differences between platforms.
MongoDB has been kind enough to share some of their code below. Other companies have had their example code anonymized or simply not included directly out of shame for the things they need to do to support their workflows. The author thanks MongoDB for their courage and their support for std::embed.
The request for some form of #include_string or similar dates back quite a long time, with one of the oldest stack overflow questions asked-and-answered about it dating back nearly 10 years. Predating even that is a plethora of mailing list posts and forum posts asking how to get script code and other things that are not likely to change into the binary.
This paper proposes <embed> to make this process much more efficient, portable, and streamlined. Here’s an example of the ideal:
#include <embed>
int main (int, char*[]) {
constexpr std::span<const std::byte> fxaa_binary = std::embed( "fxaa.spirv" );
// assert this is a SPIRV file, compile-time
static_assert( fxaa_binary[0] == 0x03 && fxaa_binary[1] == 0x02
&& fxaa_binary[2] == 0x23 && fxaa_binary[3] == 0x07
, "given wrong SPIRV data, check rebuild or check the binaries!" )
auto context = make_vulkan_context();
// data kept around and made available for binary
// to use at runtime
auto fxaa_shader = make_shader( context, fxaa_binary );
for (;;) {
// ...
// and we’re off!
// ...
}
return 0;
}
I'm working on some exercises for school.
The projects i have from my teacher work without any errors.
When i copy the code to a new project made on my computer, it shows this error:
Compiler Warning (level 3) C4996
I looked at both compiler settings and made them equal, this didn't work.
So i tried to make a project property file from my teachers project and insert it into my own project. Also this doesn't work.
Can somebody help me solving this issue?
This is the code:
#include <stdio.h>
#include <string.h>
int main(void)
{
char s1[32];
char s2[32];
strcpy(s1, "abc def.");
strcpy(s2, "ghi_x");
printf("s1=\"%s\" en s2=\"%s\"\n", s1, s2);
printf("s1 bevat %d symbolen en s2 bevat %d symbolen\n", strlen(s1), strlen(s2));
printf("De functie strcmp(s1,s2) geeft %d als functiewaarde\n", strcmp(s1, s2));
getchar();
return 0;
}
The Error I get is
Severity Code Description Project File Line Suppression State Error C4996 'strcpy': This function or variable may be unsafe. Consider using strcpy_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details
A quick Google search shows that "Compiler Warning (level 3) C4996" means you're using deprecated functions. The most likely culprits are your str* functions since they are generally unsafe. Switch to using their strn* counterparts (e.g. strncpy).
I'm using gcc toolchain for ARM and I need a linker to place a structure on a 256B boundary in memory. I've tried the aligned attribute:
volatile struct ohci_hcca hcca __attribute__ ((aligned (256)));
but with no luck:
nm out.elf | grep hcca
20011dc0 B hcca
I remember using this in past for fields that had to be on 512B boundary so I know it's possible but I seem to be missing something this time.
Thanks for any guidance.
EDIT:
The mystery's been solved. The BSP library is composed from tens of drivers and one of their header files contaned this:
#if defined __ICCARM__ || defined __CC_ARM || defined __GNUC__
//#pragma data_alignment=8 /* IAR */
#pragma pack(1) /* IAR */
#define __attribute__(...) /* IAR */
#endif /* IAR */
For __GNUC__ it doesn't make any sense unless the author of this chunk is a member of guerrilla force against GCC users. Ruined my entire evening :)
I have installed CocoaPods.. and loaded the workspace as instructed.
I am getting these warnings which I do not understand, here is an example:
Pods-CipherDatabaseSync-SQLCipher
sqlite.c
/Users/admin/Code/CipherDatabaseSync/Pods/SQLCipher/sqlite3.c:24035:13: Ambiguous expansion of macro 'MAX'
I have looked around for a couple of hours and I am stumped at what I need to do, can someone please point me in the direction of somewhere that will provide some insight?
Thanks.
In the sqlite.c file it looks as if MIN and MAX are trying to be defined in two different areas of the file. The first time on line 214
/* Macros for min/max. */
#ifndef MIN
#define MIN(a,b) (((a)<(b))?(a):(b))
#endif /* MIN */
#ifndef MAX
#define MAX(a,b) (((a)>(b))?(a):(b))
#endif /* MAX */
Then secondly at line 8519
/*
** Macros to compute minimum and maximum of two numbers.
*/
#define MIN(A,B) ((A)<(B)?(A):(B))
#define MAX(A,B) ((A)>(B)?(A):(B))
I commented out where they define it the second time and all of the warnings went away after cleaning and building the project again.
Remove the MAX and MIN macro definitions from the sqlite3.c file, since they are already defined in system headers.
Issue Solution:
Open Xcode project Build settings
add “-Wno-ambiguous-macro” into “Other C flags”
Ive got a multi platform project that compiles great on mac, but on windows all my swprintf calls with a %s are looking for a wchar_t instead of the char * im passing it. Turns out M$ thought it would be funny to make %s stand for something other than char * in wide character functions... http://msdn.microsoft.com/en-us/library/hf4y5e3w.aspx
Anyways I'm looking for a creative coding trick thats better than putting ifdef else ends around every wide string call
Update: VS 2015 CTP6 reverted the changes and Microsoft are yet again acting different to the standard.
Visual Studio 14 CTP1 and later will always treat %s as a narrow string (char*) unless you define _CRT_STDIO_LEGACY_WIDE_SPECIFIERS. It also added the T length modifier extension which maps to what MS calls the "natural" width. For sprintf %Ts is char* and for swprintf %Ts is wchar_t*.
In Visual Studio 13 and earlier %s/%c is mapped to the natural width of the function/format string and %S/%C is mapped to the opposite of the natural with:
printf("%c %C %s %S\n", 'a', L'B', "cd", L"EF");
wprintf(L"%c %C %s %S\n", L'a', 'B', L"cd", "EF");
You can also force a specific width by using a length modifier: %ls, %lc, %ws and %wc always mean wchar_t and %hs and %hc are always char. (Documented for VS2003 here and VC6 here (Not sure about %ws and when it was really added))
Mapping %s to the natural width of the function was really handy back in the days of Win9x vs. WinNT, by using the tchar.h header you could build narrow and wide releases from the same source. When _UNICODE is defined the functions in tchar.h map to the wide functions and TCHAR is wchar_t, otherwise the narrow functions are used and TCHAR is char:
_tprintf(_T("%c %s\n"), _T('a'), _T("Bcd"));
There is a similar convention used by the Windows SDK header files and the few format functions that exist there (wsprintf, wvsprintf, wnsprintf and wvnsprintf) but they are controlled by UNICODE and TEXT and not _UNICODE and _T/_TEXT.
You probably have 3 choices to make a multi-platform project work on Windows if you want to support older Windows compilers:
1) Compile as a narrow string project on Windows, probably not a good idea and in your case swprintf will still treat %s as wchar_t*.
2) Use custom defines similar to how inttypes.h format strings work:
#ifdef _WIN32
#define PRIs "s"
#define WPRIs L"hs"
#else
#define PRIs "s"
#define WPRIs L"s"
#endif
printf("%" PRIs " World\n", "Hello");
wprintf(L"%" WPRIs L" World\n", "Hello");
3) Create your own custom version of swprintf and use it with Visual Studio 13 and earlier.
Use the %ls format which always means wchar_t*.
You can use "%Ts" format specifier or you can define _CRT_STDIO_LEGACY_WIDE_SPECIFIERS=1.
Read this:
http://blogs.msdn.com/b/vcblog/archive/2014/06/18/crt-features-fixes-and-breaking-changes-in-visual-studio-14-ctp1.aspx