Re: Signed int overflow behaviour in the security context

[Georg Bauhaus]

On Sat, 2007-01-27 at 02:47 +0100, Andreas Bogk wrote:


> I'm exactly talking about the semantics of "undefined" here.  It would
> be immensely reassuring if a compiler would at least interpret this as
> "unspecified, but consistent".  Even better would be a defined and
> documented semantics for everything left undefined by the standard.


I have read the admonitions to have this thread end with the good
final words about what is causing all this: a language issue. Still,
what you are saying here is that a compiler should decide
that the meaning of "undefined" be defined.

If you know what you want to happen on your microprocessor, it seems
much simpler to just give it suitable instructions (you know how)
than to add a decision tree of GCC switches that will essentially
establish another non-portable language in itself, in a most
complicated way (as per the suggestion of Paul Schlie, considering
the number of ifs in the compiler control language I see there.)

Do you C the facts? ;-)

Georg 

Re: Signed int overflow behaviour in the security context

[Richard Kenner]

> While there are programmers out there where any attempt at getting them
> to write even remotely secure software, most of them can be taught the
> concept of LIA-1 semantics, and a lot of them already know and write
> software accordingly.  Getting them to understand that an expression
> like "if (a + b < a)" doesn't do what they would expect is harder.
> Getting them to understand that "if (a < 0)" might fail on them in
> obscure cases is close to impossible.

Really?  It's easier to teach programmers that if they keep adding
positive numbers, they'll eventually get some negative number than it
is to teach them that if they keep adding positive numbers, it's
undefined what happens when it overflows?  This seems odd to me since
so few programmers know machine-level operations anymore.

Re: Signed int overflow behaviour in the security context

[Richard Kenner]

> I'm exactly talking about the semantics of "undefined" here.  It would
> be immensely reassuring if a compiler would at least interpret this as
> "unspecified, but consistent".  Even better would be a defined and
> documented semantics for everything left undefined by the standard.

Are you proposing to define an default initial value for all uninitialized
variables?

Re: Signed int overflow behavior in the security context

[Richard Guenther]

On 1/27/07, Paul Schlie <[EMAIL PROTECTED]> wrote:

>> On Fri, Jan 26, 2007 at 06:57:43PM -0500, Paul Schlie wrote:
> Likewise, if the program has an uninitialized variable, the behavior
> will differ depending on details of optimization and how variables are
> assigned to memory.  Heap allocated for the first time might always be
> zero (as the OS delivers it that way), turning on optimization might then
> result in a nonzero initial value because of reuse of a register.

- I would argue that in this circumstance although the resulting value may
differ, the results are actually equivalent; as in both circumstances the
value returned is the value associated with it's storage location; and as
the value of all storage locations are arbitrary unless otherwise well
specified; the result may change from run to run regardless of any applied
optimizations.


If you read from an uninitialized variable twice you might as well get
a different result each time.  This is exactly the same issue than with
signed overflow and observable behavior - though as somebody notes
later - the uninitialized variable case doesn't stir up too many peoples
mind.

Richard.

Re: Signed int overflow behavior in the security context

[Florian Weimer]

* Paul Schlie:

>> People always say this, but they don't really realize what they are
>> saying. This would mean you could not put variables in registers, and
>> would essentially totally disable optimization.
>
> - can you provide an example of a single threaded program where the
> assignment of variable to a machine register validly changes its
> observable logical results?

Here's the usual suspect: 

Although the "validly" part is somewhat debatable.

Signed int overflow behavior in the security context

[Paul Schlie]

> Richard Guenther wrote:
> On 1/27/07, Paul Schlie <[EMAIL PROTECTED]> wrote:
 On Fri, Jan 26, 2007 at 06:57:43PM -0500, Paul Schlie wrote:
>>> Likewise, if the program has an uninitialized variable, the behavior
>>> will differ depending on details of optimization and how variables are
>>> assigned to memory.  Heap allocated for the first time might always be
>>> zero (as the OS delivers it that way), turning on optimization might then
>>> result in a nonzero initial value because of reuse of a register.
>> 
>> - I would argue that in this circumstance although the resulting value may
>> differ, the results are actually equivalent; as in both circumstances the
>> value returned is the value associated with it's storage location; and as
>> the value of all storage locations are arbitrary unless otherwise well
>> specified; the result may change from run to run regardless of any applied
>> optimizations.
> 
> If you read from an uninitialized variable twice you might as well get
> a different result each time.  This is exactly the same issue than with
> signed overflow and observable behavior - though as somebody notes
> later - the uninitialized variable case doesn't stir up too many peoples
> mind.

-  However x ^= x :: 0 for example is well defined because absent any
intervening assignments, all reference to x must semantically yield the same
value, regardless of what that value may be. (but does not require that its
associated storage location be literally referenced multiple times unless
correspondingly declared as being volatile; as in effect variables declared
as being volatile have no guarantee of retaining the value most recently
logically assigned within a single tread of execution, and thereby in effect
are bound to a storage location known to perpetually yield indeterminate
values upon each distinct logically specified reference, but even here the
semantics of the language requires that the reference be literally
performed, and not assumed to yield any value although the value is
undefined).

Re: Can C and C++ object files be linked into an executable?

[Ray Hurst]

