return the start of a substring in a string in c

M

Malcolm McLean

Eric Sosman said:
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%.

Compare

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

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

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

up10(boomingadvert, N);

up10(sample, N - window);


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

Ian Collins

Malcolm said:
That's partly why I insist on separating IO from logic. It is a lot
easier said than done.
But code that interacts with hardware devices using bits is inherently
non-portable anyway. It won't become any less portable if you use a
platform-specific extension.
Hardware devices and most data packets sent via common communications
protocols are addressed in bits, bytes and multiples of bytes. If
standard C lacked the means to address them, it wouldn't be much use for
systems programming, the most common use for C.
 
I

Ian Collins

Malcolm said:
The campaign is for int to be 64 bits on 64 bit machines.
There are reasons for this, one of which is that, at some future date,
it will enable us to simplify the language, particularly by removing
size_t.

The campaign for 64 bits is important because 64 bit architectures are
going to come into common use in the near future. Whilst I welcome the
end of the 2GB limit on memory, I am not trying to advocate use of 64
bit processors where 32 bit processors would be adequate.
You've banged that rather flaccid drum before and the links to reasons
why most popular operating systems chose not to go down that route have
been posted. Did you read them?

Your campaign has about as much chance of success as one to adopt an 8
foot railway gauge.
 
E

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 ...)
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 += sample/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.
 
R

Richard Bos

Malcolm McLean said:
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
 
M

Malcolm McLean

Eric Sosman said:
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.
 
E

Eric Sosman

Malcolm McLean wrote On 07/20/07 17:24,:
|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.
 
M

Malcolm McLean

Eric Sosman said:
Malcolm McLean wrote On 07/20/07 17:24,:

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.
Eric Sosman:
i.e, we can emulate every control structure with if and goto, just as we can
replace every integer type with bytes and the maximum register size. So
what's the difference between the two? Within context, Malcolm's reply isn't
too silly. "The" should read "a standard by which", admittedly. But you
don't try to apply that level of grammatical analysis to a Usenet post. It's
not a constitutional law, after all.
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.
The campaign for 64 bits T-shirt comes only in XXL.
That is the convention, except for very young children, of course.
T-shirt manufacturers and retailers found that it was real nuisance having
to keep lots of sizes in stock. So they ran a marketing campaign telling
people that the fashionable thing to do was to drown in an over-sized
T-shirt. It worked. When I sold T-shirts, girls were coming in saying "do
you have extra extra extra large?".
If one T-shirt fits all, so much more one integer size. A number cannot be
too small to fit into an integer, after all, only too big. Very seldom will
you need a number larger than 32 quadrillion. (Cryptography is an
exception). Sound samples, which you mentioned, are another marginal case -
sometimes you might need enough of them in memory at once to justify only 16
bits.
 
F

Flash Gordon

Malcolm McLean wrote, On 21/07/07 07:03:
admittedly. But you don't try to apply that level of grammatical
analysis to a Usenet post. It's not a constitutional law, after all.

People can only read what you actually post, they cannot read your mind.
If you are posting stuff that people consider stupid (i.e. that there
should only be 64 bit integers in C on 64 bit processors) then don't be
surprised if they take other things literally even if that was not how
you intended them.
The campaign for 64 bits T-shirt comes only in XXL.
That is the convention, except for very young children, of course.
T-shirt manufacturers and retailers found that it was real nuisance
having to keep lots of sizes in stock. So they ran a marketing campaign
telling people that the fashionable thing to do was to drown in an
over-sized T-shirt. It worked.

It worked so well that I can still buy small, medium and large T-shirts
with great ease.

seldom will you need a number larger than 32 quadrillion. (Cryptography
is an exception). Sound samples, which you mentioned, are another
marginal case - sometimes you might need enough of them in memory at
once to justify only 16 bits.

If you are going to see every exception as just one little exception and
fail to see the pattern. Several other reasons have also been posted for
needing smaller then 64 bit integers and reasons for int being 32 bit.
 
M

Malcolm McLean

Flash Gordon said:
Malcolm McLean wrote, On 21/07/07 07:03:

