Convert native character string to ASCII array of integers

  • Thread starter Tomás Ó hÉilidhe
  • Start date
T

Tomás Ó hÉilidhe

CBFalconer:
Which is a silly assumption.  However, you are still failing to
initialize pc and pos.


Firstly, there's no such thing as a silly assumption in programming.
If I say the string has to be all valid ASCII characters, then the
string has to be all valid ASCII characters. It's not rocket science.

Also, why are you trying to critique my code when you haven't even
read it properly? Firstly you critisize the code for not doing three
specific things -- three specific things that it wasn't intended to
do, and now you can't get your head around the fact that pc and pos
are parameters to the original function that I wrote. You'd probably
be wise to view the original post before you critique the code further.
 
P

Philip Potter

Tomás Ó hÉilidhe said:
CBFalconer:



Firstly, there's no such thing as a silly assumption in programming.
If I say the string has to be all valid ASCII characters, then the
string has to be all valid ASCII characters. It's not rocket science.

There *is* such a thing; a silly assumption is a tacit assumption. As
long as it is well documented, it is fine.
Also, why are you trying to critique my code when you haven't even
read it properly? Firstly you critisize the code for not doing three
specific things -- three specific things that it wasn't intended to
do, and now you can't get your head around the fact that pc and pos
are parameters to the original function that I wrote. You'd probably
be wise to view the original post before you critique the code further.

It is characteristic of Chuck's posts that he doesn't read the thread
before butting in. I find it much easier just to killfile him.
 
T

Tomás Ó hÉilidhe

There *is* such a thing; a silly assumption is a tacit assumption.
As long as it is well documented, it is fine.


I've accepted "silly assumptions" with open arms ever since I finished
my Ordinary Degree project this year. It was an embedded systems
project which involved four different chips communicating with each
other. If any of the chips made an error, there could be a short
circuit from 5 V to 0 V which would fry the chips, the power
transistors, and also the voltage regulator. Given that the
micrcontroller ran at 8 MHz, and also that it performed one
instruction per clock cycle, it had 8 million chances to screw up
every second. I was advised to add extra resistors to allows for these
errors but I declined the suggestion. Instead I relied on everything
working perfectly. The finished product has been plugged in constantly
overnight for the last two nights and hasn't had a hiccup. When
programming, I assume that the computer will work perfectly every
time. Of course tho, if you're worried about human error you can
always use assert's.
 
M

Morris Dovey

Tomás Ó hÉilidhe said:
If any of the chips made an error, there could be a short
circuit from 5 V to 0 V which would fry the chips, the power
transistors, and also the voltage regulator.
The finished product has been plugged in constantly
overnight for the last two nights and hasn't had a hiccup.

I'm reminded of an early computer cash register system in a gas
(petrol) station that worked without problem for over a year and
a half - until a police car pulled in for refueling. Just as the
car arrived, the dispatcher called on the radio and when the
policeman responded, his transmitted signal killed the pump
controller which, in turn, killed the cash register.

It might not be a bad idea to add those inexpensive
current-limiting resistors...

:)
 
R

Richard

Philip Potter said:
There *is* such a thing; a silly assumption is a tacit assumption. As
long as it is well documented, it is fine.

No. A documented "silly assumption" is still a silly
assumption. Documenting garbage code doesn't suddenly make it good
code. However documenting that something takes only ASCII characters is
not any assumption at all - it is a documented limitation/constraint.
It is characteristic of Chuck's posts that he doesn't read the thread
before butting in. I find it much easier just to killfile him.

Chuck is in most killfiles I would think.
 
R

Richard

Morris Dovey said:
I'm reminded of an early computer cash register system in a gas
(petrol) station that worked without problem for over a year and
a half - until a police car pulled in for refueling. Just as the
car arrived, the dispatcher called on the radio and when the
policeman responded, his transmitted signal killed the pump
controller which, in turn, killed the cash register.

It might not be a bad idea to add those inexpensive
current-limiting resistors...

:)

Or even better, just shield the electronics properly. You would not put
"current limiting resistors" in either - you would probably use some
active surge detection circuit which dissipates any peak voltages.
 
T

Tomás Ó hÉilidhe

