From: Alex Fraser on
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
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
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
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
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>