Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > supplementary C frequent answers

Reply
Thread Tools

supplementary C frequent answers

 
 
Joe Wright
Guest
Posts: n/a
 
      01-03-2004
pete wrote:
>
> Peter Pichler wrote:
> >
> > "Ben Pfaff" <(E-Mail Removed)> wrote in message
> > news:(E-Mail Removed)...
> > > Over the last couple of years, and especially recently, I've
> > > built up a few "stock" answers that supplement the C FAQ. If
> > > anyone wants to review and comment on them, I've just now put
> > > them up on my webpage, at
> > > http://benpfaff.org/writings/clc

> >
> > From that website:
> > "Using strncpy() into a large buffer can be
> > very inefficient. strncpy() always writes to every byte in the
> > destination buffer, which can waste a lot of time
> > if the destination buffer is much longer than the source string."
> >
> > Isn't this a QoI issue?

>
> If you strncpy a zero length string source to
> a hundred byte length string destination,
> 101 bytes of the destination string will be overwritten.
>

Show me. strncpy() will write n characters to the destination.

> If you strcpy a zero length string source to
> a hundred byte length string destination,
> 1 byte of the destination string will be overwritten.
>
> --
> pete


--
Joe Wright http://www.jw-wright.com
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
 
Reply With Quote
 
 
 
 
Richard Heathfield
Guest
Posts: n/a
 
      01-03-2004
Peter Pichler wrote:

> What if I don't care about the /whole/
> string, but need to limit how much to copy because I know the length of
> the destination buffer and know that it may not be long enough?


If you don't care about the whole string, strcpy is the Wrong Thing for that
task, because strcpy /does/ copy the whole string.

Personally, I never use strncpy. If I care about the whole string, I make
sure the receiving buffer is big enough. If I don't care about the whole
string, I don't treat it /as/ a string (since the bit that I care about
/isn't/ a string), and I would favour mem* routines rather than str*
routines for that purpose.

--
Richard Heathfield : http://www.velocityreviews.com/forums/(E-Mail Removed)
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
 
Reply With Quote
 
 
 
 
Ben Pfaff
Guest
Posts: n/a
 
      01-03-2004
Jeremy Yallop <(E-Mail Removed)> writes:

> Ben Pfaff wrote:
> > Over the last couple of years, and especially recently, I've
> > built up a few "stock" answers that supplement the C FAQ. If
> > anyone wants to review and comment on them, I've just now put
> > them up on my webpage, at
> > http://benpfaff.org/writings/clc

>
> | When are casts appropriate?
> |
> | Casts are generally undesirable, but there are several situations
> | where a cast legitimately comes in handy:
> [...]
> | * Passing a null pointer to a varargs function.
>
> More generally, calling a varargs function with any value whose type
> isn't compatible with what the function expects.


Most of the time, though, such conversions are more reasonably
done without a cast. (In my opinion, of course.)
--
"I hope, some day, to learn to read.
It seems to be even harder than writing."
--Richard Heathfield
 
Reply With Quote
 
Servé Lau
Guest
Posts: n/a
 
      01-03-2004
"Ben Pfaff" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Over the last couple of years, and especially recently, I've
> built up a few "stock" answers that supplement the C FAQ. If
> anyone wants to review and comment on them, I've just now put
> them up on my webpage, at
> http://benpfaff.org/writings/clc


IMO, the article "why should toupper()'s argument be cast to unsigned char?"
is not explained very well.
What do you mean with "If char is signed, then some characters have negative
values". It could use an example.

I'd also elaborate about the valid return values from main in the article
"how should main be declared". Maybe the difference between implicit return
values in C89 and C99 would fit in there too (or put it in another article)

The article about malloc's return value could use an example for its third
point. "If you cast to the wrong type by accident, odd failures can result"
What odd failures? Convince me.


 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      01-03-2004
Ben Pfaff <(E-Mail Removed)> writes:
> Jeremy Yallop <(E-Mail Removed)> writes:
>
> > Ben Pfaff wrote:
> > > Over the last couple of years, and especially recently, I've
> > > built up a few "stock" answers that supplement the C FAQ. If
> > > anyone wants to review and comment on them, I've just now put
> > > them up on my webpage, at
> > > http://benpfaff.org/writings/clc

> >
> > | When are casts appropriate?
> > |
> > | Casts are generally undesirable, but there are several situations
> > | where a cast legitimately comes in handy:
> > [...]
> > | * Passing a null pointer to a varargs function.
> >
> > More generally, calling a varargs function with any value whose type
> > isn't compatible with what the function expects.

>
> Most of the time, though, such conversions are more reasonably
> done without a cast. (In my opinion, of course.)


Can you give some examples?

Here are a couple of cases where (IMHO) a cast is appropriate:

int *ptr = <whatever>;

printf("sizeof(ptr) = %d\n", (int)sizeof(ptr));
printf("ptr = [%p]\n", (void*)ptr);

In C99, you can avoid the cast in the first printf by using "%zu", but
that's not universally supported yet. (I might use unsigned long
rather than int, but I'm reasonably certain in this case that
sizeof(ptr) <= INT_MAX.)

In the second printf, I don't see a good way to avoid the cast.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
(Note new e-mail address)
 
Reply With Quote
 
Ben Pfaff
Guest
Posts: n/a
 
      01-03-2004