People can only read what you actually post, they cannot read your mind.
If you are posting stuff that people consider stupid (i.e. that there
should only be 64 bit integers in C on 64 bit processors) then don't be
surprised if they take other things literally even if that was not how you
intended them.
They can also read the context in which you post it. It was a reply to "more
integer types make the language richer, as do more looping constructs", the
difference being that integer formats are a standard for passing data about
whilst loops are not.
Now if you think I am stupid, rather than just disagreeing with me, you
should take a reality check. Check the website and see whether this is
consistent with a stupid person. Maybe the stupidity goes the other way. I
seem to be the only person who has cottoned on to the language-wrecking
potential of not being able to use int as an arbitrary array index. Newbies
will just see size_t i, with some sort of explanation why it has to be a
size_t even though it is a counter, and think "this is a highly specialised
language just for experts."
You'll find I am right when C loses its status as the default language for
specifying algorithms, but by then the damage will have been done and it
will be too late. So we must get size_t and ptrdiff_t out of the language
now. If they were either necessary or a good idea such fundamental types
would have been in C from day one. They are neither, as long as int is the
natural integer size of the machine. Lose that convention, and there is no
choice. You need ptrdiff_t and size_t, all over your code, wrecking its
beauty and legibility.
If you are going to see every exception as just one little exception and
fail to see the pattern. Several other reasons have also been posted for
needing smaller then 64 bit integers and reasons for int being 32 bit.
There are always a myriad of little objections to any standard. "Are you
going to throw away a brand new screw-making machine, Sir Joseph, purely
because it produces thread with a pitch that is 5 degrees lower than your
standard?" It's a good point. The machine will have to be scrapped. However
the benefits massively outweighed that sort of consideration.
 
F

Flash Gordon

Malcolm McLean wrote, On 21/07/07 19:51:
They can also read the context in which you post it. It was a reply to
"more integer types make the language richer, as do more looping
constructs", the difference being that integer formats are a standard
for passing data about whilst loops are not.

See previous comment which explains why people might not think you have
grasped the context.
Now if you think I am stupid,

I did not call you stupid, I said you are saying something stupid. If
you can't see the distinction...
> rather than just disagreeing with me, you
should take a reality check. Check the website and see whether this is
consistent with a stupid person. Maybe the stupidity goes the other
way.

Or perhaps YOU should check the websites that have been pointed out to
you, such as the Intel documentation saying that you should have a 32
bit int for C on the Itanium processor, or the sites posted some time
back which explained why the Unix people decided on a 32 bit int.
I seem to be the only person who has cottoned on to the

Normally when one person is at odds with the majority of experts (I'm
talking about Intel, and those responsible for Unix standard, not just a
semi-random collection of people on Usenet) then it turns out to be the
one person who is wrong. Occasionally it is the other way around, but
not normally. So perhaps it is YOU who should reconsider and actually
look at the things you have been pointed at.
language-wrecking potential of not being able to use int as an arbitrary
array index.

It can't be a very high potential, since the language has not died in
all the time since the C89 standard was released.
> Newbies will just see size_t i, with some sort of
explanation why it has to be a size_t even though it is a counter, and
think "this is a highly specialised language just for experts."

Most newbies are not dealing with arrays with more than 32767 elements,
and by the time they are they have normally learnt enough about
programming to be able to cope with the concept of different types for
different purposes.
You'll find I am right when C loses its status as the default language
for specifying algorithms, but by then the damage will have been done
and it will be too late.

Lets see, Fortran has continued to be the default language for some
types of algorithms (C having never supplanted it), maths has continued
to be the default language for others (I've used it myself)...

However, if it has not lost its status in all the years since 1989 when
the types you complain about were introduced (not forgetting all the
16/32 bit processors) then I don't see why those types should suddenly
kill the language now.
> So we must get size_t and ptrdiff_t out of the
language now. If they were either necessary or a good idea such
fundamental types would have been in C from day one.

There are a number of things that were in C from day one that DMR has
stated were, with hindsight, a bad idea. So something not being in C
from day one does not mean it is a bad idea. Also DMR was involved in
the standardisation, as were lots of other people who we have more
reason to believe know what makes a good language than you.
> They are neither,
as long as int is the natural integer size of the machine. Lose that
convention, and there is no choice.

It has been pointed out already that 32 bits is *also* a natural size of
64 bit processors.
> You need ptrdiff_t and size_t, all
over your code, wrecking its beauty and legibility.

A lot of people find that using specific types for specific purposes
*increases* legibility. This has also been pointed out to you. Of
course, legibility is subjective, so different people disagree about
what is legible.
There are always a myriad of little objections to any standard.

Actually, they are BIG objections. It's just they you don't consider
anything that disagrees with your preconceived notions as being a big
objection.
> "Are you
going to throw away a brand new screw-making machine, Sir Joseph, purely
because it produces thread with a pitch that is 5 degrees lower than
your standard?" It's a good point. The machine will have to be scrapped.
However the benefits massively outweighed that sort of consideration.

How about, you have to throw away this Oracle cluster you have built at
tremendous expense because the language you are using no longer has
types that match the standard SQL types, oh and the SQL servers written
in C having to be rewritten in anothe rlanguage as well. Or you have to
switch to another language for writing the JVM because it no longer
supports the integer types you need. Image processing is a pretty large
domain as well, not just for home use but commercial as well. Not to
mention all those big server applications which have to be ported to
another language because suddenly the data is too bloated if it is
written in C (yes, there are modern servers which are fully populated in
terms of RAM, and they make use of all of it).
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top