a question

This was asked to me in an interview. I am wondering how many of you know this

What is the type of the addition of an unsigned and a signed integer in C?

I don't know.

Signed, probably. But I don't really know.

>>1
Whatever you cast it to afterwards because typing in C is little more than a comment.

6.3.1.8 Usual arithmetic conversions
from the C99 standard
Unsigned if it's unsigned int and int (same rank)
Signed if it's unsigned short int and int (int can represent all values of unsigned short int)
FUCK WHY THE FUCK IS THIS WRITTEN IN A FUCKCONFUZZLING MANNER

What sort of interview was this for?
I mean, abuse of implicit signed/unsigned conversions is bad mojo if there ever was one.

>>5
(unsigned-addable? (OR unsigned-int int)))
#t

(signed-addable? (OR unsigned-short int))
#t

[quote]
712 If both operands have the same type, then no further conversion is needed.

713 Otherwise, if both operands have signed integer types or both have unsigned integer types, the operand with the type of lesser integer conversion rank is converted to the type of the operand with greater rank.

714 Otherwise, if the operand that has unsigned integer type has rank greater or equal to the rank of the type of the other operand, then the operand with signed integer type is converted to the type of the operand with unsigned integer type.

715 Otherwise, if the type of the operand with signed integer type can represent all of the values of the type of the operand with unsigned integer type, then the operand with unsigned integer type is converted to the type of the operand with signed integer type.

716 Otherwise, both operands are converted to the unsigned integer type corresponding to the type of the operand with signed integer type.
[/quote]
'Otherwise' everywhere. English is now a programming language and 'Otherwise' is else if.

Otherwise, you may hax my anus.

>the operand with signed integer type is converted to the type of the operand with unsigned integer type.
How do you convert a negative to an unsigned int?

>>10
By the power of the undefined behaviour.

>>1

Assuming same rank, unsigned integer.

>>10

Put shortly, the effect is the same as if it occurred an underflow in the (unsigned) value, as if the (signed) negative value was represented in two-complement and then interpreted as an unsigned value.

For example, -1 converted to unsigned short yields 65535.

These conversions/underflows/overflows are well-defined. Signed underflows and overflows, on the other hand, are not.

>>6
a job interview. the job is embedded programming. they asked things like how do you define an array of function pointers in C, what is wrong with following macro, find the problem in that interrupt code etc. pretty specific stuff

>>13

What was the problem with the interrupt code, if you don't mind me asking?

>>14
I am still not sure, it was a simple code with a printf in it. I couldn't find anything wrong with it. I guessed that printf is probably are not developped with interrupts or multi threading in mind and it may cause errors. For example if it works in a critical section guarded by mutexes, it could go into a deadlock if it interrupts while printing another thing

>>13
Array of function pointers in C.. Do you need to have at least the parameters properly typed? I mean, if you want different kind of functions, you can't throw a "int (*f)()" to a "int (*f)(int)" can you? But maybe you can throw the return type?

>>15

yeah I would guess that it would be the presence of the printf. You want routines handling interrupts to execute and finish as quickly as possible I believe, and doing io in the middle of one probably isn't such a great idea.

>>16
function type was int f(int)

>>16
well, they are both pointers, so you can assign whatever you want in there as long as you cast it. But if you are going to call the function, you better make sure that the type of the pointer matches the type of the function it points to. That would be difficult to manage for an array of function pointers, so it is best to ensure they all have the same argument and return types, or at least have a consistent association between indeces and function types.

>>19
That's what I was going for, thanks.

>>20

yeah, if you are going to store pointers to functions that have varrying call signatures or return types, then you might want to use a structure instead:


struct my_awesome_function_table {
  void (*blah)(int x);
  void (*meep)(int k, int f, char e);
  void (*meta)(struct my_awesome_function_table* this, void* userdata);
};

But if you wanted to store them in an array, you could use an array of void pointers, and cast the pointer when you call the function it points to


int dicks(int c, char k) {
}
  return (c & k) | (c & (k<<2));

int f() {
  void* fn = dicks;
  int c = ((int(*)(int,char))fn)(56, 'a');
  return c;
}

damn they really wanted C wizards for that job. who else would know that type conversion arcana without looking it up?

>>22
Anyone mildly competent with the C language. Asking people how to declare an array of function pointers is fucking stupid though, it's syntax and not semantics and should not be of interest to any interviewer.

Even I can't remember that shit without looking it up:
void (*f[10])(); ?

>>21
you could use an array of void pointers
In POSIX, you can, but in ISO C, casting between pointers to function and pointers to object (or void) is undefined. This is because C supports non von Neumann architectures such as Harvard architectures or FPGAs where code is either stored in a separate space, as an array of logic tables and connections, or other formats.

>>23
void (*f[10])(); ?
Yes.
f is:
1. an array of 10 (f[10])
2. pointers (*f[10])
3. to function ((*f[10])())
4. returning void (void (*f[10])()).

the other questions seem okay,
but srsly, who does (unsigned int + int) addition?
I would probably anwser that I don't know, since you shouldn't really do that, or that you should use a larger signed int type to store the results lololol.

>>25
yeah, I didn't know either. But question was implying it is unsigned and I said that.