strlen

strlen is wrong because can not report if there is some error
e.g.
char *a;
and "a" point to an array of size=size_t max that has no 0 in it

re: strlen

¬a\/b said:
How did you get through the clown filter, I wonder?

Well, never mind that - I'll fix it in a second. But you're wrong about
strlen (no surprise there). It is defined to work on strings. If you
pass it something that is not a string, the behaviour is undefined. You
cannot expect strlen to do a job that it is not intended to do. It is
like complaining at a potato peeler for being unable to peel a diamond.

Looks like I need a tighter lid on the bozo bin.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

re: strlen

¬a\/b wrote:strlen is defined on strings. A string has a 0 char terminating it. It
is not strlen that is wrong but the incompetent programmer.

re: strlen

In article <52nkd353do091mlls7hlmb4vmu4maui2qo@4ax.com>, ¬a\\/b <al@f.gwrote:Then "a" considered as a string that is longer than (size_t)-1 and the
definition of size_t specifically says that the behaviour of
C is undefined if you manage to allocate an object larger than
size_t can count.

If "a" does not in fact have a terminating 0, then no matter what
size it is, it is a programming error to pass it to strlen.

If the behaviour of strlen proves to be an actual problem for your
system (e.g., if you are working in an environment that can
only allocate 64 Kb at most), then you can write a replacement
user-space function that has whatever error-signaling semantics
are appropriate.
--
Programming is what happens while you're busy making other plans.

re: strlen

Richard Heathfield wrote:Didn't get through mine - until you opened the door!

--
Ian Collins.

re: strlen

¬a\/b wrote:You are right. We are trying to fix this. Just wait a minute, we will be
soon there.

re: strlen

On Sun, 02 Sep 2007 03:18:11 -0400, Martin Ambuhl wrote:you have right only if the programmer never make errors
are you a programmer of that kind?

if strlen sees some problem it has to report an error
example return (size_t)-1 and not continue to run

if there is strlen(0); it has to report the error and not shut down
the system

So if i want to hang some of your pragrams i have just give a string
of size_t max len that has 1111111111111111111111111111111111111111
etc in it because for these string, there is the chance strlen should
result in an infinite loop (or ggets or fgets or what you want).

the idea is *all* functions should can to report errors if they see
these errors (and the programmer has to see if something goes wrong
until it is printf)

re: strlen

On Sun, 02 Sep 2007 06:58:49 +0000, Richard Heathfield
<rjh@see.sig.invalidwrote:
yes it is possible i'm like a clown :)
nothing to say

re: strlen

On Sun, 02 Sep 2007 18:31:26 +0200, ¬a\\/b wrote:
Usually, the only way of getting such invalid data into a program is to
link to it as a library. And all bets are off at that point, anyway: I
could hang your program by dancing all over memory.

B.

re: strlen

On 02 Sep 2007 17:00:49 GMT, Rob Kendrick wrote:
what is the "program"?

re: strlen

On Sun, 02 Sep 2007 03:18:11 -0400, Martin Ambuhl wrote:you have right only if the programmer never make errors
are you a programmer of that kind?

if strlen sees some problem it has to report an error
example return (size_t)-1 and not continue to run

if there is strlen(0); it has to report the error and not shut down
the system

So if i want to hang some of your pragrams i have just give a string
of size_t max len that has 1111111111111111111111111111111111111111
etc in it because for these string, there is the chance strlen should
result in an infinite loop (or ggets or fgets or what you want).

the idea is *all* functions should can to report errors if they see
these errors (and the programmer has to see if something goes wrong
until it is printf)

re: strlen

On Mon, 03 Sep 2007 18:15:42 +0200, ¬a\\/b wrote:
How about this: No conforming C program will pass anything other than a
string to strlen(). Thus, it is the program's fault, not the language's
or the C library's.

B.

re: strlen

Rob Kendrick wrote:If there is an error it's the programmer's fault, not the
language that allows such badly designed functions like
strlen to exist.

re: strlen

In article <kocod3hp1k15ur42d65ourh8mrqjufhj46@4ax.com>, ¬a\\/b <al@f.gwrote:
No it doesn't. Or are you saying that's how it should be?
That may be your idea, but it's not C's.