I'm reminded of an early computer cash register system in a gas
(petrol) station that worked without problem for over a year and
a half - until a police car pulled in for refueling. Just as the
car arrived, the dispatcher called on the radio and when the
policeman responded, his transmitted signal killed the pump
controller which, in turn, killed the cash register.

It might not be a bad idea to add those inexpensive
current-limiting resistors...

:)


(As of 29th March 2008, 10euro == 16dollars or thereabouts).

When I was testing the board, there was indeed a few short
circuits because there were errors in my code... but none of the
components got fried because I'm using a 2euro power supply that can't
supply more than 300 mA :-D

For items that are extremely well-developed and extremely
reliable, adding something like a fuse actually hurts the device
because the fuse is less reliable than the device! You can get 13 A
fuses that will allow 17 A to flow for a few weeks (and I've seen
them), and then you'll get a 13 A fuse that'll blow for no known
reason. Of all the fuses that have ever blown in my house, I'd say
most of blowings *weren't* caused by excessive current flow but rather
by a tempermental fuse. Add to this the actual cost of each fuse and
the cost of adding it to the circuit board.

For large scale production, I'd hazard a guess that it's more
expensive to put in the resistors/fuses than it is to replace the far-
and-few-between items that get damaged. Think how many 486 computers
there are in the world today that are still running perfectly. People
are buying them off eBay, loading them with two network cards and
Linux, and then using them as a network router. (I was actually at an
auction just there this morning looking to buy a Pentium III laptop
for under 20euro but it turned out to have a smashed screen, I stopped
bidding at 8euro). Digressing tho... now imagine if they saved 1 euro
on every single 486 by taking out some sort of "damage limiting
device" -- I'm sure the 1 euro per unit saving would more than cover
the cost of replacing/repairing the faulty ones.

(I realise a few resitors or even their footprints on the circuit
board won't cost 1euro, but if you consider that all the components on
my board come to a grand total of less than 2euro then I think the
maths works in terms of proportionality)

Of course though, if there's a risk of human harm, or of fire,
etc., then I'd say it's probably best to load the thing with safe
guards. For a small little circuit board tho, the worst you'll get is
a dead microchip. And if it the device is dirt cheap to make, you'd
just send them out a new one rather than repairing it.

And of course, last but certainly not least, it's always fun to
live on the wild side ;-D
 
T

Tomás Ó hÉilidhe

Richard said:
Or even better, just shield the electronics properly.


Strangely enough, I can maul my hands all over the circuit board chips
and connections while the device is on and it doesn't bat an eyelid,
which I was actually quite surprised at :-D

You would not put
"current limiting resistors" in either - you would probably use
some active surge detection circuit which dissipates any
peak voltages.


The only voltage source on the board is a constant "5 volts DC" so
current-limiting is the way to go, either by means of a fuse or of
current-limiting resistors. Even if you had a few amperes flowing thru
it, the voltage still wouldn't peak -- in fact it would drop because
there'd be a voltage drop across the internal resistance of the power
supply.

In college, we have special power supplies on which you can set a
current limit... which is pretty much an indespensible tool for
testing circuits. I've been on holidays from college for the last two
weeks though so I just went to the Pound Shop and bought an extremely
cheap power supply which also doubles as a current limiter simply by
virtue of the fact that it can't supply more than 300 mA :-D
 
R

Richard

Tomás Ó hÉilidhe said:
Strangely enough, I can maul my hands all over the circuit board chips
and connections while the device is on and it doesn't bat an eyelid,
which I was actually quite surprised at :-D




The only voltage source on the board is a constant "5 volts DC" so
current-limiting is the way to go, either by means of a fuse or of

It's nothing to do with the voltage source "in circuit" AFAICR and in
the example noted at the gas station - the noise from external sources
can cause peaks. And a 5 volt source can easily be stepped up. See
electric pens/lighters for an example :-; Bzzzzz....
 
C

CBFalconer

santosh said:
CBFalconer said:
Tomás Ó hÉilidhe said:
CBFalconer:

for ( ; *pc; ++pos, ++pc) *pos = strchr(ascii,*pc) - ascii + 0x20;

instead of:

while (*pc) *pos++ = strchr(ascii,*pc++) - ascii + 0x20;