Maybe everybody has misunderstood. These are tool issues not basic C 
programming. Object file format has nothing to do with C programming.

More specifically they are linker issues.

Is the ABI format different between C and C++ object files.
Ray

Joe Buck wrote:

On Fri, Jan 26, 2007 at 04:25:54PM -0800, Ray Hurst wrote:

They told me to go to the compiler writer newsgroup.


"They" told you wrong.  You don't need a compiler writer to answer
basic C++ programming questions.

Top level libgcc migration tips

[Daniel Jacobowitz]

I've put up some information on the wiki about moving configuration
information from gcc to libgcc.  Please, feel free to add to it!

http://gcc.gnu.org/wiki/Top-Level_Libgcc_Migration

-- 
Daniel Jacobowitz
CodeSourcery

Re: Can C and C++ object files be linked into an executable?

[Ian Lance Taylor]

Ray Hurst <[EMAIL PROTECTED]> writes:

> Maybe everybody has misunderstood. These are tool issues not basic C
> programming. Object file format has nothing to do with C programming.
> More specifically they are linker issues.
> 
> Is the ABI format different between C and C++ object files.

If you want to phrase the question in terms of object file format and
linker issues, the answer is that the format is the same.

It's easy to see why: the compiler does not produce object files.  It
produces files containing assembly language.  The assembler produces
object files.  The C and C++ compilers use the same assembler.

Ian

GCC-4.0.4

[Gabriel Dos Reis]

Please consider the GCC-4.0.4 as frozen.  No non-documentation
check-in is permitted.  For documentation check-in, please consult
with me first.

Thanks,

-- Gaby

Re: Can C and C++ object files be linked into an executable?

[Ferad Zyulkyarov]

Hi,


If you want to phrase the question in terms of object file format and
linker issues, the answer is that the format is the same.

It's easy to see why: the compiler does not produce object files.  It
produces files containing assembly language.  The assembler produces
object files.  The C and C++ compilers use the same assembler.


Before passing the ball to the assembler the compiler does name
mangling. It is different for C and C++ and the actual problem at link
time comes from here. If you have C++ sources and can compile these
sources and later link with the C object files surround your method
declarations with

extern "C" {...}

This may help. If you don't have the c++ sources, create wrappers
either to C object files or C++. For now I don't know any other
alternative.

--
Ferad Zyulkyarov
Barcelona Supercomputing Center

Re: Can C and C++ object files be linked into an executable?

[Ray Hurst]

I think this was the answer I was looking for.
By the way, was this the correct place to post it?
Ray

Ferad Zyulkyarov wrote:

Hi,


If you want to phrase the question in terms of object file format and
linker issues, the answer is that the format is the same.

It's easy to see why: the compiler does not produce object files.  It
produces files containing assembly language.  The assembler produces
object files.  The C and C++ compilers use the same assembler.


Before passing the ball to the assembler the compiler does name
mangling. It is different for C and C++ and the actual problem at link
time comes from here. If you have C++ sources and can compile these
sources and later link with the C object files surround your method
declarations with

extern "C" {...}

This may help. If you don't have the c++ sources, create wrappers
either to C object files or C++. For now I don't know any other
alternative.

Re: How to enforce the use of libjava/scripts/jar?

[Gerald Pfeifer]

On Mon, 22 Jan 2007, Andreas Schwab wrote:
>> My question now is: Is there any way to enforce the use and installation
>> of our own copy of ${PREFIX}/bin/jar${PROGRAMSUFFIX}?
> Set JAR to no before configuring.

Works like a charm.  Thanks for the hint, Andreas!

Gerald

Re: Can C and C++ object files be linked into an executable?

[Diego Novillo]

Ray Hurst wrote on 01/27/07 16:48:

I think this was the answer I was looking for.
By the way, was this the correct place to post it?


No.  That was a language question.  gcc-help or comp.std.c++ would have 
been a better forum.  This deals with the development of GCC, not its use.

Re: Can C and C++ object files be linked into an executable?

[David Daney]

Ray Hurst wrote:

By the way, was this the correct place to post it?
Ray
Two very senior GCC developers have already answered your question in 
the same manner.  If you review what they said, you will see that the 
answer is *no*.


David Daney

G++ OpenMP implementation uses TREE_COMPLEXITY?!?!

[Steven Bosscher]

Hello rth,

Can you explain what went through your mind when you picked the 
tree_exp.complexity field for something implemented new...  :-(

You know (or so I assume) this was a very Very VERY BAD thing to do,
if we are ever going to get rid of TREE_COMPLEXITY, which is a major
memory hog.  We are all better off if we can remove TREE_COMPLEXITY.

I thought we were there with an Ada patch I've just crafted, and
with the effort of Tom Tromey to remove TREE_COMPLEXITY usage from
the java front end.

But my all-languages bootstrap failed, and guess what:

/* Used to store the operation code when OMP_ATOMIC_DEPENDENT_P is set.  */
#define OMP_ATOMIC_CODE(NODE) \
  (OMP_ATOMIC_CHECK (NODE)->exp.complexity)

We should _not_ be doing this.  *Especially* not through anything
else than the TREE_COMPLEXITY accessor macro to hide the issue...
or maybe that was done on purpose? ;-)