-- Richard

--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

re: strlen

On Mon, 03 Sep 2007 19:04:13 +0200, jacob navia
<jacob@jacob.remcomp.frwrote:
You don't get it, Jacob: ANSI/ISO C is consider sacred.


K. H.

--

E-mail: info<at>simple-line<Punkt>de

re: strlen

On Mon, 03 Sep 2007 18:15:42 +0200, "¬a\\/b" <al@f.gwrote:
Since SIZE_MAX can be a valid return value from strlen on some
systems, that wouldn't seem to work.

How would you have strlen detect this problem without invoking
undefined behavior?

Why stop with strlen? What about strcat? And the string search
functions? By your logic, the subscript operators should do range
checking. As should the is-- functions. And the division operator
should check for 0. Maybe bsearch should verify the array is sorted.
Where does it stop?

Remove del for email

re: strlen

In article <b8god3hg2f979ikv0ktp4i00gsn5nvj1ra@4ax.com>,
Karl Heinze <nomail@invalidwrote:By some.

And some people consider the oil stain on their driveway that (they
think) looks like Jesus to be sacred.

Doesn't prove much.

re: strlen

¬a\/b wrote:I can't imagine myself writing a program that would
check the return value of a function
to see if invalid arguments had been passed,
instead of writing the program
to ensure that the arguments were valid,
prior to making the function call.

--
pete

re: strlen

>>strlen is wrong because can not report if there is some error

strlen() has no way to report errors, according to its definition
in Standard C.

strlen() may well have no way to *detect* the error of an unterminated
string without causing undefined behavior (aborting the program with
a smegmentation fault, for example. And nobody said a smegmentation
fault has to be a catchable error).
How does one *detect* such an error? Especially if a + size_t max is
off the end of allocated memory?
That's not what Standard C says.
It can either return or not continue to run; it can't do both.
That's not what Standard C says. And there's a difference between
shutting down the *program* (e.g. with smegmentation fault), and
shutting down the *system* (e.g. with blue screen of death or panic:
out of swap space).
I'd be interested in how functions like exit() and abort() report errors,
and how a programmer checks for errors.

re: strlen

On Mon, 03 Sep 2007 19:17:15 +0200, in comp.lang.c , Karl Heinze
<nomail@invalidwrote:
I recall the old saying:
"its a bad workman who blames his tools."

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

re: strlen

>I can't imagine myself writing a program that wouldOk, try this one. How would you verify this call before making it?

#include <stdio.h>
....
FILE *f;

f = fopen("C:\\log.txt", "w");

re: strlen

Gordon Burditt wrote:I would be checking the return value
to see if the operation succeded,
regardless of what the cause
of any potential failure might happen to be.

--
pete

re: strlen

gordonb.902u1@burditt.org (Gordon Burditt) writes:"C:\\log.txt" is a valid argument to fopen(). If, for example, you
don't have permission to write to that file, fopen() will return the
correct result, which happens to be a null pointer.

A null pointer, on the other hand, is not a valid argument to
strlen(); if you need to check whether you're about to call strlen()
with a null pointer, you *have* to check before the call.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

re: strlen

In article <lnps0zbc1t.fsf@nuthaus.mib.org>,
Keith Thompson <kst-u@mib.orgwrote:Questions could be raised at this point about what a "valid argument"
means. If I recall correctly, the interpretation of the
filename argument is designated as being implementation dependant.

Considering what how much that C leaves to the implementation
on this matter, it isn't obvious to me that the implementation
is required to accept all possible strings and deal sanely with
them (even if only to return an error response): -plausibly-
an implementation would be permitted to say "Do not -attempt-
open files whose designations do not fall within these specifications:
strange things might happen if you try, or the subway car might crash!"

--
Is there any thing whereof it may be said, See, this is new? It hath
been already of old time, which was before us. -- Ecclesiastes

re: strlen

roberson@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:I think there's a fairly clear line between a string that *might* be
valid file names (and fopen()'s result will tell you if it failed to
open it), and an argument that isn't even a pointer to a string (a
null pointer, or a pointer to the first element of an array that
doesn't contain a '\0' character, or a pointer with an indeterminate
value).