"Servé Lau" <(E-Mail Removed)> writes:

> "Ben Pfaff" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> > Over the last couple of years, and especially recently, I've
> > built up a few "stock" answers that supplement the C FAQ. If
> > anyone wants to review and comment on them, I've just now put
> > them up on my webpage, at
> > http://benpfaff.org/writings/clc

>
> IMO, the article "why should toupper()'s argument be cast to unsigned char?"
> is not explained very well.
> What do you mean with "If char is signed, then some characters have negative
> values". It could use an example.


Okay, I've updated it. (Changes may take a minute or two to
propagate.)

> I'd also elaborate about the valid return values from main in the article
> "how should main be declared". Maybe the difference between implicit return
> values in C89 and C99 would fit in there too (or put it in another article)


Sure, good suggestion.

> The article about malloc's return value could use an example for its third
> point. "If you cast to the wrong type by accident, odd failures can result"
> What odd failures? Convince me.


I don't recall at the moment, but it's definitely true--I've seen
them. Alignment-related failures surely, and I think there are
others.
--
"For those who want to translate C to Pascal, it may be that a lobotomy
serves your needs better." --M. Ambuhl

"Here are the steps to create a C-to-Turbo-Pascal translator..." --H. Schildt
 
Reply With Quote
 
Richard Heathfield
Guest
Posts: n/a
 
      01-03-2004
Ben Pfaff wrote:

> "Serve' Lau" <(E-Mail Removed)> writes:
>
>> The article about malloc's return value could use an example for its
>> third point. "If you cast to the wrong type by accident, odd failures can
>> result" What odd failures? Convince me.

>
> I don't recall at the moment, but it's definitely true--I've seen
> them. Alignment-related failures surely, and I think there are
> others.


Consider a C90 implementation which stores returned pointers in one
register, and returned integers in another. If you forget to provide a
correct prototype for a function returning a pointer, such as malloc, the
implementation is obliged to assume that the function in question returns
int, rather than a pointer type, and therefore your code could receive a
garbage value from the integer register rather than the value that malloc
actually returns, which the implementation correctly stores in the pointer
register.

--
Richard Heathfield : (E-Mail Removed)
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
 
Reply With Quote
 
Ben Pfaff
Guest
Posts: n/a
 
      01-03-2004
Richard Heathfield <(E-Mail Removed)> writes:

> Ben Pfaff wrote:
>
> > "Serve' Lau" <(E-Mail Removed)> writes:
> >
> >> The article about malloc's return value could use an example for its
> >> third point. "If you cast to the wrong type by accident, odd failures can
> >> result" What odd failures? Convince me.

> >
> > I don't recall at the moment, but it's definitely true--I've seen
> > them. Alignment-related failures surely, and I think there are
> > others.

>
> Consider a C90 implementation which stores returned pointers in one
> register, and returned integers in another. If you forget to provide a
> correct prototype for a function returning a pointer, such as malloc, the
> implementation is obliged to assume that the function in question returns
> int, rather than a pointer type, and therefore your code could receive a
> garbage value from the integer register rather than the value that malloc
> actually returns, which the implementation correctly stores in the pointer
> register.


Such a problem would be covered by the second point, "Casting its
return value can mask a failure to #include <stdlib.h>, which
leads to undefined behavior." We are discussing the third point,
"If you cast to the wrong type by accident, odd failures can
result."
--
"I ran it on my DeathStation 9000 and demons flew out of my nose." --Kaz
 
Reply With Quote
 
Peter Pichler
Guest
Posts: n/a
 
      01-03-2004
"Richard Heathfield" <(E-Mail Removed)> wrote:
> Ben Pfaff wrote:
> > "Serve' Lau" <(E-Mail Removed)> writes:
> >
> >> The article about malloc's return value could use an example for its
> >> third point. "If you cast to the wrong type by accident, odd failures

can
> >> result" What odd failures? Convince me.

> >
> > I don't recall at the moment, but it's definitely true--I've seen
> > them. Alignment-related failures surely, and I think there are
> > others.

>
> Consider a C90 implementation which stores returned pointers in one
> register, and returned integers in another. If you forget to provide a
> correct prototype for a function returning a pointer, such as malloc [...]


With more missing context in this message, I thought that he was talking
about /having/ a prototype yet casting to the wrong type. Can you see any
problems with that other than failing to compile?


 
Reply With Quote
 
Richard Heathfield
Guest
Posts: n/a
 
      01-04-2004
Ben Pfaff wrote:

<snip>

> Such a problem would be covered by the second point, "Casting its
> return value can mask a failure to #include <stdlib.h>, which
> leads to undefined behavior." We are discussing the third point,
> "If you cast to the wrong type by accident, odd failures can
> result."


Oops. Sorry about that.

--
Richard Heathfield : (E-Mail Removed)
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
 
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
strsup - supplementary string functions Malcolm McLean C Programming 19 02-03-2013 10:33 PM
[RFC] PEP 3143: supplementary group list concerns Jan Pokorný Python 1 03-11-2012 11:41 PM
frequent crashes with US Robotics 8054 22MB/s wireless card NGI Wireless Networking 0 10-27-2004 01:40 PM
Frequent Disconnections David McKinnon Wireless Networking 13 06-24-2004 08:03 PM
Supplementary groups Andrew Walrond Ruby 0 11-20-2003 12:18 AM



Advertisments