From: Alex Fraser on 13 Dec 2009 06:11 Jens Thoms Toerring wrote: [snip] > There actually are a few situation where you have no choice but > to cast, one prominent one is the connect(2) function, which > expects as it's second argument a 'const struct sockaddr *' but > where this can be a different beast, depending on if this for a > AF_UNIX socket or "real" network socket (the third argument with > the size of what you actually passed allows the function to figure > out what it got I would assume it tests the sa_family_t in the struct, which contains the address family. There's no reason why two incompatible sockaddr types couldn't have identical size. [snip] > And, finally, there are > some issues with variadic functions, i.e. functions that have an > unspecified number of arguments (the ones with '...' at the end of > the argument list) and instead rely on a "format string" that tells > the function about the types of the arguments covered by '...'. Here > it's also sometimes necessary to cast the types of the arguments to > make sure they fit exactly what's stated in the format string. This is because the compiler can't possibly know what, if any, conversions to apply. So it uses a set of rules called default argument promotions. The same rules are used when there is no prototype in scope for a function that is called. Another case where this shows up specifically in Unix programming is with execl*(). NULL may be #defined to 0, so terminating the argument list with NULL may cause an integer to be passed to the function instead of a null pointer to char. (char *)0 or (char *)NULL are correct.
From: Rainer Weikusat on 13 Dec 2009 13:27 jt(a)toerring.de (Jens Thoms Toerring) writes: [...] > Another place where a cast is prudent to use a cast is with the > is*() functions from <ctype.h> (isdigit(), isascii() etc.) where > there is an ambiguity due to some systems having signed and others > unsigned chars when you have a unqualified "char", and you get > around that by casting the argument to unsigned char. It is at least debatable if such cast has a defined behaviour. The only pointer-casts allowed by the C-standard are casts to pointers to compatible types and AFAIK, signed char, char and unsigned char are not explicitly required to be compatible.
From: Jens Thoms Toerring on 13 Dec 2009 15:58 Rainer Weikusat <rweikusat(a)mssgmbh.com> wrote: > jt(a)toerring.de (Jens Thoms Toerring) writes: > [...] > > Another place where a cast is prudent to use a cast is with the > > is*() functions from <ctype.h> (isdigit(), isascii() etc.) where > > there is an ambiguity due to some systems having signed and others > > unsigned chars when you have a unqualified "char", and you get > > around that by casting the argument to unsigned char. > It is at least debatable if such cast has a defined behaviour. The > only pointer-casts allowed by the C-standard are casts to pointers to > compatible types and AFAIK, signed char, char and unsigned char are > not explicitly required to be compatible. In that case you should cast the value of what you pass to one the functions from <ctype.h> to unsigned char (not a pointer) since the C standard requires: The header <ctype.h> declares several functions useful for testing and mapping characters. In all cases the argument is an int, the value of which shall be representable as an unsigned char or shall equal the value of the macro EOF. If the argument has any other value, the behavior is undefined. On a system with signed chars, if you pass a negative char to the functions (i.e. some non-ASCII char) the value, if taken as an int, could be a number that's neither representable by an unsigned char nor is EOF. That's, as far I understand it, the rationale for cas- ting to unsigned char in these cases. Regards, Jens -- \ Jens Thoms Toerring ___ jt(a)toerring.de \__________________________ http://toerring.de
From: Rainer Weikusat on 13 Dec 2009 17:02 jt(a)toerring.de (Jens Thoms Toerring) writes: > Rainer Weikusat <rweikusat(a)mssgmbh.com> wrote: >> jt(a)toerring.de (Jens Thoms Toerring) writes: > >> [...] > >> > Another place where a cast is prudent to use a cast is with the >> > is*() functions from <ctype.h> (isdigit(), isascii() etc.) where >> > there is an ambiguity due to some systems having signed and others >> > unsigned chars when you have a unqualified "char", and you get >> > around that by casting the argument to unsigned char. > >> It is at least debatable if such cast has a defined behaviour. The >> only pointer-casts allowed by the C-standard are casts to pointers to >> compatible types and AFAIK, signed char, char and unsigned char are >> not explicitly required to be compatible. > > In that case you should cast the value of what you pass to one > the functions from <ctype.h> to unsigned char (not a pointer) I should read postings more carefully ... thanks for the correction.
From: Geoff Clare on 14 Dec 2009 08:31 Barry Margolin wrote: >> probably a hangover from the old BASIC days (I very rarely do FILE stuff > > I think you mean "holdover". A hangover is what you get from drinking > too much, although that could also cause you to make programming > mistakes. http://www.askoxford.com/concise_oed/hangover?view=uk hangover noun 1 a severe headache or other after-effects caused by drinking an excess of alcohol. 2 a thing that has survived from the past. http://www.askoxford.com/concise_oed/holdover?view=uk Not Found http://www.askoxford.com/concise_oed/hold_1?view=uk -- PHRASES [...] hold over 1 postpone. 2 use (information) to threaten. -- Geoff Clare <netnews(a)gclare.org.uk>
First
|
Prev
|
Pages: 1 2 3 Prev: Why are there so many spam? Next: shm_open() vs. shmget(); shm_open() vs. open() |