strcmp but with '\n' as the terrminator

[Allan Bruce]

Hi there,
I am reading a file into a char array, and I want to find if a string exists
in a given line.
I cant use strcmp since the line ends with '\n' and not '\0'. Is there a
similar function that will do this, or will I have to write my own?
Thanks
Allan

[Richard Heathfield]

Paul Hsieh wrote:

<snip>

Well, I think the first thing is to realize that the C library is just
pure
digital diarrhea, especially for strings.
Please do not present your opinions, however dearly held, as if they are
facts.
The implicit requirement to
scan for the end of the string implicit in most of the string library
belies is propensity for being slow, a haven for buffer overflows, and
generally just the wrong set of primitives for string manipulation.

And yet a goodly number of C programmers manage perfectly well with
null-terminated strings in their fast, well-written code. Don't assume your
own experience is universal, and don't blame the library for /your/ buffer
overflows. If you don't like C, and you clearly don't, then why not just
use something else instead?

<snip>

--
Richard Heathfield : bi****@eton.pow ernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[Malcolm]

"Paul Hsieh" <qe*@pobox.co m> wrote in message

Well, I think the first thing is to realize that the C library is just pure digital diarrhea, especially for strings. The implicit requirement to scan for the end of the string implicit in most of the string library belies is
propensity for being slow, a haven for buffer overflows, and generally just > the wrong set of primitives for string manipulation. The functions are easy to implement, which is often important. Usually
performance in string manipulation isn't too important, since a string is
usually either input or output, and IO overhead is so large that a bit of
processing inefficiency isn't noticeable.
Finally, for better or for worse C has built in support for NUL-terminated
strings.
If your whole purpose is just to read the string off the disk as fast as
possible, then parse later, then I would recommend trying out my string
library.

I'm sure your string library is well-written, is an improvement over the C
string library, deserves to be accepted as an ANSI standard, etc.
However the problem is that it hasn't yet gained wide acceptance, so anyone
trying to understand how the code works first has to read and understand
your library documentation.
I won't say "don't use it", it might well be an advantage, particularly for
a large string-intensive project. However the issue isn't a clear-cut as you
seem to suggest.

[Kevin Easton]

Paul Hsieh <qe*@pobox.co m> wrote:
[...]