I don't know if there is another place where we can store this
value, but we definitely should.  It is hugely disappointing to see
that, just when we're there with all other front ends, you've just
introduced another user of the tree_exp.complexity field.

Can you please help me fix this ASAP?

Gr.
Steven

Re: Ada and the TREE_COMPLEXITY field on struct tree_exp

[Steven Bosscher]

On 1/18/07, Richard Kenner <[EMAIL PROTECTED]> wrote:

> I had thought of a hash table, too, but I couldn't figure out where to
> initialize and free it (i.e. where it is a "live" table, so to speak).  For
> example, I don't know if this table would be required after gimplification,
> and I also don't even know how GNAT translates its own representation to
> GIMPLE (whole translation unit at once? function at a time?).

It's fairly conventional in that part.

But that's not relevant here.  This is used for transmitting location
information on FIELD_DECLs back to the front end.  Most records in Ada are
defined at GCC's global level, so there's little point in doing anything
other than a hash table that's initialized early on (e.g., in the routine
"gigi") and never freed.  Also, the current code just saves the result for
EXPR_P nodes since only those have TREE_COMPLEXITY, but if you're switching
to a hash table, it's probably best just to record *all* results in it.


OK, attached is the preliminary hack I created some time ago.  After
some changes, it now bootstraps, but I haven't tested it yet.  I'm
passing it as an RFC.

I did not go as far as what you suggested, because I don't want to
change code I don't really understand.  This is the minimum patch I
would need to remove the complexity field from struct tree_exp.  If
one of you can do better than this, for the purpose of GNAT, please go
ahead and change it any way you see fit ;-)


No point in getting too sophisticated here: this is just a small hack to
avoid pathalogical compile-time behavior when compiling certain very complex
record types.


Are these test cases in the FSF test suite?

Thanks,
Gr.
Steven
2007-xx-xx  Steven Bosscher  <[EMAIL PROTECTED]>

gcc/
	* tree.c (iterative_hash_expr): Handle types generically.
	Also handle PLACEHOLDER_EXPR nodes.

ada/
	* decl.c: Include hashtab.h and gt-ada-decl.h
	(struct cached_annotate_value_t, cached_annotate_value_tab,
	cached_annotate_value_hash, cached_annotate_value_eq,
	cached_annotate_value_marked_p, cached_annotate_value_lookup,
	cached_annotate_value_insert): New data structures and support
	functions to implement a cache for annotate_value results.
	(annotate_value): Use the hash table as a cache, instead of
	using TREE_COMPLEXITY.

Index: tree.c
===
--- tree.c	(revision 121230)
+++ tree.c	(working copy)
@@ -5158,12 +5158,21 @@ iterative_hash_expr (tree t, hashval_t v
 	  /* DECL's have a unique ID */
 	  val = iterative_hash_host_wide_int (DECL_UID (t), val);
 	}
+  else if (class == tcc_type)
+	{
+	  /* TYPEs also have a unique ID.  */
+	  val = iterative_hash_host_wide_int (TYPE_UID (t), val);
+	}
   else
 	{
-	  gcc_assert (IS_EXPR_CODE_CLASS (class));
-	  
 	  val = iterative_hash_object (code, val);
 
+	  /* The tree must be a placeholder now, or an expression.
+	 For anything else, die.  */
+	  if (code == PLACEHOLDER_EXPR)
+	return val;
+	  gcc_assert (IS_EXPR_CODE_CLASS (class));
+
 	  /* Don't hash the type, that can lead to having nodes which
 	 compare equal according to operand_equal_p, but which
 	 have different hash codes.  */
Index: ada/decl.c
===
--- ada/decl.c	(revision 121230)
+++ ada/decl.c	(working copy)
@@ -34,6 +34,7 @@
 #include "convert.h"
 #include "ggc.h"
 #include "obstack.h"
+#include "hashtab.h"
 #include "target.h"
 #include "expr.h"
 
@@ -5864,6 +5865,104 @@ compare_field_bitpos (const PTR rt1, con
 return 1;
 }
 
+
+/* In annotate_value, we compute an Uint to be placed into an Esize,
+   Component_Bit_Offset, or Component_Size value in the GNAT tree.
+   Because re-computing the value is expensive, we cache the unique
+   result for each tree in a hash table.  The hash table key is the
+   hashed GNU tree, and the hash table value is the useful data in
+   the buckets.
+
+   The hash table entries are pointers to cached_annotate_value_t.
+   We hash GNU_SIZE in the insert and lookup functions for this
+   the hash table, using iterative_hash_expr.  Caching the hash
+   value on the bucket entries speeds up the hash table quite a
+   bit during resizing.  */
+
+struct cached_annotate_value_t GTY(())
+{
+  /* Cached hash value for this table entry.  */
+  hashval_t hashval;
+
+  /* The cached value.
+ ??? This should be an Uint but gengtype choques on that.  */
+  int value;
+
+  /* The tree that the value was computed for.  */
+  tree gnu_size;
+};
+
+/* The hash table used as the annotate_value cache.  */
+static GTY ((if_marked ("cached_annotate_value_marked_p"),
+	 param_is (struct cached_annotate_value_t)))
+  htab_t cached_annotate_value_tab;
+
+/* Hash an annotate_value result for the annotate_value cache.
+   But actually, we've stored the hash value on the cache entry.  */
+
+static unsigned int
+cached_annotate_value_hash (const void *pa)
+{
+  const struct cached_annotate_value_t *a = pa;
+ 

Re: G++ OpenMP implementation uses TREE_COMPLEXITY?!?!

[Richard Guenther]

On 1/28/07, Steven Bosscher <[EMAIL PROTECTED]> wrote:

Hello rth,

Can you explain what went through your mind when you picked the
tree_exp.complexity field for something implemented new...  :-(


Not much...

http://gcc.gnu.org/ml/gcc-patches/2005-10/msg01117.html

"... but my brain isn't working anymore."

;)

Richard.

Re: How to enforce the use of libjava/scripts/jar?

[Gerald Pfeifer]

On Sun, 21 Jan 2007, Tom Tromey wrote:
> I think we should never install the jar script -- we now have a gjar
> tool from Classpath which we can use.  On svn trunk we do build and
> install this, for native systems (I think to avoid mixing host and
> target executables in bindir).  I think we should treat the jar script
> as something that is useful for the build, but nothing else.

No objection from my side!  My problem here was that we *sometimes*
install the jar script, and sometimes we don't.  Never installing it
would also work for me. ;-)

Gerald

GCC 4.2 Release notes are almost empty

[Manuel López-Ibáñez]

Well, not really. But there are a lot of new features and important
things missing. And it should be responsibility of whoever added the
new feature to document it, shouldn't it? So now that we are in the
late phase of stage3, it could be a good moment.

Martin Michlmayr listed some things that may be worth mentioning:
http://gcc.gnu.org/ml/gcc/2006-08/msg00435.html

Some of them are still missing. Other things are not present in that
list, for example the new diagnostics pragmas.

I have made a quick and dirty Perl script for getting the changelog of
all the commits done by a single developer during GCC 4.2 lifetime.
So, take a look to your history and check whether you forgot to
mention something in http://gcc.gnu.org/gcc-4.2/changes.html before it
is too late!

Let's tell the world what we have prepared for GCC 4.2! [*]

Cheers,

Manuel.

[*] Actually, not 'we' but 'you'. I got involved in GCC after 4.2 was
branched. ;-)
#!/usr/bin/perl -w

