return the start of a substring in a string in c

[yinglcs]

Hi,
In java, there is an 'indexOf' function in String which does this:

indexOf(String str)
Returns the index within this string of the first occurrence
of the specified substring.

is there anything like that in c?

The closest thing I can find is strchr, but it check for a character,
not a substring?

Thank you.

[Eric Sosman]

Malcolm McLean wrote On 07/19/07 18:14,:

(... *Still* declining to defend his claim that strstr()
and its caller "talk to each other" with integers ...)

"Eric Sosman" <Er*********@sun.comwrote in message
news:1184880234.495526@news1nwk...

> And what language do you propose to use to manipulate
those samples? Not 64-bit-only C, that's for sure. Here's
my way of reducing the volume of one sample:

uint16_t *sample = ...;
*sample -= *sample / 10;

... and here's what you want me to do instead:

/* 8-bit (?) */ unsigned char *samplebytes = ...;
/* 64-bit */ unsigned int sample;
sample = samplebytes[0] + (samplebytes[1] << 8);
sample -= sample / 10;
samplebytes[0] = sample;
samplebytes[1] = sample >8;

It won't wash, Malcolm. It wouldn't wash even if Herakles
ran a couple rivers over it.

/* 64 bit int only code */

void reduce10(unsigned char *audio, int N)
{
int i;
int sample;

for(i=0;i<N;i++)
{
sample = get16(audio + i * 2);
sample -= sample/10;
put16(audio + i * 2, sample);
}
}

#define get16(ptr) ( ( (int)ptr[0] << 8) + ptr[1])
#define put16(ptr, x) do{ptr[0] = (x >>8) & 0xFF; ptr[1] = x &
0xFF;}while(0)

The last macro is a bit of nuisance, I'd be the first to agree. You'll use
these all the time when writing samples to and from the buffer. It might
just make a difference for such a simple manipulation as knocking off 10%.

Do you think you *improve* things by taking one simple
line of code and obfuscating it with an intermediate variable
and two macros (both unsafe from side-effects)?

Compare

void up10(uint16_t *sample, size_t N)
{
size_t i;

for(i=0;i<N;i++)
sample[i] += sample[i]/10;
}

Superfically this looks OK, but here are a few ways to break it.

up10(boomingadvert, N);

If you're worried about clipping, observe that using
64 bits won't fix it. All it'll do is postpone the clip
until the point when the samples are chopped to 16 bits
for burning to the CD. (Or do you propose that CDs should
record 64-bit samples, too? You want to cut the playing
time to from 80 to 20 minutes? One LP side = 2 CD64's?)

I'll admit one small advantage: By using lots of extra
bits the sample would survive amplification followed by a
subsequent diminution: up by ten percent and then back down
by fifty wouldn't clip. But that's not how you *do* sound
editing: You boost the volume, say "Oops! It clipped," hit
the Undo button, and boost again by a smaller amount.

up10(sample, N - window);

I don't understand what breakage you suggest here,
nor how 64-bit ints would cure it.

short *samples; /* from your colleague Fred */
up10((uint16_t *) samples, N);

Fred gave me the wrong stuff. If he gave the same
wrong stuff to you, you'd be equally in the soup.

--
Er*********@sun.com

[Richard Bos]

"Malcolm McLean" <re*******@btinternet.comwrote:

"Richard Bos" <rl*@hoekstra-uitgeverij.nlwrote in message

They are all just whole numbers. However on a 64
bit machine, 64 bit integers are efficient.

And we all have 64 bit machines, right? Guess what: wrong.

The campaign for 64 bit ints campaigns for 64 bit ints on 64 bit machines,
maintaining the convention that int is the natural integer type for the
platform. On 32 bit machines it is accepted that int should be 32 bits, just
as it should be 16 bits on small machines with 16 bit registers.

The idea is that an integer can be used to index any array.

So you _still_ haven't grasped the difference between an int and an
integer.

Richard

[Malcolm McLean]

"Eric Sosman" <Er*********@sun.comwrote in message
news:1184884531.511019@news1nwk...

Malcolm McLean wrote On 07/19/07 18:14,:

(... *Still* declining to defend his claim that strstr()
and its caller "talk to each other" with integers ...)

|No. Functions talk to each other via integers, just as humans talk to each
other via soundwaves. That isn't the only means of communication, of
course - we're not using soundwaves now - but it's an important one.
Similarly not every function takes integer parameters, and of those only a
subset take integers by indirection, which is the real problem. However that
set is large enough for integer representation to be a real issue.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Eric Sosman]

Malcolm McLean wrote On 07/20/07 17:24,:

"Eric Sosman" <Er*********@sun.comwrote in message
news:1184884531.511019@news1nwk...

>>Malcolm McLean wrote On 07/19/07 18:14,:

(... *Still* declining to defend his claim that strstr()
and its caller "talk to each other" with integers ...)

|No. Functions talk to each other via integers, just as humans talk to each
other via soundwaves. That isn't the only means of communication, of
course - we're not using soundwaves now - but it's an important one.
Similarly not every function takes integer parameters, and of those only a
subset take integers by indirection, which is the real problem. However that
set is large enough for integer representation to be a real issue.

Your original claim was

"The difference is that the integer representation
is the way that functions talk to each other."
-- Malcolm McLean, 2007-07-17

Not "a way" nor "one of the ways," but "the way." The
claim is, of course, absurd, and I'm relieved to see
that you're willing to drop it, even if it took three
days to reach that point.

May we hope that you will also drop this silly "One
size fits all" nonsense? The past does not encourage me
to be optimistic, but even a dim hope beats despair.

--
Er*********@sun.com