As for strlen, it *could* explicitly check for a null pointer
argument, and I wouldn't complain if an implementation did so. I
wouldn't even complain if a future standard required such a check (as
long as it defines the behavior if the check fails). But it's just
not practical to check for all possible argument errors. For example:
...
char *ptr = malloc(6);
assert(ptr != NULL);
strcpy(ptr, "hello");
free(ptr);
strlen(ptr);
...
The strlen call is invalid, but detecting it would probably hurt the
performance for valid arguments.

An alternative string implementation might at least partly address
this. Such alternatives have been proposed and can be implemented in
standard C if you don't mind missing out on a bit of syntactic sugar.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

re: strlen

Gordon Burditt wrote:I assume a smegmentation fault is covered under the "undefined
behaviour" clauses, which are the known response of strlen() to
unterminated strings. However I have grave problems finding
"smegmentation" in N869.txt. Meanwhile, AFAICT, all my smegs are
apparently clear.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>



--
Posted via a free Usenet account from http://www.teranews.com

re: strlen

Keith Thompson wrote:.... snip ...But what is wrong with:

char *ptr;

if (ptr = malloc(6)) strcpy(ptr, "hello");
else puts("No memory", stderr);
free(ptr);

(ignoring the use of strlen(ptr) above, which could be resolved by
defining strlen(NULL) as being 0).

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>


--
Posted via a free Usenet account from http://www.teranews.com

re: strlen

On Mon, 03 Sep 2007 22:29:02 +0100, Mark McIntyre
<markmcintyre@spamcop.netwrote:
i has to blame nothing

re: strlen

On Tue, 04 Sep 2007 19:50:47 +0200, "¬a\\/b" <al@f.gwrote:
i have to blame nothing because i already have the language now i want
if i consider my modificated stream objects that are for file string
and all

re: strlen

Gordon Burditt wrote:
[...]Umm... By returning? :-)
--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:ThisIsASpamTrap@gmail.com>

re: strlen

On Mon, 03 Sep 2007 19:04:13 +0200, jacob navia wrote:
Ya know, I think I've figured out the problem here. It's not that the
language allows functions such as strlen, which are perfectly usable.
It's that it has no way to tell goobers such as you to go use some other
language if you want the language to do your thinking for you.

Plonk. Again.

re: strlen

CBFalconer <cbfalconer@yahoo.comwrites:Sorry, you've lost me. There's nothing wrong with the code you
posted.