my $USER="mmitchel";
my $GCC_VERSION = "4.2";
my $PREV_GCC_VERSION = "4.1";
my $SVNREPOS = "svn://gcc.gnu.org/svn";

my $buffer;
my $url;
my $svnlog = "svn log --incremental";

$GCC_VERSION =~ s/\./_/g;
$PREV_GCC_VERSION =~ s/\./_/g;

$url = "${SVNREPOS}/gcc/branches/gcc-${PREV_GCC_VERSION}-branch/";
$buffer = `$svnlog --stop-on-copy $url | grep -e "^r" | tail -n 1`;
my $prevbranch;
($prevbranch) = ($buffer =~ m/^r(\d+) /);

$url = "${SVNREPOS}/gcc/branches/gcc-$GCC_VERSION-branch/";
$buffer = `$svnlog --stop-on-copy $url | grep -e "^r" | tail -n 1`;
my $lastbranch;
($lastbranch) = ($buffer =~ m/^r(\d+) /);

$url = "${SVNREPOS}/gcc/trunk/";
@buffer = `$svnlog -r $prevbranch:$lastbranch $url | grep -e "^r" | grep -e "| $USER |"`;
foreach $line (@buffer)
{
$line =~ m/^r(\d+) /;
print `$svnlog -r $1 $url`;
}

$url = "${SVNREPOS}/gcc/branches/gcc-$GCC_VERSION-branch/";
@buffer = `$svnlog -r $lastbranch:HEAD $url | grep -e "^r" | grep -e "| $USER |"`;
foreach $line (@buffer)
{
$line =~ m/^r(\d+) /;
print `$svnlog -r $1 $url`;
}

Re: Signed int overflow behavior in the security context

[Robert Dewar]

Paul Schlie wrote:


-  However x ^= x :: 0 for example is well defined because absent any
intervening assignments, all reference to x must semantically yield the same
value, regardless of what that value may be.


Nope, there is no such requirement in the standard. Undefined means
undefined. Again you are confusing the language C defined in the C 
standard with some ill-defined language in your mind with different 
semantics. Furthermore, it is quite easy to see how in practice you

might get different results on successive accesses.

Re: Signed int overflow behavior in the security context

[Paul Schlie]

> Robert Dewar wrote
>> Paul Schlie wrote:
>> -  However x ^= x :: 0 for example is well defined because absent any
>> intervening assignments, all reference to x must semantically yield the
>> same value, regardless of what that value may be.
> 
> Nope, there is no such requirement in the standard. Undefined means
> undefined. Again you are confusing the language C defined in the C
> standard with some ill-defined language in your mind with different
> semantics. Furthermore, it is quite easy to see how in practice you
> might get different results on successive accesses.

I'm game; how might multiple specified references to the same non-volatile
variable with no specified intervening assignments in a single threaded
language ever justifiably be interpreted to validly yield differing values?

(any logically consistent concrete example absent reliance on undefined
hand-waving would be greatly appreciated; as any such interpretation or
implementation would seem clearly logically inconsistent and thereby
useless; as although the value of a variable may be undefined, variable
reference semantics are well defined and are independent of its value)

