Newsgroup: comp.lang.c++
Subject: Testing C include file for C++ compatibility without a C++ caller?
From: mathog <dmathog@...>
Date: Thu, 17 Oct 2013 10:09:54 -0700
I have a C package that until recently was callable by C++ programs
without generating warnings. Everything is properly wrapped up in
#ifdef __cplusplus
extern "C" {
#endif
which I always assumed precluded the possibility of a cleanly compiling
C module throwing warnings and errors when compiled by a C++ compiler.
However, recent versions of g++ throw warnings like this when some C++
modules include AND use one of the include files in the package:
../../src/extension/internal/metafile-print.cpp:132:13: warning:
narrowing conversion of ((color >> 16) & 255u) from uint32_t
{aka unsigned int} to uint8_t {aka unsigned char} inside { } is
ill-formed in C++11 [-Wnarrowing]
These trace back to this line in the include file:
#define U_RGBA(r,g,b,a) (U_COLORREF){r,g,b,a}
which must be changed to this to eliminate the warning:
#define U_RGBA(r,g,b,a)
(U_COLORREF){(uint8_t)(r), (uint8_t)(g), (uint8_t)(b), (uint8_t)(a)}
Where U_COLORREF is defined earlier in that include file as:
typedef struct {
uint8_t Red; //!< Red color (0-255)
uint8_t Green; //!< Green color (0-255)
uint8_t Blue; //!< Blue color (0-255)
uint8_t Reserved; //!< Not used
} U_COLORREF, *PU_COLORREF;
The problem is that so far the warning only shows up when the U_RGBA is
actually USED in a C++ module, apparently with a 4 byte unsigned
(holding a value in the range 0-255) employed as one of the color values.
I have the c++ compiler line that when applied to the cpp file generates
the error message, but when run exactly the same way, but just on the
include file, like:
g++ .... -c include.h
there are no warnings.
Is it possible to test for this sort of issue using just the C++
compiler and the include file? (Using gcc or g++).
Thank you,
David Mathog
Subject: Testing C include file for C++ compatibility without a C++ caller?
From: mathog <dmathog@...>
Date: Thu, 17 Oct 2013 10:09:54 -0700
I have a C package that until recently was callable by C++ programs
without generating warnings. Everything is properly wrapped up in
#ifdef __cplusplus
extern "C" {
#endif
which I always assumed precluded the possibility of a cleanly compiling
C module throwing warnings and errors when compiled by a C++ compiler.
However, recent versions of g++ throw warnings like this when some C++
modules include AND use one of the include files in the package:
../../src/extension/internal/metafile-print.cpp:132:13: warning:
narrowing conversion of ((color >> 16) & 255u) from uint32_t
{aka unsigned int} to uint8_t {aka unsigned char} inside { } is
ill-formed in C++11 [-Wnarrowing]
These trace back to this line in the include file:
#define U_RGBA(r,g,b,a) (U_COLORREF){r,g,b,a}
which must be changed to this to eliminate the warning:
#define U_RGBA(r,g,b,a)
(U_COLORREF){(uint8_t)(r), (uint8_t)(g), (uint8_t)(b), (uint8_t)(a)}
Where U_COLORREF is defined earlier in that include file as:
typedef struct {
uint8_t Red; //!< Red color (0-255)
uint8_t Green; //!< Green color (0-255)
uint8_t Blue; //!< Blue color (0-255)
uint8_t Reserved; //!< Not used
} U_COLORREF, *PU_COLORREF;
The problem is that so far the warning only shows up when the U_RGBA is
actually USED in a C++ module, apparently with a 4 byte unsigned
(holding a value in the range 0-255) employed as one of the color values.
I have the c++ compiler line that when applied to the cpp file generates
the error message, but when run exactly the same way, but just on the
include file, like:
g++ .... -c include.h
there are no warnings.
Is it possible to test for this sort of issue using just the C++
compiler and the include file? (Using gcc or g++).
Thank you,
David Mathog
via Usenet Forums - Usenet Search,Free Usenet - comp.lang.c++ http://www.pocketbinaries.com/usenet-forums/showthread.php?110225-Testing-C-include-file-for-C-compatibility-without-a-C-caller&goto=newpost
View all the progranning help forums at:
http://www.pocketbinaries.com/usenet-forums/forumdisplay.php?128-Coding-forums
No comments:
Post a Comment