473,322 Members | 1,510 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,322 software developers and data experts.

Sort of mystified from an earlier thread

This was taken from the following:

http://groups.google.com/group/comp....3e9afae83d061c

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

Nov 15 '05 #1
12 1391
On Sat, 29 Oct 2005 21:51:46 -0400, Chad <cd*****@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/
Nov 15 '05 #2
Arctic Fidelity wrote:
On Sat, 29 Oct 2005 21:51:46 -0400, Chad <cd*****@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/


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.

Nov 15 '05 #3
Chad wrote:

This was taken from the following:

http://groups.google.com/group/comp....3e9afae83d061c

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
Nov 15 '05 #4
pete wrote:

Chad wrote:

This was taken from the following:

http://groups.google.com/group/comp....3e9afae83d061c

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.


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
Nov 15 '05 #5
In article <11*********************@g14g2000cwa.googlegroups. com>,
Chad <cd*****@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?
Nov 15 '05 #6
Arctic Fidelity wrote:
Chad wrote:
const char foo[] = "mystring";
char *constviol = strchr(foo,*foo); "

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.


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.

Nov 15 '05 #7
"Old Wolf" <ol*****@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) 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.
Nov 15 '05 #8
Keith Thompson wrote:
"Old Wolf" <ol*****@inspire.net.nz> writes:
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-)}

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.

Nov 15 '05 #9
"Old Wolf" <ol*****@inspire.net.nz> writes:
Keith Thompson wrote:
"Old Wolf" <ol*****@inspire.net.nz> writes:
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-)}

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.


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) 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.
Nov 15 '05 #10
On 2005-10-31, Old Wolf <ol*****@inspire.net.nz> wrote:
Keith Thompson wrote:
"Old Wolf" <ol*****@inspire.net.nz> writes:
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-)}

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().


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.

Nov 15 '05 #11
On 2005-10-31, Keith Thompson <ks***@mib.org> wrote:
"Old Wolf" <ol*****@inspire.net.nz> writes:
Keith Thompson wrote:
"Old Wolf" <ol*****@inspire.net.nz> writes:
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-)}

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.


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.
Nov 15 '05 #12
Jordan Abel <jm****@purdue.edu> writes:
On 2005-10-31, Keith Thompson <ks***@mib.org> wrote:

[...]
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.


unsigned char is specifically guaranteed not to have trap
representations (it's represented using a pure binary notation).
Other unsigned types have no such guarantee; they can have padding
bits. (I think the presence of padding bits allows, but does not
require the existence of trap representations.)

But C99 6.2.6.1p5 says:

Certain object representations need not represent a value of the
object type. If the stored value of an object has such a
representation and is read by an lvalue expression that does not
have character type, the behavior is undefined. If such a
representation is produced by a side effect that modifies all or
any part of the object by an lvalue expression that does not have
character type, the behavior is undefined. Such a representation
is called a _trap representation_.

This is the definition of "trap representation" (the term is in
italics). I think the "does not have character type" wording implies
that plain char, even if it's signed, cannot have any trap
representations, but I'd be happier if I could find a clearer
statement to that effect.

Assume a 2's-complement signed representation for plain char, with
CHAR_BIT==8. Without the above statement, the binary value 11111111
could be a trap representation; with it, it must represent the value
-128.

--
Keith Thompson (The_Other_Keith) 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.
Nov 15 '05 #13

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

7
by: Nova's Taylor | last post by:
Hi folks, I am a newbie to Python and am hoping that someone can get me started on a log parser that I am trying to write. The log is an ASCII file that contains a process identifier (PID),...
7
by: Ben Thomas | last post by:
Hi all, I'm having some trouble understanding the behavior of std::ostringstream. (I'm using Visual Studio .Net & STL port 4.5.3). I'll appreciate if someone can give me a little explanation of...
4
by: jarkkotv | last post by:
Hi everyone! I'm having a little problem when sorting the ArrayList and I was wondering if there is a .NET guru who can help me out :) I'm trying to sort ArrayList alphabetically in ASP.Net...
3
by: Chad | last post by:
This was taken from the following: http://groups.google.com/group/comp.lang.c/browse_thread/thread/089dfb62c71802b3/663e9afae83d061c?hl=en#663e9afae83d061c And I quote: "Well, that's also ok...
0
by: Ray S via .NET 247 | last post by:
Hi, I am trying to sort articles based on Start Date. Since we areusing Content Management Server I have to use ChannelItem class(and so ChannelItem.StartDate property). Earlier we were...
48
by: Alex Chudnovsky | last post by:
I have come across with what appears to be a significant performance bug in ..NET 2.0 ArrayList.Sort method when compared with Array.Sort on the same data. Same data on the same CPU gets sorted a...
0
by: JosAH | last post by:
Greetings, I was asked to write a Tip Of the Week; so here goes: a lot of topics are started here in this forum (and a lot of other forums too) mentioning a problem about sorting data. ...
0
by: kronus | last post by:
Hi everyone, Please tell me what I am doing wrong: I have an xml data coming to my Air application that looks something like this: <project name="Sales Demos" path="/Company Home/Client...
4
by: blowdoof | last post by:
I'm facing folowing issue: to be able to print a list of objects in a user-defined way, i've implemented an IComparer (sortclass), which is able to sort any object by its property. I have a list...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.