Re: Signed int overflow behavior in the security context

[Brooks Moses]

Paul Schlie wrote:

Robert Dewar wrote

Paul Schlie wrote:

-  However x ^= x :: 0 for example is well defined because absent any
intervening assignments, all reference to x must semantically yield the
same value, regardless of what that value may be.

Nope, there is no such requirement in the standard. Undefined means
undefined. Again you are confusing the language C defined in the C
standard with some ill-defined language in your mind with different
semantics. Furthermore, it is quite easy to see how in practice you
might get different results on successive accesses.


I'm game; how might multiple specified references to the same non-volatile
variable with no specified intervening assignments in a single threaded
language ever justifiably be interpreted to validly yield differing values?

(any logically consistent concrete example absent reliance on undefined
hand-waving would be greatly appreciated; as any such interpretation or
implementation would seem clearly logically inconsistent and thereby
useless; as although the value of a variable may be undefined, variable
reference semantics are well defined and are independent of its value)


I think you and Robert may be talking about different contexts.  I'm 
pretty sure (though not positive) that Robert is talking about the case 
after an undefined operation has occurred.  I'm not sure if you're 
talking about that, or talking about normal program operation.


In any case, for the "after an undefined operation" context, probably a 
more useful way to think about it is this: After an undefined operation, 
there are no guarantees about what code the program will be executing. 
In particular, there is no guarantee that it will actually be executing 
the code that you wrote.  And thus, any argument that assumes that it's 
doing so -- for instance, an argument that it's accessing the same 
location in memory twice, and thus should get the same result both times 
-- is relying on incorrect axioms.


This comes about because of a more fundamental and crucially important 
observation: There is _never_ a guarantee about the particular code that 
a program will be executing -- if there were, this would be assembly 
language, and optimization would be illegal.  The C standard, if it is 
anything like the Fortran standard, does not say anything at all about 
what machine code will be executed.  The guarantee is that the code that 
is being executed will have the _same result_ as the code that was 
written, so long as the written code was legal.


It thus seems pretty easy to see why undefined results can cause 
programs to act strangely.  The compiler is free, under the standard, to 
write whatever code it wants so long as that code produces the "right" 
answer to legal operations.  There's often no good reason to expect that 
this code will still produce the "right" answer to illegal operations. 
C is not assembly language.


Does that logic work for you?

- Brooks

Re: Signed int overflow behavior in the security context

[Robert Dewar]

Paul Schlie wrote:


I'm game; how might multiple specified references to the same non-volatileS
variable with no specified intervening assignments in a single threaded
language ever justifiably be interpreted to validly yield differing values?


Sorry, I'm not "game", it's something you should be able to figure out
if you know how compilers generate code and how typical compiler
optimization circuits propagate undefined information.


(any logically consistent concrete example absent reliance on undefined
hand-waving would be greatly appreciated; as any such interpretation or
implementation would seem clearly logically inconsistent and thereby
useless; as although the value of a variable may be undefined, variable
reference semantics are well defined and are independent of its value) 


Nope, you are making this up again, if you reference an uninitialized
variables, the value is undefined, period.

Re: Signed int overflow behavior in the security context

[Paul Schlie]

> Brooks Moses wrote:
>  ...
> Does that logic work for you?

no, as although a variable's value may not have been previously defined
within the context of a particular program, a variable's access semantics
are orthogonal to what ever value may result from that variable's access;
and thereby although it's resulting value may be indeterminate, successive
logical references must sensibly be presumed to yield equivalent values
baring the variable being declared as being volatile, or having an
intervening assignment.

(there seems to be too much desire to arbitrarily justify anything at the
drop of a hat given an opportunity to associate it directly or indirectly
with an undefined behavior, regardless of its sensibly; as opposed to
recognizing an undefined behavior as an opportunity to define useful
logically consistently semantics in their absents, although potentially
not strictly portable between implementations)

Re: Signed int overflow behavior in the security context

[Robert Dewar]

Brooks Moses wrote:

I think you and Robert may be talking about different contexts.  I'm 
pretty sure (though not positive) that Robert is talking about the case 
after an undefined operation has occurred.  I'm not sure if you're 
talking about that, or talking about normal program operation.


In any case, for the "after an undefined operation" context, probably a 
more useful way to think about it is this: After an undefined operation, 
there are no guarantees about what code the program will be executing. 
In particular, there is no guarantee that it will actually be executing 
the code that you wrote.  And thus, any argument that assumes that it's 
doing so -- for instance, an argument that it's accessing the same 
location in memory twice, and thus should get the same result both times 
-- is relying on incorrect axioms.


Yes, good summary ... that's exactly right


This comes about because of a more fundamental and crucially important 
observation: There is _never_ a guarantee about the particular code that 
a program will be executing -- if there were, this would be assembly 
language, and optimization would be illegal.  The C standard, if it is 
anything like the Fortran standard, does not say anything at all about 
what machine code will be executed.  The guarantee is that the code that 
is being executed will have the _same result_ as the code that was 
written, so long as the written code was legal.


Indeed the C standard is similar to the Fortran standard in this respect.


It thus seems pretty easy to see why undefined results can cause 
programs to act strangely.  The compiler is free, under the standard, to 
write whatever code it wants so long as that code produces the "right" 
answer to legal operations.  There's often no good reason to expect that 
this code will still produce the "right" answer to illegal operations. 
C is not assembly language.


