By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,406 Members | 1,353 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,406 IT Pros & Developers. It's quick & easy.

Question about the clc string lib

P: n/a
In the function below, can size ever be 0 (zero)?

char *clc_strdup(const char * CLC_RESTRICT s)
{
size_t size;
char *p;

clc_assert_not_null(clc_strdup, s);

size = strlen(s) + 1;
if (size == 0)
p = NULL;
else if ((p = malloc(size)) != NULL)
memcpy(p, s, size);

return p;
}

Jan 26 '06
Share this Question
Share on Google+
53 Replies


P: n/a

Keith Thompson schrieb:
"aegis" <ae***@mad.scientist.com> writes:
Jordan Abel wrote:

[...]
take SIZE_MAX 65535

char * foo = calloc(256,256);
memset(foo,"x",SIZE_MAX);


I'm pretty sure this is undefined behavior.


How so? The calloc() call can either succeed or fail; I don't see any
permission for it to do anything else. The memset() call is ok (if
calloc() succeeded). Note that it doesn't set the entire object; it
leaves the last byte as '\0'.
It parallels, I think, with an issue brought up
months ago(in comp.std.c) that labeled the
following as undefined behavior.

int array[10][10];

array[0][10] = 10;

and that each array object is not guaranteed to
be adjacent to the other.


As I understand the argument, the array elements are guaranteed to be
adjacent; the assignment invokes undefined behavior because an
implementation could do explicit bounds checking, not because the
address might be invalid. I don't see the connection between this and
the calloc() issue.


Douglas Gwyn presented a segmented memory model by where
the offsets from a particular base address of one of the arrays
would not exactly lead access to an adjacent array. By this reason
it was regarded as invoking undefined behavior. Because calloc
could be provide an object by the same means, it would imply
that the exploitation of accessing an adjacent array with a suitable
offset from the base address of its neighbor, would also invoke
undefined behavior. That is, the as-if rule can be applied here
for objects whose storage duration is allocated and not automatic
or static.

--
aegis

Feb 2 '06 #51

P: n/a
On Thu, 26 Jan 2006 22:14:48 -0500, CBFalconer <cb********@yahoo.com>
wrote:
Jeff wrote:
char *clc_strdup(const char * CLC_RESTRICT s)

Very poor code. Apart from the missing definition of clc_assert...
and CLC_RESTRICT strlen returns a size_t, which is unsigned. Thus
size can never be less than 1, and the "p = NULL" will never be
executed. Assuming CLC_RESTRICT has something to do with the
restrict qualifier, it is pointless because s is const. <snip>


'const' means the argument object can't be written through _this_
pointer. It doesn't prevent writing through other paths, and thus
doesn't allow (type-aliasable) caching. 'restrict' does.

- David.Thompson1 at worldnet.att.net
Feb 6 '06 #52

P: n/a

In article <11**********************@g14g2000cwa.googlegroups .com>, "Vladimir S. Oka" <no****@btopenworld.com> writes:
Michael Wojcik wrote:
In article <dr**********@nwrdmz03.dmz.ncs.ea.ibs-infra.bt.com>, "Vladimir S. Oka" <no****@btopenworld.com> writes:
Michael Wojcik wrote:
> In article <dr**********@nwrdmz01.dmz.ncs.ea.ibs-infra.bt.com>,
> "Vladimir S. Oka" <no****@btopenworld.com> writes:
>> Jordan Abel wrote:
>>
>> > [legality of] #define strdup clc_strdup
OK, I think we're in agreement on the points relevant to C; I'll just
follow up to clarify some points. (And I'll note in passing that
while we may have disagreed in this thread, I generally find your
c.l.c posts appropriate and useful.)
My wording was obviously unfortunate. I wanted to say: "I did not check
the Standard on this immediatelly before posting, I had before and this
is what I believe it said". FWIW, I'm not a native speaker.
Fair enough. I took it too strongly, then.
> So calling the function "clc_strdup" and using a macro to refer to it
> as "strdup" is legal provided stdlib.h and string.h are not included
> - but that seems rather unlikely, and you could achieve the same thing
> by giving "strdup" internal linkage (ie by declaring it static).

