#Ansi Codes from 'C'
23 messages in this thread
I would like to know how to exit ANSI text on a con: or cli window…
I've been trying 'printf("\0x9B0;33mTEST text…\0x9B0"); and it's
working but the compiler always gives me an error saying that the
Hexademical constant is t large for character..
Can anyone tell me what I'm doing wrong?? BTW, I've also tried ("\x1B0;33m
…. \x1B0\n"); but it doesn't seems to work and I've still got the same
erro. Thanks for any help. Rej
Ooops, forgot the m after the \x9B0. It's supposed to be \x9B0m. Rej
Rej,
The following program works fine and does what you want:
#include <stdio.h>
main (argc,arcv)
{
printf("\x1b[33mTesting…\x1b[31m\n");
exit();
}
Hope this helps, 8)
David
Thanks David, it's good to have an example (easier to assimilate). I'll
test it right away. Rej
The sequence \0x9b0 defines a 12bit integer; a character is only 8 bits,
which explains the error. Your compiler is giving you grief. I presume that
you are trying to send the console device control sequences. One
possibility is to embed char 9B in the source file at the right point (with
the obvious problem that the char will look funny, and you won't be able to
tell what it is). A second possibility would be to change your string to
look like this: "%c0;33…" supplying \0x9B for the %c arg. A third
possibility would be to use putchar() to send the \0x9b, followed by the
rest of the information.
Micheal, will try 'all' of these possibities! It's great to know that
there's more than one way to do it. Thank you for the information. REj
The sequence 0x9b0 _should_ translate to 0x9b30. A char is 7 bits. an
unsigned char is 8 bits, and the 0x9b will not fit in a char.
-larry
Sorry, a char is 8 bits, and an unsigned char is also 8 bits. The range of
the two is difference, but they have the same number of bits. And C
compilers will put in the unsigned bit pattern, even if it don't fit the
range i.e.
char c;
c = 255;
will put the bit pattern 1111 1111 into c, even though that's -1. The
reason the compiler is flagging it is that ANSI states that hex character
constants continue from the 'x' to the first non-hexadeciaml chracter.
Since 9b0 is greater than a character, in size, the compiler spits out a
warning message.
The way to split things up is to either use string concatenation, or to
make sure the hex constant isn't followed by something which could be
interpreted as a hexadecimal character.
-Mike
Mike,
Thanks for the correction. Funny, I fixed the very problem Rej was having
by changing char to UBYTE.
-larry
OOps…. I think I just realized why the UBYTE fixed the problem.. .I would
guess that the UBYTE scan of the string would be handled differently by the
compiler. Right? Wrong?
-larry
There is no such thing as a UBYTE string literals. Stuff between " and "
are always thought of as an array of chars. Casting it to a UBYTE *
shouldn't change the way the compiler works on escape sequences either. I
guess I don't quite follow what you're saying…could I see an example?
-Mike
Hmm… looked for the example I had, Mike, but can't find it. Will let you
know if I do, since I was sure I simply treated the CSI char as an unsigned
8 bit value in order to get around the problems.
-larry
MUCH better than my explanation!!!!!!!!!!
ThanksMike Haynie
(bought a Quantum; can't find any Quantum Mechanics…)
Well heck, C's what puts a roof over my head, so I'd better have some idea
of how it works :^)
-Mike
You are right, of course, given the assumption that hex constants are 8bits
only. The problem is that ANSI compatable compilers have to be prepared to
deal with 32bit (or is it word sized?) hex constants. (Note: in ANSI usage
hex constant is a name for _character_ constant…) If the compiler
implements this, they must be ready to read upto 8 hex characters for a
character constant. What I believe the compiler in question did was to see
the \x, begin to read a hex constant, read until a non hex digit appeared,
then complain about not being able to fit 12bits into an 8bit bag. If this
is the case, it is I think, a bug in the compiler, and an annoying one at
that.
As to a 7bit data type, I only know of 2 cases; signed and unsigned, both
are 8 bits. Both are represented as 32bits in registers, and 8bit bytes in
memory, the only difference being the interpretation of the high-order bit.
b.t.w; Which compiler are we talking about? (I missed that part if it was
mentioned).
Mike Haynie
(I could be wrong, but how can I tell?…)
Incidentally, hex character constants can pretty much go on to infinity
(well, there are some limits). ANSI didn't say 8 bits or 16 bits or 32
bits, they just said keep goin' till you hit something which isn't
hexadecimal. IMHO this is pretty messed up, as almost anybody ever using
hex char constants now has to use string concat or other tricks to get
around this 'feature'. If octal constants are already constrained to the
size of a char, I don't see why hex constants can't be (er, actually octal
is always 8bits I think).
-Mike
Mike,
Yes, to the best of my knowledge, octal constants are always 8 bits
and checking K&R (2nd Edition) the escape may be followed by 1, 2 or 3
octal digits (it doesn't say may *only* be followed, but that's implied).
However, when dealing with hex it states that there is no limit on the
number of digits, but the behavior is undefined if the resulting character
value exceeds that of the largest character.
Trying this little test in Lattice 5.05:
main()
{
printf("\0330\n");
printf("\x1b0\n");
}
generates a warning about a hex constant being too large for char
but generates no warning about the octal string. However, looking at the
output…both printf()s generate the same string of an escape followed by
the character "0" and a newline.
Don
Wow, that's what Lattice does? That looks wrong to me. If you consider
the hex constant to be '1b0' (which ANSI says is what it should be…),
then it should be chopped into 0xb0, with the 1 being thrown into the bit
bucket.
I suspect that Lattice is doing it the way most people would suspect, but
then threw in the warning to conform with ANSI. Well, ANSI does say the
result is 'implimentation defined', so I guess there method couldn't be
construed as wrong.
-Mike
The IQ of a committe is inversely proportional to the sum of the squares of
the IQ's of the individual members! ;->
Mike Haynie
(who wants to know?)
Another possibility: use string concatenation. Eg:
"\x9b""0 ….other garp"
If your hex sequence is gonna be followed by something that happens to be a
valid hexadecimal character, this is the easiest way to get around it.
-Mike
Rej,
I make it simple…I use octal rather than hex when it's embedded
in a string.
Don
Don, when I hear octal, somehow my head start spinning ;-<). Rej
Gee Rej, octal is great (for people who don't have any thumbs). 🙂
-larry