Indeed?


Does that logic work for you?


We will see :-)


- Brooks

Re: Signed int overflow behavior in the security context

[Robert Dewar]

Paul Schlie wrote:

Brooks Moses wrote:
 ...
Does that logic work for you?


no, as although a variable's value may not have been previously defined
within the context of a particular program, a variable's access semantics
are orthogonal to what ever value may result from that variable's access;
and thereby although it's resulting value may be indeterminate, successive
logical references must sensibly be presumed to yield equivalent values
baring the variable being declared as being volatile, or having an
intervening assignment.


Paul, you really really need to read the C standard. It's beginning
to sound as though you haven't, since you keep making things up that
are just not justified by the standard.


(there seems to be too much desire to arbitrarily justify anything at the
drop of a hat given an opportunity to associate it directly or indirectly
with an undefined behavior, regardless of its sensibly


There is no question about what the C standard makes undefined here.
That of course does not preclude giving it defined semantics in a
particular language, thus effectively extending the language, but the
C standard committee in making something undefined is very deliberately
deciding that it is more appropriate than making it implementation
defined.

In the case of access to uninitialized variables in C, no one (or
almost no one, I realize you are an exception), would favor trying
to make this implementation defined. The only way you will get this
is by creating a variant of gcc for your own use yourself :-)

Now a special mode for debugging which does initialize all
uninitialized variables to a specified value, a la GNAT's
pragma Initialize_Scalars, could be useful. But anyone relying
on Paul Schlie semantics for uninitialized variables is writing
rubbish instead of C!

Re: Signed int overflow behavior in the security context

[Paul Schlie]

> Robert Dewar wrote:
>> Paul Schlie wrote:
>>> Brooks Moses wrote:
>>>  ...
>>> Does that logic work for you?
>> 
>> no, as although a variable's value may not have been previously defined
>> within the context of a particular program, a variable's access semantics
>> are orthogonal to what ever value may result from that variable's access;
>> and thereby although it's resulting value may be indeterminate, successive
>> logical references must sensibly be presumed to yield equivalent values
>> baring the variable being declared as being volatile, or having an
>> intervening assignment.
> 
> Paul, you really really need to read the C standard. It's beginning
> to sound as though you haven't, since you keep making things up that
> are just not justified by the standard.
>> 
>> (there seems to be too much desire to arbitrarily justify anything at the
>> drop of a hat given an opportunity to associate it directly or indirectly
>> with an undefined behavior, regardless of its sensibly
> 
> There is no question about what the C standard makes undefined here.
> That of course does not preclude giving it defined semantics in a
> particular language, thus effectively extending the language, but the
> C standard committee in making something undefined is very deliberately
> deciding that it is more appropriate than making it implementation
> defined.
> 
> In the case of access to uninitialized variables in C, no one (or
> almost no one, I realize you are an exception), would favor trying
> to make this implementation defined. The only way you will get this
> is by creating a variant of gcc for your own use yourself :-)
> 
> Now a special mode for debugging which does initialize all
> uninitialized variables to a specified value, a la GNAT's
> pragma Initialize_Scalars, could be useful. But anyone relying
> on Paul Schlie semantics for uninitialized variables is writing
> rubbish instead of C!

[ISO/IEC 14882-2003] Section 8.5, paragraph 9 says: "... if no initializer
is specified for a nonstatic object, the object and its subobjects, if any,
have an indeterminate initial value"

Thereby it seems fairly clear to me that although an uninitialized variable
has an indeterminate INITIAL value, all subsequent accesses to that variable
will yield that INITIAL value until otherwise programmatically modified.

Thereby x ^= x is correspondingly well defined if non-volatile as originally
asserted.

Re: Signed int overflow behavior in the security context

[James Dennett]

Paul Schlie wrote:
>> Brooks Moses wrote:
>>  ...
>> Does that logic work for you?
> 
> no, as although a variable's value may not have been previously defined
> within the context of a particular program, a variable's access semantics
> are orthogonal to what ever value may result from that variable's access;

No; it's not just the value that is undefined; it's the
behavior of code attempting to use that value that is
undefined.  Aborting the program is quite conforming if
your program uses "the value" of an uninitialized int,
for example.  I write "the value" in quotes because the
variable does not *have* a value until one is assigned
to it.  The fact that storage allocated for the variable
holds some bit pattern shouldn't be confused with that
variable having a value; so long as the variable has not
been given a value, the compiler might read it from
anywhere or nowhere, and has no obligation to be
consistent.  I've seen no justification for any claim
that there is an obligation on the compiler to produce
consistent values in this situation; the C standard, on
the other hand, states quite clearly that code *cannot*
rely on any such thing.

-- James

Re: Signed int overflow behavior in the security context

[Paul Schlie]

