need to convert a char to an hexadecmial value

[Mark McIntyre]

potato, potato.

More like potatoe, potato, Mr Vice President.

Mark McIntyre

 

[Rod Pemberton]

(e-mail address removed) wrote:

[snip!]
Martin, _fix_ your quoting. You merged your reply with to Santosh's
unquoted statements. You're missing Santosh's message header.

Martin Ambuhl's post is a direct answer to the OP as can
be seen from the message headers. santosh was never in
between here. You probably mixed that up with another
subthread.

Sorry, it appears there is something wrong with the server I'm connected to.
I'll start cross checking with another for a while.

 

[santosh]

Hi,
I needed help in converting a character to the correspoding
hexadecimal values, like the following example,
ASCII value : ABC
Hex Code Value : %41%42%43...

whats the logic of conversion...

#include <stdio.h>
#include <stdlib.h>

int main(void) {
char arr[3] = { 'A', 'B', 'C' };
short cnt;

for(cnt = 0; cnt < 3; cnt++)
printf("%%%x ", arr[cnt]);

fflush(stdout);
return 0;
}

You don't use anything from <stdlib.h>.

I thought, obviously wrongly, that fflush() was declared in stdlib.h

That prints the hexadecimal values rather than converting them, but
the original problem statement wasn't very clear so it's probably ok.
(Converting to a string would require some moderately complex memory
management.)

And I felt that an array based example would be simpler to understand
for the OP.

For characters with values less than 16, you print a single digit,
e.g., "%f" rather than "%f". Again, the problem statement wasn't
clear on this point.

You print a spaces between the characters, which is inconsistent with
the example.

Yes, I hope the OP can forgive me, modify it as necessary.

Why do you use type short for the array index? It typically saves
only an insigificant amount of data space, and the resulting code
could be larger and slower on many systems. Just use int.
Okay.

The "%x" format expects an unsigned int; you're giving it a char.
It's likely to work anyway, but it could cause problems -- and proving
that it does what you want is a lot more work than just fixing the
code. This is one of those rare cases where a cast is actually
appropriate.

Alternatively, the array could have been declared as unsigned int,
though that would be gratituous waste of memory.

3 is a magic number (not a huge deal in a snippet like this).

Yes. Should have coded it cleaner.

The output isn't terminated by a new-line, so it's not guaranteed to
appear even with the fflush(stdout) (and the standard is unclear on
just what can go wrong).

I was thus far under the impression that fflush(stdout) was equivalent,
(in terms of writing buffered output), to a newline character. If
fflush(stdout) is not guaranteed to do it's job, then why define it,
atleast for stdout?

#include <stdio.h>
int main(void)
{
char arr[3] = { 'A', 'B', 'C' };
const int arr_len = sizeof(arr) / sizeof(arr[0]);
int i;

for (i = 0; i < arr_len; i++) {
printf("%%%02x", (unsigned int)arr);
}
putchar('\n');
return 0;
}

Thanks for this improvement.

 

[Keith Thompson]

Keith Thompson wrote: [...]

The output isn't terminated by a new-line, so it's not guaranteed to
appear even with the fflush(stdout) (and the standard is unclear on
just what can go wrong).

I was thus far under the impression that fflush(stdout) was equivalent,
(in terms of writing buffered output), to a newline character. If
fflush(stdout) is not guaranteed to do it's job, then why define it,
atleast for stdout?

Here's what the standard says:

A text stream is an ordered sequence of characters composed into
lines, each line consisting of zero or more characters plus a
terminating new-line character. Whether the last line requires a
terminating new-line character is implementation-defined.

And here's the description of fflush():

If stream points to an output stream or an update stream in which
the most recent operation was not input, the fflush function
causes any unwritten data for that stream to be delivered to the
host environment to be written to the file; otherwise, the
behavior is undefined.

fflush() will cause a partial line to be written to the output file
(or at least "the host environment to be written to the file", which
may not be the same thing), but if the file is then closed without a
new-line, you could still have an ill-formed text file.

Closing a file flushes it anyway, so an fflush() just before the end
of the program doesn't do any good.

fflush() is commonly used when you want to make sure that your output
appears. For example:

printf("Here's a prompt: ");
fflush(stdout);
fgets(answer);

Without the fflush() the prompt won't necessarily appear in time to be
useful. Another example:

fprintf(LOG_FILE, "About to do something dangerous\n");
fflush(LOG_FILE);
do_something_dangerous();

Here, if do_something_dangerous() causes the program to crash badly
enough, the message might never be written. <OT>It can also ensure
that the message will be visible to another process.</OT>

None of this is really guaranteed, since there can still be additional
layers of buffering in the operating system.

Thanks for this improvement.

No problem.

 

[Jordan Abel]

for(int i=0;i<strlen(s);i++)
char myChar = s;

That re-evaluates strlen(s) on each iteration, making the loop
O(N**2) rather than O(N).

While any decent compiler ...., you're right. How about i=0;s;i++?

Sure (though I'd write "s != '\0'"), or use a pointer, or compute
strlen() outside the loop. (The latter does a single unnecessary
traversal of the string, which isn't nearly as bad as doing N
unnecessary traversals.)

Many do even without full c99 support, though, mainly as a consequence
of also being C++ compilers. The same applies to //comments, though
those are bad in code to be posted on this group for other reasons.

Many != All. Using C99-specific feature, even ones that are widely
implemented, limits the portability of your code. If you're willing
to accept that, that's fine, but you should be aware of it, and you
should know how to avoid the problem if you need to (in this case, by
declaring the variable separately).

potato, potato.

Would you rather call printf and sprintf "potatoes"?

"potato, potato" is pronounced as /p@teIto p@tAto/ i.e. "ay" and "ah"
sounds for the 'a'.

And I was joking, of course there's a different. There are also
differences between functions and subroutines, but we call them all
'functions', even the ones that aren't.

 

[Jordan Abel]

More like potatoe, potato, Mr Vice President.

I was thinking of "potayto potahto"

 

[Keith Thompson]

"potato, potato" is pronounced as /p@teIto p@tAto/ i.e. "ay" and "ah"
sounds for the 'a'.

And I was joking, of course there's a different. There are also
differences between functions and subroutines, but we call them all
'functions', even the ones that aren't.

Yeah, I got the joke. The point of the joke is that there's no
practical difference between "potayto" and "potahto". There's a very
real difference between "function" and "program" (and the C standard
doesn't even use the word "subroutine".)

What exactly was your point?

 

[Default User]

Yeah, I got the joke. The point of the joke is that there's no
practical difference between "potayto" and "potahto". There's a very
real difference between "function" and "program" (and the C standard
doesn't even use the word "subroutine".)

What exactly was your point?

Let's call the whole thing off.

Well, somebody had to do it.




Brian