Обсуждение: stringify MAKE_SQLSTATE()
Hi! Following discussion at https://commitfest.postgresql.org/5/190/ patch, I found (at seems to me) a way to stringify MAKE_SQLSTATE(), the idea is to use char array as string: #include <stdio.h> #define MAKE_SQLSTATE(ch1,ch2,ch3,ch4,ch5) \ ((char[]){(char)(ch1),(char)(ch2),(char)(ch3),(char)(ch4),(char)(ch5),(char)'\0'}) #define ERRCODE_WARNING_DEPRECATED_FEATURE MAKE_SQLSTATE('0','1','P','0','1') int main(int argn, char* argv[]) { char *x = ERRCODE_WARNING_DEPRECATED_FEATURE; printf("%s\n", x); return 0; } That works for clang ang gcc48 with flags -Wall -Wextra -ansi (or -std=c90) without warnings, but doesn't work with -pedantic. Is that enough to to work with other compilers? -- Teodor Sigaev E-mail: teodor@sigaev.ru WWW: http://www.sigaev.ru/
Teodor Sigaev <teodor@sigaev.ru> writes: > Following discussion at https://commitfest.postgresql.org/5/190/ patch, I found > (at seems to me) a way to stringify MAKE_SQLSTATE(), the idea is to use char > array as string: > #define MAKE_SQLSTATE(ch1,ch2,ch3,ch4,ch5) \ > ((char[]){(char)(ch1),(char)(ch2),(char)(ch3),(char)(ch4),(char)(ch5),(char)'\0'}) I'm pretty sure that's a gcc-ism, not standard C. As I mentioned in the other thread, if we wanted to provide string versions of the ERRCODE macros, the safest way to do it would be to create a separate header file with defines like #define ERRCODE_WARNING_DEPRECATED_FEATURE "01P01" Now that we generate errcodes.h from errcodes.txt anyway, it would certainly be a trivial extension of the build infrastructure to make a second header like this. The real question is do we want to. What's your use-case for this? regards, tom lane
>> #define MAKE_SQLSTATE(ch1,ch2,ch3,ch4,ch5) \ >> ((char[]){(char)(ch1),(char)(ch2),(char)(ch3),(char)(ch4),(char)(ch5),(char)'\0'}) > > I'm pretty sure that's a gcc-ism, not standard C. Hmm, after some digging: the feature is called compound literals and it was introduced in c99 although gcc has support in c90. To disable this support it's needed a flag -pedantic. Sorry. > The real question is do we want to. What's your use-case for this? Just do not have a hardcoded values. It is too easy to make a mistake in hardcoded value. -- Teodor Sigaev E-mail: teodor@sigaev.ru WWW: http://www.sigaev.ru/