Home > Archive > C > October 2005 > Sort of mystified from an earlier thread
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Sort of mystified from an earlier thread
|
|
|
| This was taken from the following:
http://groups.google.com/group/comp...63e9afae83d061c
And I quote:
"Well, that's also ok for char**, since string literals are of type
char * in c. The general idea still stands, though.
The thing that irritates me is that despite all this, it's _trivial_
to violate const in C without resorting to all this.
const char foo[] = "mystring";
char *constviol = strchr(foo,*foo); "
What I don't get is that that 'const char f[]="mystring" ' is defined
as a char, but the prototype is defined as the following:
char *strchr(const char *s, int c);
When foo gets de-referenced (ie *foo), how come the compiler doesn't
complain about the difference between 'int' and 'char'?
Thanks in advance.
Chad
| |
| Arctic Fidelity 2005-10-30, 3:55 am |
| On Sat, 29 Oct 2005 21:51:46 -0400, Chad <cdalten@gmail.com> wrote:
> "Well, that's also ok for char**, since string literals are of type
> char * in c. The general idea still stands, though.
>
> The thing that irritates me is that despite all this, it's _trivial_
> to violate const in C without resorting to all this.
>
> const char foo[] = "mystring";
> char *constviol = strchr(foo,*foo); "
>
> What I don't get is that that 'const char f[]="mystring" ' is defined
> as a char, but the prototype is defined as the following:
>
> char *strchr(const char *s, int c);
>
> When foo gets de-referenced (ie *foo), how come the compiler doesn't
> complain about the difference between 'int' and 'char'?
I have actually been wondering about this as well. I know that char is an
integer type, but I still would have thought that int and char would have
brought up some kind of warning or what not. I'm not sure how I understand
how that all does it's thing.
- Arctic
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
| |
|
| Arctic Fidelity wrote:
> On Sat, 29 Oct 2005 21:51:46 -0400, Chad <cdalten@gmail.com> wrote:
>
>
> I have actually been wondering about this as well. I know that char is an
> integer type, but I still would have thought that int and char would have
> brought up some kind of warning or what not. I'm not sure how I understand
> how that all does it's thing.
>
> - Arctic
>
> --
> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Outside of the sloppy wording, here is my best guess on what is going
on.
When we go *foo, we are getting each character from the string.
Internally at each pass, we would have a varibale storing 'm', tnen
'y', etc. This would be the same has we done something like
char internal_string = 'm';
Then char would be automatically converted to integer (on the strchr
int c parameter). This might explain wny the gnu compiler didn't
complain even when I hard warning flags enabled.
| |
|
| Chad wrote:
>
> This was taken from the following:
>
> http://groups.google.com/group/comp...63e9afae83d061c
>
> And I quote:
>
> "Well, that's also ok for char**, since string literals are of type
> char * in c. The general idea still stands, though.
>
> The thing that irritates me is that despite all this, it's _trivial_
> to violate const in C without resorting to all this.
>
> const char foo[] = "mystring";
> char *constviol = strchr(foo,*foo); "
>
> What I don't get is that that 'const char f[]="mystring" ' is defined
> as a char, but the prototype is defined as the following:
>
> char *strchr(const char *s, int c);
>
> When foo gets de-referenced (ie *foo), how come the compiler doesn't
> complain about the difference between 'int' and 'char'?
Because there's no problem converting a char to an int,
unless (CHAR_MAX > INT_MAX)
which doesn't seem to be the case in any hosted sysytems.
--
pete
| |
|
| pete wrote:
>
> Chad wrote:
>
> Because there's no problem converting a char to an int,
> unless (CHAR_MAX > INT_MAX)
> which doesn't seem to be the case in any hosted sysytems.
There's also
N869
6.3.1 Arithmetic operands
6.3.1.1 Boolean, characters, and integers
[#2] The following may be used in an expression wherever an
int or unsigned int may be used:
-- An object or expression with an integer type whose
integer conversion rank is less than the rank of int
and unsigned int.
--
pete
| |
| Greg Comeau 2005-10-30, 6:56 pm |
| In article <1130637106.638913.16850@g14g2000cwa.googlegroups.com>,
Chad <cdalten@gmail.com> wrote:
>...const char foo[] = "mystring";
>char *constviol = strchr(foo,*foo); "
>
>What I don't get is that that 'const char f[]="mystring" ' is defined
>as a char,
No, it's defined as a conat char[9]. I'm assuming you mean
*f but that's a const char.
> but the prototype is defined as the following:
>
>char *strchr(const char *s, int c);
Correct.
>When foo gets de-referenced (ie *foo), how come the compiler doesn't
>complain about the difference between 'int' and 'char'?
Because it is one of the implicit conversions. You can do this with
no problem:
const char c = 'x';
int i;
i = c;
A similar thing happens during argument passing, since the prototype
specifically says the argument should be an int.
Why it is an int is a seperate story, but no doubt has to do
with the fact that routines such as getchar return int's (as
they, for better or worse, accomodate for the returned character
_and_ signals such as EOF).
--
Greg Comeau / Celebrating 20 years of Comeauity!
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
| |
| Old Wolf 2005-10-30, 9:56 pm |
| Arctic Fidelity wrote:
> Chad wrote:
>
>
> I have actually been wondering about this as well.
In C there is an implicit conversion from char to int.
This means that if there is a context expecting an int, but you
supply a char, then C will silently convert the char to an int.
Some people use this to call C a "weakly typed" language, and
say C has "holes in its type system". However those people are
usually Lisp trolls.
This means that the following code works:
char c = 5;
int i = c;
/* now 'i' has the value of 5 */
If C did not have this implicit conversion then you would have
to write something ugly like:
int i = (int)c;
To me, this is less type-safe than the real situation, as it
encourages the use of casts.
C also has an implicit conversion from int to char:
int i = 5;
char c = i;
/* now 'c' has a value of 5. */
But if 'i' had a value that couldn't be held by a char, then
we would have undefined behaviour (to cut a long story short).
Some compilers will issue a warning when you do a so-called
"narrowing conversion" like this.
C in fact has implicit conversions between all of the integral
and floating point types, with silent UB if the value can't
be represented.
By contrast, Java has implicit widening conversions, but no
implicit narrowing conversions. Java trolls often bring this up.
| |
| Keith Thompson 2005-10-31, 3:55 am |
| "Old Wolf" <oldwolf@inspire.net.nz> writes:
[...]
> C also has an implicit conversion from int to char:
>
> int i = 5;
> char c = i;
> /* now 'c' has a value of 5. */
>
> But if 'i' had a value that couldn't be held by a char, then
> we would have undefined behaviour (to cut a long story short).
Cutting a long story short never works around here. 8-)}
> Some compilers will issue a warning when you do a so-called
> "narrowing conversion" like this.
>
> C in fact has implicit conversions between all of the integral
> and floating point types, with silent UB if the value can't
> be represented.
Actually, overflow on a conversion has different rules than overflow
on an arithmetic operator. For arithmetic operators, overflow on a
signed integer type invokes undefined behavior. For conversion, it
either yields an implementation-defined result or raises an
implementation-defined signal (the latter is new in C99).
So, given
int i = <whatever>;
char c = i;
the implicit conversion of i to type char doesn't cause undefined
behavior -- and if plain char is unsigned, it yields a well-defined
result.
--
Keith Thompson (The_Other_Keith) kst-u@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.
| |
| Old Wolf 2005-10-31, 6:56 pm |
| Keith Thompson wrote:
> "Old Wolf" <oldwolf@inspire.net.nz> writes:
>
> Cutting a long story short never works around here. 8-)}
>
> It either yields an implementation-defined result or raises an
> implementation-defined signal (the latter is new in C99).
An implementation-defined signal might as well be UB, in practice.
I think the only thing you can do safely in a signal handler is set
a flag, or call exit(). What is the status of the char after the
signal handler returns? If it's indeterminate, then the subsequent
use of it will cause UB.
| |
| Keith Thompson 2005-10-31, 6:56 pm |
| "Old Wolf" <oldwolf@inspire.net.nz> writes:
> Keith Thompson wrote:
>
> An implementation-defined signal might as well be UB, in practice.
> I think the only thing you can do safely in a signal handler is set
> a flag, or call exit(). What is the status of the char after the
> signal handler returns? If it's indeterminate, then the subsequent
> use of it will cause UB.
So you set a flag in the signal handler; if the flag is set, you don't
look at the variable. It's not going to have anything useful in it
anyway.
I don't know of any implementation that takes advantage of the new
permission to raise a signal on overflow, and since the signal is
implementation-defined, you can't use it portably.
BTW, I think type char is guaranteed not to have any trap
representations, so an indeterminate value will just be one of the
values in the range CHAR_MIN..CHAR_MAX.
--
Keith Thompson (The_Other_Keith) kst-u@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.
| |
| Jordan Abel 2005-10-31, 9:55 pm |
| On 2005-10-31, Old Wolf <oldwolf@inspire.net.nz> wrote:
> Keith Thompson wrote:
>
> An implementation-defined signal might as well be UB, in practice.
> I think the only thing you can do safely in a signal handler is set
> a flag, or call exit().
Such a signal would most likely be SIGFPE. [I can't imagine what
else it would be], but the point is that it's something you can look
at the implementation's documents and find out what it does, and
that it'll do the same thing every time.
> What is the status of the char after the signal handler returns?
> If it's indeterminate, then the subsequent use of it will cause
> UB.
| |
| Jordan Abel 2005-10-31, 9:55 pm |
| On 2005-10-31, Keith Thompson <kst-u@mib.org> wrote:
> "Old Wolf" <oldwolf@inspire.net.nz> writes:
>
> So you set a flag in the signal handler; if the flag is set, you don't
> look at the variable. It's not going to have anything useful in it
> anyway.
>
> I don't know of any implementation that takes advantage of the new
> permission to raise a signal on overflow, and since the signal is
> implementation-defined, you can't use it portably.
>
> BTW, I think type char is guaranteed not to have any trap
> representations, so an indeterminate value will just be one of the
> values in the range CHAR_MIN..CHAR_MAX.
what about 100000000 on a signed-magnitude system?
unsigned types are guaranteed not to have any trap representations.
signed types are not. and char's signed-ness is implementation-specified.
|
|
|
|
|