> Paul Schlie wrote:
>>> Brooks Moses wrote:
>>>  ...
>>> Does that logic work for you?
>> 
>> no, as although a variable's value may not have been previously defined
>> within the context of a particular program, a variable's access semantics
>> are orthogonal to what ever value may result from that variable's access;
>
> No; it's not just the value that is undefined; it's the
> behavior of code attempting to use that value that is
> undefined.  Aborting the program is quite conforming if
> your program uses "the value" of an uninitialized int,
> for example.  I write "the value" in quotes because the
> variable does not *have* a value until one is assigned
> to it.  The fact that storage allocated for the variable
> holds some bit pattern shouldn't be confused with that
> variable having a value; so long as the variable has not
> been given a value, the compiler might read it from
> anywhere or nowhere, and has no obligation to be
> consistent.  I've seen no justification for any claim
> that there is an obligation on the compiler to produce
> consistent values in this situation; the C standard, on
> the other hand, states quite clearly that code *cannot*
> rely on any such thing.

please see: 

clearly clarifying uninitialized variables have an INITIAL value,
and thereby regardless of that value, x ^= x is then correspondingly
well defined as the language correspondingly clearly defines the
semantics of the expression independently of it's variable argument
values whether they may be apriority determinate or otherwise.

your corresponding supporting standard citation to the contrary?

Re: Signed int overflow behavior in the security context

[Paul Jarc]

Paul Schlie <[EMAIL PROTECTED]> wrote:
> your corresponding supporting standard citation to the contrary?

C99 3.17.2 defines "indeterminate value" as "either an unspecified
value or a trap representation".  6.2.6.1p5 says of trap
representations: "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."  Possibly other parts of
the standard also also make it undefined behavior to access an
uninitialized character-type variable; I haven't looked too closely.


paul

build failure, gcc-4.3-20070126 snapshot, cygwin

[tbp]

