Comparing memory with a constant

[galapogos]

Hi,
I'm trying to compare an array of unsigned chars(basically just data
without any context) with a constant, and I'm not sure how to do that.
Say my array is array[10] and I want to compare it with the constant
0x0001020304050 6070809 where array[0] == 0x00, array[1] == 0x01, etc.
How do I do that. Obviously I can't use memcmp() with the
0x0001020304050 6070809 since the compiler will use that constant as an
address and give me a segfault. Other than doing an if (array[i] =
0x0i) for all 10 values of i, how can I do such a compare? I thought of
converting the constant to a string and doing a memcmp/strcmp using
that string but not all the bytes are printable ASCII characters.

Thanks!

[CBFalconer]

Ian Collins wrote:

CBFalconer wrote:

.... snip ...

>>
How about the following (using strings for convenience), untested:

^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^

>>
#include <strings.h>
void switchonpattern (const char *pattern)
{
static const char *patterns[] = {NULL
,"pattern1"
,"pattern2"
....
,"patternN") ;

What if a pattern contains a 0 byte?

Note the underlined above. If you want arrays, use arrays and
memcmp. You may then need a length parameter in addition, or a
record with a length field.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net>

[galapogos]

Ian Malone wrote:

galapogos wrote:

Ian Collins wrote:

galapogos wrote:

>Thanks. I thought of doing that, but I'm not really comparing to just 1
constant, so having multiple constants would be kinda unwieldy. What
I'm doing is something like that

switch (array) {
case bitpattern1: ...
case bitpattern2: ...
etc...
}

where bitpattern is my 0x0001020304050 6070809 or whatever else. Now
obviously the above code won't work but I think you get my idea?

But you still have to represent the constants, don't you?

You'll have to fall back on a set of if/else tests with memcmp and const
unsigned char arrays.

Yes I know that's the worst case scenario that would work. I was just
hoping there was an easier way that I can implement the switch/case
statements rather than using a bunch of if-else statements that I'm
currently doing.

Hashtable?

--
imalone

Could you elaborate? I know the concept of a hashtable but I don't have
much experience with it and I don't see how it relates to the problem.
Are you saying each pattern will hash into the table and hopefully no
collisions will take place? Some kinda example would be great...thanks!

[galapogos]

Richard Heathfield wrote:

galapogos said:

<snip>

Hmm, so if I do a memcmp(array, "\x00\x01...\xn n"), the compiler still
allocates memory for the 2nd term even though I don't declare it as a
constant/variable?

Who knows? It doesn't have to, as the code stands. All it *has* to do is
complain that you haven't provided enough argument expressions to memcmp.

Once you've fixed that, then yes, of course the compiler will store the
information you will need for your runtime comparison, and yes, of course
that will occupy some memory, so therefore the compiler will have to
allocate some memory for it to occupy.

Everything Has To Be Somewhere.

Thanks, I guess I should've known, since such large constants won't fit
into the literal/immediate field of any instruction set architecture
anyway. I was asking because I'm programming for an embedded system so
memory is kinda valuable.

[Ian Malone]

galapogos wrote:

Ian Malone wrote:

>galapogos wrote:

>>Ian Collins wrote:
galapogos wrote:
Thanks. I thought of doing that, but I'm not really comparing to just 1
constant, so having multiple constants would be kinda unwieldy. What
I'm doing is something like that
>
switch (array) {
case bitpattern1: ...
case bitpattern2: ...
etc...
}
>
where bitpattern is my 0x0001020304050 6070809 or whatever else. Now
obviously the above code won't work but I think you get my idea?
>
But you still have to represent the constants, don't you?

You'll have to fall back on a set of if/else tests with memcmp and const
unsigned char arrays.

Yes I know that's the worst case scenario that would work. I was just
hoping there was an easier way that I can implement the switch/case
statements rather than using a bunch of if-else statements that I'm
currently doing.

Hashtable?

Could you elaborate? I know the concept of a hashtable but I don't have
much experience with it and I don't see how it relates to the problem.
Are you saying each pattern will hash into the table and hopefully no
collisions will take place? Some kinda example would be great...thanks!

If you want to be able to do switch on these numbers then I guess
you have a finite manageable number of them and they are known
at compile time. Come up with some type of preprocessor which
converts your bit patterns to valid case labels, and make the
argument to the switch statement a call to a C function which
does the same hash.

This is basically Galapogos's proposal, although his suggested
'program P' would also try to analyze the set of bit patterns
you use to produce the most efficient outcome, and could be
used when the number of bit patterns exceeds the range
representable by an operand to switch. However if you have
that many of them a switch statement would be a bit absurd.

--
imalone

[Ian Malone]

Ian Malone wrote:

If you

<etc.>

>
This is basically Galapogos's proposal, although his suggested

Sorry, Chris Torek's proposal (mental cut 'n paste broken today)

--
imalone

[Keith Thompson]

"galapogos" <go*****@gmail. comwrites:

Richard Heathfield wrote:

>galapogos said:

<snip>

Hmm, so if I do a memcmp(array, "\x00\x01...\xn n"), the compiler still
allocates memory for the 2nd term even though I don't declare it as a
constant/variable?

Who knows? It doesn't have to, as the code stands. All it *has* to do is
complain that you haven't provided enough argument expressions to memcmp.

Once you've fixed that, then yes, of course the compiler will store the
information you will need for your runtime comparison, and yes, of course
that will occupy some memory, so therefore the compiler will have to
allocate some memory for it to occupy.

Everything Has To Be Somewhere.

Thanks, I guess I should've known, since such large constants won't fit
into the literal/immediate field of any instruction set architecture
anyway. I was asking because I'm programming for an embedded system so
memory is kinda valuable.

And even if they do, literal/immediate instruction fields take up
space too.

But if you're using an embedded system where RAM is scarce and ROM is
cheap, it *is* entirely possible that the compiler will put your
string literal in ROM. The standard doesn't say anything about this,
so if you want more information you'll have to try it yourself or ask
in a system-specific forum.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.