IMO you are making a mistake. The second is simpler, and much
easier to detect inaccuracies in. The thing that screams at you is
that both are missing copying the terminal '\0'. Both are missing
the initialization of pc and pos. Both are missing handling the
fact that the char is not found in the ascii string.

They're missing neither of those three things. The context of the
code is as follows:

static char const ascii[] =
" !\"#$%&'()*+,-./0123456789:;<=>?@"
"ABCDEFGHIJKLMNOPQRSTUVWXYZ"
"[\\]^_`"
"abcdefghijklmnopqrstuvwxyz"
"{|}~";

for ( ; *pc; ++pos, ++pc)
*pos = strchr(ascii,*pc) - ascii + ' ';

*pos = 0;

Also, it is assumed that every char is valid ASCII.

Which is a silly assumption. However, you are still failing to
initialize pc and pos.

They are initialised on entry to the function. Please read the
previous articles before coming to conclusions.

Don't be silly. I am not going to chase about reading earlier
posts, which I may or may not have ever received. No
initialization was shown in the articles to which I replied.
 
T

Tomás Ó hÉilidhe

Richard:
It's nothing to do with the voltage source "in circuit" AFAICR and in
the example noted at the gas station - the noise from external sources
can cause peaks. And a 5 volt source can easily be stepped up. See
electric pens/lighters for an example :-; Bzzzzz....


I've an voltage regulator on the board, complete with a diode to make
sure the battery isn't connected the wrong way :-D
 
R

Richard

Tomás Ó hÉilidhe said:
Richard:



I've an voltage regulator on the board, complete with a diode to make
sure the battery isn't connected the wrong way :-D

<clc pedant mode on>You mean to stop it damaging anything if the battery is put in the wrong
way</> ....
 
S

santosh

CBFalconer said:
santosh said:
CBFalconer said:
Tomás Ó hÉilidhe wrote:
CBFalconer:

for ( ; *pc; ++pos, ++pc) *pos = strchr(ascii,*pc) - ascii +
0x20;

instead of:

while (*pc) *pos++ = strchr(ascii,*pc++) - ascii + 0x20;

IMO you are making a mistake. The second is simpler, and much
easier to detect inaccuracies in. The thing that screams at you
is
that both are missing copying the terminal '\0'. Both are missing
the initialization of pc and pos. Both are missing handling the
fact that the char is not found in the ascii string.

They're missing neither of those three things. The context of the
code is as follows:

static char const ascii[] =
" !\"#$%&'()*+,-./0123456789:;<=>?@"
"ABCDEFGHIJKLMNOPQRSTUVWXYZ"
"[\\]^_`"
"abcdefghijklmnopqrstuvwxyz"
"{|}~";

for ( ; *pc; ++pos, ++pc)
*pos = strchr(ascii,*pc) - ascii + ' ';

*pos = 0;

Also, it is assumed that every char is valid ASCII.

Which is a silly assumption. However, you are still failing to
initialize pc and pos.

They are initialised on entry to the function. Please read the
previous articles before coming to conclusions.

Don't be silly. I am not going to chase about reading earlier
posts, which I may or may not have ever received.

The OP does show the complete routine just a few posts up-thread.
 
R

Richard Heathfield

CBFalconer said:
Don't be silly. I am not going to chase about reading earlier
posts, which I may or may not have ever received.

Don't be silly. Either read the threads in which you are participating, or
accept the statements that are made about prior articles in that thread,
or check those statements yourself before challenging them. If you can't
accept the research that others have done, and aren't prepared to research
the matter yourself, you don't really have any grounds for challenge.
No initialization was shown in the articles to which I replied.

Then read the thread. Particularly, read this message:

<f696f5d6-395f-4335-9ff9-32f27d3ff5d7@s19g2000prg.googlegroups.com>
 
H

Harald van Dijk

santosh said:
CBFalconer said:
Tomás Ó hÉilidhe wrote:
CBFalconer:
for ( ; *pc; ++pos, ++pc) *pos = strchr(ascii,*pc) - ascii + 0x20;

instead of:

while (*pc) *pos++ = strchr(ascii,*pc++) - ascii + 0x20;

