Comments on my code?

[Platonic Solid]

Hi-

I am learning C from some old lecture notes, but they don't have
solutions so I'd like some feedback on my code if anyone has the time.

This is an exercise: "Write a program to trim any leading whitespace
from a string and return a newly allocated buffer containing the trimmed
string. Don't forget to handle errors."

main(argc, argv)
int argc; char **argv;
{
char *strtrim(), *r=0;
puts(argc>1 && (r=strtrim(*++a rgv)) ? r : "Unspecifie d error");
free(r);
}

/* trims initial whitespace */
char *strtrim(s)
char *s;
{
char *r, *malloc();
for( ; isspace(*s); s++);
r=malloc(strlen (s)+1);
if(r)
strcpy(r,s);
return r;
}

This looks OK to me and works correctly, but the compiler produces some
mysterious warnings about conflicting definitions that I don't really
understand.
--
How come we never talk anymore?

[Francine.Neary]

On Sep 1, 10:33 pm, Harald van D k <true...@gmail. comwrote:

Francine.Ne...@ googlemail.com wrote:

On Sep 1, 8:22 pm, Keith Thompson <[e-mail] rote:

Harald van D k <true...@gmail. comwrites:

Platonic Solid wrote:
char *r, *malloc(), *strcpy();

On the contrary, I've declared malloc correctly and store its return
value in a char *.

No, you haven't declared malloc correctly.

Specifically, malloc returns void*, not char*, and it takes an
argument of type size_t. Since you didn't declare the argument type,
something as simple as malloc(42) invokes undefined behavior, since
you're passing an argument of type int.

If you had declared it correctly as
void *malloc(size_t) ;
then a call like malloc(42) would implicitly convert the argument to
size_t -- and a call with a non-numeric argument would trigger an
error message.

Am I right in thinking that first standard promotions would apply, and
only then would the result be converted to size_t?

Compare these functions:

unsigned short f1 (x)
unsigned short x;
{
return x;

}

unsigned short f2 (unsigned short x)
{
return x;

}

int main(void) {
unsigned short x = 3;
return f1(x) - f2(x);

}

The call to f1 results in x being promoted to int (or unsigned int,
depending on the system), and then converted back to unsigned short. The
call to f2 does not cause x to undergo any promotion to int.

That's interesting... so there could in fact be situations when using
K&R style functions could shorten your code, if you were able to take
advantage of edge effects for promotion versus conversion.

The given
declaration of malloc falls in the same category as f2, not f1. However, I
would be very surprised to find an implementation for which the end result
is any different for integer types.

[Barry Schwarz]

On Sat, 1 Sep 2007 20:35:10 +0200 (CEST), Platonic Solid
<pl*****@mailin ator.comwrote:

>On 1 Sep 2007 at 16:42, CBFalconer wrote:

>Platonic Solid wrote:

>>>

... snip ...

>>>
OK, so that explains why strcpy produces a warning as it returns
char * and not int. But the compiler also complains about malloc
(I specifically supply the return type for that) and strlen, which
returns int so should be OK by Q 1.25.

You didn't give code, so we can't make suggestions.

On the contrary, I posted my code, but here it is again:

main(argc, argv)
int argc; char **argv;
{
char *strtrim(), *r=0;
puts(argc>1 && (r=strtrim(*++a rgv)) ? r : "Unspecifie d error");
free(r);
}

/* trims initial whitespace */
char *strtrim(s)
char *s;
{
char *r, *malloc(), *strcpy();
for( ; isspace(*s); s++);
r=malloc(strlen (s)+1);
if(r)
strcpy(r,s);
return r;
}

(I've made one fix, by putting in the correct return type for strcpy)

>If you have problems with malloc you are probably a) casting the
return or b) failing to include <stdlib.hor c) capturing the return
value in other than a pointer or d) using a C++ compiler.

On the contrary, I've declared malloc correctly and store its return
value in a char *.

No you didn't. If your notes are as old as they appear, they may say
malloc returns a char*. Unfortunately, that hasn't been true for over
15 years.

>
I'm not sure what to do about people's advice that some of the syntax in
the lecture notes is now old-fashioned - as it still seems to compile
just fine, I'm tempted to stick with what I know.

Old need not be bad but in this case it is hurting you more than
helping.
Remove del for email

[jaysome]

On Sat, 1 Sep 2007 16:23:39 +0200, "Peter J. Holzer"
<hj*********@hj p.atwrote:

