Re: [CVS ci] string_str_index

2002-11-04 Thread Dan Sugalski
At 12:41 PM +0100 10/30/02, Leopold Toetsch wrote:

Nicholas Clark wrote:

Also, no-one commented on my suggestion a long time back to remove
-fno-strict-aliasing from gcc's flags. In theory we're stopping some possible
gcc optimisations with this.



I don't see a reason, why we would need -fno-strict-aliasing.


Let's yank it for now. If we start seeing heisenbugs crop up, we can 
put it back in and see if that's causing our problem.
--
Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk


Re: [CVS ci] string_str_index

2002-10-30 Thread Nicholas Clark
On Wed, Oct 30, 2002 at 11:13:09AM +0100, Leopold Toetsch wrote:
 I moved the two - almost identical - index op bodys out of core.ops 
 and called this functions string_str_index...
 
  and did introduce a new warning WRT const.
 
 - const is currently used in some string.c functions rather inconsistently
 - should we remove it alltogether
 - introduce a dummy CONST define as hint for the programmer
 - insert more const decls (e.g. string_trans_code doesn't modify its 
 src, so ...

I'd prefer more real and explicit use of const, and correcting all const-ness
mistakes, rather than leaving it as a hint to the programmer. It's possible
that compilers will be able to optimise better if they know something is
const.

Also, no-one commented on my suggestion a long time back to remove
-fno-strict-aliasing from gcc's flags. In theory we're stopping some possible
gcc optimisations with this.

Nicholas Clark



Re: [CVS ci] string_str_index

2002-10-30 Thread Peter Gibbs
Leopold Toetsch wrote:
 - const is currently used in some string.c functions rather inconsistently
 - should we remove it alltogether
 - introduce a dummy CONST define as hint for the programmer
 - insert more const decls (e.g. string_trans_code doesn't modify its
 src, so ...

At one stage all the source strings were defined as const; I believe
this changed with the introduction of COW strings. For example,
string_transcode may call string_copy if no conversion is required;
string_copy modifies the source's flags in order to mark it as COW,
and therefore its source cannot be const.
I seem to recall that string_make, on the other hand, requires the
'buffer' parameter to be const, otherwise some compilers complain
if it is called with a literal string.
I suspect that whatever we do, some compiler will find something
to complain about; all we can do is try to keep the overall noise
level as low as possible.
--
Peter Gibbs
EmKel Systems




Re: [CVS ci] string_str_index

2002-10-30 Thread Leopold Toetsch
Nicholas Clark wrote:



I'd prefer more real and explicit use of const, and correcting all const-ness
mistakes, rather than leaving it as a hint to the programmer. It's possible
that compilers will be able to optimise better if they know something is
const.



Ack.



Also, no-one commented on my suggestion a long time back to remove
-fno-strict-aliasing from gcc's flags. In theory we're stopping some possible
gcc optimisations with this.



I don't see a reason, why we would need -fno-strict-aliasing.



Nicholas Clark



leo







Re: [CVS ci] string_str_index

2002-10-30 Thread Leopold Toetsch
Peter Gibbs wrote:


Leopold Toetsch wrote:



- insert more const decls (e.g. string_trans_code doesn't modify its
src, so ...



At one stage all the source strings were defined as const; I believe
this changed with the introduction of COW strings. For example,
string_transcode may call string_copy if no conversion is required;



string_transcode may call string_copy, when the types/encodings are the 
same. This is:
- UUOST (useless use of string_trancode ;-)
- catched on calling string_transcode
- abuse of string_transcode to make a COW string copy
IMHO this part should be tossed, so string_transcode can take a const str.


I suspect that whatever we do, some compiler will find something
to complain about; all we can do is try to keep the overall noise
level as low as possible.



This warning WRT (void*) buffer was introduced for tcc, says the 
comment. Can we put a
#ifdef __tcc__ / #endif around this - does tcc define something like this?

leo




Re: [CVS ci] string_str_index

2002-10-30 Thread Andy Dougherty
On Wed, 30 Oct 2002, Leopold Toetsch wrote:

[sundry 'const' warnings]

 This warning WRT (void*) buffer was introduced for tcc, says the 
 comment. Can we put a
 #ifdef __tcc__ / #endif around this - does tcc define something like this?

Short answer:  Yes, but it wouldn't really make any signficiant 
difference.  (And I don't know the correct cpp #define to use as I don't
have tcc installed anywhere and I didn't see such a #define in any
of the on-line documentation, though I'd certainly imagine there is one.)

Longer answer:  I assume you're referring to this part of string.c:

if (flags  BUFFER_external_FLAG) {
/* The following cast discards the 'const'.  That raises
   a warning with gcc, but is ok since the caller indicated
   it was safe by setting BUFFER_external_FLAG.
   (The cast is necessary to pacify TenDRA's tcc.)
*/
s-bufstart = (void *) buffer;

If you remove the cast, you still get a warning from gcc (and possibly
other compilers) since you are still trying to discard the 'const'.
So removing the cast only has the effect of causing tcc to refuse to build
string.c.

Nicholas Clark suggested that we could perhaps use a union, something like

union {
  const void *const_ptr;
void *nonconst_ptr;
} ptr;
/* ... */

if (flags  BUFFER_external_FLAG) {
ptr.const_ptr = buffer;
s-bufstart = ptr.nonconst_ptr;
s-buflen = buflen;
}


This should get rid of all warnings.  I haven't checked whether the optimizer
optimizes away the extra assignment or not.  If it does, then this union
trick may be the way to go.

Volunteers to check it out would be welcome.

-- 
Andy Dougherty  [EMAIL PROTECTED]




Re: [CVS ci] string_str_index

2002-10-30 Thread Leopold Toetsch
Andy Dougherty wrote:


On Wed, 30 Oct 2002, Leopold Toetsch wrote:

[sundry 'const' warnings]




Nicholas Clark suggested that we could perhaps use a union, something like



Nice idea - works for me (gcc 2.95.2)

Slightly modified - please try this (cc -Wall -Wcast-qual ..)

static union {
	const void * __c_ptr;
	void * __ptr;
} __ptr_u;

#define const_cast(b) (__ptr_u.__c_ptr = (b), __ptr_u.__ptr)

char *f(const void *b)
{
	char *s = (char*) const_cast(b);
	return s;
}
int main() {
	char *s = f(abc);
	return *s != 'a';
}

leo




Re: [CVS ci] string_str_index

2002-10-30 Thread Andy Dougherty
On Wed, 30 Oct 2002, Leopold Toetsch wrote:

  Nicholas Clark suggested that we could perhaps use a union, something like
 
 Nice idea - works for me (gcc 2.95.2)
 
 Slightly modified - please try this (cc -Wall -Wcast-qual ..)

 static union {
   const void * __c_ptr;
   void * __ptr;
 } __ptr_u;

 #define const_cast(b) (__ptr_u.__c_ptr = (b), __ptr_u.__ptr)

This works too, but not as well.
 
First, although I could be wrong, static variables in possibly threaded
code always worry me.

More specifically, however, my version, which used a variable local to the
function in question, ended up getting compiled (with cc -O) to the exact
same assembly code as the version with the plain cast.  Yes, it is more to
type in those few places in the code where it's needed, but I think that's
ok because one shouldn't be throwing away 'const'-ness casually anyway.

-- 
Andy Dougherty  [EMAIL PROTECTED]