Placing extended ASCII characters in a string literal.

[zhiayang]

Help! I've recently decided to rewrite my entire shell app code, so everything is not hardcoded and uses function pointers instead. (Do tell if it's a good idea). Now I have a problem.

I used to have a system where commands were stored in an array, one for the string the user types and one for the function pointer. The new system uses a bunch of structs storing information about that particular command, including the typed name, the pointer and some other stuff.

Now there was a bit of funny code in the old version. (trolling stuff)

>help -t
>Is this helping?
>no
>Touché (touche)

I decided to bring it back; this time I wanted every command to have the ability to respond to the next input, so I added 2 more definitions in the structure:

char *troll_trigger and
char *troll_response

Now it works perfect, however I need to put that 'é' into the response. When I paste that 'é' into XCode, it comes out as some gibberish. I used to be able to use my kprintf function and cast 130 into a char, however I cannot do that now. Help?

PS: I have that va_list thing for kprintf, however when I use va_arg(listptr, char), gcc tells me that "note: if this code is reached, the program will abort". I had to use int. Any explanation?


PPS: Also, is there a way to deactivate the RTC periodic interrupt after I enable it?

Many thanks.

[bluemoon]

XCode > preference > Text Editing > Default Text Encoding, or use \000 representation

[zhiayang]

XCode > preference > Text Editing > Default Text Encoding, or use \000 representation

Thanks, although that didn't work. I did however use \x82 and it worked. But what about the secondary questions, and is using function pointers a good idea?

[bluemoon]

For implementing features using function pointer, I think it's just a matter of preference, or design choice.
Every solution is good if it worked.

PS. I would do it this way:

1. Have a lexical parser that split a statement into blocks divided by spaces, and support quotes, etc
2. Have a dictionary that translate command into operation code, if not internally support code it default to execute external program
3. call do_operation[opcode](int argc, char* argv[]);, where argv[0] is the command, argv[1] is first parameter, etc

[gerryg400]

PS: I have that va_list thing for kprintf, however when I use va_arg(listptr, char), gcc tells me that "note: if this code is reached, the program will abort". I had to use int. Any explanation?

You have to do this

Code: Select all

char c = (char)va_arg(ap, int)

The c standard says that default argument promotion applies to all arguments passed through ellipses. This means that char, short (because they are promoted to int) and float (because it's promoted to double) are illegal.

[zhiayang]

For implementing features using function pointer, I think it's just a matter of preference, or design choice.
Every solution is good if it worked.

PS. I would do it this way:

1. Have a lexical parser that split a statement into blocks divided by spaces, and support quotes, etc
2. Have a dictionary that translate command into operation code, if not internally support code it default to execute external program
3. call do_operation[opcode](int argc, char* argv[]);, where argv[0] is the command, argv[1] is first parameter, etc

Right. The dictionary thing was my previous approach, but I found it troublesome. Although that was partially because of messy code. Also, thanks for mentioning the quotes, I didn't think of them.

You have to do this
Code:
char c = (char)va_arg(ap, int)
The c standard says that default argument promotion applies to all arguments passed through ellipses. This means that char, short (because they are promoted to int) and float (because it's promoted to double) are illegal.

That's slightly unfriendly... What are the ramifications of leaving it as an int?

[gerryg400]

You have to do this
Code:
char c = (char)va_arg(ap, int)
The c standard says that default argument promotion applies to all arguments passed through ellipses. This means that char, short (because they are promoted to int) and float (because it's promoted to double) are illegal.

That's slightly unfriendly... What are the ramifications of leaving it as an int?

Leaving what as an int ?

[zhiayang]

Leaving what as an int ?

The va_arg(char) thing.

[bluemoon]

If there is no actual next argument, or if type is not compatible with the type of the actual next argument (as promoted according to the default argument promotions), the behavior is undefined, except for the following cases:
One type is a signed integer type, the other type is the corresponding unsigned integer type, and the value is representable in both types.
One type is a pointer to void and the other is a pointer to a character type.
[XSI] Both types are pointers.

Imagine this,

Code: Select all

int foo(int a, ...);
char c = 'a';
int result = foo(1, c);

The 'a' get default promotion into int, so when you fetch it by va_arg(va, char) the type does not match, and thus undefined behavior.

[invalid]

(trolling stuff)

CleverbotOS?

>delete foo.txt
>No, I like that file.
>oh please!
>I'll move it /tmp/lovefoo, ok?
>abort! abort!
>You don't mind talking about it, do you, Dave?

[qw]

>delete foo.txt
>No, I like that file.
>oh please!
>I'll move it /tmp/lovefoo, ok?
>abort! abort!

This gives me the exact same feeling as working on an iPad...