Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Degenerate strcmp

Reply
Thread Tools

Degenerate strcmp

 
 
pete
Guest
Posts: n/a
 
      08-19-2007
Antoninus Twink wrote:

> Part of the confusion seems to be the names:
> for example, strlen takes a char * and returns an int.


The return type of strlen is size_t, not int.

--
pete
 
Reply With Quote
 
 
 
 
fishpond@invalid.com
Guest
Posts: n/a
 
      08-19-2007
On 18 Aug 2007 at 21:59, Richard Tobin wrote:
> In article <(E-Mail Removed)>,
> <(E-Mail Removed)> wrote:
>
>>Your right that a string has to be null terminated, but for random
>>memory maybe by chance there just isn't any null byte.

>
> In which case the program has a bug, because it's not allowed to call
> strcmp on "random memory" that doesn't have a nul byte. Programs
> with bugs of this kind are not required to behave in any particular way,
> so it's quite legal for strcmp to return any value it likes.
> so returning
>
>>For example, for the program
>>
>>main() { printf("%d\n",strlen(malloc(0))); }
>>
>>this will print out a random number, but in principal the strlen call
>>might never terminate, if the memory at the pointer returned by malloc
>>doesn't have any null bytes.

>
> The C library functions are only required to behave correctly if you call
> them correctly. If you call them with random data, all bets are off.
> (In this particular case, it may well produce a segmentation fault, because
> malloc(0) may return null.)


No I believe malloc(0) can never return null - after all, how could it
not be possible to allocate 0 bytes of memory!

>
> As the post you were replying to said:
>
>>> In cases where the behavior of the code is not defined,
>>> the running program can do whatever it wants.

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


--
<knghtbrd> Nintendo Declares GCN Most Popular Console Ever
<knghtbrd> Who are they kidding?
<Mercury> knghtbrd: Stock holders?
 
Reply With Quote
 
 
 
 
Flash Gordon
Guest
Posts: n/a
 
      08-19-2007
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote, On 19/08/07 13:03:
> On 18 Aug 2007 at 21:59, Richard Tobin wrote:


<snip>

>> (In this particular case, it may well produce a segmentation fault, because
>> malloc(0) may return null.)

>
> No I believe malloc(0) can never return null - after all, how could it
> not be possible to allocate 0 bytes of memory!


You believe wrong for at least three reasons.
1) All possible pointer values might have been used, and if it is
non-null it has to be unique.
2) There may be house-keeping structures required for which there is no
space.
3) The standard allows it.

<snip>

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


Please don't quote peoples signatures, the bit typically after the "--
", unless you are commenting on them. In fact, you should trim anything
not relevant to your reply as I have done.
--
Flash Gordon
 
Reply With Quote
 
Chris Dollin
Guest
Posts: n/a
 
      08-19-2007
(E-Mail Removed) wrote:

> No I believe malloc(0) can never return null


Nevertheless, it is permitted to do so. Since it is permitted,
an implemention could start with

if (requestedSize == 0) return 0;

Hence `malloc(0)` could return null. This could be a good idea
if the degenerate general case of `allocate N bytes` with N=0
took up more room than was justfied.

> - after all, how could it
> not be possible to allocate 0 bytes of memory!


If there was no room for the /bookkeeping/ necessary to record
the allocation.

--
'M All OK Hedgehog
"I just wonder when we're going to have to sit down and re-evaluate
our decision-making paradigm." /Sahara/

 
Reply With Quote
 
pete
Guest
Posts: n/a
 
      08-19-2007
(E-Mail Removed) wrote:

> No I believe malloc(0) can never return null


You believe wrongly.

