Substrings and so on
Vicent
I would like to ask you about standard or usual ways to manage with
files or strings, specially when getting input data and writing output
from an algorithm.
I mean: which structures, data types or classes? Which standard ways
to read/write from/on files?
I've read some tutorials that deal with the standard C I/O and string
(string.h) libraries, but specially when managing strings, I am a bit
lost: Are there methods or functions to get substrings from a string,
or to take "spaces" ("blanks") away (a typical "wrap" function)??
About reading data from a text file, I think this is called "parsing".
Is there any "parsing" library???
Sorry if my questions are too naive, but I am a beginner.
Thank you very much in advance!
--
Vicent
Tom St Denis
Sounds more like you have a comp.sci problem than a C problem, as in
learn how to manipulate data first then pick a language to express it.
Also, pick a single language and go with it. There is no C/C++ or
whatever. If you want to learn how to manipulate strings in C++
that's fine but at what I'm guessing is your level I'd stick to one or
another, specially since they're not related.
Tom
Flash Gordon
> I posted this also in comp.lang.c++, so sorry for multiposting.
If you are using C++ then I believe C++ provides a lot more facilities
string facilities than C.
> I would like to ask you about standard or usual ways to manage with
> files or strings, specially when getting input data and writing output
> from an algorithm.
>
> I mean: which structures, data types or classes? Which standard ways
> to read/write from/on files?
C only has one string data structure (which is not a type), and that is
the nul terminated string. For input/output you have the functions in
stdio.h
A number of people have string libraries which they have written
themselves, which use more complex structures. However, these are not
standard.
> I've read some tutorials that deal with the standard C I/O and string
> (string.h) libraries,
That's what you get.
> but specially when managing strings, I am a bit
> lost: Are there methods or functions to get substrings from a string,
> or to take "spaces" ("blanks") away (a typical "wrap" function)??
Not in C. You either have to write your own or get a non-standard
library that someone else wrote.
> About reading data from a text file, I think this is called "parsing".
> Is there any "parsing" library???
Reading the text and parsing it are different tasks. Reading is getting
it in to memory, parsing is breaking it apart in to useful chunks. Some
functions, e.g. fscanf, do both tasks. Genreally in my opinion the best
way is often to read a line at a time in to memory and then parse the
line entirely in memory.
> Sorry if my questions are too naive, but I am a beginner.
The first thing you need to do is decide which language you are trying
to learn. If it is C++ then the best answers are likely to be very
different and could include classes or templates or something else which
C does not have.
--
Flash Gordon
Ersek, Laszlo
> I posted this also in comp.lang.c++, so sorry for multiposting.
>
> I would like to ask you about standard or usual ways to manage with
> files or strings, specially when getting input data and writing output
> from an algorithm.
>
> I mean: which structures, data types or classes? Which standard ways
> to read/write from/on files?
For C++, I guess you'd look first at std::string and std:iostream.
Google them, or obtain a draft or an actual edition of the ISO C++
standard (ISO/IEC 14882). A draft might be available at the C++
Standards Committee's site:
http://www.open-std.org/jtc1/sc22/wg21/
Chapter 21, Strings library
Chapter 27, Input/output library
The Qt or Boost libraries may prove helpful as well.
http://doc.trolltech.com/4.6-snapshot/qstring.html
http://www.boost.org/doc/libs/1_41_0/libs/libraries.htm#String
For C: don't start with it. Low-level string manipulation is one of the
most error-prone tasks in general, leading to countless security
vulnerabilities.
> I've read some tutorials that deal with the standard C I/O and string
> (string.h) libraries, but specially when managing strings, I am a bit
> lost: Are there methods or functions to get substrings from a string,
> or to take "spaces" ("blanks") away (a typical "wrap" function)??
(That would be a typical "trim" function I guess.) In my opinion, the
"string interface" provided by standard C (or by versions of the Single
Unix Specification) are much lower-level than you'd need; definitiely
not for a beginner with higher abstraction needs. I suggest you switch
to another language supporting high-level string manipulation (Perl,
Python, Ruby etc) or grab a strings library. A discussion on them
occurred on Reddit some time ago; several libraries were mentioned:
http://www.reddit.com/r/programming/comments/abh76/what_string_type_should_i_use_for_a_c_project
When posting to that topic, I stumbled upon the following comparison
page:
http://www.and.org/vstr/comparison
> About reading data from a text file, I think this is called "parsing".
> Is there any "parsing" library???
Especially in relation to parsing: don't start writing parsers in C. If
you must, stick to whole-line input (with bounded length) and regular
expressions. One such regex library is PCRE:
But the Single Unix Specification defines a regex facility too.
http://www.opengroup.org/onlinepubs/007908775/xsh/regex.h.html
If you insist on consuming lines of arbitrary length, consider the
getline() GNU libc extension.
http://www.gnu.org/s/libc/manual/html_node/Line-Input.html#Line-Input
Localized low-level text processing (put very crudely: anything
non-ASCII) requires even more caution, so don't start with that either.
Some C and C++ libraries should support it transparently, though.
HTH,
lacos
Vicent
> Sounds more like you have a comp.sci problem than a C problem, as in
> learn how to manipulate data first then pick a language to express it.
>
> Also, pick a single language and go with it. There is no C/C++ or
> whatever. If you want to learn how to manipulate strings in C++
> that's fine but at what I'm guessing is your level I'd stick to one or
> another, specially since they're not related.
>
> Tom
Tom,
Thank you for your answer.
I've chosen C++, because I need to program some algorithms and I think
it is a good choice for that purpose.
So, my problem is about how to read files in C++, I think.
Vicent
> If you are using C++ then I believe C++ provides a lot more facilities
> string facilities than C.
Yes, I realize of that...
> A number of people have string libraries which they have written
> themselves, which use more complex structures. However, these are not
> standard.
OK. I didn't know that, although I was suspecting it.
> Reading the text and parsing it are different tasks. Reading is getting
> it in to memory, parsing is breaking it apart in to useful chunks. Some
> functions, e.g. fscanf, do both tasks. Genreally in my opinion the best
> way is often to read a line at a time in to memory and then parse the
> line entirely in memory.
Yes, that was my idea, in fact --First, I read a line. Then, I try to
get the information from that line into some variables in my
algorithm.
> The first thing you need to do is decide which language you are trying
> to learn. If it is C++ then the best answers are likely to be very
> different and could include classes or templates or something else which
> C does not have.
I guess I'll stay with C++.
Thank you!
Eric Sosman
> [...]
> I've chosen C++, because I need to program some algorithms and I think
> it is a good choice for that purpose.
>
> So, my problem is about how to read files in C++, I think.
Perhaps the kind people on the comp.lang.c++ forum
would be better able to assist you with that language.
Since the I/O features of C++ differ quite a lot from
those of C, and since I/O is what you're interested in ...
--
Eric Sosman
eso...@ieee-dot-org.invalid
Vicent
> In article <f393377f-5123-4c26-8d19-d6e05eee0...@36g2000yqu.googlegroups.com>, Vicent <vgi...@gmail.com> writes:
> For C++, I guess you'd look first at std::string and std:iostream.
Thank you! That's a point to start.
> Google them, or obtain a draft or an actual edition of the ISO C++
> standard (ISO/IEC 14882). A draft might be available at the C++
> Standards Committee's site:
>
> http://www.open-std.org/jtc1/sc22/wg21/
>
> Chapter 21, Strings library
> Chapter 27, Input/output library
That's a great link!! Thanks.
> The Qt or Boost libraries may prove helpful as well.
>
> http://doc.trolltech.com/4.6-snapshot/qstring.htmlhttp://www.boost.org/doc/libs/1_41_0/libs/libraries.htm#String
>
Good links, also. :-)
> For C: don't start with it. Low-level string manipulation is one of the
> most error-prone tasks in general, leading to countless security
> vulnerabilities.
OK. Everyone tells me to avoid using C-strings, so...
>
> > I've read some tutorials that deal with the standard C I/O and string
> > (string.h) libraries, but specially when managing strings, I am a bit
> > lost: Are there methods or functions to get substrings from a string,
> > or to take "spaces" ("blanks") away (a typical "wrap" function)??
>
> (That would be a typical "trim" function I guess.)
Yes, yes, sorry, I meant "trim", not "wrap". I miss those simple
"trim" functions at Visual Basic and PL/SQL Oracle...
> In my opinion, the
> "string interface" provided by standard C (or by versions of the Single
> Unix Specification) are much lower-level than you'd need; definitiely
> not for a beginner with higher abstraction needs. I suggest you switch
> to another language supporting high-level string manipulation (Perl,
> Python, Ruby etc) or grab a strings library. A discussion on them
> occurred on Reddit some time ago; several libraries were mentioned:
>
> http://www.reddit.com/r/programming/comments/abh76/what_string_type_s...
>
> When posting to that topic, I stumbled upon the following comparison
> page:
>
> http://www.and.org/vstr/comparison
>
OK, that's all very interesting. I see that other people had the same
problem before me!
> > About reading data from a text file, I think this is called "parsing".
> > Is there any "parsing" library???
>
> Especially in relation to parsing: don't start writing parsers in C. If
> you must, stick to whole-line input (with bounded length) and regular
> expressions. One such regex library is PCRE:
>
> http://www.pcre.org/
>
> But the Single Unix Specification defines a regex facility too.
>
> http://www.opengroup.org/onlinepubs/007908775/xsh/regex.h.html
>
> If you insist on consuming lines of arbitrary length, consider the
> getline() GNU libc extension.
>
> http://www.gnu.org/s/libc/manual/html_node/Line-Input.html#Line-Input
>
> Localized low-level text processing (put very crudely: anything
> non-ASCII) requires even more caution, so don't start with that either.
> Some C and C++ libraries should support it transparently, though.
What I exactly need to do is the following:
While there are still new lines:
(1) Get one line from a given text file.
(2) In that line, detect a "first" part and a "second part", which are
separated by a "=" symbol.
(3) Take away the possible "blanks" (like a "trim" function would do)
from those parts.
(4) Detect which variable in my program is being referred by the
"first part".
(5) Translate the second part (it is still a "string") into a number.
- About #1 : It can be done by means of standard I/O C libraries. I
guess that there are also ways to do it with C++ libraries.
- About #2 : It would be as simple as: detecting the position of "="
and then get two substrings. I don't understand why this step is so
difficult to perform in C!!!! I mean: there IS a C standard function
for getting the position of a character (it is "strchr"), but not a
function for substring (unless it is a substring that starts at
position 1, which can be done with "strncpy_s"). Is it easier at C++??
- About #3 : I would only need an equivalent of VB's "trim"
function... Is there anything like that at C++?
- About #4 : I can do this by using a "case" or an "if" statement. No
problem at all with this step, provided that "first part" has been
successfully extracted and trimmed.
- About #5 : I hope that a proper casting statement will be enough.
So, do you think that C++ std::string and std:iostream classes are
the right choice for me??
Thank you in advance for your feed-back!!!
--
Vicent
Lorenzo Villari
la...@ludens.elte.hu (Ersek, Laszlo) wrote:
>
> For C: don't start with it. Low-level string manipulation is one of
> the most error-prone tasks in general, leading to countless security
> vulnerabilities.
>
I thought that was comp.lang.c...
Ersek, Laszlo
Please elaborate.
Thanks,
lacos
Lorenzo Villari
la...@ludens.elte.hu (Ersek, Laszlo) wrote:
>
> Please elaborate.
>
> Thanks,
> lacos
C is not perfect I know that, but saying "C: don't start with it" in a
newsgroup with this name, it sounds a bit strange to me. That's all.
Ersek, Laszlo
> (5) Translate the second part (it is still a "string") into a number.
>
> - About #5 : I hope that a proper casting statement will be enough.
Please read an introductory book or tutorial on C, preferably one not
contradicting the ISO C standard(s). I hope others will name such works.
Reddit had a similar discussion recently. I obviously can't vouch for
the pieces of advice given there.
http://www.reddit.com/r/programming/comments/au1fg/dear_proggit_what_book_would_you_recommend_for_a/
> So, do you think that C++ std::string and std:iostream classes are
> the right choice for me??
I don't know. For the stated purpose, in (not standard) C I'd likely use
fgets() with a 32,767 byte buffer, then call regexec() in order to
identify the trimmed parts via parenthesized subexpressions, then call
strtol() to convert the decimal sequence to a long int.
Cheers,
lacos
Ersek, Laszlo
Thanks for answering.
I love C (even though most of the time this love is unrequited). I
didn't intend to point out C's perceived "shortcomings" -- I hope not to
have an ego that big. I tried to signal that C (and especially
manipulation of character arrays for parsing purposes) might not be the
best choice for the *original poster*, following completely from what I
perceived to be the OP's understanding of C.
Someone advising against me operating a sawbench would be completely
justified. A sawbench is a wonderful tool. It's not the sawbench, it's
me. I should start with introductory woodworking lessons first.
(Yes, I just compared C to a sawbench, please forgive me. And for the
record, I can "operate" a hand saw.)
Cheers,
lacos
santosh
[...]
> What I exactly need to do is the following:
>
> While there are still new lines:
> (1) Get one line from a given text file.
> (2) In that line, detect a "first" part and a "second part", which are
> separated by a "=" symbol.
> (3) Take away the possible "blanks" (like a "trim" function would do)
> from those parts.
> (4) Detect which variable in my program is being referred by the
> "first part".
> (5) Translate the second part (it is still a "string") into a number.
>
> - About #1 : It can be done by means of standard I/O C libraries. I
> guess that there are also ways to do it with C++ libraries.
Yes. For C, fgets() is the obvious choice, but if you want to read in
lines of arbitrary length, then you might have to write your own
function which uses dynamically allocated memory.
> - About #2 : It would be as simple as: detecting the position of "="
> and then get two substrings. I don't understand why this step is so
> difficult to perform in C!!!! I mean: there IS a C standard function
> for getting the position of a character (it is "strchr"), but not a
> function for substring (unless it is a substring that starts at
> position 1, which can be done with "strncpy_s"). Is it easier at C++??
Your point #2 is not clear. Do you simply need to locate the first
occurence of a '=' character? For that purpose strchr() would be fine.
[...]
> - About #5 : I hope that a proper casting statement will be enough.
Atleast for C, no. Casting is not appropriate. Depending on what type
of number the "string" represents (i.e., integer or real), you'll want
to use one of the strto*() family of functions, like strtol() strtoul
() & strtod() to name three.
Here's a good online reference to Standard C library functions (among
others):
<http://www.dinkumware.com/manuals/>
[...]
santosh
> In article <4bd734c0-8413-4c4b...@g29g2000yqe.googlegroups.com>, Vicent <vgi...@gmail.com> writes:
>
> > (5) Translate the second part (it is still a "string") into a number.
> >
> > - About #5 : I hope that a proper casting statement will be enough.
>
> Please read an introductory book or tutorial on C, preferably one not
> contradicting the ISO C standard(s). I hope others will name such works.
One online tutorial for complete beginners might be the one by Steve
Summit:
<http://www.eskimo.com/~scs/cclass/cclass.html>
Since Mr. Summit was apparently involved in the standardisation
process of C90, one might trust his tutorial not to contradict
Standard C. :-)
[...]
Robert Latest
> On 26 ene, 15:20, la...@ludens.elte.hu (Ersek, Laszlo) wrote:
>> For C: don't start with it. Low-level string manipulation is one of the
>> most error-prone tasks in general, leading to countless security
>> vulnerabilities.
Depends. It can be fun and educative. See below.
>
>
> What I exactly need to do is the following:
>
> While there are still new lines:
> (1) Get one line from a given text file.
Use fgets() in a while loop.
> (2) In that line, detect a "first" part and a "second part", which are
> separated by a "=" symbol.
> (3) Take away the possible "blanks" (like a "trim" function would do)
> from those parts.
That's the fun part. You need a few simple loops to do this. I used to
do a lot of those string-walking exercises, so I just typed this into
the newsreader untested. It really helps you develop a sense of what
goes on behind the curtain.
for (p = buffer; *p && isspace(*p); ++p) ; /* skip initial WS */
first_part = p; /* save pointer */
for (; *p && *p != '='; ++p) ; /* find '=' */
for (q = p+1; *q && isspace(*q); ++q) ; /* skip more WS */
second_part = q; /* save pointer */
for (--p; isspace(*p); --p) ; /* skip trailing WS */
*(p+1) = 0; /* mark end of 1st */
for (p = second_part; *p; ++p) ; /* find \0 char */
for (--p; isspace(*p); --p) ; /* skip trailing WS */
now first_part and second_part should be nicely trimmed, NUL-terminated
C strings. This thing will probably segfault when fed invalid strings,
so some input validity checks are in order. This method can be driven to
the extreme; the nice thing is that everything happens in a single chunk
of memory ('buffer') which gets pointed into and peppered with zeroes.
If your first and second part can't contain whitespace, it boils down to
a sscanf() one-liner:
#include <stdio.h>
int main(void)
{
char *str = "abcd = 100 "; /* test string */
char first[20];
int second;
int r;
r = sscanf(str, " %[^ =] = %d", first, &second);
if (r == 2) {
printf("%s=%d\n", first, second);
} else {
fprintf(stderr, "Couldn't parse string (r=%d)\n", r);
}
return 0;
}
It would be wise to check for the position of the '=' sign first to make
sure that the buffer 'first' doesn't overflow.
> (4) Detect which variable in my program is being referred by the
> "first part".
A bsearch()-based solution comes to mind
> (5) Translate the second part (it is still a "string") into a number.
strtol(), or automatically done by sscanf()
> - About #2 : It would be as simple as: detecting the position of "="
> and then get two substrings. I don't understand why this step is so
> difficult to perform in C!!!!
> I mean: there IS a C standard function
> for getting the position of a character (it is "strchr"), but not a
> function for substring
strtok() can also be your friend. For index-based substrings, use
strdup() and pointer arithmetics. All one-liners.
> So, do you think that C++ std::string and std:iostream classes are
> the right choice for me??
It really depends on what the rest of your application does. If breaking
up a string into two parts overwhelms you complexity-wise, it probably
does very little.
That said, I nowadays greatly prefer Python over C for many things,
although I enjoy coding in C more. Especially when dealing with
undefined input, the necessary overhead of error-checking and -handling
in C (and C++) can be bothersome.
robert
Ersek, Laszlo
In article <7s92b...@mid.uni-berlin.de>, Robert Latest <bobl...@yahoo.com> writes:
> If your first and second part can't contain whitespace, it boils down to
> a sscanf() one-liner:
>
> #include <stdio.h>
> int main(void)
> {
> char *str = "abcd = 100 "; /* test string */
> char first[20];
> int second;
> int r;
>
> r = sscanf(str, " %[^ =] = %d", first, &second);
> if (r == 2) {
> printf("%s=%d\n", first, second);
> } else {
> fprintf(stderr, "Couldn't parse string (r=%d)\n", r);
> }
> return 0;
> }
>
> It would be wise to check for the position of the '=' sign first to make
> sure that the buffer 'first' doesn't overflow.
[...]
>> (5) Translate the second part (it is still a "string") into a number.
>
> strtol(), or automatically done by sscanf()
abcd=99999999999999999999999999999999999999999999999999999999
%d -> implementation-defined behavior ("signed overflow")
%u -> silent truncation ("unsigned overflow")
%*d -> assignment suppressed, not applicable here
%9ld -> file position indicator will advance until after the ninth nine
(I think), the stored long int value (999,999,999) won't reflect the
actual decimal string, a matching failure will follow only in the next
cycle. Full range of long int not available to decimal strings.
Magnitude of smallest negative value is about one tenth of the greatest
positive value.
strtol() is better.
When writing my previous post in the thread, I've tried to create a
scanf() format string that (a) relies only on completely defined
behavior, (b) is correct: parses what the OP needs (pre-set limits on
the lengths of the trimmed parts are allowed), (c) is complete: refuses
anything else. I gave up after a while and decided to wait for other
submissions and try to break them, or if I can't, learn from them.
Cheers,
lacos
Ersek, Laszlo
> abcd=99999999999999999999999999999999999999999999999999999999
>
> %d -> implementation-defined behavior ("signed overflow")
I apologize, that would hold for a conversion from eg. unsigned int; the
fscanf() spec says (C99 7.19.6.2 The fscanf function, p10):
----v----
Unless assignment suppression was indicated by a *, the result of the
conversion is placed in the object pointed to by the first argument
following the format argument that has not already received a conversion
result. If this object does not have an appropriate type, or if the
result of the conversion cannot be represented in the object, the
behavior is undefined.
----^----
See also
http://groups.google.com/group/comp.lang.c.moderated/msg/700a797a716cf74a
Cheers,
lacos
William Ahern
>
> For C: don't start with it. Low-level string manipulation is one of
> the most error-prone tasks in general, leading to countless security
> vulnerabilities.
>
I'm going to go out on a limb here and disagree. My first languages were
Perl and Javascript (circa Netscape Navigator 2.0). The problem with
languages that treat strings as _opaque_, discrete objects is that you lose
perspective of so many other important concerns, and can easily develop
horrible habits.
For one thing, a computer is similarly finite, and for "fixed sized" objects
that consume more memory than your computer, you must learn to treat them as
streams, or otherwise not so discrete.
Similarly in a networked environment (which predominates these days), where
one is simply not taking in discrete input (en toto) and generating discrete
output, that any particular string might be discrete is of lesser
consequence. Often it becomes preferable to view the inputs (even if line or
word oriented, as in HTTP and SMTP) as a stream of discrete, 1-byte strings
(i.e. bytes). But doing this in, say, Java or Perl is extremely cumbersome,
to say the least, because the notion of string is oriented to something on
the order of 32 to, let's say, 4k octet long pieces of data. (Very loosely
speaking, of course, but irrespective of whether we're talking about
fixed-length or variable-length string structures.) The languages' treatment
of integral objects isn't nearly so rich; there are no pointers, for
example.
This notion of the string is, I think, strongly influenced by functional
languages, where the characteristic of immutability strongly influences how
one emphasizes the process of data processing; and by history, where "line
oriented" record processing was a good computation/space balance given the
restrictions of the day. This can be very practical at times, but
increasingly less so in very important areas.
Anyhow, skipping ahead, my _point_ is that many security issues arise
because of how one conceives of their data structures. Programmers often
habitually prefer buffers (i.e. strings) as intermediate processing objects,
even when the particular circumstance doesn't call for it, and a stream or
byte oriented solution would be preferable (and would preclude many types of
buffer overruns). Learning which data structures are preferable means
learning their strengths and weaknesses, and learning their strengths and
weaknesses means using many different languages which highlight these
qualities in a data structure. Thus, it's not necessarily a bad idea to
learn C strings and related structures while learning them in other
languages simultaneously, or proximately so. There are opportunities for
learning concepts, and opportunities for acquiring habits, and one must be
careful about which opportunity they're taking advantage of.
Ersek, Laszlo
> One online tutorial for complete beginners might be the one by Steve
> Summit:
>
> <http://www.eskimo.com/~scs/cclass/cclass.html>
>
> Since Mr. Summit was apparently involved in the standardisation
> process of C90, one might trust his tutorial not to contradict
> Standard C. :-)
Bookmarked, thank you!
lacos
Nick Keighley
> On 26 ene, 15:20, la...@ludens.elte.hu (Ersek, Laszlo) wrote:
> > In article <f393377f-5123-4c26-8d19-d6e05eee0...@36g2000yqu.googlegroups.com>, Vicent <vgi...@gmail.com> writes:
> > For C++, I guess you'd look first at std::string and std:iostream.
>
> Thank you! That's a point to start.
so why are you still here?
:-)
seriously the answer to the question "how do i do string handling" is
radically different depending on whether you're using C++ or C. C++'s
string handling is far more sophisticated. With C you should probably
acquire (or write!) a decent string handling library. And if you've
got serious serious string handling problems consider a more string
oriented language.
<snip>
> > > I've read some tutorials that deal with the standard C I/O and string
> > > (string.h) libraries, but specially when managing strings, I am a bit
> > > lost: Are there methods
C has no "methods"
> > > or functions to get substrings from a string,
> > > or to take "spaces" ("blanks") away (a typical ["trim"] function)??
no not really
<snip>
> What I exactly need to do is the following:
get hold of a decent tutorial
eg. http://en.wikipedia.org/wiki/The_C_Programming_Language_(book)
and an online reference
eg. http://www.dinkumware.com/manuals/
> While there are still new lines:
> (1) Get one line from a given text file.
fgets()
> (2) In that line, detect a "first" part and a "second part", which are
> separated by a "=" symbol.
> (3) Take away the possible "blanks" (like a "trim" function would do)
> from those parts.
> (4) Detect which variable in my program is being referred by the
> "first part".
> (5) Translate the second part (it is still a "string") into a number.
sscanf() can do most of this (not step 4 though!)
int first;
char second [MAX_SIZE_SECOND];
if (sscanf (line, "%s = %d", &first, second) != 2)
{
/* report error */
}
else
{
/* process stuff */
}
> - About #1 : It can be done by means of standard I/O C libraries. I
> guess that there are also ways to do it with C++ libraries.
for C++ answers ask in comp.lang.c++ !
> - About #2 : [...]
> there IS a C standard function
> for getting the position of a character (it is "strchr"), but not a
> function for substring (unless it is a substring that starts at
> position 1, which can be done with "strncpy_s").
don't use strncpy() use strcpy() (or sscanf()!)
[...]
> - About #4 : I can do this by using a "case" or an "if" statement.
yes.
> No
> problem at all with this step, provided that "first part" has been
> successfully extracted and trimmed.
>
> - About #5 : I hope that a proper casting statement will be enough.
no casting won't help you. Use sscanf() or strtod() (or one of its
friends)
<snip>
Nick Keighley
wrote:
> sscanf() can do most of this (not step 4 though!)
>
> int first;
> char second [MAX_SIZE_SECOND];
>
> if (sscanf (line, "%s = %d", &first, second) != 2)
> {
> /* report error */
> }
> else
> {
> /* process stuff */
> }
oops!
char first [MAX_LINE_LENGTH];
int second;
if (sscanf (line, "%s = %d", first, &second) != 2)
{
/* report error */
}
else
{
/* process stuff */
}
"line" is of course the previously read input line
Nick Keighley
wrote:
> On 26 Jan 2010 15:20:07 +0100 la...@ludens.elte.hu (Ersek, Laszlo) wrote:
>
> > For C: don't start with it. Low-level string manipulation is one of
> > the most error-prone tasks in general, leading to countless security
> > vulnerabilities.
>
> I'm going to go out on a limb here and disagree. My first languages were
> Perl and Javascript (circa Netscape Navigator 2.0). The problem with
> languages that treat strings as _opaque_, discrete objects is that you lose
> perspective of so many other important concerns, and can easily develop
> horrible habits.
nice post. Interesting and thought provoking.
<snip>
Keith Thompson
[...]
> no casting won't help you. Use sscanf() or strtod() (or one of its
> friends)
The problem with using the *scanf() family for numeric conversion is
that the behavior on overflow is undefined. The strto*() functions
don't have this problem.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Phil Carmody
No, that leads to countless insecurities instead.
Phil
--
Any true emperor never needs to wear clothes. -- Devany on r.a.s.f1
Nick Keighley
> Nick Keighley <nick_keighley_nos...@hotmail.com> writes:
> > no casting won't help you. Use sscanf() or strtod() (or one of its
> > friends)
>
> The problem with using the *scanf() family for numeric conversion is
> that the behavior on overflow is undefined. The strto*() functions
> don't have this problem.
yes I forgot that (seems a bit of an oversight- if the library has the
machinary available to detect overflow why not use it in scanf()?). he
seemed like he was parsing a noddy .ini file or some such and I
thought a scanf() solution might be good enough for him.
Lorenzo Villari
Phil Carmody <thefatphi...@yahoo.co.uk> wrote:
>
> No, that leads to countless insecurities instead.
>
No what? Read the other reply for what I really meant.
Phil Carmody
> On Thu, 28 Jan 2010 11:39:57 +0200
> Phil Carmody <thefatphi...@yahoo.co.uk> wrote:
>
>>
>> No, that leads to countless insecurities instead.
>
> No what?
If you cast off all context so quickly, you will often not understand.
Lorenzo Villari
Phil Carmody <thefatphi...@yahoo.co.uk> wrote:
>
> If you cast off all context so quickly, you will often not understand.
>
Even in context I don't understand that one:
On Thu, 28 Jan 2010 11:39:57 +0200
Phil Carmody <thefatphi...@yahoo.co.uk> wrote:
> Lorenzo Villari <vll...@tiscali.it> writes:
> > On 26 Jan 2010 15:20:07 +0100
> > la...@ludens.elte.hu (Ersek, Laszlo) wrote:
> >
> >>
> >> For C: don't start with it. Low-level string manipulation is one of
> >> the most error-prone tasks in general, leading to countless
> >> security vulnerabilities.
> >
> > I thought that was comp.lang.c...
>
> No, that leads to countless insecurities instead.
>
"No" I think is opposed to "yes" and that would mean I suppose, you
meant I was saying that what Ersek, Laszlo wrote was wrong, which is
not what I meant and I've explained that in another reply. Am I right?
Phil Carmody
> On Thu, 28 Jan 2010 20:59:46 +0200
> Phil Carmody <thefatphi...@yahoo.co.uk> wrote:
>
>> If you cast off all context so quickly, you will often not understand.
>
> Even in context I don't understand that one:
>
> On Thu, 28 Jan 2010 11:39:57 +0200
> Phil Carmody <thefatphi...@yahoo.co.uk> wrote:
>
>> Lorenzo Villari <vll...@tiscali.it> writes:
>> > On 26 Jan 2010 15:20:07 +0100
>> > la...@ludens.elte.hu (Ersek, Laszlo) wrote:
>> >
>> >>
>> >> For C: don't start with it. Low-level string manipulation is one of
>> >> the most error-prone tasks in general, leading to countless
>> >> security vulnerabilities.
>> >
>> > I thought that was comp.lang.c...
>>
>> No, that leads to countless insecurities instead.
>
> "No" I think is opposed to "yes" and that would mean I suppose, you
> meant I was saying that what Ersek, Laszlo wrote was wrong, which is
> not what I meant and I've explained that in another reply. Am I right?
No was indeed disagreement. However 'that' refers to the most
recently mentioned noun - namely 'comp.lang.c'.