Determining the 'type' of a variable, if only its name is given

Hi, is it possible, to determine the 'type' of a variable, if only its name is given. With 'type', I don't mean the exact type, such as enum, but instead the following information: a) sizeof b) signed or unsigned a) ... is always easy to determine: sizeof(var) !! b) ... is - as far as I know - only easy to determine, if sizeof(var) >= sizeof(int) Here are the macros I use: #define WIDTH_GE_INT(EXPR) (sizeof(EXPR) >= sizeof(int)) #define EXPR_OR_VAR_IS_SIGNED(EXPR) (WIDTH_GE_INT(EXPR) \ ? P99_SIGNED(EXPR) \ : /* EXPR is a variable */ /* GCC extension - "statement expressions" */ ({int _temp; int _is_signed; _temp = EXPR , \ _is_signed = (!((EXPR = -1) > 0)) , \ EXPR = _temp , \ _is_signed;})) Get Jens Gustedt's fantastic P99_SIGNED macro here: http://p99.gforge.inria.fr/p99-html/group__integers_ga3eb39ccac28ebd8265c1a31dc00f53ab.html As you can see above, if sizeof(var) < sizeof(int), I actually have to access the variable in order to determine if it is signed or unsigned. I really do not like this. Is there any other way, to determine if a variable var is signed or unsigned, if sizeof(var) < sizeof(int) ??? Thanks. J. PS: Is it possible, to write the above macros in standard C, without using gcc's extension of "statement expressions"

Ahhh! Here's a rewrite of the previous post, with BETTER FORMATTING: Hi, is it possible, to determine the 'type' of a variable, if only its name is given. With 'type', I don't mean the exact type, such as enum, but instead the following information: a) sizeof b) signed or unsigned a) ... is always easy to determine: sizeof(var) !! b) ... is - as far as I know - only easy to determine, if sizeof(var)>= sizeof(int) Here are the macros I use: #define WIDTH_GE_INT(EXPR) (sizeof(EXPR) >= sizeof(int)) #define EXPR_OR_VAR_IS_SIGNED(EXPR) \ (WIDTH_GE_INT(EXPR) \ ? P99_SIGNED(EXPR) \ : /* EXPR is a variable */ \ /* GCC extension - "statement expressions" */ \ ({int _temp; int _is_signed; \ _temp = EXPR , \ _is_signed = (!((EXPR = -1) > 0)) , \ EXPR = _temp , \ _is_signed;})) Get Jens Gustedt's fantastic P99_SIGNED macro here: http://p99.gforge.inria.fr/p99-html/group__integers_ga3eb39ccac28ebd8... As you can see above, if sizeof(var) < sizeof(int), I actually have to access the variable in order to determine if it is signed or unsigned. I really do not like this. Is there any other way, to determine if a variable var is signed or unsigned, if sizeof(var) < sizeof(int) ??? Thanks. J. PS: Is it possible, to write the above macros in standard C, without using gcc's extension of "statement expressions"

On 06/15/2012 04:51 AM, John Reye wrote: .... > Get Jens Gustedt's fantastic P99_SIGNED macro here: > http://p99.gforge.inria.fr/p99-html/group__integers_ga3eb39ccac28ebd8... That link doesn't work for me. -- James Kuyper

John Reye wrote: > http://p99.gforge.inria.fr/p99-html/group__integers_ga3eb39ccac28ebd8... It works better with my webrowser, if instead I use this URL: http://p99.gforge.inria.fr/p99-html/group__integers.html -- pete