>On 2007-09-01 13:26, jacob navia <ja***@jacob.re mcomp.frwrote:

>Platonic Solid wrote:

>>On 1 Sep 2007 at 12:53, jacob navia wrote:
P.S. What happens when s is NULL?

If you look carefully I check argc>1, so it never gets called with s
null.

Sure, but is strtrim only for this particular call?
In that case a function is not necessary!

What happens when you call strlen(NULL)?

The C Standard says this about the function strlen:

<quote>
1 #include <string.h>
size_t strlen(const char *s);

2 The strlen function computes the length of the string pointed to by
s.

3 The strlen function returns the number of characters that precede
the terminating null character.
</quote>

Since a NULL pointer points to "nothing", it cannot point to anything
that includes a "terminatin g null character". Therefore, the behavior
(of strlen(NULL)) is undefined.

Best regards
--
jay

[Barry Schwarz]

On Sat, 1 Sep 2007 14:01:58 +0200 (CEST), Platonic Solid
<pl*****@mailin ator.comwrote:

>Hi-

I am learning C from some old lecture notes, but they don't have
solutions so I'd like some feedback on my code if anyone has the time.

This is an exercise: "Write a program to trim any leading whitespace
from a string and return a newly allocated buffer containing the trimmed
string. Don't forget to handle errors."

main(argc, argv)
int argc; char **argv;

The lecture notes must be very old. This method of definition, while
still legal, fell out of style before 1990.

>{
char *strtrim(), *r=0;
puts(argc>1 && (r=strtrim(*++a rgv)) ? r : "Unspecifie d error");

Since the requirement did not specify handling errors in a user
friendly way, I guess this qualifies.

free(r);
}

/* trims initial whitespace */
char *strtrim(s)
char *s;
{
char *r, *malloc();
for( ; isspace(*s); s++);
r=malloc(strlen (s)+1);

Since there is no prototype for strlen, a C89 compiler is required to
assume that it returns an int. Since the previous declaration for
malloc was not a prototype, the compiler is required to assume it
takes an int for its only argument. Since malloc actually takes a
size_t which need not be an (unsigned) int, this invokes undefined
behavior.

It is only the coincidence that char* and void* must have the same
representation that might prevent further undefined behavior. If your
compiler and run-time library treat void* special, such as returning
it in a unique register, that prevention just evaporated.

Why are you lying to the compiler and not including the headers with
the correct prototypes?

if(r)
strcpy(r,s);
return r;
}

This looks OK to me and works correctly, but the compiler produces some
mysterious warnings about conflicting definitions that I don't really
understand.

How are we supposed to explain them if you won't tell us what they
say?
Remove del for email

[Flash Gordon]

Barry Schwarz wrote, On 02/09/07 17:27:

On Sat, 1 Sep 2007 14:01:58 +0200 (CEST), Platonic Solid
<pl*****@mailin ator.comwrote:

>Hi-

I am learning C from some old lecture notes, but they don't have
solutions so I'd like some feedback on my code if anyone has the time.

This is an exercise: "Write a program to trim any leading whitespace
from a string and return a newly allocated buffer containing the trimmed
string. Don't forget to handle errors."

main(argc, argv)
int argc; char **argv;

The lecture notes must be very old. This method of definition, while
still legal, fell out of style before 1990.

Well, it took a little while for all implementations to support the ANSI
standard, but basically true.

>{
char *strtrim(), *r=0;
puts(argc>1 && (r=strtrim(*++a rgv)) ? r : "Unspecifie d error");

Since the requirement did not specify handling errors in a user
friendly way, I guess this qualifies.

> free(r);
}

/* trims initial whitespace */
char *strtrim(s)
char *s;
{
char *r, *malloc();
for( ; isspace(*s); s++);
r=malloc(strlen (s)+1);

Since there is no prototype for strlen, a C89 compiler is required to
assume that it returns an int.

True, and it means the call invokes undefined behaviour.

Since the previous declaration for
malloc was not a prototype, the compiler is required to assume it
takes an int for its only argument.

Misleading, although true in this case. The compiler is required to
assume that it takes whatever it is given. As the compiler has assumed
strlen returns an int it wll make the value of strlen(s)+1 an int as
well and so assume malloc takes an int. Had there been a correct
prototype for strlen in place then it would have been "legal" although
very bad practice. Well, legal if the return type of malloc had been
specified as void* instead of incorrectly being specified as char*.

Since malloc actually takes a
size_t which need not be an (unsigned) int, this invokes undefined
behavior.

True.

It is only the coincidence that char* and void* must have the same
representation that might prevent further undefined behavior. If your
compiler and run-time library treat void* special, such as returning
it in a unique register, that prevention just evaporated.

Why are you lying to the compiler and not including the headers with
the correct prototypes?

Because he is working from notes that pre-date the standard?

> if(r)
strcpy(r,s);
return r;
}

