Re: Signed int overflow behavior in the security context
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
Re: Signed int overflow behavior in the security context
Paul Schlie <[EMAIL PROTECTED]> wrote: > if it has an indeterminate value [...] has no bearing on an rvalue > access to a well defined storage location You might think so, but that's actually not true in the C standard's terminology. It sounds like you interpret "indeterminate value" to mean what the standard defines as "unspecified value" (3.17.3): "valid value of the relevant type where this International Standard imposes no requirements on which value is chosen in any instance". But "indeterminate value" is defined differently (3.17.2), and any reasoning based on your common-sense understanding of the term, instead of the standard's definition of it, has no relevance to the standard. The standard is not intuitive; it can only be understood by careful reading. The key concept that you seem to be missing is trap representations. See 6.2.6.1p5, also keeping in mind that "lvalue", as used in the standard, probably means something slightly different from what you might expect; see 6.3.2.1p1. paul
Re: Signed int overflow behavior in the security context
Paul Schlie <[EMAIL PROTECTED]> wrote: > x = x ; perfectly fine; as lvaue x clearly designates an object (no trap) Can you cite the part of the standard that says that? The fact that an expression designates an object does not exclude that object from holding a trap representation. A trap representation, as defined by the standard (6.2.6.1p5), is unrelated to dereferencing an invalid pointer. The word "trap" is also sometimes used to refer to dereferencing an invalid pointer, but that's not relevant here, since the standard uses a different definition. paul
Re: Signed int overflow behavior in the security context
Paul Schlie <[EMAIL PROTECTED]> wrote: > One can only hope that the recommendations won't see the light of day in > their present form, as it's fairly clear that once an unspecified value is > read (presuming absents of a trap representation), it becomes logically > visible, and thereby clearly no longer logically indeterminate. An unspecified value was never indeterminate in the first place. The terms are not synonymous. And an object holding an indeterminate value does not stop being indeterminate when its value is read; reading it invokes undefined behavior. This is true Because The Standard Says So, no matter how illogical it may seem. > presuming absents of any possibility of a trap representation for a > given implementation That's an unreliable presumption. As noted in the defect report, a trap representation can have the same bit pattern as a valid value. Trapness depends not just on the bit pattern, but also how the bit pattern was produced. So even if there are no hardware-level traps, if you read an indeterminate object, a compiler is allowed to produce the same behavior as if there were hardware-level traps. > (as the undefined behavior referenced in the DR is related to a pointer > becoming indeterminate *Some* of the DR relates to pointers. But reading the value of any object (pointer or otherwise) holding a trap representation invokes undefined behavior. paul
Re: Signed int overflow behavior in the security context
Paul Schlie <[EMAIL PROTECTED]> wrote: > Paul Jarc wrote: >> As noted in the defect report, a trap representation can have the >> same bit pattern as a valid value. Trapness depends not just on >> the bit pattern, but also how the bit pattern was produced. > > - that's not what is says Did you read it? # Implementations are permitted to track the origins of a bit-pattern # and treat those representing an indeterminate value as distinct from # those representing a determined value. > a pointer value may be/become a trap representation [...] That is also true, but there is more than that. > is required to be well specified [...] as otherwise the language > couldn't be utilized to write even the most hardware drivers > required of all computer systems. In a sense, the language *can't* be used to write most hardware drivers. Drivers do invoke undefined behavior - that is, the standard makes no guarantees about their behavior - but the particular platform they are targeted for makes its own guarantees, so the code is still useful, even though it is not strictly conforming C. paul
Re: GCC 4.0 RC1 Available
gcc/doc/install.texi still mentions gcc 3.5 in a few places. paul
Re: Suggestion
"YaniMan" <[EMAIL PROTECTED]> wrote: > Or these messages should going (by an option) to the stdout rather than > stderr, so i can write a parser (gcc a.c | myparser) to convert the > messages. gcc a.c 2>&1 | myparser >&2 paul
finding gcc's installation prefix
To find gcc's installation prefix, I've been using
"gcc -print-search-dirs". That worked up until 4.3, but now gcc
chases symlinks so it can print symlink-free paths. What I want is
the installation path just as it was spelled in
"./configure --prefix=...". In my case, that spelling is an absolute
path with no .. elements or superfluous slashes, but it does have
symlinks. Is there any way to get that with gcc 4.3? If not, this
patch seems to restore the behavior I want, but will it have any
harmful consequences?
--- gcc/gcc.c 2008-03-02 17:54:56.0 -0500
+++ gcc/gcc.c 2008-11-13 00:29:45.0 -0500
@@ -3413,7 +3413,7 @@
/* FIXME: make_relative_prefix doesn't yet work for VMS. */
if (!gcc_exec_prefix)
{
- gcc_exec_prefix = make_relative_prefix (argv[0], standard_bindir_prefix,
+ gcc_exec_prefix = make_relative_prefix_ignore_links (argv[0],
standard_bindir_prefix,
standard_exec_prefix);
gcc_libexec_prefix = make_relative_prefix (argv[0],
standard_bindir_prefix,
Re: BOOT_CFLAGS coverage
Jack Howarth wrote: > make -j 8 profiledbootstrap BOOT_CFLAGS="-g -O3" > > I noticed the absence of these flags being utilized in libdecnumber, > libffi, libgcc, etc. On a related note, how can I pass *linker* flags for linking libgcc? I've passed --with-stage1-ldflags and --with-boot-ldflags to ./configure, and I've passed LDFLAGS_FOR_TARGET and BOOT_LDFLAGS to make, but none of those seem to get used when building libgcc_s.so.1 (or libgcj_bs.so.1.0.0). I even tried editing gcc/Makefile.in, in the rule for libgcc.mvars. I changed the SHLIB_LINK line to: echo SHLIB_LINK = '$(subst $(GCC_FOR_TARGET) ...my-flags-here...,$$(GCC_FOR_TARGET),$(SHLIB_LINK))' >> tmp-libgcc.mvars This change gets propagated into gcc/Makefile, but somehow when libgcc.mvars is created, my flags don't appear there. paul
Re: BOOT_CFLAGS coverage
Ian Lance Taylor wrote: > LDFLAGS_FOR_TARGET is the one that should be used. However, you're > right that it doesn't appear to happen. This is a bug. ... > I think you need to edit the file gcc/config/t-slibgcc-elf-ver. Thanks--adding $(LDFLAGS_FOR_TARGET) to SHLIB_LINK in that file seems to work. paul
Re: Passing LDFLAGS to stage2 and stage3 gcc
Rainer Emrich <[EMAIL PROTECTED]> wrote: > So I wan't to pass LDFLAGS="-Wl, -rpath, /somedir" to stage3 to link gcc, cpp, > etc. with the rpath information. I do this by editing LDFLAGS_FOR_TARGET in the top-level Makefile.in, and also passing LDFLAGS, BOOT_LDFLAGS, and HOST_LDFLAGS assignments as arguments to make. I'm not cross-compiling, though, so you may have to adjust that somewhat. paul
Re: GCC 4.2.0 Status Report (2007-05-11)
Sorry to bring this up so late, but I just tried building the last 4.2.0 prerelease and hit what seems to be a build bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31906 paul
Re: GCC 4.2.0 Status Report (2007-05-11)
Joe Buck <[EMAIL PROTECTED]> wrote: > I don't even think this qualifies as a bug. It's basically an > enhancement request, to have a clean way of supporting glibc in > an unusual place. It works in previous versions going back to 2.95.3, so I'd think it would be a bug, and a regression. But since this is such a rare circumstance, I wouldn't expect it to be a release-blocker. I brought it up only in the hope that it might be transparent to someone and fixed before the release, but I certainly understand if it isn't. paul
Re: GCC 4.2.0 Status Report (2007-05-11)
Joe Buck <[EMAIL PROTECTED]> wrote: > But this was never a documented, supported way of doing things; > nothing that involves hand-editing could be. Fair enough, as far as my particular case is concerned. But something new in 4.2 is inserting "-Xcompiler" between "-Xlinker" and the following argument. It may be that this insertion can be triggered in other ways that don't involve hand-editing, which would make it definitely a bug. So this is not known to be a bug, but also not known to not be a bug. > Maybe there could be something like --with-libc=/some/path that > would automatically generate the correct Makefiles; that would be an > enhancement. Yes, although a more general enhancement would be to let the user add arbitrary flags to LDFLAGS_FOR_TARGET. paul
