Re: [vox-tech] C - passing chars and pointer to chars
On Sun, 4 Jun 2006 13:29:08 -0400 [EMAIL PROTECTED] (Peter Jay Salzman) wrote: > the "value" of i and j is the same "value" as c. the only provisio > is how that value is interpreted. since i and j are both signed > ints, when you print them with printf() or cout, the pattern will be > interpreted as an unsigned int, that is, 255. not -1. > > to summarize, someFunction() doesn't change the value of c. If the compiler treats native char as unsigned: i will be 0x00ff or 255. j will be 0x00ff or 255. If the compiler treats native char as signed: i will be 0x or -1. j will be 0x00ff or 255. That's because when it converts -1 from a signed char (8-bit) to a signed int (16 bit or larger, I'm assuming native 32 bit here, but it doesn't matter) it does a sign extend. When you pass an unsigned pointer and cast it as a signed pointer you treat the value in the variable differently. Shrug it off if you will, but -1 and 255 are VERY different values. Treating them as the same can cause some real headaches. Depending on one native implementation and then porting to another platform that might have a different implementation can cause some pretty bad headaches too, because things that worked just fine suddenly break for no obvious reason. (For example, expecting a native 16-bit integer to wrap above 0x and then porting to an implementation that uses native 32-bit integer. And if that sounds like the voice of experience talking, well, it is. :) THAT is why char * and unsigned char * and signed char * are three entirely different animals and should be treated as such. And when you DO figure out the reason you spend the next month sifting through the code trying to find all the instances of native whatever and trying to determine whether each one needs to be changed to explicit signed, unsigned, short, long, and so on. That's why I like to be explicit up front. And I would not use printf()'s behaviour as the only yardstick for this issue. ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] C - passing chars and pointer to chars
On Sun, Jun 04, 2006 at 05:52:34PM -0500, Ken Bloom wrote: > On Sunday 04 June 2006 13:58, Micah J. Cowan wrote: > > On Sun, Jun 04, 2006 at 09:57:18AM -0500, Ken Bloom wrote: > > > On Sunday 04 June 2006 09:05, Peter Jay Salzman wrote: > > > > On Sat 03 Jun 06, 10:27 PM, Ken Bloom <[EMAIL PROTECTED]> said: > > > > > Cue, the **Fundemental axiom of the C++ type system**, stated > > > > > as follows: > > > > > A* is automaitcally convertable to B* if and only if A is a > > > > > B. (Likewise for pass by reference). > > > > > > > > > > (this is my own generalization though, and there may actually > > > > > be exceptions) > > > > > > > > Although this was interesting to read, it doesn't say much other > > > > than to restate my observation in a more sophisticated way. > > > > > > IMO, all that matters is that the axiom is the reason. > > > > Except the axiom is rather far from the truth, only an ideal. > > > > C++ is more strongly typed than C. I am not a language theorist, but > > I believe it is still not considered "strongly typed". > > > > The ability to silently convert from int to char (your compiler might > > actually complain about it in some circumstances: a compiler is > > allowed to complain about whatever the hell it wants, but there's no > > requirement to here, and in most cases, it won't) illustrates one > > exception, certainly. > > That's not an IS_A relationship. That's automatic conversion. That was exactly my point. However, on looking back, I misread your axiom to say "A is automatically convertable to B if and only if..." My bad. -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] C - passing chars and pointer to chars
On Sunday 04 June 2006 13:58, Micah J. Cowan wrote: > On Sun, Jun 04, 2006 at 09:57:18AM -0500, Ken Bloom wrote: > > On Sunday 04 June 2006 09:05, Peter Jay Salzman wrote: > > > On Sat 03 Jun 06, 10:27 PM, Ken Bloom <[EMAIL PROTECTED]> said: > > > > Cue, the **Fundemental axiom of the C++ type system**, stated > > > > as follows: > > > > A* is automaitcally convertable to B* if and only if A is a > > > > B. (Likewise for pass by reference). > > > > > > > > (this is my own generalization though, and there may actually > > > > be exceptions) > > > > > > Although this was interesting to read, it doesn't say much other > > > than to restate my observation in a more sophisticated way. > > > > IMO, all that matters is that the axiom is the reason. > > Except the axiom is rather far from the truth, only an ideal. > > C++ is more strongly typed than C. I am not a language theorist, but > I believe it is still not considered "strongly typed". > > The ability to silently convert from int to char (your compiler might > actually complain about it in some circumstances: a compiler is > allowed to complain about whatever the hell it wants, but there's no > requirement to here, and in most cases, it won't) illustrates one > exception, certainly. That's not an IS_A relationship. That's automatic conversion. --Ken -- I usually have a GPG digital signature included as an attachment. See http://www.gnupg.org/ for info about these digital signatures. pgpjVhb1MkpIZ.pgp Description: PGP signature ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] C - passing chars and pointer to chars
On Sun, Jun 04, 2006 at 09:57:18AM -0500, Ken Bloom wrote: > On Sunday 04 June 2006 09:05, Peter Jay Salzman wrote: > > On Sat 03 Jun 06, 10:27 PM, Ken Bloom <[EMAIL PROTECTED]> said: > > > Cue, the **Fundemental axiom of the C++ type system**, stated as > > > follows: > > > A* is automaitcally convertable to B* if and only if A is a B. > > > (Likewise for pass by reference). > > > > > > (this is my own generalization though, and there may actually be > > > exceptions) > > > > > Although this was interesting to read, it doesn't say much other than > > to restate my observation in a more sophisticated way. > > IMO, all that matters is that the axiom is the reason. Except the axiom is rather far from the truth, only an ideal. C++ is more strongly typed than C. I am not a language theorist, but I believe it is still not considered "strongly typed". The ability to silently convert from int to char (your compiler might actually complain about it in some circumstances: a compiler is allowed to complain about whatever the hell it wants, but there's no requirement to here, and in most cases, it won't) illustrates one exception, certainly. The reality, though, isn't far from what you state: "all that matters is that the Standard is the reason". If the Standard dictates you must issue a diagnostic when such-and-such is attempted, by golly, you will (except that historically, GCC has ignored this when they "don't feel like it"; thus the reason for the -pedantic switch). -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] C - passing chars and pointer to chars
On Sun, Jun 04, 2006 at 10:05:22AM -0400, Peter Jay Salzman wrote: > I gave good reasons *why* passing the pointers should always work. I think > Micah really got at the heart of the matter: > > >Micah said: >Pointers to incompatible types are not guaranteed to be represented the >same way, even though in practice they are. /All/ pointer types must be >convertible to and from a pointer to any character type, and used as >such, so this makes it all the more likely that they will be represented >the same. > >Irregardless, the Standard does /require/ that a warning be given when >you try to do this. > > > I think the main point is the lack of guarantee that they're represented > the same way. Here's what I think he means. > > I *think* what Micah is saying here is that even though a char and signed > char types have the same width (1 byte) and are implemented the same way in > practise, there's no guarantee that they *are* implemented the same way. Actually, no: char and signed char /must/ be represented the same way, if char is signed. > For example, a perverse compiler writer may put a byte of dead storage (for > whatever reason) in between contiguous elements of a char array and 2 bytes > of dead storage in between contiguous elements of a signed char array. Well, no, it couldn't. At the very least, you must be able to convert a pointer to /anything/ to a pointer to character type, and be able to inspect the byte values in that way. I was actually talking about the fact that the /pointer/ types don't have to be represented the same way. A compiler could represent signed char pointers as a value bit-shifted two to the left, whereas a pointer to char could be a bitwise complement of the same value. Not likely, but basically, the Standard committee don't want you just passing stuff around in general without first declaring, "I know what the hell I'm doing" (via a cast). -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] C - passing chars and pointer to chars
On Sun 04 Jun 06, 8:02 AM, Jeffrey J. Nonken <[EMAIL PROTECTED]> said:
>
> unsigned char c = 255;
> signed int i;
> signed int j;
>
> signed int someFunction(char * nativeChar)
> {
> return(&nativeChar);
> }
>
>
> i = someFunction(*c);
> j = c;
>
>
> (I'm extremely rusty on my c pointer syntax and don't have a book handy,
> I'm trying to pass a pointer to "c" and return "c" converted to signed
> integer. I hope I didn't screw that up too badly.) Assume for the
> moment the compilers don't complain about the different pointer types.
>
> Compiler #1 treats native char type as unsigned.
> Compiler #2 treats native char type as signed.
>
> When you switch from compiler #1 to compiler #2:
> What happens to the value of i?
> What happens to the value of j?
the pointer syntax is a bit mangled, but that's ok. the gods created java
for people who can't get their pointer stuff straight. ;-)
both i and j will equal 255. the interpretation of a set of bits is
independent of the set of bits.
when you pass the bit pattern that corresponds to 255 to someFunction(), the
bit pattern doesn't change, even though someFunction() takes a char. BTW,
on x86, char almost always means "signed char" but this is platform
dependent. but this doesn't even matter since the width of a char is the
same as the width of a signed char which is the same as the width of an
unsigned char.
the "value" of i and j is the same "value" as c. the only provisio is how
that value is interpreted. since i and j are both signed ints, when you
print them with printf() or cout, the pattern will be interpreted as an
unsigned int, that is, 255. not -1.
to summarize, someFunction() doesn't change the value of c.
pete
___
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] C - passing chars and pointer to chars
On Fri, 2 Jun 2006 11:31:43 -0400
[EMAIL PROTECTED] (Peter Jay Salzman) wrote:
> What I'm getting at is this. Because all the chars have the same
> width, it doesn't matter WHAT kind of pointer you pass in to a
> function: char, signed char, or unsigned char. Pointer arithmetic
> just works, and it works because they all have the same width.
>
> On the other hand, the data is what gets mangled if you don't use the
> correct type:
>
>char c = 255;
>printf("%d", c);
>
> prints, as expected, -1. Not 255.
>
> So it seems to me that if the compiler complains about anything, it
> should complain about passing a different type of char, not a
> different type of char *.
unsigned char c = 255;
signed int i;
signed int j;
signed int someFunction(char * nativeChar)
{
return(&nativeChar);
}
i = someFunction(*c);
j = c;
(I'm extremely rusty on my c pointer syntax and don't have a book handy,
I'm trying to pass a pointer to "c" and return "c" converted to signed
integer. I hope I didn't screw that up too badly.) Assume for the
moment the compilers don't complain about the different pointer types.
Compiler #1 treats native char type as unsigned.
Compiler #2 treats native char type as signed.
When you switch from compiler #1 to compiler #2:
What happens to the value of i?
What happens to the value of j?
___
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] C - passing chars and pointer to chars
On Sunday 04 June 2006 10:28, Peter Jay Salzman wrote: > On Sun 04 Jun 06, 9:57 AM, Ken Bloom <[EMAIL PROTECTED]> said: > > On Sunday 04 June 2006 09:05, Peter Jay Salzman wrote: > > > On Sat 03 Jun 06, 10:27 PM, Ken Bloom <[EMAIL PROTECTED]> said: > > > > Cue, the **Fundemental axiom of the C++ type system**, stated > > > > as follows: > > > > A* is automaitcally convertable to B* if and only if A is a > > > > B. (Likewise for pass by reference). > > > > > > > > (this is my own generalization though, and there may actually > > > > be exceptions) > > > > > > Although this was interesting to read, it doesn't say much other > > > than to restate my observation in a more sophisticated way. > > > > IMO, all that matters is that the axiom is the reason. > > > > --Ken > > BTW, you mentioned that it was a generalization of the fundamental > axiom of the C++ type system -- what is the fundamental axiom? That > sounds like something I should know, but I've never heard of it. Oh. I didn't make that comment easy to parse, did I. The "fundemental axiom" is something I just named, based on observing this kind of behavior throughout the language. > BTW, "void *" seems to be an exception to the axiom: Maybe everything is a void. > Herr Godel would say that this type of thinking is why it took > humanity over 2000 years to discover non-Euclidean geometry. ;-) There are other languages that break the axiom, but they're just that: other languages. --Ken -- I usually have a GPG digital signature included as an attachment. See http://www.gnupg.org/ for info about these digital signatures. pgpz0E3y5Lp5l.pgp Description: PGP signature ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] gcc and quieting warnings
On Sun 04 Jun 06, 10:30 AM, Ken Bloom <[EMAIL PROTECTED]> said: > > Your problem isn't -Wall. It's -W (now called -Wextra) > > from the man page: > The following -W... options are not implied by -Wall. Some of them > warn about constructions that users generally do not consider question- > able, but which occasionally you might wish to check for; others warn > about constructions that are necessary or hard to avoid in some cases, > and there is no simple way to modify the code to suppress the warning. > > -Wextra > (This option used to be called -W. The older name is still sup- > ported, but the newer name is more descriptive.) Print extra warn- > ing messages for these events: > [...] > * If -Wall or -Wunused is also specified, warn about unused argu- > ments. > [...] > > It seems to me that the following happens: > -Wextra alone doesn't warn you about unused parameters. > -Wall alone doesn't warn you about unused parameters. > -Wall -Wextra does warn you about unused parameters. > > Sad thing is most of the other conditions that -Wextra -Wall give you > seem to be worth checking for. > > --Ken That's really too bad. I think something like splint's annotations would be useful, especially in the early stages of a program's development when you compile the program often, not necessarily to run the program, but to make sure there are no "obvious" syntax errors as you code. Oh well. Thanks for the info! Pete ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] gcc and quieting warnings
On Sunday 04 June 2006 08:29, Peter Jay Salzman wrote:
> On Sat 03 Jun 06, 10:56 PM, Ken Bloom <[EMAIL PROTECTED]> said:
> > On Friday 02 June 2006 10:53, Peter Jay Salzman wrote:
> > > I always use -W -Wall when I compile code. However, sometimes, I
> > > want gcc to ignore certain instances of a warning. For example,
> > > in something like a stub function, or a signal callback, or even
> > > an API function that doesn't use all the parameters, like:
> > >
> > >JNIEXPORT void JNICALL
> > >Java_HelloWorld_print( JNIEnv *env, jobject obj )
> > >{
> > > printf("Hello World!\n");
> > > return;
> > >}
> > >
> > > gcc of course complains about unused parameters. Of course, I
> > > *could* simply not use -W -Wall, but I don't want to NOT use -W
> > > -Wall just because I haven't gotten around to finishing a stub
> > > function. Besides, active development is the best time to turn on
> > > compiler warnings.
> > >
> > > I also assume there's a gcc -Wfno-unused-parameter (or something
> > > similar to this). But again, I don't want to turn off the check
> > > for the entire program just because of one or two functions.
> > >
> > > In splint/lclint/lint, "annotations" are used to shut the checker
> > > up for cases where you don't want it to check a semantic. I
> > > don't know the exact syntax, but it looks something like:
> > >
> > >FILE *fp;
> > >if ( (fp = fopen("foo", "r")) != NULL )
> > > f( fp );
> > >fclose( fp ); /* @NO NULL CHECK@ */
> > >
> > > and splint won't complain about the fact that fp may become
> > > uninitialized or corrupt after passing passing it to f(). The
> > > annotations are what make splint even remotely useful, otherwise
> > > I'd be reading warnings all day long.
> > >
> > > Does gcc have something similar? Some way of telling the
> > > compiler to ignore a certain type of warning at a certain point
> > > in the code?
> > >
> > > I tried doing a search for "annotation" in the behemoth gcc info
> > > page, but no dice. I wouldn't know what else to call it.
> >
> > What version of G++ are you using?
> >
> > [EMAIL PROTECTED] ~]$ g++ --version
> > g++ (GCC) 4.0.4 20060507 (prerelease) (Debian 4.0.3-3)
> > Copyright (C) 2006 Free Software Foundation, Inc.
> > This is free software; see the source for copying conditions.
> > There is NO
> > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
> > PURPOSE.
> >
> > [EMAIL PROTECTED] ~]$ cat test.cpp
> > void foo(int a){
> >
> > }
> >
> > int main(){
> >foo(1);
> >return 0;
> > }
> > [EMAIL PROTECTED] ~]$ g++ -Wall -o test test.cpp
> > [EMAIL PROTECTED] ~]$ g++ -Wall -Wunused -o test test.cpp
> > [EMAIL PROTECTED] ~]$ g++ -Wall -Wunused-parameter -o test
> > test.cpp test.cpp:1: warning: unused parameter ‘a’
> >
> > It seems that in g++ 4.0 -Wall implies -Wunused, which in turn
> > implies -Wunused-variable -Wunused-label -Wunused-function, but
> > does not imply -Wunused-parameter.
> >
> > --Ken
>
> [EMAIL PROTECTED] cat foo.c
> void f(int env, int obj)
> {
>return;
> }
> [EMAIL PROTECTED] gcc -c -W -Wall foo.c
> foo.c:1: warning: unused parameter ‘env’
> foo.c:1: warning: unused parameter ‘obj’
>
> tan$ gcc -v
> Using built-in specs.
> Target: i486-linux-gnu
> Configured with: ../src/configure -v
> --enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr
> --enable-shared --with-system-zlib --libexecdir=/usr/lib
> --without-included-gettext --enable-threads=posix --enable-nls
> --program-suffix=-4.0 --enable-__cxa_atexit --enable-clocale=gnu
> --enable-libstdcxx-debug --enable-java-awt=gtk-default
> --enable-gtk-cairo
> --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre
> --enable-mpfr --disable-werror --with-tune=i686
> --enable-checking=release i486-linux-gnu Thread model: posix
> gcc version 4.0.4 20060507 (prerelease) (Debian 4.0.3-3)
Your problem isn't -Wall. It's -W (now called -Wextra)
from the man page:
The following -W... options are not implied by -Wall. Some of them
warn about constructions that users generally do not consider question-
able, but which occasionally you might wish to check for; others warn
about constructions that are necessary or hard to avoid in some cases,
and there is no simple way to modify the code to suppress the warning.
-Wextra
(This option used to be called -W. The older name is still sup-
ported, but the newer name is more descriptive.) Print extra warn-
ing messages for these events:
[...]
* If -Wall or -Wunused is also specified, warn about unused argu-
ments.
[...]
It seems to me that the following happens:
-Wextra alone doesn't warn you about unused parameters.
-Wall alone doesn't warn you about unused parameters.
-Wall -Wextra does warn you about unused parameters.
Sad thing is most of the other conditions that -Wextra -Wall give you
seem to be worth checking for.
--Ken
--
I usually have a GPG digital signature included as an attachment.
See http://www.gnupg.o
Re: [vox-tech] C - passing chars and pointer to chars
On Sun 04 Jun 06, 9:57 AM, Ken Bloom <[EMAIL PROTECTED]> said:
> On Sunday 04 June 2006 09:05, Peter Jay Salzman wrote:
> > On Sat 03 Jun 06, 10:27 PM, Ken Bloom <[EMAIL PROTECTED]> said:
> > > Cue, the **Fundemental axiom of the C++ type system**, stated as
> > > follows:
> > > A* is automaitcally convertable to B* if and only if A is a B.
> > > (Likewise for pass by reference).
> > >
> > > (this is my own generalization though, and there may actually be
> > > exceptions)
>
> >
> > Although this was interesting to read, it doesn't say much other than
> > to restate my observation in a more sophisticated way.
>
> IMO, all that matters is that the axiom is the reason.
>
> --Ken
Herr Godel would say that this type of thinking is why it took humanity over
2000 years to discover non-Euclidean geometry. ;-)
BTW, "void *" seems to be an exception to the axiom:
[EMAIL PROTECTED] cat bar.c
void f( void *b );
int main( void )
{
int a;
f( &a );
return 0;
}
[EMAIL PROTECTED] gcc -W -Wall -c bar.c
[EMAIL PROTECTED]
A "int *" is convertable to "void *" even though an int isn't a void. There
is no data type of "void" (I think), but it's still a counter example.
BTW, you mentioned that it was a generalization of the fundamental axiom of
the C++ type system -- what is the fundamental axiom? That sounds like
something I should know, but I've never heard of it.
Pete
___
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] C - passing chars and pointer to chars
On Sunday 04 June 2006 09:05, Peter Jay Salzman wrote: > On Sat 03 Jun 06, 10:27 PM, Ken Bloom <[EMAIL PROTECTED]> said: > > Cue, the **Fundemental axiom of the C++ type system**, stated as > > follows: > > A* is automaitcally convertable to B* if and only if A is a B. > > (Likewise for pass by reference). > > > > (this is my own generalization though, and there may actually be > > exceptions) > > Although this was interesting to read, it doesn't say much other than > to restate my observation in a more sophisticated way. IMO, all that matters is that the axiom is the reason. --Ken -- I usually have a GPG digital signature included as an attachment. See http://www.gnupg.org/ for info about these digital signatures. pgp0FjnA7PkqL.pgp Description: PGP signature ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] C - passing chars and pointer to chars
On Sat 03 Jun 06, 10:27 PM, Ken Bloom <[EMAIL PROTECTED]> said: > > Cue, the **Fundemental axiom of the C++ type system**, stated as > follows: > A* is automaitcally convertable to B* if and only if A is a B. > (Likewise for pass by reference). > > (this is my own generalization though, and there may actually be > exceptions) > > When handling inheritance, if Derived is a Base (Derived inherits from > Base), then Derived* can be automatically converted to Base*. But a > Derived* is not a Base*, so a Derived** cannot be automatically > converted to a Base**. > > When dealing with templates, you cannot pass vector where a > vector is expected, neither by reference nor by pointer, because > vector is not a vector (because if you were to stick a > new Base into the vector, then it would violate the type of > vector). > > Supposing you wanted to create a new reference_counted_pointer. A > reference_counted_pointer is not a > reference_counted_pointer, and cannot be used as such, but you > would want to implement all of the appropriate conversions when writing > reference_counted_pointer to mimic the semantics of an ordinary > pointer. > > signed char is not an unsigned char, but they are convertable. However, > signed char * is not convertable to unsigned char *, and to force such > a conversion, you would use a reinterpret_cast<> (which reinterprets > the actual bits according to a different time), or as it seems from > Bill's post, a static_cast<> (which is generally safer when it's > allowed). > > --Ken Bloom Although this was interesting to read, it doesn't say much other than to restate my observation in a more sophisticated way. I gave good reasons *why* passing the pointers should always work. I think Micah really got at the heart of the matter: Micah said: Pointers to incompatible types are not guaranteed to be represented the same way, even though in practice they are. /All/ pointer types must be convertible to and from a pointer to any character type, and used as such, so this makes it all the more likely that they will be represented the same. Irregardless, the Standard does /require/ that a warning be given when you try to do this. I think the main point is the lack of guarantee that they're represented the same way. Here's what I think he means. I *think* what Micah is saying here is that even though a char and signed char types have the same width (1 byte) and are implemented the same way in practise, there's no guarantee that they *are* implemented the same way. For example, a perverse compiler writer may put a byte of dead storage (for whatever reason) in between contiguous elements of a char array and 2 bytes of dead storage in between contiguous elements of a signed char array. The only guarantees are: 1. a char and signed char provide only one byte of storage. 2. ++(char *) will point to the next element of a char array. 3. ++(signed char *) will point to the next element of a signed char array. and that's it. In the scenario of the perverse compiler writer, if you made a "char *" point to a "signed char" array, if you added one to the char pointer, it won't quite reach the next element of the signed char array: signed char ar[5]; char *c_ptr = ar; ++c_ptr; memory ****** char array [0] [1] [2] signed char array [0][1] ^^ || c_ptr ++c_ptr As long as each element only provides one byte of storage, and that adding one to the respective array worked, the standard will be satisfied. In practise, char and signed char arrays are always implemented as: memory ***** char array [0] [1] [2] [3] [4] signed char array [0] [1] [2] [3] [4] ^^ || c_ptr ++c_ptr but the standard doesn't guarantee this, which is why passing different types of char pointers works in practise, but is not absolutely guaranteed by the standard to work. At least, this is how I read Micah's response. Maybe it's not correct. :) If this is approximately correct, then the warning makes complete sense, even though in practise, it's not necessary. Pete ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] gcc and quieting warnings
On Sat 03 Jun 06, 10:56 PM, Ken Bloom <[EMAIL PROTECTED]> said:
> On Friday 02 June 2006 10:53, Peter Jay Salzman wrote:
> > I always use -W -Wall when I compile code. However, sometimes, I
> > want gcc to ignore certain instances of a warning. For example, in
> > something like a stub function, or a signal callback, or even an API
> > function that doesn't use all the parameters, like:
> >
> >JNIEXPORT void JNICALL
> >Java_HelloWorld_print( JNIEnv *env, jobject obj )
> >{
> > printf("Hello World!\n");
> > return;
> >}
> >
> > gcc of course complains about unused parameters. Of course, I
> > *could* simply not use -W -Wall, but I don't want to NOT use -W -Wall
> > just because I haven't gotten around to finishing a stub function.
> > Besides, active development is the best time to turn on compiler
> > warnings.
> >
> > I also assume there's a gcc -Wfno-unused-parameter (or something
> > similar to this). But again, I don't want to turn off the check for
> > the entire program just because of one or two functions.
> >
> > In splint/lclint/lint, "annotations" are used to shut the checker up
> > for cases where you don't want it to check a semantic. I don't know
> > the exact syntax, but it looks something like:
> >
> >FILE *fp;
> >if ( (fp = fopen("foo", "r")) != NULL )
> > f( fp );
> >fclose( fp ); /* @NO NULL CHECK@ */
> >
> > and splint won't complain about the fact that fp may become
> > uninitialized or corrupt after passing passing it to f(). The
> > annotations are what make splint even remotely useful, otherwise I'd
> > be reading warnings all day long.
> >
> > Does gcc have something similar? Some way of telling the compiler to
> > ignore a certain type of warning at a certain point in the code?
> >
> > I tried doing a search for "annotation" in the behemoth gcc info
> > page, but no dice. I wouldn't know what else to call it.
>
> What version of G++ are you using?
>
> [EMAIL PROTECTED] ~]$ g++ --version
> g++ (GCC) 4.0.4 20060507 (prerelease) (Debian 4.0.3-3)
> Copyright (C) 2006 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There is
> NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
> PURPOSE.
>
> [EMAIL PROTECTED] ~]$ cat test.cpp
> void foo(int a){
>
> }
>
> int main(){
>foo(1);
>return 0;
> }
> [EMAIL PROTECTED] ~]$ g++ -Wall -o test test.cpp
> [EMAIL PROTECTED] ~]$ g++ -Wall -Wunused -o test test.cpp
> [EMAIL PROTECTED] ~]$ g++ -Wall -Wunused-parameter -o test test.cpp
> test.cpp:1: warning: unused parameter ‘a’
>
> It seems that in g++ 4.0 -Wall implies -Wunused, which in turn
> implies -Wunused-variable -Wunused-label -Wunused-function, but does
> not imply -Wunused-parameter.
>
> --Ken
[EMAIL PROTECTED] cat foo.c
void f(int env, int obj)
{
return;
}
[EMAIL PROTECTED] gcc -c -W -Wall foo.c
foo.c:1: warning: unused parameter ‘env’
foo.c:1: warning: unused parameter ‘obj’
tan$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.0 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-java-awt=gtk-default --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --enable-mpfr
--disable-werror --with-tune=i686 --enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.0.4 20060507 (prerelease) (Debian 4.0.3-3)
___
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] dtd dicer toaster daemon
On Sat 03 Jun 06, 11:34 PM, Chris Horsting <[EMAIL PROTECTED]> said: > Does anyone know how to find dtd daemon? According to the documentation > of k3b my system has to start this daemon. The one or two times I used k3b, I didn't need no stinkin' daemon. Although I have zero interest in KDE or k3b, the daemon's name got me interested enough to do some Googling. All I found were people asking the same question. I'm guessing this is some kind of inside joke. I'm _so_ glad I don't use KDE. You may want to consider asking the question on the k3b mailing list (I assume one exists). I haven't been following the thread, so I don't know what your problem is, but if you find an answer, it would be good to post the solution here so Google can index it. Pete ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
[vox-tech] dtd dicer toaster daemon
Does anyone know how to find dtd daemon? According to the documentation of k3b my system has to start this daemon. ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