In other words, there _are_ circumstances where it actually _is_ legal,
even according to your reading of the Standard.


Since Jordan's question did not refer to those restricted circum-
stances, it applies to the general case; and in the general case,
his proposition ("this action is permitted by the Standard") is
false. "p -> q" does not imply "q".


Jordan said: "it is legal to do X".
You said: "no, what you just said is false".

To me, if "is legal" is false, "is not legal" is true, and that does
not allow exceptions, especially in pedantic mode you claim to be in.


OK. We have a difference of opinion here on what it means for
Jordan's proposition to be false.

I take Jordan's proposition to have an implicit universal qualifier:
"is X true independent of other qualifications?". It is not - X is
only true if additional conditions are satisfied. Thus the
proposition as a whole is false.

You seem to be interpreting it as having an implicit existential
qualifier: "is there at least one circumstance under which X is
true?". There is, thus the proposition is not, in your view, false.

So I'd agree with your statement "if 'is legal' is false, 'is not
legal' is true" - where we seem to have run into confusion is in
the meaning of "is not legal" in this case. I am claiming "is not
legal [in at least some circumstances]", and you are claiming "is
legal [in at least some circumstances]". Of course these two
statements are commensurate, provided there's at least one legal
circumstance and one illegal one (which there are).

Thus the disagreement arises from whether it is better to gloss
"is legal in some circumstances and illegal in others" as "is
legal" or "is not legal". And when put that way, most people
would probably say "neither", and spell the whole thing out.
If you told me: 'your reply to Jordan (and/or Jordan's original claim)
is not strictly correct (or not correct in all circumstances -- as is
the case), the only correct answer is "in many/most circumstances
you're not allowed to do it, but there are some where you can, and
here's why"', I'd have remained as quiet as a mouse.
OK, I think we've both arrived at that conclusion.
(BTW, In my graduate maths class we used `->` to express implication,
so I genuinely don't understand your: "p -> q" does not imply "q".)


I'm using "->" for implication too; I just spelled out the second
"imply" because I thought it would be clearer than

Exists(p,q) s.t. not ((p -> q) -> q)

In other words, "the fact that p implies q, does not suffice to imply
q [in the absence of asserting p]". (Of course this is just incom-
plete modus ponens.) Here it applies as "if certain circumstances
hold, then the definition is allowed; but without knowing whether
those circumstances hold, we cannot say the definition is allowed (in
the general case)".
Why would it be
unlikely for a source file not to include certain standard headers?
I've seen quite a few.


Actually, this is more plausible than I originally thought. I
was thinking that the Standard allows standard headers to include
other standard headers, but it does not (there was a thread about
this on comp.std.c back in 2001[1]). The C++ standard does allow
this, which may have been what I was thinking of.


I was talking about (user) source files.


Right. What I meant was that originally I was thinking that standard
headers could include other standard headers, which meant that
string.h or stdlib.h could be "silently" included in a source file
even if it was not explicitly included, nor included by a user header.

That would make it harder to safely employ the sort of definition
Jordan suggested, because if you included even one standard header,
you couldn't be sure that stdlib.h or string.h hadn't been also
included, thus reserving the identifiers in question.

However, as it turns out, the consensus on comp.std.c appears to be
that standard headers are not permitted to include other standard
headers, so this danger technically shouldn't exist. (In practice,
it appears that several implementations do include standard headers
in other standard headers. Oh well.)
So, your reading does not actually contradict Jordan's (or mine, for
that matter), at least not entirely.


I submit that it does - that as the question is expressed, there is no
partial correctness that can attach. It is incorrect as stated.


Here, I'll respectfully disagree.


Fair enough; as I wrote above, I now believe this depends on the
interpretation of Jordan's "legal" (specifically, whether it implies
universality or existence).

--
Michael Wojcik mi************@microfocus.com

Pogo: The dogs *scarcely* ever catches the rabbit.
Bun: "Scarcely" got a very unpleasant ring of frequency to it. -- Walt Kelly
Feb 6 '06 #53