The 'strlen(ptr)' call in the code I posted would not be resolved by
defining the result of strlen(NULL). At the point of the call, the
value of 'ptr' is indeterminate; it's unlikely to be a null pointer.
(Remember that free() doesn't set its argument to NULL; in fact, it
can't.) Having strlen() detect a null pointer argument would be easy
enough; having it detect invalid arguments in general would not.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

re: strlen

Strange things that *might* happen, and *do* happen on some
existing systems, if you (try to) fopen() some random string:

- If you open a name designating a serial port, it might pause
indefinitely waiting for someone to assert "Data Carrier Detect",
and it might raise "Data Terminal Ready".
- If you open a name designating a named pipe, it might pause waiting
for someone to open the other end, and if you write on it you might get
sent a SIGPIPE signal if the read end has been closed.
- If you open a name designating a raw tape device, it might rewind the
tape, and possibly unload it when it is closed.
- If you open a name (referred to as "/dev/io" on some systems), it
might permit user-level-program use of input and output instructions
normally reserved for the OS and drivers itself.
- If you open a name designating kernel memory ("/dev/kmem" or "/dev/mem"
on some systems) and write random crap to it, you might crash the system.

re: strlen

On Mon, 03 Sep 2007 16:57:59 -0400, pete wrote:what i can imagine is this
sstream a, b;

a = "String1";
a << "String1" << "String1" << "String1" << "String1";
b=a;
a<<b; /* strcat */
if(a) error;
else goes all ok;

so i think it is better i ceck for errors in some places and not
always
in C it could not be done for size_t overflow error

re: strlen

On Mon, 03 Sep 2007 10:22:24 -0700, Barry Schwarz wrote:i don't say "stop"

in that little place (the streams place)
i have to decide what is better to do and what it is not
don't know is all is ok because i have only some example program that
use it

re: strlen

On Wed, 05 Sep 2007 07:17:19 +0200, "¬a\\/b" <al@f.gwrote:in that place the function for to get a input string like ggets or
other should be

sstring a;
........
cin >a;
other opheration with(a);

if(a) error;
else goes ok;

where "sstring" object use malloc
and "a" has a flag that say if all is ok in it

re: strlen

Keith Thompson wrote:The strlen thing was an incomplete addendum, and would require that
free be accompanied by a "ptr = NULL" statement in the first
sample. The main point was that the faulty code was not necessary
at any time, nor was the silly use of assert.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>



--
Posted via a free Usenet account from http://www.teranews.com

re: strlen

CBFalconer <cbfalconer@yahoo.comwrites:Perhaps I didn't make the point clearly enough.

This thread started with a claim that strlen is "wrong" because it
doesn't report errors. The purpose of my code snippet (not intended
to be good code, so don't bother "fixing" it) is to demonstrate that
strlen *cannot* check for all possible errors. The point of the
malloc and free was to create a pointer with an indeterminate value;
the assert was just a quick and dirty way to show that I was concerned
only with the case where malloc succeeds.

A program bug can lead to strlen being called with a null pointer. An
implementation of strlen could detect this fairly easily (the trick is
to decide what to do next). But a different program bug can easily
lead to strlen being called with a number of other invalid arguments;
detecting such errors in strlen is impractical.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

re: strlen

On Wed, 05 Sep 2007 07:17:19 +0200, "¬a\\/b" <al@f.gwrote:in that place the function for to get a input string like ggets or
other should be

sstring a;
........
cin >a;
other opheration with(a);

if(a) error;
else goes ok;

where "sstring" object use malloc
and "a" has a flag that say if all is ok in it
that i can check where i want

re: strlen

CBFalconer wrote:He is probably referring to "smegma", which is kind of
like genital toe-jam...

--
+----------------------------------------------------------------+
| Charles and Francis Richmond richmond at plano dot net |
+----------------------------------------------------------------+

re: strlen

On Mon, 03 Sep 2007 21:24:38 -0000,(Gordon Burditt) wrote:strlen has a way to report error because the string
a[strlen(a)];
not exist if strlen(a)=size_tmax

|""| = 0 len, 1 size
|"a"| = 1 len, 2 size
.............
and not exist
|"..."| = size_tmax len, (size_tmax +1) size

so strlen() can return only <(size_tmax -1)
so size_tmax is for error

is it above correct?
wrong for above
see above: strlen return size_tmax
:)))
yes it has to return and not hang the program with the infinite loop
but possibly i have seen wrong on it
if your program is an OS program it can shut down the system
i don't know, i say that it is better that every function return in
some way if the operation goes well
or all data has some flag that say if all operations with that data
are all ok

re: strlen

On Fri, 07 Sep 2007 23:49:45 +0200, "¬a\\/b" <al@f.gwrote:
strlen() has no way to report errors,
etc

re: strlen

On Fri, 07 Sep 2007 23:49:45 +0200, "¬a\\/b" <al@f.gwrote:
so strlen() can return only <=(size_tmax -1)
ararrarrrrrrGGGG

italians are not germans

re: strlen

On Fri, 07 Sep 2007 23:52:48 +0200, "¬a\\/b" <al@f.gwrote:
wrong etc

re: strlen

In article <98i3e3tg83l6m7r18cmmd69pc4448fpqom@4ax.com>, ¬a\\/b <al@f.gwrote:Perhaps you'd like to try arguing with yourself in private?

-- Richard


--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

re: strlen

On 7 Sep 2007 22:46:23 GMT, richard@cogsci.ed.ac.uk (Richard Tobin)
wrote:
no i like to arguing with myself in public
your is a not valid signature

On Mon, 03 Sep 2007 21:24:38 -0000,(Gordon Burditt) wrote:strlen has a way to report error because the string
a[strlen(a)];
not exist if strlen(a)=size_tmax