This looks OK to me and works correctly, but the compiler produces some
mysterious warnings about conflicting definitions that I don't really
understand.

How are we supposed to explain them if you won't tell us what they
say?

Well, of you have probably explained a lot of the problems the compiler
was warning about :-)
--
Flash Gordon

[Barry Schwarz]

On Sat, 01 Sep 2007 13:06:55 -0700, Fr************@ googlemail.com
wrote:

>On Sep 1, 8:22 pm, Keith Thompson <[e-mail] rote:

>Harald van D k <true...@gmail. comwrites:

Platonic Solid wrote:
char *r, *malloc(), *strcpy();

>On the contrary, I've declared malloc correctly and store its return
value in a char *.

No, you haven't declared malloc correctly.

Specifically , malloc returns void*, not char*, and it takes an
argument of type size_t. Since you didn't declare the argument type,
something as simple as malloc(42) invokes undefined behavior, since
you're passing an argument of type int.

If you had declared it correctly as
void *malloc(size_t) ;
then a call like malloc(42) would implicitly convert the argument to
size_t -- and a call with a non-numeric argument would trigger an
error message.

Am I right in thinking that first standard promotions would apply, and
only then would the result be converted to size_t?

Since 42 is already an integer, what standard promotions are you
referring to? If the argument had been an expression with operators,
the final value of the expression would have been converted to size_t.
If the process of evaluating the expression required standard
promotions, they would be performed first. However, the expression
consisted of a single short int variable, then I don't believe the
standard promotions are needed to convert the short value to a size_t
value (n1124, section 6.3.1.1, footnote 48).
Remove del for email

[Keith Thompson]

Barry Schwarz <sc******@doezl .netwrites:

On Sat, 01 Sep 2007 13:06:55 -0700, Fr************@ googlemail.com
wrote:

[...]

>>Am I right in thinking that first standard promotions would apply, and
only then would the result be converted to size_t?

Since 42 is already an integer, what standard promotions are you
referring to?

[...]

Ahem. Yes, 42 is an integer, but the relevant point is that it's an
int. (int is one of several integer types.)

--
Keith Thompson (The_Other_Keit h) ks***@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"

[pete]

Keith Thompson wrote:

>
Barry Schwarz <sc******@doezl .netwrites:

On Sat, 01 Sep 2007 13:06:55 -0700, Fr************@ googlemail.com
wrote:

[...]

>Am I right in thinking that first
standard promotions would apply, and
only then would the result be converted to size_t?

Since 42 is already an integer, what standard promotions are you
referring to?

[...]

Ahem. Yes, 42 is an integer, but the relevant point is that it's an
int. (int is one of several integer types.)

But, there are no promotions
that would apply to an argument expression of type int,
prior to conversion to the parameter's type of size_t,
as in what Francine.Neary replied to:

"If you had declared it correctly as
void *malloc(size_t) ;
then a call like malloc(42) would implicitly convert the argument to
size_t -- and a call with a non-numeric argument would trigger an
error message."

--
pete

[Keith Thompson]

pete <pf*****@mindsp ring.comwrites:

Keith Thompson wrote:

>Barry Schwarz <sc******@doezl .netwrites:

On Sat, 01 Sep 2007 13:06:55 -0700, Fr************@ googlemail.com
wrote:

[...]

>>Am I right in thinking that first
standard promotions would apply, and
only then would the result be converted to size_t?

Since 42 is already an integer, what standard promotions are you
referring to?

[...]

Ahem. Yes, 42 is an integer, but the relevant point is that it's an
int. (int is one of several integer types.)

But, there are no promotions
that would apply to an argument expression of type int,
prior to conversion to the parameter's type of size_t,
as in what Francine.Neary replied to:

[snip]

My point was that Barry was glossing over the disinction between 'int'
and 'integer'.

--
Keith Thompson (The_Other_Keit h) ks***@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"