P: n/a
Michael Wojcik wrote:

In article <11**********************@g14g2000cwa.googlegroups .com>,
"Vladimir S. Oka" <no****@btopenworld.com> writes:
Michael Wojcik wrote:
> In article <dr**********@nwrdmz03.dmz.ncs.ea.ibs-infra.bt.com>,
> "Vladimir S. Oka" <no****@btopenworld.com> writes:
> > Michael Wojcik wrote:
> > > In article <dr**********@nwrdmz01.dmz.ncs.ea.ibs-infra.bt.com>,
> > > "Vladimir S. Oka" <no****@btopenworld.com> writes:
> > >> Jordan Abel wrote:
> > >>
> > >> > [legality of] #define strdup clc_strdup
OK, I think we're in agreement on the points relevant to C; I'll just
follow up to clarify some points. (And I'll note in passing that
while we may have disagreed in this thread, I generally find your
c.l.c posts appropriate and useful.)


(In a hushed voice: Thanks!)
My wording was obviously unfortunate. I wanted to say: "I did not
check the Standard on this immediatelly before posting, I had before
and this is what I believe it said". FWIW, I'm not a native speaker.


Fair enough. I took it too strongly, then.


As written it could have easily been seen as flippant, I can see that
now. Wonderful thing, hindsight. ;-)

<snip>
Jordan said: "it is legal to do X".
You said: "no, what you just said is false".

To me, if "is legal" is false, "is not legal" is true, and that does
not allow exceptions, especially in pedantic mode you claim to be in.


OK. We have a difference of opinion here on what it means for
Jordan's proposition to be false.

I take Jordan's proposition to have an implicit universal qualifier:
"is X true independent of other qualifications?". It is not - X is
only true if additional conditions are satisfied. Thus the
proposition as a whole is false.

You seem to be interpreting it as having an implicit existential
qualifier: "is there at least one circumstance under which X is
true?". There is, thus the proposition is not, in your view, false.

So I'd agree with your statement "if 'is legal' is false, 'is not
legal' is true" - where we seem to have run into confusion is in
the meaning of "is not legal" in this case. I am claiming "is not
legal [in at least some circumstances]", and you are claiming "is
legal [in at least some circumstances]". Of course these two
statements are commensurate, provided there's at least one legal
circumstance and one illegal one (which there are).

Thus the disagreement arises from whether it is better to gloss
"is legal in some circumstances and illegal in others" as "is
legal" or "is not legal". And when put that way, most people
would probably say "neither", and spell the whole thing out.


Yes, it seems so. I also believe Jordan's original proposition wasn't
very strictly put, allowing different takes on it.

<snip: more agreement>
(BTW, In my graduate maths class we used `->` to express implication,
so I genuinely don't understand your: "p -> q" does not imply "q".)


I'm using "->" for implication too; I just spelled out the second
"imply" because I thought it would be clearer than

Exists(p,q) s.t. not ((p -> q) -> q)


Ah, I see now. I wasn't expecting "mixed" notation (I might have also
been thrown off by your double quotes positions). What you've written
is obviously correct.

<snip: spelling out the logic above>

<snip: std. .h files can't include other std. .h files>
> > So, your reading does not actually contradict Jordan's (or mine,
> > for that matter), at least not entirely.
>
> I submit that it does - that as the question is expressed, there is
> no
> partial correctness that can attach. It is incorrect as stated.


Here, I'll respectfully disagree.


Fair enough; as I wrote above, I now believe this depends on the
interpretation of Jordan's "legal" (specifically, whether it implies
universality or existence).


Now, if only Jordan came back and clarified his original question...

;-)

PS
It's refreshing seeing that around here one can still settle differences
in a civilised manner (trolls notwithstanding).

--
BR, Vladimir

With a gentleman I try to be a gentleman and a half, and with a fraud I
try to be a fraud and a half.
-- Otto von Bismark

Feb 7 '06 #54

53 Replies

This discussion thread is closed

Replies have been disabled for this discussion.