"James Kuyper" <jameskuyper@verizon.net> wrote in message news:jrf95p$2dt$1@dont-email.me... > On 06/15/2012 04:51 AM, John Reye wrote: > ... >> Get Jens Gustedt's fantastic P99_SIGNED macro here: >> http://p99.gforge.inria.fr/p99-html/group__integers_ga3eb39ccac28ebd8... > > That link doesn't work for me. Try the one in the original post. (Ie. http://p99.gforge.inria.fr/p99-html/group__integers_ga3eb39ccac28ebd8265c1a31dc00f53ab.html) -- bartc

Am 15.06.2012 10:51, schrieb John Reye: > is it possible, to determine the 'type' of a variable, if only its > name is given. [snip things about oldish C99] > Is there any other way, to determine if a variable var is signed or > unsigned, if sizeof(var) < sizeof(int) ??? with C11's _Generic you may do that, provided your implementation hasn't extended integer types that are narrower than int, you can do something horrible like _Generic(var, default: use_the_previous_method(var), char: (CHAR_MAX < UCHAR_MAX), char const: (CHAR_MAX < UCHAR_MAX), char volatile: (CHAR_MAX < UCHAR_MAX), char const volatile: (CHAR_MAX < UCHAR_MAX), char _Atomic: (CHAR_MAX < UCHAR_MAX), char const _Atomic: (CHAR_MAX < UCHAR_MAX), char volatile _Atomic: (CHAR_MAX < UCHAR_MAX), char const volatile _Atomic: (CHAR_MAX < UCHAR_MAX), _Bool: 0, _Bool const: 0, _Bool volatile: 0, _Bool const volatile: 0, _Bool _Atomic: 0, _Bool const _Atomic: 0, _Bool volatile _Atomic: 0, _Bool const volatile _Atomic: 0, signed char: 1, signed short: 1, signed char const: 1, signed short const: 1, signed char volatile: 1, signed short volatile: 1, signed char const volatile: 1, signed short const volatile: 1, signed char _Atomic: 1, signed short _Atomic: 1, signed char const _Atomic: 1, signed short const _Atomic: 1, signed char volatile _Atomic: 1, signed short volatile _Atomic: 1, signed char const volatile _Atomic: 1, signed short const volatile _Atomic: 1, unsigned char: 0, unsigned short: 0, unsigned char const: 0, unsigned short const: 0, unsigned char volatile: 0, unsigned short volatile: 0, unsigned char const volatile: 0, unsigned short const volatile: 0, unsigned char _Atomic: 0, unsigned short _Atomic: 0, unsigned char const _Atomic: 0, unsigned short const _Atomic: 0, unsigned char volatile _Atomic: 0, unsigned short volatile _Atomic: 0, unsigned char const volatile _Atomic: 0, unsigned short const volatile _Atomic: 0 ) - the case for "char" works since "unsigned char" can't have padding bits - _Bool is unsigned per definition - then for all cases you have to distinguish all qualified types. at least as quickly I didn't come up with an idea that would force an conversion to an rvalue such that it would drop all qualifiers, and wouldn't promote to the rank of "int" Jens

James Kuyper wrote: > John Reye wrote: > >> Get Jens Gustedt's fantastic P99_SIGNED macro here: >> http://p99.gforge.inria.fr/p99-html/group__integers_ga3eb39ccac28ebd8... > > That link doesn't work for me. Google "helpfully" truncates URLs. Neat, uh?

On 06/16/12 02:37 AM, Jens Gustedt wrote: > Am 15.06.2012 10:51, schrieb John Reye: >> is it possible, to determine the 'type' of a variable, if only its >> name is given. > > [snip things about oldish C99] > >> Is there any other way, to determine if a variable var is signed or >> unsigned, if sizeof(var)< sizeof(int) ??? > > with C11's _Generic you may do that, provided your implementation > hasn't extended integer types that are narrower than int, > > you can do something horrible like > <snip something horrible> > > > - the case for "char" works since "unsigned char" can't have padding > bits > - _Bool is unsigned per definition > - then for all cases you have to distinguish all qualified types. at > least as quickly I didn't come up with an idea that would force an > conversion to an rvalue such that it would drop all qualifiers, and > wouldn't promote to the rank of "int" This could go in a header somewhere: it's similar to C++'s use of the numeric_limits template. -- Ian Collins

Am 15.06.2012 23:27, schrieb Ian Collins: > On 06/16/12 02:37 AM, Jens Gustedt wrote: >> Am 15.06.2012 10:51, schrieb John Reye: >> with C11's _Generic you may do that, provided your implementation >> hasn't extended integer types that are narrower than int, >> >> you can do something horrible like >> > <snip something horrible> > > This could go in a header somewhere: sure it should, I think nobody ever considered using _Generic directly in user code. The committee didn't even bother to provide a standard "renaming" macro for it, like "bool" for "_Bool" or "alignas" for "_Alignas". > it's similar to C++'s use of the numeric_limits template. generally speaken, _Generic in many places can be used where in C++ there would be a template, yes. And now that we have it in the language effectively one could think of phasing out all these individual MIN/MAX macros by just one for each purpose. I'll work on that. Jens

John Reye <jononanon@googlemail.com> writes: > Ahhh! > > Here's a rewrite of the previous post, with BETTER FORMATTING: > > > > > Hi, > > is it possible, to determine the 'type' of a variable, if only its > name is given. > > With 'type', I don't mean the exact type, such as enum, but instead > the following information: > a) sizeof > b) signed or unsigned > > a) ... is always easy to determine: sizeof(var) !! Two problems with sizeof: one, the size of a type is not guaranteed to correlate with the range of a type; and two, sizeof doesn't work on bitfield variables. > b) ... is - as far as I know - only easy to determine, > if sizeof(var)>= sizeof(int) Only if the integer conversion rank of (var) is at least as big as the integer conversion rank of (int), which is not the same thing. > Here are the macros I use: > #define WIDTH_GE_INT(EXPR) (sizeof(EXPR) >= sizeof(int)) > > #define EXPR_OR_VAR_IS_SIGNED(EXPR) \ > (WIDTH_GE_INT(EXPR) \ > ? P99_SIGNED(EXPR) \ > : /* EXPR is a variable */ \ > /* GCC extension - "statement expressions" */ \ > ({int _temp; int _is_signed; \ > _temp = EXPR , \ > _is_signed = (!((EXPR = -1) > 0)) , \ > EXPR = _temp , \ > _is_signed;})) > > Get Jens Gustedt's fantastic P99_SIGNED macro here: > http://p99.gforge.inria.fr/p99-html/group__integers_ga3eb39ccac28ebd8... > > As you can see above, if sizeof(var) < sizeof(int), I actually have to > access the variable in order to determine if it is signed or unsigned. > I really do not like this. > > Is there any other way, to determine if a variable var is signed or > unsigned, if sizeof(var) < sizeof(int) ??? > > Thanks. > J. > > PS: Is it possible, to write the above macros in standard C, without > using gcc's extension of "statement expressions" I believe it is not.

