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

[Dave Thompson]

On Sun, 20 Jul 2003 16:52:40 GMT, qe*@pobox.com (Paul Hsieh) wrote:

[casting fread() as if it took void* rather than FILE*, or wrapping]

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.
I'm going to treat your question as limited to pointers to different
data types; as Chris T notes downthread in C functions are in the type
system, and pointer to function is a kind of pointer, but that's not
relevant to this issue.

In addition to the usually-cited DG Eclipse and I'm pretty sure Nova,
I believe some Pr1me's had word pointers different from byte pointers.
But I doubt many are still in use, especially using C.

PDP-10 does have a different format, but the word-address bits
coincide, so writing a correctly-aligned byte pointer and using it as
a word pointer would actually work. (And there are still some clone
machines and a very few restored ones operating; the original C
compilers for this machine were long pre-Standard, but last year a gcc
port was reported to be in work!)

I do have experience of one platform that arguably still exists: the
original Tandem NonStop, aka T-16 or TNS1, had different byte and word
(16-bit) pointers. Tandem's next architecture step, the TNS2, added
byte (32-bit) "extended" pointers to everything, but still supported
"standard" 16-bit pointers. And the only-then-supported C compiler
used a word pointer for anystruct* -- so all structs were aligned and
padded at least to a two-byte boundary, even if their contents didn't
require it -- while of course void* had to be a byte pointer.

Then Tandem^WCompaq^WHP went to a RISC (MIPS) CPU, TNSR, which also
emulates TNS1 and TNS2, and the toolchain therefor is still supported
("nonnative" compiler, here in "small" model) -- and I know people who
are still compiling and running code written in the days when TNS2 was
new and extended addresses inefficient, containing 16-bit pointer
conversions that shift left and right one bit, and would fail horribly
if they didn't. They don't write new programs this way, but when they
need to make relatively small changes to (often quite large) existing
systems, they keep the existing architecture, and if they wanted to
add your code in such a environment it would fail.

[...] 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.)

Not, on most (reasonable) implementations, if you put it in a separate
source file/translation unit and hence a separate .o in the .a.

Alternatively, since you're distributing as source, just put it in a
separate file that the user can choose to compile or not.

Although, on many systems nowadays, the whole standard library (and
often quite a bit more) is always there even if you don't use it.
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.

This is a much more compelling argument to me. If it's out of your
intended scope, leave it out -- especially as it's trivial.

- David.Thompson1 at worldnet.att.net

[Paul Hsieh]

Dave Thompson <da*************@worldnet.att.net> wrote:

On Sun, 20 Jul 2003 16:52:40 GMT, qe*@pobox.com (Paul Hsieh) wrote:
[casting fread() as if it took void* rather than FILE*, or wrapping]

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.
I'm going to treat your question as limited to pointers to different
data types; as Chris T notes downthread in C functions are in the type
system, and pointer to function is a kind of pointer, but that's not
relevant to this issue.

In addition to the usually-cited DG Eclipse and I'm pretty sure Nova,
I believe some Pr1me's had word pointers different from byte pointers. [...]
PDP-10 does have a different format, but the word-address bits
coincide, so writing a correctly-aligned byte pointer and using it as
a word pointer would actually work. [...] I do have experience of one
platform that arguably still exists: the original Tandem NonStop, aka T-16
or TNS1, had different byte and word (16-bit) pointers. Tandem's next
architecture step, the TNS2, added byte (32-bit) "extended" pointers to
everything, but still supported "standard" 16-bit pointers. [...]

An interesting walk down the bowel of forgotten computer history ...
just out of curiosity, how many of these have C99 compliant C
compilers on them, and of those that don't how many are planned or
known to be in the works (that still suffer from these different
pointer representation problems)?

[...] 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.)

Not, on most (reasonable) implementations, if you put it in a separate
source file/translation unit and hence a separate .o in the .a.

Well, I prefer the one file approach for this library as I use shared
static functions that I neither want to maintain in duplicate nor
expose outside of the bstrlib module. Also, if its implemented in too
many files, then it would motivate me to make scripts/makefiles for
building libraries which are platform specific.
Alternatively, since you're distributing as source, just put it in a
separate file that the user can choose to compile or not.

Well since it was brought up, I have now put it in the documentation.
People running Novas and Tandem NonStop computers who really have a
burning desire to do new development with the bstring library can
transcribe it from there (I hesitate to say "cut and paste", as that
concept might not exist in that universe ...)

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

[Kevin Easton]

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

Well since it was brought up, I have now put it in the documentation.
People running Novas and Tandem NonStop computers who really have a
burning desire to do new development with the bstring library can
transcribe it from there (I hesitate to say "cut and paste", as that
concept might not exist in that universe ...)

Don't look now, but you're relying on a benign manifestation of
undefined behaviour - ie. if the C Standard was more strict about
constraint violations and required a run-time error to be thrown, as
some other languages do, then it wouldn't be doable :D.

- Kevin.

[Arthur J. O'Dwyer]

On Wed, 30 Jul 2003, Paul Hsieh wrote:

Kevin Easton <[e-mail]> wrote:

Paul Hsieh <qe*@pobox.com> wrote:
[re: Paul's use of undefined behavior in, I suppose, the bstring
library. He tried to call fread() with an incorrect prototype, or
something, which in my limited experience seems like a really dumb
and completely avoidable thing to do]

Well since it was brought up, I have now put it in the documentation.
People running Novas and Tandem NonStop computers who really have a
burning desire to do new development with the bstring library can
transcribe it from there (I hesitate to say "cut and paste", as that
concept might not exist in that universe ...)

Don't look now, but you're relying on a benign manifestation of
undefined behaviour - ie. if the C Standard was more strict about
constraint violations and required a run-time error to be thrown, as
some other languages do, then it wouldn't be doable :D.

The ANSI C standard is an inadequate standard. It is important to
recognize when the standard has failed us and promote an alternative
defacto standard behavior when it is correct to do so.

Hee hee!

Why not just fix the bug, instead of attacking the standard?
We all know how you wish ISO had provided your precious ROL opcode
with its own operator, but as far as I can tell this bug has nothing
to do with defects (real or perceived) in the Standard; it's just
a bug introduced by a faulty cast. Fix the program and the bug will
go away.

Also, this whole "promote an alternative de facto standard behavior"
thing is silly. How are *you* going to promote the alternative behavior
(presumably, using the same representation for (void *) as (FILE *))?
*You* aren't the compiler writer. Might as well try to "promote" the
"alternative standard" of 2+2=5 by replacing all occurrences of '5'
in your code.

-Arthur