[ -f stage_final ] || echo stage3 > stage_final
make[1]: Entering directory `/cygdrive/d/src/gcc/gcc-4.3-20070126/yo'
make[2]: Entering directory `/cygdrive/d/src/gcc/gcc-4.3-20070126/yo'
make[3]: Entering directory `/cygdrive/d/src/gcc/gcc-4.3-20070126/yo'
rm -f stage_current
make[3]: Leaving directory `/cygdrive/d/src/gcc/gcc-4.3-20070126/yo'
make[2]: Leaving directory `/cygdrive/d/src/gcc/gcc-4.3-20070126/yo'
make[2]: Entering directory `/cygdrive/d/src/gcc/gcc-4.3-20070126/yo'
make[3]: Entering directory `/cygdrive/d/src/gcc/gcc-4.3-20070126/yo/libiberty'
make[4]: Entering directory
`/cygdrive/d/src/gcc/gcc-4.3-20070126/yo/libiberty/testsuite'
make[4]: Nothing to be done for `all'.
make[4]: Leaving directory
`/cygdrive/d/src/gcc/gcc-4.3-20070126/yo/libiberty/testsuite'
make[3]: Leaving directory `/cygdrive/d/src/gcc/gcc-4.3-20070126/yo/libiberty'
make[3]: Entering directory `/cygdrive/d/src/gcc/gcc-4.3-20070126/yo/intl'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory `/cygdrive/d/src/gcc/gcc-4.3-20070126/yo/intl'
make[3]: Entering directory
`/cygdrive/d/src/gcc/gcc-4.3-20070126/yo/build-i686-pc-cygwin/libiberty'
make[4]: Entering directory
`/cygdrive/d/src/gcc/gcc-4.3-20070126/yo/build-i686-pc-cygwin/libiberty/testsuite'
make[4]: Nothing to be done for `all'.
make[4]: Leaving directory
`/cygdrive/d/src/gcc/gcc-4.3-20070126/yo/build-i686-pc-cygwin/libiberty/testsuite'
make[3]: Leaving directory
`/cygdrive/d/src/gcc/gcc-4.3-20070126/yo/build-i686-pc-cygwin/libiberty'
make[3]: Entering directory
`/cygdrive/d/src/gcc/gcc-4.3-20070126/yo/build-i686-pc-cygwin/fixincludes'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory
`/cygdrive/d/src/gcc/gcc-4.3-20070126/yo/build-i686-pc-cygwin/fixincludes'
make[3]: Entering directory `/cygdrive/d/src/gcc/gcc-4.3-20070126/yo/libcpp'
test -f config.h || (rm -f stamp-h1 && make stamp-h1)
make[3]: Leaving directory `/cygdrive/d/src/gcc/gcc-4.3-20070126/yo/libcpp'
make[3]: Entering directory
`/cygdrive/d/src/gcc/gcc-4.3-20070126/yo/libdecnumber'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory
`/cygdrive/d/src/gcc/gcc-4.3-20070126/yo/libdecnumber'
make[3]: Entering directory `/cygdrive/d/src/gcc/gcc-4.3-20070126/yo/gcc'
make[3]: Leaving directory `/cygdrive/d/src/gcc/gcc-4.3-20070126/yo/gcc'
Checking multilib configuration for libgcc...
make[3]: Entering directory
`/cygdrive/d/src/gcc/gcc-4.3-20070126/yo/i686-pc-cygwin/libgcc'
# If this is the top-level multilib, build all the other
# multilibs.
make[4]: Entering directory
`/cygdrive/d/src/gcc/gcc-4.3-20070126/yo/i686-pc-cygwin/libgcc'
if [ -z "" ]; then \
  true; \
else \
  rootpre=`${PWDCMD-pwd}`/; export rootpre; \
  srcrootpre=`cd ../../../libgcc; ${PWDCMD-pwd}`/; export srcrootpre; \
  lib=`echo ${rootpre} | sed -e 's,^.*/\([^/][^/]*\)/$,\1,'`; \
  compiler="/cygdrive/d/src/gcc/gcc-4.3-20070126/yo/./gcc/xgcc
-B/cygdrive/d/src/gcc/gcc-4.3-20070126/yo/./gcc/
-B/usr/local/gcc-4.3-20070126/i686-pc-cygwin/bin/
-B/usr/local/gcc-4.3-20070126/i686-pc-cygwin/lib/ -isystem
/usr/local/gcc-4.3-20070126/i686-pc-cygwin/include -isystem
/usr/local/gcc-4.3-20070126/i686-pc-cygwin/sys-include"; \
  for i in `${compiler} --print-multi-lib 2>/dev/null`; do \
dir=`echo $i | sed -e 's/;.*$//'`; \
if [ "${dir}" = "." ]; then \
  true; \
else \
  if [ -d ../${dir}/${lib} ]; then \
flags=`echo $i | sed -e 's/^[^;]*;//' -e 's/@/ -/g'`; \
if (cd ../${dir}/${lib}; make "AR=ar" "AR_FLAGS=rc"
"CC=/cygdrive/d/src/gcc/gcc-4.3-20070126/yo/./gcc/xgcc
-B/cygdrive/d/src/gcc/gcc-4.3-20070126/yo/./gcc/
-B/usr/local/gcc-4.3-20070126/i686-pc-cygwin/bin/
-B/usr/local/gcc-4.3-20070126/i686-pc-cygwin/lib/ -isystem
/usr/local/gcc-4.3-20070126/i686-pc-cygwin/include -isystem
/usr/local/gcc-4.3-20070126/i686-pc-cygwin/sys-include" "CFLAGS=-g
-fkeep-inline-functions" "DESTDIR=" "EXTRA_OFILES=" "HDEFINES="
"INSTALL=/usr/bin/install -c" "INSTALL_DATA=/usr/bin/install -c -m
644" "INSTALL_PROGRAM=/usr/bin/install -c" "LDFLAGS=" "LOADLIBES="
"RANLIB=ranlib" "SHELL=/bin/sh" "prefix=/usr/local/gcc-4.3-20070126"
"exec_prefix=/usr/local/gcc-4.3-20070126"
"libdir=/usr/local/gcc-4.3-20070126/lib"
"libsubdir=/usr/local/gcc-4.3-20070126/lib/gcc/i686-pc-cygwin/4.3.0"
"tooldir=/usr/local/gcc-4.3-20070126/i686-pc-cygwin" \
CFLAGS="-g -fkeep-inline-functions ${flags}" \
CCASFLAGS=" ${flags}" \
FCFLAGS=" ${flags}" \
FFLAGS=" ${flags}" \
ADAFLAGS=" ${flags}" \
prefix="/usr/local/gcc-4.3-20070126" \
exec_prefix="/usr/local/gcc-4.3-20070126" \
GCJFLAGS=" ${flags}" \
CXXFLAGS="-g -O2  ${flags}" \
   

Re: Signed int overflow behavior in the security context

[Paul Schlie]

> Paul Jarc wrote:
>> Paul Schlie <[EMAIL PROTECTED]> wrote:
>> your corresponding supporting standard citation to the contrary?
> 
> C99 3.17.2 defines "indeterminate value" as "either an unspecified
> value or a trap representation".  6.2.6.1p5 says of trap
> representations: "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."  Possibly other parts of
> the standard also also make it undefined behavior to access an
> uninitialized character-type variable; I haven't looked too closely.

- an lvalue expression is the target expression of an assignment, and
thereby if it has an indeterminate value, it's sensible that it's
semantics are undefined, as in effect it specifies value is being
assigned to an indeterminate storage location (which obviously isn't
a good or determinate thing to do; but has no bearing on an rvalue
access to a well defined storage location returning an indeterminate
value). i.e. lvalue = rvalue :: known_location = indeterminate_value;
or in the case of x ^= x :: known_location = x_value ^ x_value :: 0.

Re: Signed int overflow behavior in the security context

[Paul Schlie]

> Paul Jarc wrote:
>> Paul Schlie <[EMAIL PROTECTED]> wrote:
>> your corresponding supporting standard citation to the contrary?
> 
> C99 3.17.2 defines "indeterminate value" as "either an unspecified
> value or a trap representation".  6.2.6.1p5 says of trap
> representations: "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."  Possibly other parts of
> the standard also also make it undefined behavior to access an
> uninitialized character-type variable; I haven't looked too closely.

- an lvalue expression is the target expression of an assignment, and
thereby if it has an indeterminate value, it's sensible that it's
semantics are undefined, as in effect it specifies value is being
assigned to an indeterminate storage location (which obviously isn't
a good or determinate thing to do; but has no bearing on an rvalue
access to a well defined storage location returning an indeterminate
value). i.e. lvalue = rvalue :: known_location = indeterminate_value;
or in the case of x ^= x :: known_location = x_value ^ x_value :: 0.

(sorry, or more generally an lvalue expression represent a storage
location designation, either source or target, which if indeterminate
doesn't arguably have a reasonably well specified behavior; which isn't
the case with x ^= x, where all storage location designations are well
defined)