Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.c > #42496

Re: array-size/malloc limit and strlen() failure

From Keith Thompson <kst-u@mib.org>
Newsgroups comp.lang.c
Subject Re: array-size/malloc limit and strlen() failure
Date 2014-04-02 15:14 -0700
Organization None to speak of
Message-ID <lnvbure5ur.fsf@nuthaus.mib.org> (permalink)
References (1 earlier) <vvQ_u.132442$o%7.101937@fx29.am4> <ln38hvhiku.fsf@nuthaus.mib.org> <lhhmud$5hc$1@speranza.aioe.org> <533C6997.4020404@verizon.net> <d862f9d4-d888-4502-97f4-e566a2c42226@googlegroups.com>

Show all headers | View raw


Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Wednesday, April 2, 2014 8:48:39 PM UTC+1, James Kuyper wrote:
>> On 04/02/2014 03:03 PM, glen herrmannsfeldt wrote:
>> > Keith Thompson <kst-u@mib.org> wrote:
>> > (snip, someone wrote)
>> >>> However, you can write your own strlen() function which takes
>> >>> some of that into account, if you're that paranoid about it
>> >>> (although beware that if the address space is 64-bits,
>> >>> wrap-around might be impossible).
>> >  
>> >> You can't *portably* write such a strlen() function.  There is no
>> 
>> >> portable way to tell whether a given non-null address is valid or not.
>> > 
>> > Hmm. You can check to see if p++ is less than p. ...
>> 
>> That depends upon whether you evaluate 'p' before or after evaluating 
>> p++, and the most obvious way of checking that condition leaves that
>> order unspecified (it also has undefined behavior, for a different but
>> closely related reason). You can avoid both problems with a temporary:
>> 
> You could hold on to the pointer passed, then compare it with your
> temporary travelling pointer. If it compares as equal, wrap-round has
> occurred.

And how do you know pointers "wrap around" under ++?  I wrote
above that you can't *portably* write such a strlen() function.
Do you disagree?  Keep in mind that incrementing a pointer just
past the end of an array has undefined behavior.

Perhaps it can be done if you have detailed knowledge about the memory
layout and addressing scheme of the current platform -- but you could
still get false negatives if, for example, an array with no '\0' happens
to be immediately followed in memory by another array that does have a
'\0'.

For example:

    char s0[4] = "abcd"; // no terminating '\0'
    char s1[4] = "def";

If s1 happens to immediately follow s0 in memory, strlen(s0) will likely
return 7 rather than reporting an error -- unless your implementation
uses fat pointers.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

Back to comp.lang.c | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

array-size/malloc limit and strlen() failure jay <arnuld.mizong@gmail.com> - 2014-04-01 23:31 -0700
  Re: array-size/malloc limit and strlen() failure Xavier Roche <xroche@free.fr.NOSPAM.invalid> - 2014-04-02 08:47 +0200
  Re: array-size/malloc limit and strlen() failure Kaz Kylheku <kaz@kylheku.com> - 2014-04-02 07:36 +0000
  Re: array-size/malloc limit and strlen() failure "BartC" <bc@freeuk.com> - 2014-04-02 10:10 +0100
    Re: array-size/malloc limit and strlen() failure Keith Thompson <kst-u@mib.org> - 2014-04-02 08:11 -0700
      Re: array-size/malloc limit and strlen() failure glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-02 19:03 +0000
        Re: array-size/malloc limit and strlen() failure James Kuyper <jameskuyper@verizon.net> - 2014-04-02 15:48 -0400
          Re: array-size/malloc limit and strlen() failure Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-02 14:42 -0700
            Re: array-size/malloc limit and strlen() failure Keith Thompson <kst-u@mib.org> - 2014-04-02 15:14 -0700
        Re: array-size/malloc limit and strlen() failure Keith Thompson <kst-u@mib.org> - 2014-04-02 14:55 -0700
          Re: array-size/malloc limit and strlen() failure glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-02 23:42 +0000
  Re: array-size/malloc limit and strlen() failure Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-02 02:34 -0700
  Re: array-size/malloc limit and strlen() failure James Kuyper <jameskuyper@verizon.net> - 2014-04-02 07:40 -0400
    Re: array-size/malloc limit and strlen() failure Thomas Jahns <jahns@idontlikespam.dkrz.de> - 2014-04-02 13:52 +0200
    Re: array-size/malloc limit and strlen() failure Keith Thompson <kst-u@mib.org> - 2014-04-02 08:21 -0700
      Re: array-size/malloc limit and strlen() failure James Kuyper <jameskuyper@verizon.net> - 2014-04-02 11:30 -0400
      Re: array-size/malloc limit and strlen() failure glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-02 19:26 +0000
        Re: array-size/malloc limit and strlen() failure "BartC" <bc@freeuk.com> - 2014-04-02 20:39 +0100
        Re: array-size/malloc limit and strlen() failure Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2014-04-02 14:39 -0600
        Re: array-size/malloc limit and strlen() failure Keith Thompson <kst-u@mib.org> - 2014-04-02 15:03 -0700
          Re: array-size/malloc limit and strlen() failure Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-03 01:11 -0700
            Re: array-size/malloc limit and strlen() failure Ike Naar <ike@iceland.freeshell.org> - 2014-04-03 14:27 +0000
              Re: array-size/malloc limit and strlen() failure James Kuyper <jameskuyper@verizon.net> - 2014-04-03 17:56 -0400
            Re: array-size/malloc limit and strlen() failure Keith Thompson <kst-u@mib.org> - 2014-04-03 08:18 -0700
              Re: array-size/malloc limit and strlen() failure gazelle@shell.xmission.com (Kenny McCormack) - 2014-04-03 15:30 +0000
      Re: array-size/malloc limit and strlen() failure Stephen Sprunk <stephen@sprunk.org> - 2014-04-03 00:33 -0500

csiph-web