Re: reporting typedef errors automatically

Roman Mashak <mrv@xxxxxxxx> wrote:
Hello, Jens!
You wrote on 29 May 2008 20:54:28 GMT:

[skip]
JTT> I guess it's meant to provoke the compiler to emit an error
JTT> message (or at least a warning) in the case that int8_ta and
JTT> uint8_t don't have a size of 1, int8_t/uint8_t don't have a
JTT> size of 2 etc. since in that case e.g. 'sizeof( int8_t ) == 1'
JTT> woukd be false and thus result in the value 0. And then you
JTT> would try to create an array of length 0 which isn't legal.

I integrated the above code in the test example and compiled it twice with
'gcc -W -Wall -std=c99...' and 'gcc -W -Wall -std=c89...'. No error was
emmited in the second case. Should it have been?

That then probably means that on your system an int8_t/uint8_t
has a size of of 1, and int16_t/uint16_t has a size of 2 etc.
And, no it also shouldn't emit an error message for the C89
case since in order to compile it even in C99 mode you must
have included <stdint.h> (or some other header file that
automatically includes <stdint.h>)- in that header file the
types (int8_t,...) are defined. And if they are defined in
that header file and that header file exists and is included,
then they are defined regardless if you compile in C89 or
C99 mode.

After having had a look at the article you got that from it
is clearer what this is all about. Before C99 the existence
of a header file named <stdint.h> wasn't required and so all
these types weren't required to be defined. Thus some people
would do it themselves with typedefs like this

typedef signed char int8_t;
typedef unsigned char uint8_t;
typedef short int int16_t;
typedef unsigned short int uint16_t;
typedef int int32_t;
typedef unsigned int uint32_t;

But this would break on a system where e.g. an int has only 16
and not 32 bits. So the whole thing proposed in that article was
meant as a check if the assumptions made when creating these
typedefs were correct for the machine you are compiling it on.
But if you have a <stdint.h> header file coming with your system
it's rather useless (unless you're paranoid if the implementation
you are using got it really right;-) to do these kind of checks,
they should always succeed.
Regards, Jens
--
\ Jens Thoms Toerring ___ jt@xxxxxxxxxxx
\__________________________ http://toerring.de
.

Relevant Pages

  • Re: managing header files
    ... hundred by commenting out some external declarations, ... complaints) but the complaints about redundant declarations and the complaints ... to simplify the problem I decided to just try to compile ... approach of, in effect, finding one header file that all the .c files ...
    (comp.lang.c.moderated)
  • Re: Converting .lib to .dll
    ... Adding the header file to the project does nothing. ... a DLL file. ... EXPORT_SETTING int VP_DoWhatever(int parameter1, int parameter2) ... And when you compile this, ...
    (microsoft.public.dotnet.framework.compactframework)
  • Re: Parse errors
    ... Your code, shown in the previous message, will not compile with either ... NULL (which clearly indicates that it is a pointer). ... in it appropriate to a header file! ... you need prototypes for all of the functions defined in this ...
    (comp.os.linux.development.apps)
  • Re: function prototypes
    ... > the prototype and the procedure will actually agree. ... same header file in the implementation (which C ... as the header declarations can ... and compile stubs earlier than you might want, ...
    (comp.lang.fortran)
Loading