Jens Gustedt <jens.gustedt@loria.fr> writes: > Am 15.06.2012 10:51, schrieb John Reye: >> is it possible, to determine the 'type' of a variable, if only its >> name is given. > > [snip things about oldish C99] > >> Is there any other way, to determine if a variable var is signed or >> unsigned, if sizeof(var) < sizeof(int) ??? > > with C11's _Generic you may do that, provided your implementation > hasn't extended integer types that are narrower than int, > > you can do something horrible like > > _Generic(var, > default: use_the_previous_method(var), > > char: (CHAR_MAX < UCHAR_MAX), > char const: (CHAR_MAX < UCHAR_MAX), > [snip remainder] In most cases I expect this approach will work fine, but unfortunately it doesn't always, specifically for bitfields. Btw, the many redundant parentheses are, well, redundant.

Hi Am 23.06.2012 05:42, schrieb Tim Rentsch: > Jens Gustedt <jens.gustedt@loria.fr> writes: > >> with C11's _Generic you may do that, provided your implementation >> hasn't extended integer types that are narrower than int, >> >> you can do something horrible like >> >> _Generic(var, >> default: use_the_previous_method(var), >> >> char: (CHAR_MAX < UCHAR_MAX), >> char const: (CHAR_MAX < UCHAR_MAX), >> [snip remainder] > > In most cases I expect this approach will work fine, but unfortunately > it doesn't always, It did some more experiments with this and actually found that the handling of qualified types is not very well designed with this new _Generic tool. In the case it was asked here (for a variable, i.e an lvalue) it seems consistent, but for rvalues it is completely underspecified. I'll post a question comp.std.c about this > specifically for bitfields. the signedness of bitfields is really a special case oddity. What should _Generic trigger, here. The declared type or the effective type? A bitfield that is declared with just "int" could (implementation defined) well be unsigned in nature. To the extreme on a system with 32 bit wide "int", a bit field with specification "int a:32" could be unsigned. > Btw, the many redundant parentheses are, well, redundant. but not superficial coding styles vary, as you probably know Jens

Jens Gustedt <jens.gustedt@loria.fr> writes: > Hi > > Am 23.06.2012 05:42, schrieb Tim Rentsch: >> Jens Gustedt <jens.gustedt@loria.fr> writes: >> >>> with C11's _Generic you may do that, provided your implementation >>> hasn't extended integer types that are narrower than int, >>> >>> you can do something horrible like >>> >>> _Generic(var, >>> default: use_the_previous_method(var), >>> >>> char: (CHAR_MAX < UCHAR_MAX), >>> char const: (CHAR_MAX < UCHAR_MAX), >>> [snip remainder] >> >> In most cases I expect this approach will work fine, but unfortunately >> it doesn't always, > > It did some more experiments with this and actually found that the > handling of qualified types is not very well designed with this new > _Generic tool. In the case it was asked here (for a variable, i.e an > lvalue) it seems consistent, but for rvalues it is completely > underspecified. > > I'll post a question comp.std.c about this Okay, I'll look over at that. >> specifically for bitfields. > > the signedness of bitfields is really a special case oddity. What > should _Generic trigger, here. The declared type or the effective > type? Good question! I wonder if the Standard says, or if a DR should be filed for that? > A bitfield that is declared with just "int" could (implementation > defined) well be unsigned in nature. To the extreme on a system with > 32 bit wide "int", a bit field with specification "int a:32" could be > unsigned. Not just could be but would be, on a system where 'int' means unsigned int for bitfields. My point about bitfields (which was a bit off the mark for the particular context here, but oh well) is that using _Generic for bitfields gives misleading results as regards their behavior under integer promotion rules (ie, a bitfield declared as 'unsigned x:3' will show up as unsigned int but will promote to an int). More confusingly, a bitfield is an lvalue but cannot have its address taken. It would be nice if these distinctions could be handled under _Generic, but alas they cannot. >> Btw, the many redundant parentheses are, well, redundant. > > but not superficial > > coding styles vary, as you probably know My comment was only about the redundancy, not about style. However, on the issue of style, IME style rules that promote using redundant parentheses almost always do more harm than good. I don't see any added value in using parentheses as they were in the example above. Conversely, I do see a big negative, in that people unfamiliar with the new _Generic construct might come away with the mistaken impression that those parentheses are required. The reason for my comment was to correct any such mistaken conclusions.

On 6/15/2012 10:02 AM, Noob wrote: > James Kuyper wrote: > >> John Reye wrote: >> >>> Get Jens Gustedt's fantastic P99_SIGNED macro here: >>> http://p99.gforge.inria.fr/p99-html/group__integers_ga3eb39ccac28ebd8... >> >> That link doesn't work for me. > > Google "helpfully" truncates URLs. Neat, uh? Somewhat helpful for Google Groups users. Not helpful for the rest of Usenet, since they don't convert their own messages containing URLs to NNTP format correctly for long URLs.