If your whole purpose is just to read the string off the disk as fast as
possible, then parse later, then I would recommend trying out my string
library (http://bstring.sourceforge.net) as it should lead to a much
simpler solution:

#include "bstrlib.h"
#include "bstraux.h"

bstring b = bread ((bNread) fread, fptr); /* Read the whole file */

bNRead is defined thus in bstrlib.h:

typedef size_t (* bNread) (void *buff, size_t elsize, size_t nelem,
void *parm);

....and bread in part:

bstring bread (bNread readPtr, void * parm) {
/* ... */
l = readPtr ((void *) (buff->data + i), 1, n - i, parm);

When you make the bread() call in your example, bread has undefined
behaviour here, because it calls the fread function through an
incorrectly-typed function pointer. bread is passing a void *, but
fread is prototyped as accepting a FILE * as that formal parameter, and
the incorrectly-typed function pointer means there is no conversion.

To do this correctly, you must define an intermediate function:

#include <stdio.h>
#include "bstrlib.h"
#include "bstraux.h"

size_t bfread (void *buff, size_t elsize, size_t nelem, void *parm)
{
return fread(buff, elsize, nelem, parm);
}

....and now the call:

bstring b = bread (bfread, fptr); /* Read the whole file */

is OK (the conversion from FILE * to void * happens at the call to
bread, coerced by the bread prototype, and the conversion from void *
back to FILE * occurs at the call to fread, coerced by the fread
prototype).

Perhaps you should include this wrapper function for fread in your
library, since reading from FILE * is likely to be quite common?

I think you should also reflect on the fact that even the creator of
bstring can't seem to post simple examples using it that don't have
errors.

- Kevin.

[Paul Hsieh]

In article <ne************ ********@tomato .pcug.org.au>, kevin@-nospam-
pcug.org.au says...

Paul Hsieh <qe*@pobox.co m> wrote:
[...]

If your whole purpose is just to read the string off the disk as fast as
possible, then parse later, then I would recommend trying out my string
library (http://bstring.sourceforge.net) as it should lead to a much
simpler solution:

#include "bstrlib.h"
#include "bstraux.h"

bstring b = bread ((bNread) fread, fptr); /* Read the whole file */
bNRead is defined thus in bstrlib.h: [...]

Yes, I am aware of this issue; I have made a note of this in my documentation.
I am blatantly recommending that people break the ANSI rules for this. BTW,
can you name me at least one platform where this actually ends up being an
issue? I would like to make a note of it in my documentation, but I don't seem
to have ever encountered a platform which implemented pointers for one type
different from pointers of another type. In fact I am suspicious as to whether
such a platform exists.
[...] Perhaps you should include this wrapper function for fread in your
library, since reading from FILE * is likely to be quite common?
A possibility, but then it would force your program to link with file
manipulation functions (or at least fgetc and fread.)

I know this is difficult to understand, but bstring is a *STRING LIBRARY*. It
is *NOT* a file library, and makes absolutely no impositions on the
implementation of file streams whatsoever, while still being able to use them.

I.e., if someone decided that C's file functions are worthless in the same way
that I decided that C's string library functions are worthless, and used the
same philosophy that I did with bstring, then that library should be able to
work together with my library with no issue (even without having awareness of
the existence of bstrlib). I.e., neither of us would have to go through hoops
to interoperate, since we would have both exposed C-library sematic compatible
mechanisms.

Same thing is true of regexp's or other parsing libraries -- bstring will work
well with them.
I think you should also reflect on the fact that even the creator of
bstring can't seem to post simple examples using it that don't have
errors.

Apparently that's par for the course for source code posted here. Obviously,
the original should download the documentation and read it before using the
bstring library where this function prototype coercion ANSI problem is
explained.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sourceforge.net/

[James Antill]

On Sun, 20 Jul 2003 07:50:23 +0000, Richard Heathfield wrote:

And yet a goodly number of C programmers manage perfectly well with
null-terminated strings in their fast, well-written code. Don't assume your

Please give examples, because...

http://www.and.org/vstr/security.html#reason

....doesn't agree with you at all, and it does provide examples where very
competent people didn't manage it.

--
James Antill -- ja***@and.org
Need an efficent and powerful string library for C?
http://www.and.org/vstr/

[Paul Hsieh]

In article <bf**********@n ewsg4.svr.pol.c o.uk>, ma*****@55bank. freeserve.co.uk
says...

"Paul Hsieh" <qe*@pobox.co m> wrote in message

Well, I think the first thing is to realize that the C library is just
pure digital diarrhea, especially for strings. The implicit requirement to
scan for the end of the string implicit in most of the string library
belies is propensity for being slow, a haven for buffer overflows, and
generally just the wrong set of primitives for string manipulation.
The functions are easy to implement, which is often important.

And very difficult to implement for speed. I've optimized strlen () by itself
several times based on various ideas I've had or which have been given to me.
I can beat the strlen performance of nearly every C library written by a huge
margin, and still its an embarrasement as being necessarily O(n), when there is
no sensible reason not to be O(1).
[...] Usually
performance in string manipulation isn't too important, since a string is
usually either input or output, and IO overhead is so large that a bit of
processing inefficiency isn't noticeable.
You obviously haven't been introduced to the world of XML, HTML, or ASN1. You
probably have never considered how to implement a fast and space efficient
spell checker, text editor, or database either. Of course you could just
concede that C is the wrong tool for those jobs ...
Finally, for better or for worse C has built in support for NUL-terminated
strings.

If your whole purpose is just to read the string off the disk as fast as
possible, then parse later, then I would recommend trying out my string
library.
I'm sure your string library is well-written, is an improvement over the C
string library, deserves to be accepted as an ANSI standard, etc.

Well, I don't quite see things that way. The C ANSI committee are the group of
people who did *NOT* deprecate gets() and added C++ namespace conflicting
complex numbers which is suitable for numerical computationalis t, and worthless
to number theorists (i.e., no complex integers) when they had the opportunity
in the C99 Spec. Whether or not my library is endorsed or considered by them
.... I mean these people are totally irrational, what motivation would or should
I have to submit my library to the ANSI C committee?

And you don't have to *speculate* as to whether or not its well written or not;
the source is fairly small, you can look at it yourself.
However the problem is that it hasn't yet gained wide acceptance, so anyone
trying to understand how the code works first has to read and understand
your library documentation.
The library is only 7 months old, there is a lot of competition from other
string libraries out there and apparently I'm not much of an advertiser. This
seems like a poor rationale for deciding whether or not an extension should be
added to the C standard -- and it clearly was not used for adding floating
point complex numbers.
I won't say "don't use it", it might well be an advantage, particularly for
a large string-intensive project. However the issue isn't a clear-cut as you
seem to suggest.

You cannot buffer overflow with my library unless you are trying really really
hard to do so. With the C library its fairly difficult *NOT* to buffer
overflow. I.e., I would claim that using my library is suitable for *ANY*
amount of string manipulation, if for no other reason than to mitigate the
buffer overflow problem that goes hand in hand with the C library's string
functions.

Squashing this bug alone would probably save Microsoft alone millions in
development costs.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sourceforge.net/

[Richard Heathfield]

James Antill wrote:

On Sun, 20 Jul 2003 07:50:23 +0000, Richard Heathfield wrote:

And yet a goodly number of C programmers manage perfectly well with
null-terminated strings in their fast, well-written code. Don't assume
your

Please give examples, because...

http://www.and.org/vstr/security.html#reason

...doesn't agree with you at all, and it does provide examples where very
competent people didn't manage it.

On the contrary, the page doesn't disagree with me at all. It advocates good
practice with respect to buffer management, and I certainly agree with
that. It also points out the limitations of fixed size buffers, and I agree
there too.

As for null-terminated strings, why, the page doesn't even mention the term.

I think you've misunderstood the intent of the author of that page. Why
don't you ask him what he really meant to say? ;-)

--
Richard Heathfield : bi****@eton.pow ernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[Malcolm]

"Paul Hsieh" <qe*@pobox.co m> wrote in message

You obviously haven't been introduced to the world of XML, HTML, or
ASN1. You probably have never considered how to implement a fast and
space efficient spell checker, text editor, or database either. Of course you could just concede that C is the wrong tool for those jobs ...
I'm a games programmer so I don't generally do text-intensive apps.
However I use Internet Explorer. With a dial-up connection such I have at
home it often takes about two seconds for a page to load. With such an
overhead, no amount of efficiency in the string library is going to make any
noticeable difference.
With a spell checker, the problem would seem to be searching the dictionary.
I don't see how avoiding NUL-terminated strings is going to make a vast
improvement.
I have written a text editor - it was an assignment. I stored the text as a
linked list of lines, and performance was fine. If you try to store
everything as one ASCIIZ string then you are admittedly asking for trouble.
I have been warned "never to bullshit your way into a database job" so I'll
withhold comment on this.
... I mean these people are totally irrational, what motivation would or
should I have to submit my library to the ANSI C committee?
Because then everyone would use your library, you would be famous, and you
could write a book "Notes on Using the Extended String Library" and make a
nice amount of money. As happened with the Standard Template Library.
the buffer overflow problem that goes hand in hand with the C library's
string functions.

Squashing this bug alone would probably save Microsoft alone millions in
development costs.

If you program in C you have to get used to the fact that arrays don't have
bounds checking.
It is also tempting to write code that uses fixed "big enough" buffers. I
will often do this for an internal tool. Since the program is meant for
internal use only, no-one is going to try to find weaknesses in it to
exploit.
In practise I haven't found string buffer overflows to be much of a problem.

[Kevin Easton]

Paul Hsieh <qe*@pobox.co m> wrote:

In article <ne************ ********@tomato .pcug.org.au>, kevin@-nospam-
pcug.org.au says...

Paul Hsieh <qe*@pobox.co m> wrote:
[...]

> If your whole purpose is just to read the string off the disk as fast as
> possible, then parse later, then I would recommend trying out my string
> library (http://bstring.sourceforge.net) as it should lead to a much
> simpler solution:
>
> #include "bstrlib.h"
> #include "bstraux.h"
>
> bstring b = bread ((bNread) fread, fptr); /* Read the whole file */

bNRead is defined thus in bstrlib.h: [...]

Yes, I am aware of this issue; I have made a note of this in my documentation.
I am blatantly recommending that people break the ANSI rules for this. BTW,
can you name me at least one platform where this actually ends up being an
issue? I would like to make a note of it in my documentation, but I don't
seem to have ever encountered a platform which implemented pointers for one
type different from pointers of another type. In fact I am suspicious as
to whether such a platform exists.

The Data General Eclipse had different representations for word and byte
pointers - converting from one to the other required a shift and mask,
so accessing one as the other without conversion would lead to
unpredictable results.

Since you ask about any kind of pointers, not just pointers to object
types, there are several platforms where function pointers are larger
(in some cases, *much* larger) than object pointers - this is why
conversions between function pointer and object pointer types aren't
defined.

Anyway, once upon a time all the world was a VAX - I don't plan on
repeating the mistakes of the past. Why should people write this
erroneous code, when there is a simple, correct alternative?

[...] Perhaps you should include this wrapper function for fread in your
library, since reading from FILE * is likely to be quite common?

A possibility, but then it would force your program to link with file
manipulation functions (or at least fgetc and fread.)

OK - you'd like it to be portable to non-hosted implementations . Fair
enough. Since the requisite function is a one-liner anyway, you can
just include it in the documentation for people to copy and paste if
they need it.

- Kevin.

[Chris Torek]

In article <ne************ ********@tomato .pcug.org.au>
Kevin Easton <[e-mail]> writes, in part:

The Data General Eclipse had different representations for word and byte
pointers - converting from one to the other required a shift and mask ...
Just a shift, actually -- the bits are carefully arranged with ring
and segment numbers offset by one bit, so that a one-bit shift
serves to convert one into the other. The "word" is a 16-bit word,
so a byte pointer has one extra low-order bit that must be introduced
or discarded as necessary. The top bit of a word pointer is a
special "indirect" bit that is not used in C at all (so it can be
discarded without loss of information).
Anyway, once upon a time all the world was a VAX - I don't plan on
repeating the mistakes of the past.

Indeed, we see this happening today with the introduction of 64-bit
architectures. All of the "ILP32 vs LP64" items that were posted
a short while ago are wonderful examples of assuming "all the
world's an i386 or other 32-bit, byte-oriented processor". The C
language proper does not assume this, and if you (the generic "you")
also avoid assuming it, your code will work on both ILP32 *and*
LP64 machines, with no source-level changes required.

(As usual, those who do not learn from history are doomed to repeat
it. :-) )
--
In-Real-Life: Chris Torek, Wind River Systems (BSD engineering)
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://67.40.109.61/torek/index.html (for the moment)
Reading email is like searching for food in the garbage, thanks to spammers.