|""| = 0 len, 1 size
|"a"| = 1 len, 2 size
.............
and not exist
|"..."| = size_tmax len, (size_tmax +1) size

so strlen() can return only <=(size_tmax -1)
so size_tmax is for error

is it above correct?
wrong for above
see above: strlen return size_tmax
:)))
yes it has to return and not hang the program with the infinite loop
but possibly i have seen wrong on it
if your program is an OS program it can shut down the system
i don't know, i say that it is better that every function return in
some way if the operation goes well
or all data has some flag that say if all operations with that data
are all ok

re: strlen

On Sat, 08 Sep 2007 07:09:54 +0200, "¬a\\/b" <al@f.gwrote:yes i like it :))

pheraps it is better that strlen(0); segfault the program
(if the program is not an OS program)
so i can see there is some error because program not continue.

this in the realty is ok and make to find many errors

the alternative is
1) the error handling like c++
2) the programmer controll each call
3) the system controll each call like:

e^^printf ret<=0 ? (showerr("printf"), exit(0), 1) : ret ;
e^^strlen
ret==size_tmax||arg1==0 ? (showerr("strlen"),exit(0), 1): ret;
e^^malloc ret==0 ? (showerr("malloc"), exit(0),1): ret;
e1^^malloc ((int)arg1)<0||ret==0? (showerr("malloc"), exit(0),1): ret;


int main()
{
if( e1^^printf(a)==printf(b) )
c=malloc(134);
e^^strlen(c);

}

so each function can be associated with one or more functios that
determine what the system has to do if found an error in the arguments
of the function or in the return of the function
for exampe

malloc(a);
is the system malloc that behave like the standard C one

e^^malloc(a);
is the system malloc that behave like the standard C one that check
for ret==0; if find ret==0 show a message and exit

e1^^malloc(a);
is the system malloc that behave like the standard C one that check
for if (int)a<0 (arg1<0) or return ==0 (ret==0) and in that case exit

but for this i have to blame a language like say Sosman and others
because i never will write a compiler

re: strlen

On Sat, 08 Sep 2007 20:45:35 +0200, "¬a\\/b" <al@f.gwrote:
4) data object has a number or a flag that rapresent error that
programmer can check whatever it like and all function that use that
data can to change in case of errors

re: strlen

Keith Thompson wrote:

[...]
Agreed, a run-time check would hurt performance, but for your example,
this fault can be detected at no cost:

$ cat -n invalid_ptr.c
1 #include <stdio.h>
2 #include <stdlib.h>
3 #include <string.h>
4 #include <assert.h>
5
6 int main(void)
7 {
8 size_t len;
9 char *ptr = malloc(6);
10
11 assert(ptr != NULL);
12 strcpy(ptr, "hello");
13 free(ptr);
14
15 len = strlen(ptr);
16
17 return 0;
18 }

$ splint invalid_ptr.c
Splint 3.1.1 --- 20 Jun 2006

invalid_ptr.c: (in function main)
invalid_ptr.c:15:16: Variable ptr used after being released
Memory is used after it has been released (either by passing as an
only param
or assigning to an only global). (Use -usereleased to inhibit warning)
invalid_ptr.c:13:8: Storage ptr released

Finished checking --- 1 code warning


However, after calling free(), I always guard the pointer like this:

free(ptr);
ptr = NULL;

There are some good commercial memory tools available, which typically
insturment debug builds during development, this doesn't hurt
performance either (in release builds), but cut down the development time.


--
Tor <torust [at] online [dot] no>

re: strlen

On Sat, 08 Sep 2007 20:45:35 +0200, "¬a\\/b" <al@f.gwrote:
this is a public forum why i have not to write here?
it is c related, it talk about important problem of how check errors
so where and why check errors?
int e_printf(char* a, ... )
{int r;
va_list args;
va_start(args, a);
r=printf(a, args);
va_end(args);
if(r<=0)
{showerror("printf"); exit(0);}
return r;
}

size_t e_strlen(char* a)
{size_t r;
if(a==0)
{
a0: showerror("strlen"); exit(0);
}
r=strlen(a);
if(r==size_tmax) goto a0;
return r;
}

etc
i have to blame nothing again