«

I encountered a problem after we had converted our declarations of
'unsigned short int' to uint16_t. In one instance, whoever did the
conversion failed to delete the 'short' keyword so we had a 'uint16_t
short'. The compiler (GNU 3.3.5) allows this but ignores the original
unsigned keyword and initialzes the variable as a signed short int. I
created a very simple test program just to see what was happening:

#include <stdio.h>

typedef unsigned short my_int16;

int main(int argc, char *argv[]) {

short s = -1;
unsigned short us = -1;
my_int16 my = -1;
my_int16 short mys = -1;

printf("%d, %d, %d, %d\n", s, us, my, mys);
return 0;
}


output is > -1, 65535, 65535, -1

So my "unsigned short short" has a value of -1. The compiler gives a
warning for the declaration of 'us' and 'my' since I'm initializing an
unsigned int to a negative value, but it has no problem with my
declaration of an 'unsigned short short'?

Should this be a warning/error? Why is this allowed?

steve

By the way, I quickly googled this error and I know that I'm not the
only one who has declared a uint16_t short, a few other people will
also see some odd behaviour if they're expecting an unsigned value.

wrote:
> I encountered a problem after we had converted our declarations of
> 'unsigned short int' to uint16_t. In one instance, whoever did the
> conversion failed to delete the 'short' keyword so we had a 'uint16_t
> short'. The compiler (GNU 3.3.5) allows this but ignores the original
> unsigned keyword and initialzes the variable as a signed short int. I
> created a very simple test program just to see what was happening:

It's technically ill-formed code. Unlike redundant const/volatile via
a typedef, there isn't such a thing for short.

>
> So my "unsigned short short" has a value of -1. The compiler gives a
> warning for the declaration of 'us' and 'my' since I'm initializing an
> unsigned int to a negative value,

Initialializing an unsigned with -1 is valid however.

Ron Natalie posted:

> Unlike redundant const/volatile via a typedef, there isn't such a thing
> for short.

Please elaborate on that. The "const" in the following typedef is certainly
not redundant.

typedef int const cint;

int main()
{
cint i = 7;

i = 4; /* Opps! */
}

Nor is the "volatile" in the following typedef:

typedef int volatile vint;

int main()
{
vint i = 7;

int *p = &i; /* Opps! */
}

--

Frederick Gotham

Frederick Gotham wrote:
> Ron Natalie posted:
>
>> Unlike redundant const/volatile via a typedef, there isn't such a thing
>> for short.
>
> Please elaborate on that. The "const" in the following typedef is certainly
> not redundant.

I'm talking about the following:

int const const foo; // ILL-FORMED
typedef int const cint;
const cint goo; // LEGAL, the redundant const
// from the typedef is allowed.
short short int foo; // ILL-FORMED
typedef short int sint;
short sint foo; // ILL-FORMED, no exemption for repeated
// short like there is for const

wrote:
> Should this be a warning/error? Why is this allowed?

You didn't tell your tool to behave like an ANSI/ISO conforming
implementation of C++.

Most C and C++ compilers enable their extensions by default. This means
that they can misinterpret or even reject some strictly conforming
programs, and fail to diagnose programs which require a diagnostic.

For any compiler you happen to be using, it behooves you to find out
how to make it behave in a conforming way.

With gcc, there are two flags for this: -ansi to disable the
non-conforming extensions, and -pedantic to request all required
diagnostics.

I have an installation of GCC 3.4.3 here.

The C front end, even without -ansi or -pedantic, diagnoses "uint16_t
short x" with this message:

error: long, short, signed or unsigned used invalidly for `x'

The C++ front end from 3.4.3, however, is silent, unless given
-pedantic, in which case it yields the same message.