IMO you are making a mistake. The second is simpler, and much
easier to detect inaccuracies in. The thing that screams at you is
that both are missing copying the terminal '\0'. Both are missing
the initialization of pc and pos. Both are missing handling the
fact that the char is not found in the ascii string.

They're missing neither of those three things. The context of the
code is as follows:
[snip]
Also, it is assumed that every char is valid ASCII.

Which is a silly assumption. However, you are still failing to
initialize pc and pos.

They are initialised on entry to the function. Please read the previous
articles before coming to conclusions.

Don't be silly. I am not going to chase about reading earlier posts,
which I may or may not have ever received. No initialization was shown
in the articles to which I replied.

You knew the code wouldn't work without a declaration, and simply assumed
it had been omitted from the message, as the code was a snippet, not a
complete function.

You knew the code wouldn't work without initialisation. You didn't make
the same assumption here, not even after Tomás told you the
initialisation wasn't missing in the original code. Why not?
 
G

Gordon Burditt

I've accepted "silly assumptions" with open arms ever since I finished
my Ordinary Degree project this year. It was an embedded systems
project which involved four different chips communicating with each
other. If any of the chips made an error, there could be a short
circuit from 5 V to 0 V which would fry the chips, the power
transistors, and also the voltage regulator. Given that the
micrcontroller ran at 8 MHz, and also that it performed one
instruction per clock cycle, it had 8 million chances to screw up
every second. I was advised to add extra resistors to allows for these
errors but I declined the suggestion. Instead I relied on everything
working perfectly. The finished product has been plugged in constantly
overnight for the last two nights and hasn't had a hiccup.

How do you shut down and restart this thing without frying it?

Incidentally, I am not sure that a short would fry this thing in
one clock cycle. It might reset it back to synchronization or it
might get it out of whack and guarantee it will fry.
When
programming, I assume that the computer will work perfectly every
time.

I hope you never design airplanes or nuclear reactors.
Of course tho, if you're worried about human error you can
always use assert's.

I suppose that ECC memory for critical applications, CRCs on disk
sectors, and checksums on TCP packets are just wasted effort?
 
T

Tomás Ó hÉilidhe

How do you shut down and restart this thing without frying it?


With the power switch. (I don't see why you think it would get fried
from being turned off or on).

Incidentally, I am not sure that a short would fry this thing in
one clock cycle.


I have a 16-Bit shift register chip that should only have one 1 on it
at a time. If a second 1 appears, there could be a short circuit from
5 V to 0 V. This lone 1 gets shifted around in a loop a couple of
hundred thousand times per second. Once a second 1 makes its way on,
it's there to stay.

As I've said though, the chips work perfectly together so no second 1
makes its way in.

I suppose that ECC memory for critical applications, CRCs on disk
sectors, and checksums on TCP packets are just wasted effort?


What's your comments on the following code?

const letters[] = "abcd";

unsigned i = some_value % 4;

letters = 'X';

Or do you think, before we access memory, that we should verify that
"i" is in the range of 0 thru 3?
 
I

Ian Collins

Tomás Ó hÉilidhe said:
I suppose that ECC memory for critical applications, CRCs on disk
sectors, and checksums on TCP packets are just wasted effort?

What's your comments on the following code?

const letters[] = "abcd";

unsigned i = some_value % 4;

letters = 'X';

Or do you think, before we access memory, that we should verify that
"i" is in the range of 0 thru 3?

You just have (some_value % 4).

The real world isn't perfect, random bit toggles happen, noise on signal
lines happens, magnetic media has defects.

I always use ECC memory for anything that might be considered a "server"
and I use a file system with end to end checksumming on all my systems.
 
T

Tomás Ó hÉilidhe

The real world isn't perfect, random bit toggles happen,
noise on signal lines happens, magnetic media has defects.

I always use ECC memory for anything that might be considered
a "server" and I use a file system with end to end
checksumming on all my systems.


Of course, things like ECC should be used for sending data across the
internet and for reading from drives... but I don't think we'd get
very far in programming if we didn't assume that the CPU and RAM
always do their job perfectly. I mean even look at a simple strcpy
function:

void strcpy(char *dst,char const *src)
{
while (*dst++ = *src++);
}
 

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

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,902
Latest member
Elena68X5

Latest Threads

Top