N869
7.20.3 Memory management functions
[#1]

If the size of the space requested is zero,
the behavior is implementation-defined:
either a null pointer is returned,
or the behavior is as if the size were some nonzero value,
except that the returned pointer shall
not be used to access an object.

> - after all, how could it
> not be possible to allocate 0 bytes of memory!


That's not what a null pointer return value means for malloc(0).

--
pete
 
Reply With Quote
 
Richard Tobin
Guest
Posts: n/a
 
      08-19-2007
In article <(E-Mail Removed)>,
<(E-Mail Removed)> wrote:

>No I believe malloc(0) can never return null - after all, how could it
>not be possible to allocate 0 bytes of memory!


The specification of library functions is a question best determined by
looking at the standard, not by arguing "it must be like this".

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      08-19-2007
(E-Mail Removed) wrote:
> Richard Tobin wrote:
>

.... snip ...
>
>> The C library functions are only required to behave correctly if
>> you call them correctly. If you call them with random data, all
>> bets are off. (In this particular case, it may well produce a
>> segmentation fault, because malloc(0) may return null.)

>
> No I believe malloc(0) can never return null - after all, how
> could it not be possible to allocate 0 bytes of memory!


Easy. Read the C standard.

--
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

 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      08-19-2007
(E-Mail Removed) wrote:
> [...]
> No I believe malloc(0) can never return null -


Would reading section 7.20.3 paragraph 1 of the language
Standard alter your belief?

"[...] If the size of the space requested is zero,
the behavior is implementation-defined: either a
null pointer is returned, or the behavior is as if
the size were some nonzero value, except that the
returned pointer shall not be used to access an object."

> after all, how could it
> not be possible to allocate 0 bytes of memory!


Most likely, because it fails to allocate the internal
bookkeeping space it uses for keeping track of the addresses
it has returned that have not yet been free()d.

There's a potentially interesting quibble here, for people
interested in quibbles. The Standard requires (same paragraph)
that memory obtained from malloc() be "disjoint" from all other
objects, which is not quite the same as requiring that it have
an address different from that of all other objects. Since the
value of malloc(0) cannot be used to access an object, it could
be argued that the program cannot test disjointness without
engaging in undefined behavior anyhow. This would seem to open
the door to a malloc(0) that returned the same non-null value
on every call (a value free() would ignore), avoiding the need
for bookkeeping and making it possible to call malloc(0) an
unlimited number of times without fear of failure.

But even if it did so, the proposed use

> main() { printf("%d\n",strlen(malloc(0))); }


.... would be in trouble anyhow, because the strlen() call tries
to use the returned pointer to access an object -- an access
the Standard forbids.

--
Eric Sosman
(E-Mail Removed)lid
 
Reply With Quote
 
Flash Gordon
Guest
Posts: n/a
 
      08-19-2007
Eric Sosman wrote, On 19/08/07 15:43:
> (E-Mail Removed) wrote:
>> [...]
>> No I believe malloc(0) can never return null -

>
> Would reading section 7.20.3 paragraph 1 of the language
> Standard alter your belief?
>
> "[...] If the size of the space requested is zero,
> the behavior is implementation-defined: either a
> null pointer is returned, or the behavior is as if
> the size were some nonzero value, except that the
> returned pointer shall not be used to access an object."
>
> > after all, how could it
> > not be possible to allocate 0 bytes of memory!

>
> Most likely, because it fails to allocate the internal
> bookkeeping space it uses for keeping track of the addresses
> it has returned that have not yet been free()d.
>
> There's a potentially interesting quibble here, for people
> interested in quibbles. The Standard requires (same paragraph)
> that memory obtained from malloc() be "disjoint" from all other
> objects, which is not quite the same as requiring that it have
> an address different from that of all other objects. Since the
> value of malloc(0) cannot be used to access an object, it could
> be argued that the program cannot test disjointness without
> engaging in undefined behavior anyhow.


The following does not invoke undefined behaviour since you are always
allowed to test for equality (the first byte is 1 beyond the end which
is still OK or you could not free it)...

#include <stdlib.h>
#include <stdio.h>

int main(void)
{
void *p1 = malloc(0);
void *p2 = malloc(0);

if (p1==NULL || p2==NULL)
puts("At least one null pointer returned");
else if (p1==p2)
puts("Regions are not disjoint");
else
puts("Regions are disjoint");

free(p1);
free(p2);

return 0;
}

> This would seem to open
> the door to a malloc(0) that returned the same non-null value
> on every call (a value free() would ignore), avoiding the need
> for bookkeeping and making it possible to call malloc(0) an
> unlimited number of times without fear of failure.


No, I don't think so. See above.

> But even if it did so, the proposed use
>
> > main() { printf("%d\n",strlen(malloc(0))); }

>
> ... would be in trouble anyhow, because the strlen() call tries
> to use the returned pointer to access an object -- an access
> the Standard forbids.


Agreed. That is not allowed whatever malloc(0) returns.
--
Flash gordon
 
Reply With Quote
 
Mark Bluemel
Guest
Posts: n/a
 
      08-20-2007
(E-Mail Removed) wrote:
>
> No I believe malloc(0) can never return null - after all, how could it
> not be possible to allocate 0 bytes of memory!


You've never used IBM's AIX C runtime obviously...
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
segfault when strcmp Robert Mens C Programming 6 10-23-2003 02:53 AM
strcmp muser C++ 6 10-09-2003 08:18 AM
strcmp problem Shane Peck C++ 6 09-22-2003 05:44 PM
strcmp but with '\n' as the terrminator Allan Bruce C Programming 53 07-30-2003 07:38 PM
please help with strcmp() Andrej Hocevar C Programming 3 07-19-2003 04:41 PM



Advertisments